-----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: 1.2.3.49 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/mail.archives/nanog/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 1.2.3.49 DOWN (Attribute Flags Error) Jul 25 15:57:14:N:BGP Peer 1.2.3.49 UP (ESTABLISHED)
If I debug updates on that session I get: (Lines added for readability)
Jul 25 15:57:21 BGP: 1.2.3.49 rcv UPDATE 142.166.102.0/24 Jul 25 15:57:21 BGP: 1.2.3.49 rcv UPDATE w/attr: Origin=IGP AS_PATH=AS_SEQ(2) 4323 8881 8881 8881 30915 NextHop=1.2.3.49 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: 1.2.3.49 rcv UPDATE 193.27.220.0/23 Jul 25 15:57:21 BGP: 1.2.3.49 rcv UPDATE w/attr: Origin=IGP AS_PATH=AS_SEQ(2) 4323 2828 19092 14188 14188 14188 14188 14188 NextHop=1.2.3.49 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: 1.2.3.49 rcv UPDATE 64.13.0.0/22
Jul 25 15:57:21 BGP: 1.2.3.49 rcv invalid COMMUNITY attribute flag d0
Jul 25 15:57:21 BGP: 1.2.3.49 rcv UPDATE w/attr: Origin=IGP AS_PATH=AS_SEQ(2) 4323 12956 3352 NextHop=1.2.3.49 ATOMIC_AGGREGATE AGGREGATOR AS=3352 Speaker=81.46.63.133
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: hardenrm@uiuc.edu Urbana, IL 61801 University of Illinois - Urbana/Champaign - All your Base - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFGqLedtuPckBBbXboRAo+hAJ9lmxtsgZ5jCRN9K1LQYwxgaYHuGgCfeEkp aMi5H7z3nnAEu1v6jwpKth8= =HtEt -----END PGP SIGNATURE-----