Hi All, The AS at the company I work for running (OpenBSD 4.2 and 4.3) as well as the AS run by a associate of mine (OpenBSD 4.4) experienced rather wild route flaps earlier today. Quoted from Andy Davidson's post to nanog.
"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 looking at the source this would appear to be 'expected' behavior however it does leave you without any internet connectivity. I'm not as much of a BGP guru as I should be but what would be the impact of dropping the route/update rather than dropping the session? Pete Bristow
