North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: TWTC issue with Foundry routers?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As a Foundry user utilizing Communities this caught my eye...I found a similar post to Nanog last year that pointed me in the right direction on this I think. It seems the author of that post seems to have hit the nail on th head. Your debugging shows Jul 25 15:57:21 BGP: 184.108.40.206 rcv invalid COMMUNITY attribute flag d0 Decoded, the Attribute flag 'd0' means the attribute is: Optional, transitive, and extended (greater than 255 octets) It seems when the FI400 receives the 'd0' flag stating that the next update has an extended attribute field, it borks. I'd guess this due to a large amount of Communities attached to that prefix for whatever reason. Though I suppose the upstream router could be at fault for flagging 'd0' and then sending a _non_ extended attribute. Its hard to tell. One would assume that the FI400 should merely discard that update rather than take the session down, but I need to read more into the RFC to know for sure. Sorry I don't have a definitive answer, but you might ask TWTC to _actually_ not send you communities and see if it goes away. :) Either way it seems a call to Foundry TAC is in order as this is unacceptable behavior. Original Post from 2006: http://www.merit.edu/mailinglist/mailarchives/old_archive/2006-04/msg00034.html /Ryan David Hubbard wrote: > Anyone know of any changes that were made with TWTC (AS 4323) > last night that may have affected those running Foundry > routers? We peer with a number of providers and last night > our TWTC connection went down with: > > > Jul 25 15:57:22:N:BGP Peer 220.127.116.11 DOWN (Attribute Flags Error) > Jul 25 15:57:14:N:BGP Peer 18.104.22.168 UP (ESTABLISHED) > > If I debug updates on that session I get: > (Lines added for readability) > > > Jul 25 15:57:21 BGP: 22.214.171.124 rcv UPDATE 126.96.36.199/24 > Jul 25 15:57:21 BGP: 188.8.131.52 rcv UPDATE w/attr: Origin=IGP > AS_PATH=AS_SEQ(2) 4323 8881 8881 8881 30915 NextHop=184.108.40.206 > COMMUNITY=4323:51 4323:501 4323:1003 4323:2001 4323:2503 4323:34510 > 4323:50000 65101:1003 65102:4 65103:1 65104:301 > Jul 25 15:57:21 BGP: 220.127.116.11 rcv UPDATE 18.104.22.168/23 > Jul 25 15:57:21 BGP: 22.214.171.124 rcv UPDATE w/attr: Origin=IGP > AS_PATH=AS_SEQ(2) 4323 2828 19092 14188 14188 14188 14188 14188 > NextHop=126.96.36.199 COMMUNITY=4323:51 4323:501 4323:1015 4323:2503 > 4323:36410 4323:50000 65101:1015 65102:4 65103:1 65104:301 > Jul 25 15:57:21 BGP: 188.8.131.52 rcv UPDATE 184.108.40.206/22 > > > Jul 25 15:57:21 BGP: 220.127.116.11 rcv invalid COMMUNITY attribute flag d0 > > > Jul 25 15:57:21 BGP: 18.104.22.168 rcv UPDATE w/attr: Origin=IGP > AS_PATH=AS_SEQ(2) 4323 12956 3352 NextHop=22.214.171.124 ATOMIC_AGGREGATE > AGGREGATOR AS=3352 Speaker=126.96.36.199 > > > > The router is a Foundry NetIron 400 running their 7.8 code. > We have two of these talking to Level 3, TWTC, Cogent, Uunet > and AT&T and only the TWTC had an issue. They sent me a > default route instead of full routes and the session came > up and was stable; go back to full routes and error. They > admitted to me this afternoon that three other customers are > having the same issue. That's when we started wondering if > they changed something that the Foundry code doesn't like. > Interesting though is that they claim to not be sending me > communities while the output above indicates they are. > > Any ideas; be nice to get the link back up. :-) > > Thanks, > > David - -- Ryan M. Harden, BS, KC9IHX Office: 217-265-5192 CITES - Network Engineering Cell: 630-363-0365 2130 Digital Computer Lab Fax: 217-244-7089 1304 W. Springfield email: [email protected] Urbana, IL 61801 University of Illinois - Urbana/Champaign - All your Base - -----BEGIN PGP SIGNATURE----- Version: GnuPG v188.8.131.52 (GNU/Linux) iD8DBQFGqLedtuPckBBbXboRAo+hAJ9lmxtsgZ5jCRN9K1LQYwxgaYHuGgCfeEkp aMi5H7z3nnAEu1v6jwpKth8= =HtEt -----END PGP SIGNATURE-----