Hi,
Further to my email two and a half hours ago, it seems that the prefix
causing OpenBGPd speakers to die is 91.207.218.0/23, which is
originated by a 4-byte ASN speaker.
OpenBGPd is checking AS4_PATH to ensure that it contains only AS_SET
and AS_SEQUENCE types, as per RFC4893. When processing the UPDATE for
91.207.218.0/23 it sees :
91.207.218.0/23
Path Attributes - Origin: Incomplete
Flags: 0x40 (Well-known, Transitive, Complete)
Origin: Incomplete (2)
AS_PATH: xx xx 35320 23456 (13 bytes)
AS4_PATH: (65044 65057) 196629 (7 bytes)
RFC4893 is clear on the matter :
"
To prevent the possible propagation of confederation path segments
outside of a confederation, the path segment types
AS_CONFED_SEQUENCE
and AS_CONFED_SET [RFC3065] are declared invalid for the AS4_PATH
attribute.
"
OpenBGPd is therefore dropping the sessions when this update is
received. Unideal if this attribute is learned on multiple upstreams...
The impact today is fairly limited as there are relatively few bgp
speakers honouring the 4-byte ASN protocol extension rules, but as
code that support these features creeps around the internet, the next
time this happens the impact could be much greater, so we need to
understand which implementation of which BGP software caused this
illegal origination.
Modifying the OpenBGPd software to permit AS_CONFED_SEQUENCE,
AS_CONFED_SET in an as4_path causes the path to be accepted and the
session is not torn down. This isn't a great fix.
From a software point of view, I agree that a configurable option to
reject the route but keep the session, reject the route and drop the
session, accept the route but log/send trap, etc. would be nicer, but
this is an implementation thing and probably beyond the scope of this
list.
For now, does anyone have contacts at 196629 or 35320 who can explain
the implementation and fix the behaviour ?
Andy
