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

[Heath Jones]

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 <alumbis at gmail.com> 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 <
> rbf+cisco-nsp at panix.com <rbf%2Bcisco-nsp at panix.com> <
> rbf%2Bcisco-nsp at panix.com <rbf%252Bcisco-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/
> >
> _______________________________________________
> 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/
>