[m_seger]

Hi everyone,

so here are my setups to the problem:

Setup 1
======

VIO Server with a Virtual Ethernet Adapter, with VLAN ID 10, SlotID 10,
Access external network checked and IEEE 802.3Q unchecked.
The VIO Server has a SEA Adapter configured, with a internal IP.

LPAR Client with a Virtual Ethernet Adapter, with VLAN ID 10, SlotID 10,
Access external network unchecked and IEEE 802.3Q unchecked.

PC-Client with connects from another network over a firewall to the
"P5-Network"
----------------------------------------------------------------------

Setup 2
======
LPAR Client with a Hardware NIC allocated

PC-Client with connects from another network over a firewall to the
"P5-Network"
----------------------------------------------------------------------

In Setup 1 almost everything works, I can Ping from the PC-Client to VIO and
LPAR Client and also the other way around. I am also able to ssh from the
PC-Client to VIO Server. Only if I try to ssh to the LPAR Client it takes around
90 Seconds only to get a Login Prompt, and after that another 90 secs to
be able to enter the Password and so on. If I ssh from the VIO to the LPAR
Client everything works smooth.

In Setup 2 I have no problem at all! I can ssh from the PC-Client to the LPAR
Client in no delay.


What do I have to do, to get ssh working in Setup 1?


thanks and cheers

Mike

[steevojb]

Hi,

What are your ping response times ?

Have you tried connection via telnet ?

Have you got DNS configured that doesn't know about the VIO client ? / Can the client see the DNS server (if configured)

Can you SSH from the VIO client to the LPAR with hardware NIC without any issues ?

Steve

[GFGMojo]

I used the same IP address structure as my client - same gateway - same nameserver -

I set my Clients up with Etherchannels and Etherchanneled my two VIO servers as well - on VIO servers:

$ mkvdev -lnagg ent0 ent1

$ lsdev |grep ent3
ent3 Available EtherChannel / IEEE 802.3ad Link Aggregation

So I know it worked - now

$ mkvdev -sea ent3 -vadapter ent2 -default ent2 -defaultid 1

Now I have this -

en0 Defined Standard Ethernet Network Interface
en1 Defined Standard Ethernet Network Interface
en2 Defined Standard Ethernet Network Interface
en3 Defined Standard Ethernet Network Interface
en4 Available Standard Ethernet Network Interface
ent0 Available 10/100/1000 Base-TX PCI-X Adapter (14106902)
ent1 Available 10/100/1000 Base-TX PCI-X Adapter (14106902)
ent2 Available Virtual I/O Ethernet Adapter (l-lan)
ent3 Available EtherChannel / IEEE 802.3ad Link Aggregation
ent4 Available Shared Ethernet Adapter
inet0 Available Internet Network Extension

I configured the IP Address on en4 and I'm off and running!

for the SSH part do a google search on

howto install openssh in aix

howto and openssh all one word - no spaces - then you will see a wiki.ittoolbox.com article - very informative! Check the other software required with sshd and the sshd service - prngd, zlib, and openssl - startsrc -s sshd !

Good Luck -

Lou Wilcox

[m_seger]

Thanks for your replies, but my problem is still not solved.
Well at least I am closer to the cause of it!

Now I have reproduced the problem in a simpler setting.

I took a VIO Server with a Physical(ent0) and a virtual Ethernet
Adapter (ent1, PVID 10, Access external network checked and
IEEE 802.1Q unchecked) and created a SEA adapter:

mkdev -sea ent0 -vadapter ent1 -default ent1 -defaultid 10
ent2 available
en2
et2

Then I assigned a IP Address to en2 and I could access the
VIO Server with no problem with ssh
***
After that I installed another VIO Server with a physical(ent0) and
2 virtual Ethernet Adapters (ent1 --> same as above, ent2 --> PVID 10,
Access external network and IEEE 802.1Q unchecked) and also with
a SEA Adapter:

mkdev -sea ent0 -vadapter ent1 -default ent1 -defaultid 10
ent3 available
en3
et3

Then I assigned a IP Address to the additional virt. Ethernet Adapter (ent2)
as it is documented for Performance Reasons in several HowTos

POWER5 Virtualization: How to work with VLANs using the IBM Virtual I/O Server

Now, things changed, ssh and telnet is slow as described in the first post,
but for example ping is about the same (2ms / 3 ms)


So I took my PC directly into the "server-network" to exclude some switches
and a Firewall, and things worked just fine!

So it seems that the Firewall (Cluster) and/or switches and the virtual
Ethernet Adapter of the p570 somehow don't work properly together.
I checked Firewall and Switches with our network guys, but they did
not find anything special. Our Network runs without a VLANs and
without DNS, but a DefaultID (VLAN) on the Switches is set to 1. So
I also changed my VLAN ID to 1 but ssh still didn't work, so we installed
an any-any rule on the Firewall but it still didn't work. We also made an
ARP entry to the Firewall Multicast MAC Adresse. :-(

So does anybody have a hint?

[m_seger]

In the meantime we narrowed the problem down.

We now know that the problem is somehow related
to the interoperation of our Firewall (Checkpoint Cluster)
and the p570.

If we telnet to a physical card in the same p570
things work just fine.

With the virtual Adapter we still have our problems.

So we collected the traffic of a telnet session and we
see that communication gets established as we expect
it. But when the virtual adapter sends the first telnet
protocol packet (after successful syn/ack) the packet
never arrives on the other side.

After analyzing the logs we found out that the LG Bit
is set to 1 on the virtual Ethernet adapter.
(wireshark says: "locally administered address (this is NOT the factory default)")

So I guess somehow the Check Point Cluster does not
like this setting and dumps the packet.

So if somebody knows how to handle this, please post, Thanks.

[m_seger]

Hi everyone,

Last week I had a network specialist check the scenario. After
half a day of work he found out that virtual Ethernet Adapters
somehow can not handle a Multicast IP Address as Gateway. So you
either have to use a physical IP of the Firewall, or assign an
IP Address to the corresponding SEA Adapter and use it as Gateway.

The reason we use Multicast IP Addresses are that we use a Cluster
Firewall for Redundancy.

I will open a PMR to address this problem to IBM.

Thanks to all the guys, who contributed to this topic.

Cheers Mike

[ScriptDaddy]

I was always told to stick the IP on the SEA and not the Virtual Ethernet, and for some reason I can't remember why.

Maybe this is the reason why.

Ben

[m_seger]

The Problem is solved,

Virtual Ethernet Adapters can't handle Multicast IP Addresses as a Gateway,
so you have to turn the Checksum Offload Parameter of the virtual Adapter
off and everything works fine.

Cheers Mike