Configuring Routing Policies

Building Blocks: Basic Filtering Rules

Next we'll address the policies that will be referred to by other policies. They are not unique per customer/ peer/transit and need to be defined only once.

In this section, we are not showing you actual policies. You will cut and paste relevant prefix lists and AS path groups, though, that are used in the policies later on in the chapter.

Reject Bogon Autonomous System Numbers

A BGP route announcement contains a field, called AS path, consisting of the autonomous system numbers from all networks that propagate the route advertisement in order to reach its destination, the originating autonomous system number.

The AS paths you see in your routing table are automatically created as each network propagating a route advertisement prepends its own autonomous system number to the path. Finally, it is possible to manually prepend an autonomous system number in order to influence routing decisions.

In addition to the public autonomous system numbers assigned by the RIRs, there are private autonomous system numbers that are to be used for different purposes (like private peering with networks that do not need an RIR-assigned autonomous system number).

All autonomous system numbers used to be 16-bit numbers (from 0 up to 65,535), but these days 32-bit autonomous system numbers are universally supported. The different types of autonomous system num- bers are:

• 0: reserved

• 1 through 64,495: public autonomous system numbers

• 64,496 through 64,511: reserved to use in documentation

• 64,512 through 65,534: private autonomous system numbers

• 65,535: reserved

• 4,200,000,000 through 4,294,967,294: 32-bit private autonomous system numbers

A popular use of private autonomous system numbers is using such numbers (from a private autonomous system numbers list) for networks that do not have an autonomous system number assigned by an RIR in order to establish a BGP session with an upstream network. In this case, mistakes are easy to make. Private autonomous system numbers can accidentally leak into a publicly visible AS path. Or sometimes a network operator will mistype the autonomous system number they wish to prepend, polluting the path you receive. Therefore you have to reject route advertisements that contain a private or reserved autonomous system number.

The bogon autonomous system numbers are defined in RFCs. The list below shows exactly which RFC describes the bogon autonomous system number, so if you want to learn more about why a certain autono- mous system number should not be in your secure routing table, you can consult the relevant RFC.

Define an as-path group that lists the bogon autonomous system numbers:

You do this by entering the following commands:

Remember, this is not the actual policy yet. The policy calling these prefix lists is coming up, so please read through a few more paragraphs!

With this policy your routers will filter routes that you receive from outside and that may contain a private autonomous system number. In order to avoid private autonomous system numbers being announced (sent) from your network, it is good practice in DFZ operations to enable the remove-private option on EBGP sessions.

For example:

Make sure you have this option set on all your EBGP sessions.

Reject Bogon Prefixes

A bogon prefix should not be visible in the global routing table, as these prefixes are meant for internal use (RFC 1918), test networks (RFC 4737), multicast, and other internal purposes. Thus these prefixes should never be accepted or advertised to the DFZ.

You can create a prefix list as follows:

You do this by entering the following commands:

The same for IPv6 commands:

The policy calling these prefix lists is coming up, only a few more paragraphs!

Reject Long Prefixes

The global routing table in the DFZ is expanding daily, as more and more networks start announcing more and more prefixes. In principle, there is no problem announcing routes of any length – technically, even a /32 route (for a single IPv4 address) will work. However, uncontrolled growth of the routing table is not sustainable (just calculate how much bigger the DFZ would be if all IPv4 space would be announced as a /32). Many networks have started filtering on prefix length.

These days you can generally expect your announcement to be dropped if you announce a prefix that is /25 or longer (a subnet of 128 IPv4 addresses or less). The following policy configures your network to do the same, so all these pesky little /28 and /32 routes don’t make it to your RIB. The same applies to IPv6 where we put the boundary at /48 subnets.

The policies to filter out routes for these long prefixes appear later in the chapter. They consist of two steps: a generic policy that is called and returns only prefixes of sufficient length, and a policy that takes this list and filters only the relevant routes from it.

Reject Long AS Paths

We’ve seen before that each network on the route automatically “builds” an AS path, adding its own autonomous system number to the front of the AS path of the advertised route. In practice, since BGP looks for the shortest AS path by default, most active routes your network uses will have an AS path of only 1 - 6 autonomous system numbers. Perhaps sometimes a path can be longer, and then of course there is manual AS path prepending (as a traffic engineering measure), which causes longer paths to be seen in the table. But generally speaking, an AS path longer than a dozen or so autonomous system numbers can be considered useless. If you see such a long AS path, it is probably the work of a network administrator who needs a copy of this book.

The most common reason for extremely long AS paths is prepending. Using two to three times your own autonomous system number in a prepend is, when needed, considered a good practice to influence routes. However, prepending more than that doesn’t make sense. Looking at the DFZ, at the time of this writing there are some prefixes with an AS path length of about 40 autonomous system numbers, which we highly doubt is useful. Let’s take a safe margin, and consider everything with an AS path of more than 50 to be useless and deserving to be filtered out in our secure routing table.

As always, define what you want to filter first:

And then, read on to get to the policy where we call this definition! Just one more building block to go.

Reject Routes Containing Known Transit or Very Large Network Autonomous System Numbers

The biggest networks in the world (mainly known as “Tier-1”) never buy transit from each other or from smaller (“Tier-2”) networks. For instance, it would be very strange if your customer or peer started sending you routes that have AS2914 (NTT) or AS1299 (Telia) in their AS path; it is not very likely that NTT or Telia would buy transit from your customer. Therefore, your import policy also contains AS path filters that reject routes that have the AS numbers of the “big names” in them. If you would legitimately receive these from a customer or peer, you are probably not the target audience for this book.

The same goes for some of the other very large networks like Facebook, Google, Microsoft, and Cloudflare. They will probably not buy transit from your peers, so if you receive their routes from your peers, there must be something fishy going on. So why not make sure you won’t use any of these routes, which you know are not correct in the first place?

First, let’s define the AS path group:

Using this AS path group in the policy that’s coming up protects you from accepting routes that your customers or peers are accidentally leaking to you. How this fits into the bigger picture will be shown later on.

Make sure to add this policy only on your customer and peer BGP sessions (and not to your transits) or you will end up with a very small (and a very limited) usable routing table!

Reject the Remainder

By default, the last action in the Junos OS implementation of BGP is to allow everything that is left after policies. The default behavior will become configurable in the future to stay compliant with the BGP-4 specifications and as defined in https://tools.ietf.org/html/rfc8212. Though, at the time of writing this book, RFC8212 hasn’t been implemented, so you should make sure you have a policy in place to reject the remainder.

Define a policy that simply rejects all routes that it sees:

Or in cut-and-paste commands:

This policy is used later on to create an explicit reject, meaning that you do not rely on whatever the protocol (BGP) does at the end of a policy chain. It is always better to make your configuration clear and explicit (think of your most junior network admin having to troubleshoot a network outage at 4 AM).

Filtering Customer Routes

Finally, it’s time to configure some actual routing policy! First, let’s look at how to filter routes that you receive from your customers, and how to set up a policy to announce routes to your customers, both for default route and full table scenarios.

Accepting Routes from Customers

Checking the routes that you accept from your customers is the most important bit of configuration in your network! In the end, you need to announce your customer’s routes to others. Those announcements need to be clean and contain only correct routing information – so let’s start by accepting clean routes only, then you won’t have to worry about bringing the Internet to a halt.

The routing policy that you will use to filter the routes received from customers will include a list of the prefixes that the customer is allowed to advertise. In this example you configure the prefix list manually, but in the Appendix you’ll find the way to get the prefix lists to auto-update! After finishing this book you should feel comfortable using this configuration for filtering your customer’s routes, and don’t forget to implement automatic prefix-list updates so your routing table remains secure!

The configuration below assumes that your customer’s AS number is 123 and they will be announcing 192.0.2.0/24 and 2001:db8::/32. It also assumes that your own AS number is 456:

You configure these by entering:

In addition, let’s create two BGP communities that the policies use, as well as one you will need later on:

When creating the discard ‘anchor route’ to originate your prefix, you can tie this community to it:

Now, onto the policies that will actually accept your customer’s routes. It all starts by accepting the exact prefix that they are allowed to announce following the prefix-list:

You configure this by entering:

This policy is unique to every BGP customer you have, just like every prefix list is unique to each BGP customer. You apply this import policy on the BGP session with your customer in the import policy chain.

We added the BGP community MYCUSTOMER to the routes accepted from your customer. This makes it easier to export these routes later on.

Next, your customer may announce more specific prefixes to you. The prefix list entry may have a /22 defined, for instance, but you want to allow your customer to announce up to a /24. Simply using prefix-list-filter AS123 orlonger doesn’t work, because that would allow the customer to announce up to a /32. So first, create a policy that allows routes up to /24, and then combine that with the policy allowing these routes if they are inside the customer prefix list:

Note that policy-statement MORE-SPECIFIC-UPTO-24 is generic – it is configured on the router only once and used for all customers. The policy-statement IMPORT-123 is unique to each customer, however, and has to be configured once per customer.

You configure these policies by entering:

The policy MORE-SPECIFIC-UPTO-24 needs to be defined only once. The customer’s AS or prefixes are not referenced in this policy. The policy IMPORT-123 has to be defined once per customer, though.

The exact same logic applies for the IPv6 policies, where you will accept routes up to /48:

You configure this by entering:

Like with the IPv4 policies, the policy MORE-SPECIFIC-UPTO-48-INET6 needs to be defined only once. The customer’s AS or prefixes are not referenced in this policy. The policy IMPORT-123-INET6 has to be defined once per customer, though.

Finally, you may choose to allow your customers to announce even more specific routes to you – more specific than a /24. They could use these routes for traffic engineering, for instance. While you may carry them in your network, you should not announce them to your other customers, peers, or transits. This is why we will accept them here, but add the well-known “NO-EXPORT” BGP community to them:

You configure this by entering:

And for IPv6:

And you configure this by entering:

Now that we’ve defined the import policy for your customer’s routes, you may wonder where the final reject policy that will reject routes that the customer is not allowed to announce is. You’re correct of course – here is the entire policy that you will use for importing routes from your customers:

The BGP Configuration

The final part of the configuration for importing customer routes is to configure the policies as import policies on the BGP session with the customer. Remember that the first policy, TRANSIT-CUSTOMER-GENERIC, is generic and needs to be defined only once; the second policy is AS specific. Each customer has three policies chained together:

1. The generic policy that rejects the unwanted routes;

2. The customer-specific policy that accepts the customer’s routes;

3. A final reject policy that rejects everything else.

For instance:

Another customer would be:

Announcing Routes to Customers

Your customers receive your network’s routes, which enables them to use your network for sending traffic. This can be either a full table, or a default route. If you wish to send your customers a default route, be sure to generate one by creating a discard default route.

After reading the examples for full table and default route exports, it should be easy for you to create a policy catering to those customers that wish to receive a full table as well as a default route.

Announcing a Full Table to Customers

The policy for sending a full table is more complicated than it would seem. It is necessary to drop routes that have the NO-EXPORT community, for instance. And don’t forget to add a term that accepts the routes that your own network originates – a very common mistake is to send your transit customer only the routes that you have learned via EBGP (which is BGP default behavior), and not include your own routes:

Or in cut-and-paste form:

Announcing a Default to Customers

The policies for sending a default route to customers are easy:

Or in cut-and-paste commands:

This will work if you have a default route in your network already. Remember our warning above in case you don’t have one.

The BGP Configuration

The final part of configuration for exporting routes to customers is to configure the policies as export policies on the BGP session with the customer. All export policies are generic and need to be defined only once. Each customer has two policies chained together:

1. The generic policy that accepts either default or full table routes.

2. A final reject policy that rejects everything else.

For instance:

Another customer would be:

Filtering Peering Routes

The policies for peers are a little different from those for customers, but not by much. For peers, you reject the same routes as for customers, and you accept routes inside their AS-SET (if you have automatic prefix filtering implemented). Of course, you reject default routes, RPKI invalids, long AS paths, and bogons. The only major changes are taking a different local preference (lower than customer routes), not adding the BGP community for exporting the peer routes, and not allowing any prefix longer than /24.

Accepting Routes from Peers

This is the entire policy statement for importing routes from peers:

Or in cut-and-paste form:

The BGP Configuration

The final part of configuration for importing peer routes is to configure the policies as import policies on the BGP session with the peer. Remember that the first policy, PEER-GENERIC, is generic and needs to be defined only once; the second policy is AS specific. Each peer has three policies chained together:

1. The generic policy that rejects the unwanted routes.

2. The peer-specific policy that accepts the peer’s routes.

3. A final reject policy that rejects everything else.

For instance:

Announcing Routes to Peers

Your peers should receive your own routes and the routes of your customers. Fortunately, we have used BGP communities to tag these routes, so it is very simple to create the relevant policy statements:

Or in cut-and-paste form:

The BGP Configuration

The final part of the configuration for exporting routes to peers is to configure the policies as export policies on the BGP session with the peer. All export policies are generic and need to be defined only once. Each peer has two policies chained together:

1. The generic policy that accepts your routes and customer routes.

2. A final reject policy that rejects everything else.

For instance:

Filtering Transit Routes

The policies for your transit providers are once again a little different from those for peers, but again not by much. For transits, you reject the same routes as for peers: default routes, RPKI invalids, long AS paths, and bogons. The only major changes are accepting routes from the “big networks” instead of rejecting them, taking a different local preference (lower than peer routes), not adding the BGP community for exporting the transit routes, and accepting all remaining routes instead of rejecting them.

Accepting Routes from Transits

This is the entire policy statement for importing routes from transits:

Or in cut-and-paste form:

The BGP Configuration

The final part of configuration for importing transit routes is to configure the policies as import policies on the BGP session with the transit provider. Remember that the first policy, TRANSIT-GENERIC, is generic and needs to be defined only once; the second policy is AS specific. Each transit has three policies chained together:

1. The generic policy that rejects the unwanted routes.

2. The transit-specific policy that accepts the transit’s routes.

3. A final reject policy that rejects everything else.

For instance:

Announcing Routes to Transits

Your transits should receive your own routes and the routes of your customers. As with exporting routes to peers, here we use BGP communities to tag these routes, so it is very simple to create the relevant policy statements:

And in cut-and-paste form:

The BGP Configuration

The final part of configuration for exporting routes to transits is to configure the policies as export policies on the BGP session with the transit. All export policies are generic and need to be defined only once. Each transit has two policies chained together:

1. The generic policy that accepts your routes and customer routes.

2. A final reject policy that rejects everything else.

For instance:

Conclusion

From a policy perspective your routers now have what it takes to filter routes, create a secure routing table, and talk BGP to your customers, peers, and transit providers. Your network should be in great shape! Well done!

You might have noticed that we did not configure policies to filter routes you originate on customer, peer, and transit sessions. This was done on purpose, as by nature BGP will filter announcements containing your own AS number in order to prevent loops. If you receive a route advertisement containing your prefix but originating from a different AS number, RPKI will filter those if you have created ROAs. It is however never bad to explicit filter out your own routes on all eBGP sessions.

Next, some ways to check if things are going right and what to do if they aren’t.