3 ms·

The problem is that folks took advantage of the behavior of BGP where it would forward unknown attributes that the local device didn't understand, as a means to

The problem is that folks took advantage of the behavior of BGP where it would forward unknown attributes that the local device didn't understand, as a means to do all sorts of things throughout the network. People now rely on that behavior. Now, we're experiencing the downside of this "feature"

spwa4 1y ago
BGP has classes attributes that it forwards. While it is true that it forwards route attributes it doesn't know about, this was an attribute that it DID know about and knows it shouldn't forward. In fact it's a bit strange just how lenient Juniper's software was here. If a session is configured as IBGP on one end and EBGP on the other end, it should never get past the initial message. Juniper not only let it get past the connection establishment but forwarded obviously wrong routes.
- sc68cal 1y ago
  Yes but you are seeing a symptom of what I believe is a fundamental design decision to be liberal in passing on data and then _later_ go through and build logic that stops certain things from being forwarded, and the result is that things slip through the cracks that shouldn't. Rather than the inverse where you only forward things explicitly and by default do not forward.
- icehawk 1y ago
  As far as I'm aware "a session is configured as IBGP on one end and EBGP on the other end" isn't possible. You can't configure it like that, most of the BGP implementations I'm familiar with automatically treat the a same-AS neighbor as iBGP and a different-AS neighbor as eBGP. Juniper explicitly has 'internal' and 'external' neighbors, but you can't configure a different peer AS than your own on an internal neighbor or the same peer AS on an external neighbor. BGP sessions also have the AS of the neighbor specified in the local config, and will not bring up the session if it's not what's configured.
zajio1am 1y ago
Without this behavior it would be impossible to deploy newer BGP attributes globally.
- sc68cal 1y ago
  I understand that, but it's a double edged sword. We enjoyed that flexibility for a long time, but lately we are now experiencing the downsides of this flexibility.

spwa4 1y ago

BGP has classes attributes that it forwards. While it is true that it forwards route attributes it doesn't know about, this was an attribute that it DID know about and knows it shouldn't forward. In fact it's a bit strange just how lenient Juniper's software was here. If a session is configured as IBGP on one end and EBGP on the other end, it should never get past the initial message. Juniper not only let it get past the connection establishment but forwarded obviously wrong routes.

sc68cal 1y ago
Yes but you are seeing a symptom of what I believe is a fundamental design decision to be liberal in passing on data and then _later_ go through and build logic that stops certain things from being forwarded, and the result is that things slip through the cracks that shouldn't. Rather than the inverse where you only forward things explicitly and by default do not forward.
icehawk 1y ago
As far as I'm aware "a session is configured as IBGP on one end and EBGP on the other end" isn't possible. You can't configure it like that, most of the BGP implementations I'm familiar with automatically treat the a same-AS neighbor as iBGP and a different-AS neighbor as eBGP. Juniper explicitly has 'internal' and 'external' neighbors, but you can't configure a different peer AS than your own on an internal neighbor or the same peer AS on an external neighbor. BGP sessions also have the AS of the neighbor specified in the local config, and will not bring up the session if it's not what's configured.

zajio1am 1y ago

Without this behavior it would be impossible to deploy newer BGP attributes globally.

sc68cal 1y ago
I understand that, but it's a double edged sword. We enjoyed that flexibility for a long time, but lately we are now experiencing the downsides of this flexibility.