Multi-level IS-IS in a single area? Think again!

Many service providers choosing IS-IS as their IGP use it within a single area (or at least run all routers as L1L2 routers). Multi-level IS-IS design is a royal pain, more so in MPLS environments where every PE-router needs a distinct route for every BGP next hop (see also Disable L1 Default Route in IS-IS). Moreover, MPLS TE is reasonably simple only within a single level (L1 or L2).

I’m positive at least some service providers do something as stupid as I usually did – deploy IS-IS with default settings using a configuration similar to this one:

Typical IS-IS configuration

interface Loopback0
 ip address 10.0.1.1 255.255.255.255
 ip router isis
!
interface Serial1/0
 description Link to P router
 ip address 10.0.7.9 255.255.255.252
 ip router isis
 mpls ip
!
interface Serial1/4
 description Backup link to RR
 ip address 10.0.7.53 255.255.255.252
 ip router isis
 mpls ip
!
router isis
 net 49.0000.0000.cccc.0001.00
 metric-style wide transition
 log-adjacency-changes

The above router configuration and the printouts included in this post were generated on a simple 4-router service provider network I’m using for lab configurations in the Building IPv6 Service Provider Core webinar (IPv6 has been removed to simplify the printouts).

After the IS-IS adjacencies are established, the show isis neighbors command displays the expected results: all adjacencies are L1L2 adjacencies.

PE-A#show isis neighbors

Tag null:
System Id      Type Interface   IP Address      State Holdtime Circuit Id
RR             L1L2 Se1/4       10.0.7.54       UP    27       00
P              L1L2 Se1/0       10.0.7.10       UP    25       00

The IS-IS database looks OK: every router originates an L1 LSP and an L2 LSP (there are also LSPs for Ethernet segments, for example P.02-00)

IS-IS database on PE-A

PE-A#show isis database

Tag null:
IS-IS Level-1 Link State Database:
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
PE-A.00-00          * 0x000001C2   0x730E        1081              0/0/0
PE-B.00-00            0x000001C1   0x9A01        369               0/0/0
RR.00-00              0x000001C3   0xCE94        1087              0/0/0
P.00-00               0x000001C3   0xE49B        1046              0/0/0
P.02-00               0x000001BD   0xD0D8        1023              0/0/0
IS-IS Level-2 Link State Database:
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
PE-A.00-00          * 0x000001C5   0xE601        1081              0/0/0
PE-B.00-00            0x000001C1   0x9674        1083              0/0/0
RR.00-00              0x000001C5   0xA9F9        1090              0/0/0
P.00-00               0x000001C3   0xAF39        1085              0/0/0
P.02-00               0x000001C0   0xE24C        1174              0/0/0

A detailed look in any L2 LSP reveals the horror behind the scenes: every single IP prefix known to IS-IS is advertised in every L2 LSP (there are four loopback addresses advertised by PE-A, even though it only has one).

L2 LSP originated by PE-A

PE-A#show isis database L2 PE-A.00-00 detail

Tag null:

IS-IS Level-2 LSP PE-A.00-00
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
PE-A.00-00          * 0x000001C5   0xE601        944               0/0/0
  Area Address: 49.0000
  NLPID:        0xCC
  Hostname: PE-A
  IP Address:   10.0.1.1
  Metric: 50         IS-Extended RR.00
  Metric: 10         IS-Extended P.00
  Metric: 10         IP 10.0.1.1/32
  Metric: 30         IP 10.0.1.2/32
  Metric: 30         IP 10.0.1.5/32
  Metric: 20         IP 10.0.1.6/32
  Metric: 20         IP 10.0.2.0/24
  Metric: 10         IP 10.0.7.8/30
  Metric: 20         IP 10.0.7.16/30
  Metric: 50         IP 10.0.7.52/30

The explanation of this seemingly absurd behavior is very simple: every L1L2 router leaks intra-area L1 routes into L2 topology. If the L1 and L2 topology overlap (which should not be the case), you get every single L1 prefix in every single L2 LSP. It’s obviously not a good idea to cram a round peg (IP routing) into a square hole (CLNS routing protocol with totally different addressing hierarchy).

Apart from consuming way too much memory, this behavior generates a few other side effects:

  • Every time there’s a topology change, every router in your network runs SPF twice; once for L1 and once for L2. It also changes its L2 LSP based on the results;
  • All the changed L2 LSPs are flooded across the network;
  • Changed L2 LSPs trigger partial L2 SPF in every router ... and if you’re trigger-happy and have reduced SPF timers, you might get more than one partial SPF run due to late arrival of some changes.

Obviously it makes no sense to run IS-IS in L1L2 mode if you have only a single IS-IS area. I would prefer L2-only mode; if you run IS-IS only in level-1, you might get an inadvertent default route caused by a misconfigured L1L2 router.

To change the router type to L2-only takes a single command in Cisco IOS: is-type level-2-only. According to my today’s understanding of Junos, it might be a bit more complex to do the same thing there (feedback welcome).

After the configuration change, the L2 LSP originated by PE-A contains just the local IP prefixes:

L2 LSP originated by PE-A running in L2-only mode

PE-A#show isis data PE-A.00-00 detail

Tag null:

IS-IS Level-2 LSP PE-A.00-00
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
PE-A.00-00          * 0x000001C8   0xFE7C        1184              0/0/0
  Area Address: 49.0000
  NLPID:        0xCC
  Hostname: PE-A
  IP Address:   10.0.1.1
  Metric: 50         IS-Extended RR.00
  Metric: 10         IS-Extended P.00
  Metric: 10         IP 10.0.1.1/32
  Metric: 10         IP 10.0.7.8/30
  Metric: 50         IP 10.0.7.52/30

Summary: Unless you have very good reasons to do otherwise, run IS-IS in a single area and configure all routers as L2-only routers (and remember: using recipes without understanding them can hurt your network).

12 comments:

  1. as far as I know in junos
    set protocols isis level 1 disable
    will do the same

    Nitzan

    ReplyDelete
  2. Marko Milivojevic23 November, 2011 09:38

    Few comments :-)

    Inter-area MPLS-TE works to some extent in IS-IS, with either loose next-hop or with a verbatim statement (your trick for TE with EIGRP).

    Another one, the comment about misconfigured L1L2 router leaking a default route. Chances of that happening are slim, since to leak a default route, that L1L2 would have to have L1 adjacency as well as L2 adjacency in order to generate an update with ATT bit set, which would cause L1 routers to install a default route. Unlike OSPF's ABRs, IS-IS border routers don't actually advertise the default.

    The rest - I couldn't agree more on.

    -Marko.

    ReplyDelete
  3. According to my understanding of the documentation, you can disable in an IS-IS level only on a per-interface basis.

    ReplyDelete
  4. Another one of my "what's not white is black" blunders :-P

    Of course I know there's loose next hop (even had it working in the lab once) and I wanted to say something along the lines of "automatic MPLS TE" or "it's simple within a level" ... Another proof that English is not my native language :-$

    As for a misconfigured router - have to test what happens if you run multiple IS-IS instances on the same box (before you tell me how stupid I am: this is pure speculation).

    ReplyDelete
  5. in the interface you put the metric,hold-time etc ... under level 2 but there you dont have to disable level 1 if you did it in the under the protocol

    ReplyDelete
  6. You can do it at router level also:

    [edit protocols isis]
    tt@router# show
    level 1 | 2 {
    disable;
    }

    and you can do it at interface level:

    [edit protocols isis]
    tt@router# show
    interface intf.unit {
    level (1 | 2) disable;
    }

    One more post later on.

    As Marko wrote : The rest - I couldn't agree more on.

    ReplyDelete
  7. Marko Milivojevic23 November, 2011 20:13

    Even with multiple instances, ATT will be set inly if there's an adjacency in L2.

    ReplyDelete
    Replies
    1. No actually the ATT bit in L1 LSP will be set only when the router has an L2 adjacency with a router in DIFFERNET AREA
      Connection to DIFFERNET AREA is the prerequisite for a L12 router to set the ATT bit (unless it’s set manually)

      Delete
    2. Strictly speaking, I believe the spec calls for the ATT bit to be set in the L1 LSP if the router can reach another area (and not necessarily directly L2-adjacent to that area).

      Delete
  8. in case of inter-area TE, re-optimization at abr is a very painful topic to cover, not even mention signal the path base on link-coloring/admin-grp.
    these fancy isis design, like routes leak and att bit works perfect for ip world, but not mpls, just like many vendor choose to ignore over-load-bit.
    run TE in single area makes everybody easy, or explicit path to mimic the old OTN concept, just my 1 cent.

    ReplyDelete
  9. For the ATT bit to be set, I believe (might be wrong) that the L1/L2 'router' has to have adjacencies established in both L1 and L2 levels but they have to have different Area IDs (I should test this in a quick lab... but I'm risking trusting my memory)

    Correct me if I'm wrong.

    ReplyDelete
  10. In my Service Provider "book" disabling the default L1/L2 adjacencies is probably the first thing I do after starting adding interfaces to IS-IS (for all the reasons you mentioned but also because I usually don't like defaults).

    Also, since apparently you started your journey in the JunOS world let me give you a thumb rule (been there done that). If you know you can do something with IOS (and flavors) it's almost guaranteed that you can do the same with JunOS, and until some years ago, you usually could do more. I also tend to trust JunOS defaults a bit more than the IOS* ones (I never enjoy the practice of hiding from the user the "system default")

    For example your recent blog regarding label control/assignment is a good example how the JunOS default is much more sane compared to the IOS (incidentally I think I start configuring MPLS using one of your books and during the optimization stage of my first lab I think I used it to limit the announcement of labels to only my Loopback subnet).

    I sincerely hope not many Service Providers are doing that "stupid" thing... if they are I recommend them to get one of Doyle's IS-IS books and all stupid things should be taken care of.

    Regards,

    (this javascript in macos chrome is still doing multiple posts...)

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.