Alastair Neil wrote On 08/22/06 10:49,:
On 8/22/06, *Steffen Weiberle* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi Alastair,
Alastair Neil wrote On 08/22/06 08:59,:
> Hi I have a Sunfire V440 with 2 processors and 10Gbytes of memory
I have
> configured eight zones all using the second ce interface
ce1. The port
> is connected to a nortel buisiness policy switch running at
100Mbs/full
> duplex. I am seeing unacceptible levels of packet loss to the
systems.
> With all the zones booted and idle we get around 5-6% loss which can
> climb to 50-60% with activity. One of these zones will run
apache2, the
> rest will be running tomcat.
If things are idle, what data are you loosing?
Ok totally idle is perhaps an exaggeration, I noticed the symptoms when
typing in an ssh session, periods where the systems appeared hung. I
then started mtr from my linux workstation and left it running and
noticed that when idle the reported packet loss was averaging 5%, but
once I started a ssh session it escalated quickly.
Not sure if both connections are to the same interface or IP address.
kstat -m ce0 and separately, ce1 might show something.
any parameters in particular of interest? It show full duplex for both
interfaces, I am having the network guys verify that that is what the
switch ports are running too.
I don't have access to a CE interface, so I don't know what i'd be
looking at 'til I see it.
ndd /dev/ce might be good as well. you would need to set the instance
to 0 and then to 1 to get all the data. I am looking for link partner
status--is the other end negotiating or not.
I should note I see this packet loss on both interfaces, ip_forwarding
and ip_strict_dst_multihoming are both 0.
These setting should have no effect, both interfaces are on the same
subnet. That said, you have local-mac-address?=false in eeprom. So
both ce0 and ce1 have the same MAC address. Some switches get confused
by that. Not sure how a Nortel switch of your type behaves in that
scenario. But the symptom if there is a problem is that the switch
ping-pongs back and forth between the two interfaces as host
0:3:ba:74:56:cb, and as such ethernet frames may get dropped on the floor.
Easy was to see if that fixes it is to 'ifconfig ce1 ether
0:3:ba:74:56:cc', incrementing the lowest octet by 1 (temporarily)
Steffen
Where and how are you measuring this loss?
>
> I would appreciate any assitance as I am new to zones. Is this
> configuration excessive for the hardware?
Theoretically no. I had a customer run 3,000 netscape 2.x instances on
an E4000 running 2.5.1 years ago. Business level service with SLAs. So
without metrics this configuration seems fine.
Steffen
Totally unrelated to zones, the first thing that comes to mind is
auto-negotation mis-match. But that is pure speculation on my part
based on other network performance problems folks have had.
>
> rgds, Alastair Neil
>
> Here is the output from ifconfig -a:
>
> -bash-3.00# ifconfig -a
>
> lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL>
> mtu 8232 index 1
> inet 127.0.0.1 <http://127.0.0.1> <http://127.0.0.1>
netmask ff000000
> lo0:1:
flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL>
> mtu 8232 index 1
> zone apps-inst
> inet 127.0.0.1 <http://127.0.0.1> <http://127.0.0.1>
netmask ff000000
> lo0:2:
flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL>
> mtu 8232 index 1
> zone apps-SWE432
> inet 127.0.0.1 <http://127.0.0.1> <http://127.0.0.1>
netmask ff000000
> lo0:3:
flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL>
> mtu 8232 index 1
> zone hermes-web
> inet 127.0.0.1 <http://127.0.0.1> <http://127.0.0.1>
netmask ff000000
> lo0:4:
flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL>
> mtu 8232 index 1
> zone apps
> inet 127.0.0.1 <http://127.0.0.1> <http://127.0.0.1>
netmask ff000000
> lo0:5:
flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL>
> mtu 8232 index 1
> zone apps-SWE632
> inet 127.0.0.1 <http://127.0.0.1> <http://127.0.0.1>
netmask ff000000
> lo0:6:
flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL>
> mtu 8232 index 1
> zone apps-SWE642
> inet 127.0.0.1 <http://127.0.0.1> <http://127.0.0.1>
netmask ff000000
> lo0:7:
flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL>
> mtu 8232 index 1
> zone apps-SWE645
> inet 127.0.0.1 <http://127.0.0.1> <http://127.0.0.1>
netmask ff000000
> lo0:8:
flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL>
> mtu 8232 index 1
> zone apps-IT314
> inet 127.0.0.1 <http://127.0.0.1> <http://127.0.0.1>
netmask ff000000
> ce0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500
> index 2
> inet 129.174.94.22 <http://129.174.94.22>
<http://129.174.94.22> netmask ffffff00
> broadcast 129.174.94.255 <http://129.174.94.255>
<http://129.174.94.255>
> ether 0:3:ba:74:56:cb
> ce1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500
> index 3
> inet 0.0.0.0 <http://0.0.0.0> <http://0.0.0.0>
netmask ff000000 broadcast
> 0.255.255.255 <http://0.255.255.255> < http://0.255.255.255>
> ether 0:3:ba:74:56:cb
> ce1:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu
1500
> index 3
> zone apps-inst
> inet 129.174.94.32 <http://129.174.94.32>
<http://129.174.94.32> netmask ffffff00
> broadcast 129.174.94.255 <http://129.174.94.255> <
http://129.174.94.255>
> ce1:2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu
1500
> index 3
> zone apps-SWE432
> inet 129.174.94.35 <http://129.174.94.35>
<http://129.174.94.35> netmask ffffff00
> broadcast 129.174.94.255 <http://129.174.94.255>
<http://129.174.94.255 <http://129.174.94.255>>
> ce1:3: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu
1500
> index 3
> zone hermes-web
> inet 129.174.94.33 <http://129.174.94.33>
<http://129.174.94.33> netmask ffffff00
> broadcast 129.174.94.255 <http://129.174.94.255>
<http://129.174.94.255>
> ce1:4: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu
1500
> index 3
> zone apps
> inet 129.174.94.34 <http://129.174.94.34> <
http://129.174.94.34> netmask ffffff00
> broadcast 129.174.94.255 <http://129.174.94.255>
<http://129.174.94.255>
> ce1:5: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu
1500
> index 3
> zone apps-SWE632
> inet 129.174.94.36 <http://129.174.94.36>
<http://129.174.94.36> netmask ffffff00
> broadcast 129.174.94.255 <http://129.174.94.255>
<http://129.174.94.255>
> ce1:6: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu
1500
> index 3
> zone apps-SWE642
> inet 129.174.94.37 <http://129.174.94.37>
<http://129.174.94.37> netmask ffffff00
> broadcast 129.174.94.255 <http://129.174.94.255>
<http://129.174.94.255>
> ce1:7: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu
1500
> index 3
> zone apps-SWE645
> inet 129.174.94.38 <http://129.174.94.38>
<http://129.174.94.38> netmask ffffff00
> broadcast 129.174.94.255 <http://129.174.94.255>
<http://129.174.94.255>
> ce1:8: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu
1500
> index 3
> zone apps-IT314
> inet 129.174.94.39 <http://129.174.94.39>
<http://129.174.94.39> netmask ffffff00
> broadcast 129.174.94.255 <http://129.174.94.255> <
http://129.174.94.255>
>
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> zones-discuss mailing list
> zones-discuss@opensolaris.org <mailto:zones-discuss@opensolaris.org>
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org <mailto:zones-discuss@opensolaris.org>
------------------------------------------------------------------------
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
