<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Bonding Failover Problem in Operating System - Linux</title>
    <link>https://community.hpe.com/t5/operating-system-linux/bonding-failover-problem/m-p/4149260#M83428</link>
    <description>Maybe a switch (spanning tree or something) issue. It looks that it takes too long to identify the location of the MAC address.&lt;BR /&gt;&lt;BR /&gt;Check the status in proc/net/bonding/bond0.&lt;BR /&gt;&lt;BR /&gt;Check also the port status for autonegotiation problems.</description>
    <pubDate>Sat, 23 Feb 2008 23:16:25 GMT</pubDate>
    <dc:creator>Ivan Ferreira</dc:creator>
    <dc:date>2008-02-23T23:16:25Z</dc:date>
    <item>
      <title>Bonding Failover Problem</title>
      <link>https://community.hpe.com/t5/operating-system-linux/bonding-failover-problem/m-p/4149259#M83427</link>
      <description>I have DL380 G4s with NC7771 NIC cards running redhat ES 3 update 6.  I have them in mode 1 plugged in to separate switches.  I have tried the tg3 and ncm5700 nic drivers.  The problem is that when I unplug the active nic it won't pass traffic to the other nic for about 60-90 seconds.  When you view the dmesg output it shows it failing immediately and activating the other nic.  Any ideas why this is not working correctly?&lt;BR /&gt;&lt;BR /&gt;modules.conf -&lt;BR /&gt;#alias eth0 tg3&lt;BR /&gt;alias eth0 bcm5700&lt;BR /&gt;#alias eth1 tg3&lt;BR /&gt;alias eth1 bcm5700&lt;BR /&gt;#alias eth2 bcm5700&lt;BR /&gt;alias scsi_hostadapter cciss&lt;BR /&gt;alias usb-controller usb-uhci&lt;BR /&gt;alias usb-controller1 ehci-hcd&lt;BR /&gt;alias bond0 bonding&lt;BR /&gt;options bond0 mode=1 miimon=100&lt;BR /&gt;&lt;BR /&gt;ifcfg-bond0 -&lt;BR /&gt;DEVICE=bond0&lt;BR /&gt;BOOTPROTO=none&lt;BR /&gt;IPADDR=10.70.80.119&lt;BR /&gt;NETMASK=255.255.240.0&lt;BR /&gt;ONBOOT=yes&lt;BR /&gt;TYPE=Ethernet&lt;BR /&gt;USERCTL=no&lt;BR /&gt;&lt;BR /&gt;ifcfg-eth0 -&lt;BR /&gt;# eth0&lt;BR /&gt;DEVICE=eth0&lt;BR /&gt;#IPADDR=10.70.80.119&lt;BR /&gt;#NETMASK=255.255.240.0&lt;BR /&gt;BOOTPROTO=none&lt;BR /&gt;USERCTL=no&lt;BR /&gt;MASTER=bond0&lt;BR /&gt;SLAVE=yes&lt;BR /&gt;ONBOOT=yes&lt;BR /&gt;#ETHTOOL_OPTS="speed 100 duplex full autoneg off"&lt;BR /&gt;TYPE=Ethernet&lt;BR /&gt;&lt;BR /&gt;ifcfg-eth1 -&lt;BR /&gt;DEVICE=eth1&lt;BR /&gt;BOOTPROTO=none&lt;BR /&gt;USERCTL=no&lt;BR /&gt;MASTER=bond0&lt;BR /&gt;SLAVE=yes&lt;BR /&gt;ONBOOT=yes&lt;BR /&gt;#ETHTOOL_OPTS="speed 100 duplex full autoneg off"&lt;BR /&gt;TYPE=Ethernet&lt;BR /&gt;&lt;BR /&gt;dmesg output&lt;BR /&gt;bcm5700: eth0 NIC Link is Down&lt;BR /&gt;bond0: link status definitely down for interface eth0, disabling it and making interface eth1 the active one.&lt;BR /&gt;</description>
      <pubDate>Fri, 22 Feb 2008 21:33:59 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/bonding-failover-problem/m-p/4149259#M83427</guid>
      <dc:creator>Tim Goodman</dc:creator>
      <dc:date>2008-02-22T21:33:59Z</dc:date>
    </item>
    <item>
      <title>Re: Bonding Failover Problem</title>
      <link>https://community.hpe.com/t5/operating-system-linux/bonding-failover-problem/m-p/4149260#M83428</link>
      <description>Maybe a switch (spanning tree or something) issue. It looks that it takes too long to identify the location of the MAC address.&lt;BR /&gt;&lt;BR /&gt;Check the status in proc/net/bonding/bond0.&lt;BR /&gt;&lt;BR /&gt;Check also the port status for autonegotiation problems.</description>
      <pubDate>Sat, 23 Feb 2008 23:16:25 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/bonding-failover-problem/m-p/4149260#M83428</guid>
      <dc:creator>Ivan Ferreira</dc:creator>
      <dc:date>2008-02-23T23:16:25Z</dc:date>
    </item>
    <item>
      <title>Re: Bonding Failover Problem</title>
      <link>https://community.hpe.com/t5/operating-system-linux/bonding-failover-problem/m-p/4149261#M83429</link>
      <description>It's not a switch problem because I have some DL380 G5s and DL360 G3s that fail over correctly.  The servers are negotiating correctly.</description>
      <pubDate>Fri, 29 Feb 2008 19:01:43 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/bonding-failover-problem/m-p/4149261#M83429</guid>
      <dc:creator>Tim Goodman</dc:creator>
      <dc:date>2008-02-29T19:01:43Z</dc:date>
    </item>
    <item>
      <title>Re: Bonding Failover Problem</title>
      <link>https://community.hpe.com/t5/operating-system-linux/bonding-failover-problem/m-p/4149262#M83430</link>
      <description>Check your kernel configuration for ARP values, for example, arp_filter.&lt;BR /&gt;&lt;BR /&gt;The, I would try with fail_over_mac option.</description>
      <pubDate>Fri, 29 Feb 2008 19:30:31 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/bonding-failover-problem/m-p/4149262#M83430</guid>
      <dc:creator>Ivan Ferreira</dc:creator>
      <dc:date>2008-02-29T19:30:31Z</dc:date>
    </item>
    <item>
      <title>Re: Bonding Failover Problem</title>
      <link>https://community.hpe.com/t5/operating-system-linux/bonding-failover-problem/m-p/4149263#M83431</link>
      <description>arp_filter is 0&lt;BR /&gt;&lt;BR /&gt;I can't do fail_over_mac because it was added in v 3.2 and I'm running 2.6</description>
      <pubDate>Fri, 29 Feb 2008 19:46:13 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/bonding-failover-problem/m-p/4149263#M83431</guid>
      <dc:creator>Tim Goodman</dc:creator>
      <dc:date>2008-02-29T19:46:13Z</dc:date>
    </item>
  </channel>
</rss>

