Previous Section  < Free Open Study >  Next Section

Migrating IS-IS from Narrow to Wide Metrics

As discussed in Chapter 3, IS-IS needs wide metrics enabled in order for MPLS TE to work. However, if you're running IS-IS already, chances are you're not running with wide metrics enabled. You might also have some devices in the network that don't understand wide metrics at all. The tricky bit in migrating from narrow to wide metric support is that you need to do so with as little service disruption as possible. If you just go to some routers and turn on metric-style wide, routers that don't understand wide-style metrics will not understand the IS-IS advertisements from the wide-style routers, and your network will break. So the goal here is to enable wide metrics with as little service disruption as possible.

The resolution of this problem is fairly simple if you follow the steps covered next.

Assuming that all routers start at narrow metrics only (the default), you have a couple of choices:

  • Moving from narrow to wide metrics in two steps

  • Moving from narrow to wide metrics in three steps

Moving from Narrow to Wide Metrics in Two Steps

Moving from narrow to wide metrics in two steps is the shorter of the two migration strategies:

Step 1. Configure all routers to both advertise and accept both old and new TLVs with the command metric-style transition. If not all routers in your network understand wide metrics, you'll have to stay at metric-style transition until you can get those routers to code that understands wide metrics.

Step 2. Configure all routers to both advertise and accept only new-style TLVs by using metric-style wide instead of metric-style transition.

The advantage of configuring all routers to both advertise and accept both old and new TLVs is that you have only two steps to go through, so you can migrate to TE faster, with less maintenance windows devoted to migration. The downside is that when you both advertise and accept old- and new-style TLVs, the size of your link-state database (LSDB) doubles. This is not a concern on most networks, but if your network is extremely large, this might be an issue for you. Check the Holding column of the IS-IS Update entry in show processes memory, as demonstrated in Example 10-13.

Example 10-13 Checking the LSDB Size with the show process memory Command

gsr3#show processes memory |  include IS-IS Update |  PID

 PID TTY  Allocated      Freed    Holding    Getbufs    Retbufs Process

 126   0   10882888    2950160     219460          0          0 IS-IS Update

If doubling this number is of concern to you, consider the other method of transitioning from narrow to wide metrics.

Moving from Narrow to Wide Metrics in Three Steps

This method is longer, but it sidesteps the problem of doubling the size of your LSDB. The steps to do this are as follows:

Step 1. Configure all routers to advertise only old-style TLVs but accept both old and new using the command metric-style narrow transition.

Step 2. Configure all routers to advertise new-style TLVs and accept both using the command metric-style wide transition.

Step 3. Configure all routers to advertise new-style TLVs and accept only new-style TLVs using the command metric-style wide.

This avoids doubling the size of your database, but at the expense of one additional migration step. The choice is up to you. As long as you end up at metric-style wide, it doesn't matter how you get there.

The section "Migrating an IS-IS Network to a New Technology" in the "Multiprotocol Label Switching Overview," which you can find on www.cisco.com (also see Appendix B), provides excellent coverage of how to do this.

    Previous Section  < Free Open Study >  Next Section