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

[Brett Frankenberger]

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