virtual nic and timeouts

[peterve]

Hi,

I have configured my 2 network adapters to act as 1 virtual network adapter (RedHat AS 4)

ifcfg-bond0 :
DEVICE=bond0
IPADDR=1.1.1.1
NETMASK=255.255.255.0
ONBOOT=yes
BOOTPROTO=none
USERCTL=no

ifcfg-eth0 :
DEVICE=eth0
USERCTL=no
ONBOOT=yes
MASTER=bond0
SLAVE=yes
BOOTPROTO=none


ifcfg-eth1 :
DEVICE=eth1
USERCTL=no
ONBOOT=yes
MASTER=bond0
SLAVE=yes
BOOTPROTO=none

when I pull one of the network cables, the server remains accessible - no timeouts

when I put the cable back in the NIC, I'm getting timeouts for about 5 to 10 seconds.

This behaviour happens when I put both cables in the same switch, or when I put them in different switches.

Can somebody tell me why I'm seeing these timeouts ?
They might be normal - but I need to know exactly why I'm seeing them

thanks


--------------------------------------------------------------------
How can I believe in God when just last week I got my tongue caught in the roller of an electric typewriter?
---------------------------------------------------------------------

 

[ProbablyDown]

It could just be the routing reestablishing data paths. Similarly, I have that happen on my san.

 

[peterve]

there is no routing - the only thing I can think of is the fact that the ARP table on the switch needs to be rebuilt...

could this be the reason ?

--------------------------------------------------------------------
How can I believe in God when just last week I got my tongue caught in the roller of an electric typewriter?
---------------------------------------------------------------------

 

[zeland]

If I'm not mistaken, your switch must support line/port aggregation. Don't know if its still called that now a days.


--== Anything can go wrong. It's just a matter of how far wrong it will go till people think its right. ==--

 

[zeland]

Sorry about that. It's called link aggregation. We used it back when we were using Intel Express switches. We never really got double the bandwidth. It was usually around 60% better with lots of small transfers. Transferring large files usually yielded about 40% improvement or less. With the advent of Gigabit technology, we've abandoned all out Intel switches & link aggregation.


--== Anything can go wrong. It's just a matter of how far wrong it will go till people think its right. ==--

 

[LawnBoy]

Link Aggregation Control Protocol (LACP). On my HP Procurve Gig switches I see up to 80% increase per channel added.

I've never tried the virtualization you mention, but here are some things to bear in mind: if the virtualization causes both nics to present the same MAC address to the switch, the switch will 'freak out' because it can only assign 1 route to any MAC. This is called an ARP (or broadcast) storm and will propagate to other switches on the network. You can avoid this problem by running Spanning Tree Protocol (STP) on the switch which will place one of the duplicate routes in a standby mode.

ARP tables usually rebuild very quickly but if you are running STP the delay could be caused by the switch testing the duplicate routes to determine which link should be in standby.

 

[peterve]

STP is in fact turned on, so that should get rid of the broadcast issue, however I will try out the LACP and see what it does in terms of bandwidth

--------------------------------------------------------------------
How can I believe in God when just last week I got my tongue caught in the roller of an electric typewriter?
---------------------------------------------------------------------

 

[unixfreak]

Same thing happens on AIX. There's a delay after you plug a cable back in.