snar at snar
Jul 27, 2012, 2:30 AM
Post #1 of 1
(369 views)
Permalink
|
|
bgp, attribute flags error...
|
|
Hi!
Yesterday some BGP sessions with our clients started flapping with the
following messages in logs:
Jul 26 13:07:58.240 RT.LVI.UA rpd[1472]: bgp_read_v4_message:9945:
NOTIFICATION received from <client's ip> (External AS <client's AS>):
code 3 (Update Message Error) subcode 4 (attribute flags error),
Data: c8 07 08 00 00 c0
Well, c8 in Data: is clearly 'not too correct', '8' is the 'lower-order
bits' with one bit set to one, while RFC clearly says that "They MUST be
zero when sent":
The lower-order four bits of the Attribute Flags octet are unused.
They MUST be zero when sent and MUST be ignored when received.
but looks like JunOS sends flags byte just as received, without
re-generating or zeroizing, and customer's software (openbgpd)
is a bit buggy and does not ignores these bits but resets session
instead[1].
Right now I had to shut down peering with neighbor sending these
prefixes, but may be there are other workarounds ?
[1] bgpd/rde.c CHECK_FLAGS macro should be redefined as
(((s & 0xf0) & ~(ATTR_EXTLEN | (m))) == (t))
instead of just
(((s) & ~(ATTR_EXTLEN | (m))) == (t))
--
In theory, there is no difference between theory and practice.
But, in practice, there is.
_______________________________________________
juniper-nsp mailing list juniper-nsp [at] puck
https://puck.nether.net/mailman/listinfo/juniper-nsp
|
