On 8/22/06, Steffen Weiberle <[EMAIL PROTECTED]> wrote:
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.
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 should note I see this packet loss on both interfaces, ip_forwarding and ip_strict_dst_multihoming are both 0.
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.
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 should note I see this packet loss on both interfaces, ip_forwarding and ip_strict_dst_multihoming are both 0.
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> 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> 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> 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> 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> 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> 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> 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> 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> netmask ff000000
> ce0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500
> index 2
> inet 129.174.94.22 <http://129.174.94.22> netmask ffffff00
> broadcast 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> netmask ff000000 broadcast
> 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> netmask ffffff00
> broadcast 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> netmask ffffff00
> broadcast 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> netmask ffffff00
> broadcast 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> netmask ffffff00
> broadcast 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> netmask ffffff00
> broadcast 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> netmask ffffff00
> broadcast 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> netmask ffffff00
> broadcast 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> netmask ffffff00
> broadcast 129.174.94.255 < http://129.174.94.255>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> zones-discuss mailing list
> zones-discuss@opensolaris.org
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
_______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
