Hi Tobias,

Yes, IPMP is IP Multipathing. Even if you have multiple addresses on the same subnet on different interfaces, as you do, it does not automatically enable IPMP.


I would suggest trying your test with your web server in the global zone after configuring .34 in the global as well, and modifying your web server config to only listen to .34. In other words, remove zones from the equation. I suspect things will still behave the same, and point to how outbound interface gets selected.

And I still get confused by that selection.... Back with interface groups (pre IPMP), outbound traffic on would leave on the same interface a connection came in on, but I'm not sure that is still the case.

Steffen

Tobias Oberstein wrote On 05/09/06 02:06,:
Hi Steffen,

Hi Tobias,

First impression would that this is a routing issue.

What is the IP address of the global zone? Are you running IPMP?


The global zone is bound to 3 of the 4 interfaces:

..
e1000g0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
         inet 62.146.25.62 netmask ffffffe0 broadcast 62.146.25.63
         ether 0:14:4f:1:3b:cc
e1000g1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
         inet 62.146.25.59 netmask ffffffe0 broadcast 62.146.25.63
         ether 0:14:4f:1:3b:cd
e1000g2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
         inet 62.146.25.60 netmask ffffffe0 broadcast 62.146.25.63
         ether 0:14:4f:1:3b:ce
..

The non-global zone is bound to 1 of the 4 interfaces:

..
e1000g2:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
         zone ws1
         inet 62.146.25.34 netmask ffffffe0 broadcast 62.146.25.63
..

No other non-global zones are bound to e1000g0.

Here's my setup:

[EMAIL PROTECTED]:/etc]$ cat /etc/hosts
#
# Internet host table
#
127.0.0.1       localhost
62.146.25.62    tavo1g  loghost
62.146.25.59    tavo1i
62.146.25.60    tavo1p

[EMAIL PROTECTED]:/etc]$ cat /etc/netmasks
62.146.25.32    255.255.255.224

[EMAIL PROTECTED]:/etc]$ cat /etc/hostname.e1000g0
tavo1g

[EMAIL PROTECTED]:/etc]$ cat /etc/hostname.e1000g1
tavo1i

[EMAIL PROTECTED]:/etc]$ cat /etc/hostname.e1000g2
tavo1p

[EMAIL PROTECTED]:/etc]$ cat /etc/default/mpathd
#
#pragma ident   "@(#)mpathd.dfl 1.2     00/07/17 SMI"
#
# Time taken by mpathd to detect a NIC failure in ms. The minimum time
# that can be specified is 100 ms.
#
FAILURE_DETECTION_TIME=10000
#
# Failback is enabled by default. To disable failback turn off this option
#
FAILBACK=yes
#
# By default only interfaces configured as part of multipathing groups
# are tracked. Turn off this option to track all network interfaces
# on the system
#
TRACK_INTERFACES_ONLY_WITH_GROUPS=yes
[EMAIL PROTECTED]:/etc]$

[EMAIL PROTECTED]:/etc]$ ifconfig e1000g0 modlist
0 arp
1 ip
2 pfil
3 e1000g
[EMAIL PROTECTED]:/etc]$ ifconfig e1000g1 modlist
0 arp
1 ip
2 pfil
3 e1000g
[EMAIL PROTECTED]:/etc]$ ifconfig e1000g2 modlist
0 arp
1 ip
2 pfil
3 e1000g


Whats IPMP? Is it IP multipathing? Did not know this exists until your
reply? I did nothing to either enable or disable IP multipathing.

Just read the chapter in the Sys Adm Guide .. from my understanding of
this, my configuration above is NOT a IPMP one.

Thanks for helping,
Tobias


Steffen

Tobias Oberstein wrote On 05/08/06 16:43,:

After spending many hours looking at ipmon/ethereal logs, I believe I've found a explanation (a bug?) for the following strange behaviour (Solaris 10u1):

I've got a non-global zone with Apache2 with dedicated IP and bound to interface e1000g2 of a Sun X4200 box. The global zone has a different dedicated IP bound to a different interface e1000g0.

When I point a browser at the web site, the HTML page often comes up immediately, but sometimes it will hang and only load when I press the reload browser button one or multiple times. This is reproducible with different browsers from different networks with or without DNS resolution. It's reproducible with other non-local zones configured alike and running different TCP based services (namely SSH or non-Apache HTTP).

This is what happens in a failing case (Ethereal client dump "dump_failed.txt" and IPF log "att1.txt" lines 1-3 pp): the incoming TCP SYN comes over interface e1000g2 (correct) and is passed by IPF. However, the non-global zone sends the TCP SYN-ACK package back over interface e1000g0, which is wrong and causes IPF to fail to build a correct state entry. Then, afterwards, the response packets from the webserver will be filtered by IPF, since it has no state entry.

In the success case (Ethereal client dump "dump_success.txt" and IPF log "att1.txt" lines 19-21 pp), the incoming TCP SYN is answered correctly by a TCP SYN-ACK both over interface e1000g2. IPF can build a state entry and all subsequent packets from the webserver reach the client.

...snip..

_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to