I am not very familiar with Juniper config, but this phrase summarizes it well. "This means we (AS13335) took the prefix received from Meta (AS32934), our peer, and then advertised it toward Lumen (AS3356), one of our upstream transit providers. " basically you should not receive a prefix from an eBGP session ( different AS) and advertize to an eBGP session. As they mention at the next steps, good use of communities could help avoiding it, in case of other misconfigurations.
Yes of course, but from a test perspective, this kind of mistake, given their configuration snippet and how they wrote the RCA, it seems to suggest they were simply diff-ing the initial and desired configs as any VCS would do (or, more likely, a Juniper “show|compare” command).
This didn’t catch the fact that removing that line essentially removed all conditions, allowing received routes to be re-advertised by the Miami router.
Communities are useful in this case, but this kind of thing could have happened with any kind of configuration.
Example:
(Before)
set firewall family inet filter FILTER NAME term TERM1 from source-address 10.10.10.1
set firewall family inet filter FILTER NAME term TERM1 from destination-port ssh
set firewall family inet filter FILTER NAME term TERM1 then discard
What happens when you remove references to 10.10.10.1, maybe because that IP is not blacklisted anymore? You’re simply removing one condition, leaving all ssh traffic to be discarded. That’s essentially what happened with the BGP outage, only here you have no BGP communities to save you.
That’s why I re-read the RCA, because this kind of incident is way more general than BGP-specific misconfigurations.
