BGP inbound traffic policy. Here's one way how not to do it.

When it comes to creating an inbound traffic policy for your network, there are a few options available. This post looks at a common misconception when attempting to use more specific prefixes to influence inbound traffic to your network.

A relatively simple and common way to influence inbound traffic is to advertise more specific prefixes over one peer than another. Let's use the following diagram as an example.

In this example, R1 advertises 2x /25 whilst R2 advertises 1x /24 to R3 and R4 over BGP. Looking from R3's perspective for a moment, it has 3 prefixes in its routing table, and based on basic IP forwarding principles, R3 will always match the more specific route in its routing table when making a forward decision. In other words, any traffic destined to 10.0.100.0/24 will match either of the /25 addresses and be sent to R1. R3 is happy as it has fulfilled its purpose in life. The same can't be said about R1 though - emotional damage.

There's a problem with this approach. In this scenario, R1 is connected to 10.0.100.0/24, and adds two static routes 10.0.100.0/25 and 10.0.100.128/25 with Null0 as the next hop. This will allow the prefixes to be added to its BGP table, i.e. network or redistribution, and advertised, but returning traffic will be blackholed as these networks are more specific than its connected network - administrative distance or AD isn't taken into consideration here because as far as R1 is concerned these routes are different.

The misconception is that you can utilise static routes in the way described to create a route summary, advertise it over BGP and influence inbound traffic. As shown, you can but R1 will drop packets rendering this approach not fit for purpose. The static routes are not summary routes and no larger prefixes, i.e. /26 to /32, exist in R1's routing table.

What other options are there? Assuming you can only manipulate your network's policy - which is often the case over public networks - would be to consider manipulating the AS PATH or MED attributes or actually create a route summary for your connected prefix, i.e. a /23 maybe, if you're a die hard about using specific prefixes. That's content for another post, another time.

Summary

When it comes to using BGP to create an inbound or outbound policy to your network there's no absolute right or wrong answers. BGP has plenty of attributes and features to help you achieve what you want based on the design requirements and constraints. Having multiple options often leads to confusion and basic networking foundation principles are overlooked, but even then, if enough questions are asked at least a couple of feasible options will come to the surface. In other words, I have plenty of tools in my toolbox. I love every single one of them, but in all honesty, most of the work I do can be accomplished with a simple screw driver.

Disclaimer

Multiple packets were dropped in the making of this post.