Accepting and Announcing Routes

Receiving and Advertising Routes to and from Customers

Providing connectivity to your customers is what you have built your network for! If you provide statically routed services to your customers (for example, leased lines or co-location) and your customers generally use your IP space, then your priority is to turn your own routing table into a secure routing table. If you also provide BGP service to your customers (you act as their transit provider and your customers announce their own IP space to you), then you will also want to configure some additional policies in your network to make life easier for your customers and for yourself.

Accepting Routes from Customers

As you set up connections to your customers, BGP will be used to announce their routes into your network. Your customers’ announcements cause your network to forward them traffic. By sending your customers’ announcements to your peers and transits (your routers will automatically prepend your own autonomous system number onto theirs); your network keeps your customers online. Since accepting routes from your customers is often directly connected to revenue, it’s important to accept as many routes from them as possible.

However, you need to perform checks on the announcements they send and not let them announce just any old routes that could severely harm the stability and security of your network.

These checks are:

• Only accept prefixes that have a valid route object in an IRR database.

• Only accept autonomous system numbers downstream of your customer that have a valid registration in your customers’ AS-SET.

• Only accept prefix lengths up to /24 IPv4 and /48 IPv6.

• Only accept RPKI valid and unknown routes. Reject RPKI invalid.

• Reject routes containing a bogon autonomous system number, bogon prefix, prefix longer than /24, or AS path of unreasonable length.

• Reject routes you originate yourself; you should never receive your own routes from a customer.

Since your customers typically send you a few routes, it may seem feasible to implement route filters manually. But in the long run this will not scale, and you’re better off using automation to implement the checks on the routes your customers send from the start. An example automation system is shown in the Appendix. This will take care of the route object and AS-SET checks referred to above.

Thanks to these checks, mistakes (they happen!) do not affect your network or the rest of the Internet. For instance, your customer could accidentally misconfigure their router and start announcing a full table to you instead of just their own routes. Without the correct filters on your side of the session you would accept and forward their announcements to the rest of the Internet, potentially disrupting business (and cat videos) worldwide.

Announcing Routes to Customers

Your customers expect to get full Internet connectivity from you. This means you will typically announce to them:

• A default route

• A full table (all routes known in the global routing table)

• Or a combination of a full table and a default route (not covered in detail)

Following the guidelines in this book means you will have a secure routing table to announce to your customers. They may receive fewer routes from you than from your competition (if your competition does not implement a secure routing table). But in Introducing Routing Security chapter we showed that this is a good thing! We also believe that providing a default route from this secure routing table is a better default route than one from a non secure routing table. Why offer a default route to networks that intentionally, or unintentionally, announce the wrong IP address space?

Receiving and Advertising Routes to and from Peers

Now that we’ve looked at how to filter customer BGP sessions, the next step is peering sessions. In this context, a peer is another BGP-speaking network, roughly the same size, or at least the same type (tier) of network, as yours, that you are exchanging routes (and therefore traffic) with. Whether those peers are private peers or peers on an Internet Exchange Point (IXP) is not important for the setup of your secure routing table.

Typically, you would receive between one and several thousand routes from a peer; the peer would send you their routes and those of their customers, and you would send them your routes and those of your customers. Note that you will not be announcing your peer’s routes to your transits – if someone is paying you to distribute their routes further upstream (to your other peers and transits) they are considered a customer, not a peer. Although you do, of course, announce routes learned from a peer to your customers.

Accepting Routes from Peers

A peer’s network is a network like yours - operated by humans with fat fingers. Just as you did for customer routes, you will also need to filter the advertisements you accept from peers. In most cases you will receive a substantial number of routes via peers, so filtering on a per prefix basis, or by manually adding policies, doesn’t scale.

Announcing Routes to Peers

You will typically announce the following routes to your peers. In this example it doesn’t really matter if it’s a private peer or if it’s on an IXP:

• Your own routes (the ones that your AS originates)

• Your customer’s routes (the ones that you learn from your BGP customers)

For example, if you tag routes received from your customers with a unique community and a general ‘customers community’ you can then advertise specific, or all, customer routes really easily to your peers. Think about the possibilities if you extend this method to peers and transits – and realize that the hard work is actually done in the import policies, not the export policies. Once your import policies filter and tag all received routes correctly, your routing table is clean and exporting routes from it will be a breeze.

Receiving and Advertising Routes from and to Transit Providers

So far, we’ve been talking about running BGP with your customers (who will send you only their own routes) and peers (who will send you their own routes, plus those of their customers).

In contrast, a transit will send you a ‘full table’, meaning that they will send you all the routes they know – a route to every destination on the Internet (hopefully filtered using RPKI, etc.).

A transit provider typically does not send a default route, although they can usually do so on request. In addition to sending you their full routing table, a transit provider will also accept your routes and send them to all of their customers, peers, and other transit providers, making them transport traffic on your behalf and sending it on to your network. So it seems likely that you will always want to accept all routes from your transit providers. But then, not everything is what it seems!

Accepting Routes from Transit Providers

When it comes to accepting routes from your transit provider, you of course need to accept the vast majority of them in order to make your network capable of reaching the entire Internet. However, even transit providers may send you routes that you may want to refuse, such as:

• RPKI invalids;

• Routes containing a bogon autonomous system number, bogon prefix, prefix longer than /24, or AS path of unreasonable length;

• Routes originating from your own network; you should never receive your own routes from a transit.

Announcing Routes to Transits

Typically, you would announce your and your customer’s routes to your transit providers—remember the TIP where we used communities to tag those routes? This is the same set of routes that you would announce to your peers. Therefore, the same rules apply as with the ‘Announcing routes to peers’ instance described earlier in this chapter.

Conclusion

After implementing both the import and export filters and enabling RPKI, both of which are detailed in the next chapters, you should arrive at a situation as illustrated in Figure 2.1, where it is very clear what you accept from whom and to whom you advertise.

To make it easier remember this simple rule: you should always tag received routes with communities and advertise to the right parties based on these communities. This will make your life much easier.