Agreed. I haven't gone to the effort of double checking Brett's work - but the approach is definately the right one. It's very common for a developer to screw up a pointer or boolean operation, just sometimes these bugs actually make it past testing. I wouldn't be surprised.. Also, what's the point of having a log entry if it doesnt get read? :)
On 24 August 2010 03:52, Pete Lumbis <[email protected]> wrote: > I'm with Brett here. The update is malformed and you are just the victim. > I'd try to gather a packet capture as well and you should be able to go to > your provider armed with the bogus BGP update in both pcap and log form and > tell them it's their fault. > > -Pete > > On Mon, Aug 23, 2010 at 10:06 AM, Brett Frankenberger < > [email protected] <rbf%[email protected]> < > rbf%[email protected] <rbf%[email protected]>>> wrote: > > > On Mon, Aug 23, 2010 at 01:34:50PM +0100, Zoe O'Connell wrote: > > > On 23/08/10 13:07, Florian Weimer wrote: > > > > * Zoe O'Connell: > > > > > > > > > > > >>> 729078: Aug 22 16:21:39 MDT: %BGP-3-NOTIFICATION: sent to neighbor > > A.B.C.D > > > >>> 3/1 (update malformed) 21 bytes 31FE420C 31FE58C8 124683E8 0206CC67 > > 00 > > > >>> 729079: Aug 22 16:21:39 MDT: BGP: A.B.C.D Bad attributes FFFF FFFF > > FFFF FFFF > > > >>> FFFF FFFF FFFF FFFF 0060 0200 0000 4140 0101 0040 020C 0205 00AE > 0CB9 > > 235A > > > >>> 2046 5BA0 4003 0426 6532 7580 0404 0000 5DE8 C008 0800 AE52 0800 > AE55 > > FD31 > > > >>> FE42 0C31 FE58 C812 4683 E802 06CC 6700 0000 0002 1854 1608 1854 > 1609 > > > >>> > > > > 5BA0 suggests its related to 32 bit ASNs. We've got the prefixes in > > > > our table, apparently with a proper 32-bit ASN: > > > > > > Yes, that's the conclusion we came to as well when we had it. (Luckily, > > > it was an iBGP link to a firewall so easier to troubleshoot than a > > > customer link). As far as I can recall, without Capability Negotiation > > > it can't send 4-byte ASNs and some devices have a bug or differing RFC > > > interpretation that means they can't handle being on the receiving end > > > properly - if Cogent won't change their end, an IOS upgrade on the > > > original psoters end should resolve it. I'm sure I sent a mail to > > > someone about it at the time with more precise detail, but I can't seem > > > to find it now. > > > > There's no IOS upgrade that's going to make the router happy with the > > message shown above. After the community attribute, it contains an > > attribute startin with: 31FE420C. Among other things, that's > > specifying a length of 0x420C, which is much longer than the entire > > message. And it has the "partial" bit set on an optional, > > non-transitive attribute, which isn't allowed. And it's Attribute Code > > 254, which doesn't exist (shouldn't cause a NOTIFY, though ... the > > NOTIFY is likely being triggered by the length field.) And the 0x01 bit > > it set in the flags byte, which is also wrong (but also shouldn't cause > > a NOTIFY). It's pretty obviously a seriously malformed attribute. > > > > Assuming the router is correctly logging the message it received, the > > problem is on the sending end. > > > > (It's disappointing how people troubleshoot these days. Shot in the > > dark IOS upgrades and parameter changes, when the entire objectionable > > message is logged and can be decoded with a copy of the BGP RFC and 10 > > minutes.) > > > > -- Brett > > _______________________________________________ > > cisco-nsp mailing list [email protected] > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
