irp demo
Request Noction IRP Demo

Request a personalized demo/review session of our Intelligent Routing Platform

irp trial
Start Noction IRP Trial

Evaluate Noction IRP, and see how it meets your network optimization challenges

nfa demo
Noction Flow Analyzer Demo

Schedule a one-on-one demonstration of our network traffic analysis product

nfa trial
Free Noction Flow Analyzer Trial

Test drive NFA today with your own fully featured 30-day free trial

Do route optimizers cause fake routes?

route optimizersYesterday, an incident occurred where an Autonomous System (AS) advertised more than 7,000 prefixes that belong to other networks. These are “more specific” prefixes—subsets of the IP address ranges belonging to other organizations.

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:

!
ip community-list standard ACLCOMM-IRP permit 123:456
!
route-map RM-EXPORT-PROVIDER1 deny 10
match local-preference 250
!
route-map RM-EXPORT-PROVIDER1 deny 20
match community ACLCOMM-IRP
!
router bgp 65535
neighbor 10.2.2.2 remote-as 64512
neighbor 10.2.2.2 route-map RM-EXPORT-PROVIDER1 out
!


For Juniper:

protocols bgp group providers {
type external;
export [ deny-irp allow-local ];
}
policy-options {
policy-statement deny-irp {
term 0 {
from {
protocol bgp;
community IRP;
}
then reject;
}
term 1 {
from {
protocol bgp;
local-preference 250;
}
then reject;
}
then default-action reject;
}
community IRP members 123:456;
}

 

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.

Boost BGP Performance

Automate BGP Routing optimization with Noction IRP

bgp demo


SUBSCRIBE TO NEWSLETTER

You May Also Like