Date: Fri, 16 Mar 2012 17:49:07 +0100 From: Damien Fleuriot <ml@my.gd> To: Snoop <snoop@email.it> Cc: "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Re: LAGG bug or misconfiguration??? Message-ID: <4F636F03.1020900@my.gd> In-Reply-To: <1331915503.4898.16.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> <4F631FB6.4060303@my.gd> <1331915503.4898.16.camel@urano.inhio.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
I confirm you should see fast transition for your VLANs to forwarding state. Are your ports in access or trunk mode ? If they're trunked, portfast alone won't do it, you need "spanning-tree portfast trunk". Additionally, are you using link aggregation on the cisco swi ? (channel-group) On 3/16/12 5:31 PM, Snoop wrote: > That's the STP configuration on my two switch ports: > > spanning-tree portfast > spanning-tree bpduguard enable > > > > On Fri, 2012-03-16 at 12:10 +0100, Damien Fleuriot wrote: >> 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 >> _______________________________________________ >> 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: > Innammorarsi � facile con Meetic, milioni di single si sono iscritti, si sono conosciuti e hanno riscoperto l'amore. Tutto con Meetic, prova anche tu! > Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8292&d=16-3
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F636F03.1020900>