Schlagwort-Archive: isis

Configuring BFD for ISIS and OSPF

In this post I show you how to configure BFD Liveness Detection for your IGP. Again I use the topology of my post IGP loop prevention:

Redistribution between ISIS/OSPF
Redistribution between ISIS/OSPF

BFD is a very lightweight (small header, simple states) protocol to detect forwarding problems between two links(single-hop) or nodes(multi-hop). It uses UDP packets to encapsulate BFD control packets (single-hop uses port 3784, multi-hop uses 4784) and BFD echo packets (3785). It is specified in RFC 5880 and 5881.

BFD operates after session establishment. That means, if your adjacency came up and the router started exchanging hello packets, then additionally BFD starts to send periodic packets.

There exists 2 modes of BFD:

  • Async mode – every side send periodic hello packets, if x-packets not received take the session down
  • Demand mode – only send hello packets if needed, if x-packets not received take the session down

Additionally BFD implements a Echo function. Echo function should loop back the received packets. Echo function was designed for slow systems, if only one side (Router) could implement BFD and the slow systems (Host or CE) only loop the packet and doesn’t have to look at it. As far as I know JunOS currently have no support for BFD Echo function, so we must not think about it.

Usually you will implement BFD async mode with subsecond intervals. You configure BFD on interface level (sometimes on session level e.g.: BGP, targeted-LDP…) the interval of the packets in milliseconds and a multiplier.

Example configuration of R2 with interval 100ms and multiplier 3:

admin@router> 
admin@router> show configuration logical-systems R2 protocols | display set
 set logical-systems R2 protocols isis export export-OSPF-to-ISIS
 set logical-systems R2 protocols isis interface fe-0/2/3.50 bfd-liveness-detection minimum-interval 100
 set logical-systems R2 protocols isis interface fe-0/2/3.50 bfd-liveness-detection multiplier 3
 set logical-systems R2 protocols isis interface fe-0/2/3.50 level 1 disable
 set logical-systems R2 protocols isis interface lo0.2 passive
 set logical-systems R2 protocols ospf export export-ISIS-to-OSPF
 set logical-systems R2 protocols ospf area 0.0.0.0 interface lo0.2 passive
 set logical-systems R2 protocols ospf area 0.0.0.0 interface fe-0/2/3.53 bfd-liveness-detection minimum-interval 100
 set logical-systems R2 protocols ospf area 0.0.0.0 interface fe-0/2/3.53 bfd-liveness-detection multiplier 3

You can check the BFD state with the command „show bfd session <detail|extensive>“:

admin@router> show bfd session logical-system R2 extensive
 Detect Transmit
 Address State Interface Time Interval Multiplier
 10.0.1.13 Up fe-0/2/3.53 0.300 0.100 3
 Client OSPF realm ospf-v2 Area 0.0.0.0, TX interval 0.100, RX interval 0.100
 Session up time 00:31:39
 Local diagnostic None, remote diagnostic None
 Remote state Up, version 1
 Logical system 5, routing table index 29
 Min async interval 0.100, min slow interval 1.000
 Adaptive async TX interval 0.100, RX interval 0.100
 Local min TX interval 0.100, minimum RX interval 0.100, multiplier 3
 Remote min TX interval 0.100, min RX interval 0.100, multiplier 3
 Local discriminator 5, remote discriminator 6
 Echo mode disabled/inactive

 Detect Transmit
 Address State Interface Time Interval Multiplier
 10.0.1.1 Up fe-0/2/3.50 0.300 0.100 3
 Client ISIS L2, TX interval 0.100, RX interval 0.100
 Session up time 00:31:39
 Local diagnostic None, remote diagnostic NbrSignal
 Remote state Up, version 1
 Logical system 5, routing table index 29
 Min async interval 0.100, min slow interval 1.000
 Adaptive async TX interval 0.100, RX interval 0.100
 Local min TX interval 0.100, minimum RX interval 0.100, multiplier 3
 Remote min TX interval 0.100, min RX interval 0.100, multiplier 3
 Local discriminator 8, remote discriminator 2
 Echo mode disabled/inactive

  2 sessions, 2 clients
 Cumulative transmit rate 20.0 pps, cumulative receive rate 20.0 pps
admin@router>

If you lost more BFD packets than the configured multiplier is set, the BFD session goes down and also takes immediately your IGP adjacency down. This lead to faster failure detection and mostly faster convergence.

Most BFD sessions for single-hop run distributed on your FPC/MPC with the help of PPM. That means you could use very low intervals (maybe 3x15ms). But there are also limitations in the amount of such short-interval sessions, so call JTAC and ask about limits if you plan to use a heavy amount of sessions. BFD multi-hop session currently only works from RE, so you should never use intervals faster than 300ms.

Hint 1: Don’t forget to allow BFD control packets in your firewall filter!

Hint 2: If you clear your BFD session or deactivate the configuration, BFD signals a „Admin Down“ flag in the hello packets. This could lead to different results in convergence tests. If you really want to proove BFD function, you should pull the cable or add a firewall filter.

I hope that gave you short overview about the BFD protocol and functions.

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.