Date: Fri, 16 Mar 2012 12:10:46 +0100 From: Damien Fleuriot <ml@my.gd> To: Snoop <snoop@email.it> Cc: dweimer@dweimer.net, "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Re: LAGG bug or misconfiguration??? Message-ID: <4F631FB6.4060303@my.gd> In-Reply-To: <1331893099.4898.10.camel@urano.inhio.eu> References: <1331838392.1453.5.camel@blackfriar.inhio.eu> <9D882CD7-5BD1-4A49-86AB-DD8A5B86D4EC@my.gd> <1331893099.4898.10.camel@urano.inhio.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
You're not looking for FEC or ethechannel or 802.3ad at all. What you're looking for, in the case of a *failover* configuration, is a "spanning-tree portfast" feature so that your port doesn't transition through the different spantree states before forwarding traffic. Kindly obtain the configuration from whoever has it and let us know. On 3/16/12 11:18 AM, Snoop wrote: > Hi Dweimer and Damien, > thanks for replying. > > The server is connected to a switch of the datacentre. The configuration > of this switch is unknown to me and I obviously have no access to it but > I truly believe that such an enterprise environment has management > capabilities. > Anyway, in which way the configuration would affect the lagg > functionality? Might this issue be related to what stated in the FreeBSD > LAGG pages in the handbook? > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-aggregation.html > > "Cisco® Fast EtherChannel® > > Cisco Fast EtherChannel (FEC), is a static setup and does not negotiate > aggregation with the peer or exchange frames to monitor the link. If the > switch supports LACP then that should be used instead." > > > > On Fri, 2012-03-16 at 10:45 +0100, Damien Fleuriot wrote: >> Sorry top posting from phone. >> >> >> Show your switch's port configurations. >> >> We're using VLAN tagging over lagg failover interfaces at work and I have already tried the tests you described, to much better results. >> >> We're also running 8.2 so the only thing that seems to differ between us is the switch config, likely. >> >> >> >> On 15 Mar 2012, at 20:06, Snoop <snoop@email.it> wrote: >> >>> Hi there, >>> a while after setting up my new server (with 8 jails in it) I've decided >>> (after postponing several times) to properly check the functionality of >>> the lagg and the result was very disappointing. >>> >>> The test I've done is very simple. >>> I've started copying a file from one site to another of my VPN network >>> (from the server I've been testing the net to another node somewhere >>> else) and in the meantime I've been physically disconnecting the main >>> network cable to check the responsiveness of the lagg configuration. >>> Then I've plugged the cable back to check if the traffic would switch >>> back to the main NIC as it should. >>> >>> The result was basically this (lagg0 members: bge0 primary, bge1 >>> secondary) >>> >>> - when bge0 unplugged the traffic switched almost instantaneously to >>> bge1 >>> - when bge0 plugged back in, the network stopped working completely with >>> the two NICs polling synchronously until I manually unplug bge1. Then >>> within 2-4 seconds traffic goes back on bge0 (I've been waiting for a >>> little more than a minute maximum to avoid all the active connections on >>> the server to timeout). >>> >>> Now, I've repeated the same test about 10-15 times randomly waiting for >>> different times between the unplug-replug procedure. The result was >>> always the same. >>> >>> So, below are the ipconfig outputs >>> - before to start the test >>> - when bge0 gets unplugged >>> - when bge0 gets plugged back in >>> >>> I couldn't see anything odd. >>> ___________________________________________________________________________________ >>> lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu >>> 1500 >>> >>> options=8009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE> >>> ether 00:14:ee:00:8a:c0 >>> inet xxx.xx.xx.224 netmask 0xffffff00 broadcast xxx.xx.xx.255 >>> inet xxx.xx.xx.227 netmask 0xffffffff broadcast xxx.xx.xx.227 >>> inet xxx.xx.xx.225 netmask 0xffffffff broadcast xxx.xx.xx.225 >>> inet 172.16.3.2 netmask 0xffffffff broadcast 172.16.3.2 >>> inet 172.16.3.3 netmask 0xffffffff broadcast 172.16.3.3 >>> inet 172.16.3.4 netmask 0xffffffff broadcast 172.16.3.4 >>> inet 172.16.3.5 netmask 0xffffffff broadcast 172.16.3.5 >>> inet 172.16.3.6 netmask 0xffffffff broadcast 172.16.3.6 >>> inet xxx.xx.xx.226 netmask 0xffffffff broadcast xxx.xx.xx.226 >>> media: Ethernet autoselect >>> status: active >>> laggproto failover >>> laggport: bge1 flags=0<> >>> laggport: bge0 flags=5<MASTER,ACTIVE> >>> ___________________________________________________________________________________ >>> lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu >>> 1500 >>> >>> options=8009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE> >>> ether 00:14:ee:00:8a:c0 >>> inet xxx.xx.xx.224 netmask 0xffffff00 broadcast xxx.xx.xx.255 >>> inet xxx.xx.xx.227 netmask 0xffffffff broadcast xxx.xx.xx.227 >>> inet xxx.xx.xx.225 netmask 0xffffffff broadcast xxx.xx.xx.225 >>> inet 172.16.3.2 netmask 0xffffffff broadcast 172.16.3.2 >>> inet 172.16.3.3 netmask 0xffffffff broadcast 172.16.3.3 >>> inet 172.16.3.4 netmask 0xffffffff broadcast 172.16.3.4 >>> inet 172.16.3.5 netmask 0xffffffff broadcast 172.16.3.5 >>> inet 172.16.3.6 netmask 0xffffffff broadcast 172.16.3.6 >>> inet xxx.xx.xx.226 netmask 0xffffffff broadcast xxx.xx.xx.226 >>> media: Ethernet autoselect >>> status: active >>> laggproto failover >>> laggport: bge1 flags=4<ACTIVE> >>> laggport: bge0 flags=1<MASTER> >>> ___________________________________________________________________________________ >>> >>> lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu >>> 1500 >>> >>> options=8009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE> >>> ether 00:14:ee:00:8a:c0 >>> inet xxx.xx.xx.224 netmask 0xffffff00 broadcast xxx.xx.xx.255 >>> inet xxx.xx.xx.227 netmask 0xffffffff broadcast xxx.xx.xx.227 >>> inet xxx.xx.xx.225 netmask 0xffffffff broadcast xxx.xx.xx.225 >>> inet 172.16.3.2 netmask 0xffffffff broadcast 172.16.3.2 >>> inet 172.16.3.3 netmask 0xffffffff broadcast 172.16.3.3 >>> inet 172.16.3.4 netmask 0xffffffff broadcast 172.16.3.4 >>> inet 172.16.3.5 netmask 0xffffffff broadcast 172.16.3.5 >>> inet 172.16.3.6 netmask 0xffffffff broadcast 172.16.3.6 >>> inet xxx.xx.xx.226 netmask 0xffffffff broadcast xxx.xx.xx.226 >>> media: Ethernet autoselect >>> status: active >>> laggproto failover >>> laggport: bge1 flags=0<> >>> laggport: bge0 flags=5<MASTER,ACTIVE> >>> __________________________________________________________________________________ >>> Also nothing unusual on dmesg: >>> >>> ....... >>> bge0: link state changed to DOWN >>> bge0: link state changed to UP >>> bge1: link state changed to DOWN >>> bge1: link state changed to UP >>> bge0: link state changed to DOWN >>> bge0: link state changed to UP >>> bge1: link state changed to DOWN >>> bge1: link state changed to UP >>> bge0: link state changed to DOWN >>> bge0: link state changed to UP >>> bge1: link state changed to DOWN >>> bge1: link state changed to UP >>> ....... >>> >>> The following is the related configuration in rc.conf: >>> >>> ....... >>> ifconfig_bge0="up" >>> ifconfig_bge1="up" >>> cloned_interfaces="lagg0" >>> ifconfig_lagg0="laggproto failover laggport bge0 laggport bge1 >>> xxx.xx.xx.224/24" >>> ifconfig_lagg0_alias_0="inet xxx.xx.xx.225/32" >>> ifconfig_lagg0_alias_1="inet xxx.xx.xx.226/32" >>> ifconfig_lagg0_alias_2="inet xxx.xx.xx.227/32" >>> ifconfig_lagg0_alias_3="inet 172.16.3.2/27" >>> ifconfig_lagg0_alias_4="inet 172.16.3.3/27" >>> ifconfig_lagg0_alias_5="inet 172.16.3.4/27" >>> ifconfig_lagg0_alias_6="inet 172.16.3.5/27" >>> ifconfig_lagg0_alias_7="inet 172.16.3.6/27" >>> ....... >>> >>> The system is an IBM xSeries 336 type 8837 >>> kern.version: FreeBSD 8.2-RELEASE-p3 #0: Tue Sep 27 18:45:57 UTC 2011 >>> >>> Just for the record, I've done the test from the host (xxx.xx.xx.224/24) >>> not from any of the jail in place. >>> Any idea or similar issue around? Am I missing something? >>> Thanks. >>> >>> >>> >>> -- >>> Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f >>> >>> Sponsor: >>> Offerta speciale: a partire da soli Euro 18.90 puoi stampare le tue Foto su vera Tela Pittorica e creare Quadri fino a 80x50 cm! >>> Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=11453&d=15-3 >>> _______________________________________________ >>> freebsd-questions@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions >>> To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-questions@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions >> To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" > > > > > -- > Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f > > Sponsor: > ING DIRECT Conto Arancio. 4,20% per 12 mesi, zero spese, aprilo in due minuti! > Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=11921&d=16-3
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F631FB6.4060303>