Abstraction, Layering, and a little Anycast

Ok, so the post from yesterday asked you to look at a diagram and determine where a packet would route and why it might take that path. Hopefully some of you have had a chance to lab it up to test any theories you have. Even if you haven’t we can still have a look and draw some logical conclusions.

We know from the diagram that 10.0.0.1/32 is directly connected to R1, so no matter what, it will take the directly connected path. However, R2 will learn about the 10.0.0.1/32 prefix via IGP (OSPF) and EGP (BGP). The default eBGP administrative distance is 20, whereas OSPF is 110. My initial thought is that if R2 learns about 10.0.0.1/32 via eBGP as well as OSPF, eBGP will be preferred because of the lower AD. To some extent this is true. If you choose to not advertise the 10.0.0.1 prefix to eBGP neighbors, then it will be preferred via eBGP. However, once you include the network statement, it will choose the IGP path.

Here are some outputs:

R1 (show ip route):

C 10.0.0.1/32 is directly connected, Loopback1

R2 (show ip route, show ip bgp, show run):

O 10.0.0.1/32 [110/11] via 10.1.34.2, 09:14:11, Ethernet0/1

(10.1.34.2 is the IGP neighbor advertising this prefix):


BGP table version is 2, local router ID is 192.168.0.3
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal, r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

Network Next Hop Metric LocPrf Weight Path
* 10.0.0.1/32 10.1.13.1 0 0 100 i
*> 10.1.34.2 11 32768 i

router bgp 200
no synchronization
bgp log-neighbor-changes
network 10.0.0.1 mask 255.255.255.255
neighbor 10.1.13.1 remote-as 100
no auto-summary

Watch what happens when I remove the ‘network’ statement:

R2 (show ip route):

B 10.0.0.1/32 [20/0] via 10.1.13.1, 00:00:06

It’s being learned via eBGP!

This could be a problem depending on whether you want to advertise this prefix to your eBGP neighbors. You can use the network backdoor command so the router will prefer IGP learned routes over eBGP learned routes, but this command will not advertise the network to your eBGP neighbors. You’ll get a rib-failure – shown below in the output from show ip bgp:


Network Next Hop Metric LocPrf Weight Path
r> 10.0.0.1/32 10.1.13.1 0 0 100 i

When designing networks, you must have deep knowledge of how protocols operate and interact with other protocols. The BGP/IGP interaction is one of these, and this is just a small example.

Share/Save/Bookmark

IP Routing: Aggregation Concepts and Techniques

  • Purpose of route aggregation
  • Scalability and fault isolation
  • How to Aggregate

What is the purpose of route aggregation? We aggregate routes to decrease the sizes of our routing tables, hide information, and decrease convergence times. The boundary device – ASBR / ABR / whatever – will use a route summarization technique to aggregate prefixes towards the direction of advertisement. For example, if you own the 10.0.0.0/8 network, and you’re advertising this network to a customer, you may wish to simply advertise the classful network rather than advertising more specific prefixes (like 10.1.1.0/24, etc.) even if you have your network subnetted. By only advertising the aggregate, the size of your customers routing tables is minimized, which decreases the amount of calculation needed during reconvergence and hides information about how your AS is subnetted. The advertisement of a default route towards the access layer is also an example of aggregation. How does one accomplish the task of aggregation with various routing protocols?

  • BGP: the use of the aggregate-address <NET> <MASK> <summary-only> command
    • at least one more-specific address in that NET need to be present in the IGP and either redistributed into BGP or present in a network statement
    • you can use a route to Null0 to create this IGP route
  • OSPF: stub and the area <Area #> range <NET> <MASK> command
    • best practice is to create a route to Null0 to avoid routing loops
    • you may also need to look at no rfc1583 compatible command
  • EIGRP: stub and the ip summary-address eigrp <AS> <NET> <MASK> interface command
    • Remember that when you do this, a route to Null0 is automatically created
    • EIGRP also automatically summarizes, so you may want to disable this with the no auto-summary command

References: OSPF Design Guide EIGRP Design Guide BGP Case Studies

MPLS notes

I took a class this past week for some more formalized MPLS training. I will be posting some notes to remind myself of key ideas.

There are a few key take-aways that helped me understand the how and why of MPLS. I knew the basics, like how MPLS uses ‘tags’ instead of layer 3 addresses to switch packets. A few years ago this was an important differentiator because if the routers could avoid a layer 3 lookup they could switch packets much faster. This advantage has become obsolete because most lookups are done in hardware, or at least installed in hardware after an initial layer 3 lookup that is done in software.

Anyway, besides that I didn’t realize the benefits to service providers and I’ll try to outline them below:

MPLS allows providers to keep external routes at the edges of their networks.

Why is this important? iBGP requires a full-mesh of peers, and if you don’t run BGP on all transit links you’ll wind up blackholeing traffic. Let’s say you learn about the prefix 192.168.1.0/24 from one of your customers via eBGP. You advertise this to your iBGP neighbor across the cloud, which is maybe 3 routers in diameter. Another customer then wants to send traffic to this network which you have advertised. A packet with the destination of 192.168.1.1 comes into your network, hits the second hop which does not have a route to 192.168.1.1 in its table. The route isn’t there because you haven’t redistributed it into your IGP.

There are two solutions to this problem. You can advertise the eBGP learned routes into your IGP, or you can run iBGP across all your transit routers. Either solution doesn’t scale particularly well. With redistribution, your IGP will have to scale to the number of routes your customers will have, potentially hundreds of thousands. There isn’t an IGP that can handle this. The other solution: full iBGP mesh, requires [n*(n-1)]/2 peering relationships. You can use route reflectors, but this is difficult to scale as well.

The solution MPLS provides is elegant. You simply run an IGP like you normally would, run MPLS on top of your network, and peer using the loopback interfaces of your edge BGP speakers. MPLS builds a forwarding table based on the loopbacks, so when a packet comes into your network bound for 192.168.1.1, your edge BGP router does a layer 3 lookup, finds the next hop of the remote iBGP peer loopback, and encapsulates it inside an MPLS packet. The intermediate routers then use MPLS tags to switch the packet to the remote iBGP router.

Think about that and read it again. MPLS removes the requirement of full mesh, and removes the requirement to redistribute routes into your cloud. This permits service providers to scale to a very large network.

In short: MPLS permits SP networks to keep their routing tables at the edges of their networks. Your transit routers don’t have to carry your edge routes and they also don’t have to worry about convergence.

More to follow…