IS-IS, MPLS-TE, and wide metrics

I came across an interesting topic in the book Traffic Engineering with MPLS yesterday. The topic involves migration from narrow to wide metrics. As you know, wide metrics are required to support MPLS TE, so if you have a network that is currently deployed with narrow metrics (the default) you will have to migrate to the wide metric style. You may even have devices that only support narrow metrics, so you’ll have to figure out what to do with them in the meantime – perhaps they won’t be in the path of TE tunnels, so you might not need to replace/upgrade them immediately. Anyway, starting on page 465, the book details two procedures to migrate from narrow to wide metrics:

  1. migrating from narrow to wide metrics in two steps
  2. migrating from narrow to wide metrics in three steps

Why the difference in steps? Well, the first one involves enabling all routers to advertise & accept both styles of metrics, which will increase the size of your LSDB by roughly 2x. The three step program takes longer but does not require the same amount of memory.

Here’s a good link from cisco referenced in the book. Transitioning IS-IS to a New Technology

Share/Save/Bookmark

Book Review: Definitive MPLS Network Designs

I have access to safari books through my employer, so I’ll be doing some brief reviews of each book to determine whether or not I’ll be buying it for further study.

The first of this series is Definitive MPLS Network Designs. The book contains several case studies that will be helpful in studying for the CCDE. There is a brief overview of the various technologies that are used with MPLS, but the technical content is not deep. This book concentrates on design aspects by examining design issues related to the following network types:

  • Interexchange Carrier
  • National Telco
  • Global SP
  • Large Enterprise

Buy or don’t buy? Since the CCDE concentrates on design rather than implementation, case studies are a must as part of your path to certification. I’ll be buying the book.


Share/Save/Bookmark

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…