Do route optimizers cause fake routes?

Due to the way BGP works, traffic preferentially flows towards these more specifics, with the result that traffic towards destinations such as parts of Amazon EC2 then went to an incorrect AS.

There are multiple reasons as to why such incidents can occur:

1. More specific prefixes were generated in this AS. This is not routine BGP behavior.
2. The AS propagated the more specific prefixes, even though they don’t belong to said AS.
3. At least one of the AS’s upstream ISPs accepted the more specific prefixes, even though they don’t belong to the afore mentioned AS.

Two of these are easily explained. The more specific prefixes are generated by Noction IRP – a route optimizer that is commonly deployed in various BGP networks. IRP is a product that optimizes network traffic by adjusting BGP routing in real-time. IRP uses more specific prefixes in order to influence traffic flow without modifying the original BGP information.

Normally, ISPs have filters to make sure they only accept the correct prefixes from their customers. As far as we’ve been able to determine, the reason that other ISPs have accepted the more specific prefixes belonging to other organizations is that these aren’t actually ISPs that the afore mentioned AS pays for connectivity, but rather, they’re peers on the Los Angeles Internet Exchange. Due to the scale of BGP information that is exchanged over internet exchanges, it’s often infeasible to apply the kind of filtering here that ISPs apply to their customers.

This leaves one last line of defense against leaking more specific prefixes: the filters that limit outgoing BGP updates that an AS sends to its peers. We wrote a blog post about this in October: Filtering your BGP updates. Human error is usually the main cause of this type of issue, but bugs in whatever router being used can also not be ruled out.

In order to further reduce the likelihood of these problems occurring in the future, we will be adding a feature within Noction IRP to give an option to tag all the more specific prefixes that it generates with the BGP NO_EXPORT community. This will not be enabled by default, due to potential drawbacks; such as customers who use multiple ASes or customers who have eBGP sessions with private ASes, but it will be an option if a customer wants to use it. This way, even if filters fail, more specific prefixes won’t be propagated to external autonomous systems.

In the meantime, these configuration snippets will filter out the more specific prefixes generated by IRP. (Assuming 10.2.2.2 is the address of an external BGP peer with AS number 64512 and 123:456 is a community added by IRP.)

For Cisco:

For Juniper:

Note that if additional filtering or application of policy is required, this needs to be added at the end of the route map or policy statement listed above.