[c-nsp] Cogent IOS upgrade == BGP-3, "update malformed"

[Pete Lumbis]

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 <
rbf+cisco-nsp at panix.com <rbf%2Bcisco-nsp at panix.com>> 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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>