IGP loop prevention (OSPF / ISIS)

In this post, we will take a look at a simple IGP loop and how to prevent it. As you know, an IGP redistribution loop only occur if you have a mutual redistibribution between two or more sites.  Depending on your local preference, the „better“ routes is choosen to be active and is also eligible for redistribution into the other protocol.

We will use for this example a flat ISIS Level 2 domain and OSPF Area 0. Nothing special like NSSA or L2>L1 leaking stuff.

ISIS:

If you redistribute a static route, routes from other IGPs or directly connected interfaces into ISIS they will always advertised in TLV 130 also known as „IP External Reachability TLV“. A Level 2 external IP Prefix get a preference value of 165 (see cheat-sheet preferences).

OSPF:

If you redistribute a static route, routes from other IGPs or directly connected interfaces into OSPF they will always advertised in Type 5 LSA also known as „External LSA“. A external OSPF route  get a preference value of 150 (see cheat-sheet preferences).

As you can see, OSPF external routes get per default a better preference value than ISIS external routes. That mean, at a mutual redistribution, where ISIS and OSPF meet ;-), the OSPF routes always get active will be the preferred path.

Lets take a look at an  example. I use the same topology with logical systems as you known from my post about IGP load balancing.  R1 redstribute a directly connected interface with the prefix 10.0.5.0/24 into ISIS. (this is only for testing purposes, usually you use passive statement to get an interface into ISIS as internal route)

Redistribution between ISIS/OSPF
Redistribution between ISIS/OSPF

R1 will do this by the following configuration:

interfaces {
    fe-0/2/2 {
        unit 100 {
            description "Example for external network";
            vlan-id 100;
            family inet {
                address 10.0.5.1/24;
            }
        }
    }
}
protocols {
    isis {
        export export-intf-as-external;
    }
}
policy-options {
    policy-statement export-intf-as-external {
        term export-intf {
            from {
                route-filter 10.0.5.0/24 exact;
            }
            then accept;
        }
    }
}

At R2 and R3 we will have a mutual redistribution between ISIS and OSPF:

protocols {
    isis {
        export export-OSPF-to-ISIS;
    }
    ospf {
        export export-ISIS-to-OSPF;
    }
}
policy-options {
    policy-statement export-ISIS-to-OSPF {
        term isis-routes {
            from protocol isis;
            then accept;
        }
        then reject;
    }
    policy-statement export-OSPF-to-ISIS {
        term ospf-routes {
            from protocol ospf;
            then accept;
        }
        then reject;
    }
}

At this point everything is ok, we can see that R2 redistribute the external prefix 10.0.5.0/24 into OSPF. R4 can reach it via R2. From the point of view of R3 the OSPF route via R4>R2 is preferred, because the preference of OSPF is better than ISIS. Also R3 will redistribute the better OSPF route into ISIS. R1 will ignore it, because it has the better direct connected prefix.

admin@router:R3> show route 10.0.5.0/24
inet.0: 14 destinations, 20 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 10.0.5.0/24 *[OSPF/150] 16:50:35, metric 20, tag 0
 > to 10.0.1.17 via fe-0/2/3.54
 [IS-IS/165] 00:07:54, metric 20
 > to 10.0.1.5 via fe-0/2/3.51

In your exam, you should now be warned because you know that you have a suboptimal routing from R3>R4>R2>R1 and also no load-balancing (R4 via R2/R3 to R1 and vice versa). Currently everything works as configured, but also as intended?

Your problem start if the prefix from R1 fails maybe because of an interface failure. R1 will stop redistributing the prefix into ISIS.  Also R2 now remove the prefix from its ISIS database and doesn’t redistribute it into OSPF. In theory everything should be fine. OSPF doesn’t see the external prefix anymore and the prefix should disappear from our network.

admin@router:R1> show route 10.0.5.0/24
inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
  10.0.5.0/24 *[Direct/0] 00:00:05
    > via fe-0/2/2.100
  10.0.5.1/32 *[Local/0] 17:28:08
    Local via fe-0/2/2.100
admin@router:R1> edit
Entering configuration mode

[edit]
admin@router:R1# set interfaces fe-0/2/2 unit 100 disable

[edit]
admin@router:R1# commit
commit complete

[edit]
admin@router:R1# exit
Exiting configuration mode
admin@router:R1>

Oh no 😉  we forgot R3! R3 redistributed (due to its configuration) the external OSPF prefix back into ISIS. That means we also have an TLV 130 for the external prefix from R3 in ISIS.

admin@router:R1> show route 10.0.5.0/24
inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
  10.0.5.0/24 *[IS-IS/165] 00:00:03, metric 50
    > to 10.0.1.6 via fe-0/2/2.51
  10.0.5.1/32 *[Local/0] 17:28:25
    Reject
admin@router:R1> show isis adjacency
Interface             System         L State        Hold (secs) SNPA
fe-0/2/2.50           router-R2        2  Up                    8  0:5:85:3d:98:41
fe-0/2/2.51           router-R3        2  Up                    7  0:5:85:3d:98:41

This image show you what now happen:

Loop ISIS/OSPF
Loop ISIS/OSPF

The prefix 10.0.5.0/24 will never disappear from your network. You can prevent for such loops in multiple ways:

  • Increase OSPF preference for externel prefixes to 166
  • Decrease ISIS preference for external prefixes to 149
  • Filter already redistributed routes by tags

Changing the preference values is not the best idea, because you only turn the problem to the other side. In some cases this could be a valid solution, but in fact it is not way you should do it. The common solution for this problem is filtering by tags. Both ISIS and OSPF can attach an administrative tag (value like a number) to a prefix included in the LSA/TLV. So we have the ability to filter everything we already redistributed from ISIS to OSPF at the border of R2 and R3.

We change our mutual redistribution configuration a litte bit. We are now tag our ISIS routes in OSPF with 5678 and our OSPF routes in ISIS with 1234 and also filtering on these values:

policy-options {
    policy-statement export-ISIS-to-OSPF {
        term no-tag-5678 {
            from {
                protocol isis;
                tag 5678;
            }
            then reject;
        }
        term isis-routes {
            from protocol isis;
            then {
                tag 1234;
                accept;
            }
        }
        then reject;
    }
    policy-statement export-OSPF-to-ISIS {
        term no-tag-1234 {
            from {
                protocol ospf;
                tag 1234;
            }
            then reject;
        }
        term ospf-routes {
            from protocol ospf;
            then {
                tag 5678;
                accept;
            }
        }
        then reject;
    }
}

You can see the tag in your routing-table:

admin@router:R4> show route 10.0.5.0/24
inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
 + = Active Route, - = Last Active, * = Both
  10.0.5.0/24 *[OSPF/150] 00:17:54, metric 20, tag 1234
   > to 10.0.1.14 via fe-0/2/2.53

admin@router:R4>

You can test the filtering by disabling the interface in R1 again. The prefix should now disappear from the network:

admin@router:R1> show route 10.0.5.0/24

inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.5.0/24        *[Direct/0] 00:19:59
                    > via fe-0/2/2.100
10.0.5.1/32        *[Local/0] 18:06:29
                      Local via fe-0/2/2.100

admin@router:R1> edit
Entering configuration mode

[edit]
admin@router:R1# set interfaces fe-0/2/2 unit 100 disable

[edit]
admin@router:R1# commit and-quit
commit complete
Exiting configuration mode

admin@router:R1> show route 10.0.5.0/24

inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.5.1/32        *[Local/0] 18:06:46
                      Reject

admin@router:R1>

As you can see, it is quite simple to protect your network for such a loop condition. You should always filter your routes at IGP borders if you thing about mutual redistribution. Here you can find the complete configuration for the logical systems: logical-systems-igp-loop.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.