Archiv der Kategorie: JNCIE-SP exam topics

When you get a MTU Mismatch in OSPF….

…you will always see that the adjacency will stuck in ExStart/ExChange.

OSPF doesn’t check the configured MTU size on an interface with the hello packets. But it must make sure, that the OSPF database exchange works completly. To avoid an MTU problem, the MTU will be exchanged in the Database Description (DBD) packets. If the MTU doesn’t match (RFC 2328 section 10.6) the routers never start exchanging Link-State Advertisements (LSA).

The reason:
OSPF itself doesn’t define a fragmention, but every OSPF router should be able to split multiple LSAs into several packets (see RFC 2328 Appendix A.1).  The size of these LSAs is determined by the MTU of your outgoing interface. To avoid fragementation your router will always build smaller LSAs to fit into MTU.  But if your packets will be bigger as your neighbor could receive, they got lost and your neighbor could never get your database. 

Here is an example of an MTU mismatch beween R1 and R2.

MTU Mismatch between R1 and R2
MTU Mismatch between R1 and R2

We see that both routers stuck in ExStart:

admin@router> show ospf neighbor logical-system R1
Address Interface State ID Pri Dead
10.0.1.2 fe-0/2/2.50 ExStart 10.0.2.2 128 36

admin@router> show ospf neighbor logical-system R2
Address Interface State ID Pri Dead
10.0.1.1 fe-0/2/3.50 ExStart 10.0.2.1 128 35

The „show ospf interface“ command give us some hints:

admin@router> show ospf interface detail logical-system R1
Interface State Area DR ID BDR ID Nbrs
fe-0/2/2.50 BDR 0.0.0.0 10.0.2.2 10.0.2.1 1
 Type: LAN, Address: 10.0.1.1, Mask: 255.255.255.252, MTU: 1200, Cost: 1
 DR addr: 10.0.1.2, BDR addr: 10.0.1.1, Priority: 128
 Adj count: 0
 Hello: 10, Dead: 40, ReXmit: 5, Not Stub
 Auth type: None
 Protection type: None
 Topology default (ID 0) -> Cost: 1

admin@router> show ospf interface detail logical-system R2
Interface State Area DR ID BDR ID Nbrs
fe-0/2/3.50 DR 0.0.0.0 10.0.2.2 10.0.2.1 1
 Type: LAN, Address: 10.0.1.2, Mask: 255.255.255.252, MTU: 1500, Cost: 1
 DR addr: 10.0.1.2, BDR addr: 10.0.1.1, Priority: 128
 Adj count: 0
 Hello: 10, Dead: 40, ReXmit: 5, Not Stub
 Auth type: None
 Protection type: None
 Topology default (ID 0) -> Cost: 1
fe-0/2/3.53 Down 0.0.0.0 0.0.0.0 0.0.0

And we can see it in tcpdump in the DBD but not in the Hello packets:

admin@router> monitor traffic interface fe-0/2/3.50 no-resolve detail Address resolution is OFF. Listening on fe-0/2/3.50, capture size 1514 bytes

13:03:15.100618 In IP (tos 0xc0, ttl 1, id 23483, offset 0, flags [none], proto: OSPF (89), length: 68) 10.0.1.1 > 224.0.0.5: OSPFv2, Hello, length 48 Router-ID 10.0.2.1, Backbone Area, Authentication Type: none (0) Options [External] Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.252, Priority 128 Designated Router 10.0.1.2, Backup Designated Router 10.0.1.1 Neighbor List: 10.0.2.2

13:03:18.269589 Out IP (tos 0xc0, ttl 1, id 23514, offset 0, flags [none], proto: OSPF (89), length: 68) 10.0.1.2 > 224.0.0.5: OSPFv2, Hello, length 48 Router-ID 10.0.2.2, Backbone Area, Authentication Type: none (0) Options [External] Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.252, Priority 128 Designated Router 10.0.1.2, Backup Designated Router 10.0.1.1 Neighbor List: 10.0.2.1

13:03:18.301879 Out IP (tos 0xc0, ttl 1, id 23517, offset 0, flags [none], proto: OSPF (89), length: 52) 10.0.1.2 > 10.0.1.1: OSPFv2, Database Description, length 32 Router-ID 10.0.2.2, Backbone Area, Authentication Type: none (0) Options [External, Opaque], DD Flags [Init, More, Master], MTU: 1500, Sequence: 0x0a01e9de

13:03:18.623449 In IP (tos 0xc0, ttl 1, id 23520, offset 0, flags [none], proto: OSPF (89), length: 52) 10.0.1.1 > 10.0.1.2: OSPFv2, Database Description, length 32 Router-ID 10.0.2.1, Backbone Area, Authentication Type: none (0) Options [External, Opaque], DD Flags [Init, More, Master], MTU: 1200, Sequence: 0x0a01cae3

 

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.

Load-Balancing for IGP

In the following post I will explain you a usual configuration to achieve a load-balancing in JunOS. I will use the following topology for this example:

Topology for Load-Balancing
Topology for Load-Balancing

The routers are all configured as logical-systems on one M5 in my lab. The connection between them is made by one cross cable between port fe-0/2/2 and fe-0/2/3 via VLANs.

For this example I use OSPF as IGP with every router in Area 0.

IGP - OSPF
IGP – OSPF

 

Default Behavior

The default configuration in JunOS doesn’t have load-balancing enabled. Even if your IGP learned multiple equal-paths to the same destination, it shows you them in your routing-table, but only one next-hop is choosen to get installed into your forwarding-table.

We will take a  look at the loopback address of R4 from the point of view of R1. R1 see two equal-paths to 10.0.2.4, one goes to R2, the other one goes via R3. In the routing-table we can see that R1 „selected“  the route with the next-hop of R3. Also this next-hop got installed into the forwarding-table:

admin@router:R1> show route 10.0.2.4 extensive

inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
10.0.2.4/32 (1 entry, 1 announced)
TSI:
KRT in-kernel 10.0.2.4/32 -> {10.0.1.6}
 *OSPF Preference: 10
 Next hop type: Router
 Address: 0x8fd1078
 Next-hop reference count: 2
 Next hop: 10.0.1.2 via fe-0/2/2.50
 Next hop: 10.0.1.6 via fe-0/2/2.51, selected
 State: <Active Int>
 Age: 8:43 Metric: 2
 Area: 0.0.0.0
 Task: OSPF
 Announcement bits (1): 2-KRT
 AS path: I

admin@router:R1> show route forwarding-table destination 10.0.2.4 detail
Logical system: R1
Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
10.0.2.4/32 user 0 10.0.1.6 ucst 1046 5 fe-0/2/2.51
<snip>

What does it mean for us? Only the next-hop pointing R3 will used to forward traffic to the destination 10.0.2.4 – ever! The next-hop will only change, if link goes down and the IGP has to choose another path.

Per-Packet or Per-Flow?

The load-balancing configuration in JunOS is a little bit misleading. It use a configuration option named „per-packet“. In fact every current platform (like MX) use a per-flow load-balancing. Only the early M20/M40 ABC-chipsets got a chip called C-chip, also known as „Internet Processor I“, which only could do per-packet load-balancing. Every later chipsets, including newer ABC-chipsets with Cf-chip „Internet Processor II“, do per-flow load-balancing. So don’t bother about it, just know it is always a per-flow load-balancing.

IGP Load-Balancing

To activate per-flow load-balancing you must configure a policy with an then-action „load-balance per-packet“. You can influence the load-balancing by adding a route-filter to the policy. Additionally youm ust apply this policy to the forwarding-table.

Here is configuration example:

admin@router:R1> show configuration | compare rollback 1
[edit logical-systems R1]
+ policy-options {
+     policy-statement load-balance {
+         then {
+             load-balance per-packet;
+         }
+     }
+ }
+ routing-options {
+     forwarding-table {
+         export load-balance;
+     }
+ }

admin@router:R1>

This configuration now allow the router to install all (upto 16 per default) equal-cost next-hops into your forwarding-table. With multiple next-hops your chipset now can do the per-flow load-balancing.

admin@router:R1> show route forwarding-table destination 10.0.2.4

 Logical system: R1
 Routing table: default.inet
 Internet:
 Destination Type RtRef Next hop Type Index NhRef Netif
 10.0.2.4/32 user 0 ulst 262142 3
 10.0.1.2 ucst 1044 5 fe-0/2/2.50
 10.0.1.6 ucst 1046 5 fe-0/2/2.51

Influence hashing

The hashing algorithm determine a flow by source/destination IP address and doesnt‘ include the TCP/UDP ports. If you want to include the layer-4 informations, you must apply the following configuration:

admin@router# show | compare

[edit]
+ forwarding-options {
+     hash-key {
+         family inet {
+             layer-3;
+             layer-4;
+         }
+     }
+ }

[edit]
admin@router#

(if you work with logical systems you cannot configure the hash-key, you must configure this globally…)

Configuration

Here you can download my configuration of the  Logical-Systems.

In one of my next posts, I will explain BGP multipath configuration and VPN load-balancing.

VRRPv2 interface and route tracking

This post is a followup to my previous post about VRRPv2 and explain simple interface and route tracking conifguration for VRRP.

Why do we need tracking?

In most cases you want check your uplink states to your core routers. Because the VRRP Master should be able to route your traffic into your core and should not be a black hole if your core router fails.

The VRRP configuration gives you two options to achieve this. With interface tracking, you can specify one or more interfaces to track on. This allows you to track for the physical link properties. The other option is route tracking, which allow you to track for a specific route which must be present in your routing-table.  Both options give you the ability to track your uplink states in a more or less simple way.

Interface Tracking

You can add a tracking for one or multiple interfaces. The tracked interface need a priority-cost, which will be substracted from the configured priority if the interface goes down.

vrrpv2_interface_tracking

admin@ROUTER:R2# show
interfaces {
    fe-0/2/1 {
        unit 0 {
            family inet {
                address 10.0.1.3/24 {
                    vrrp-group 1 {
                        virtual-address 10.0.1.1;
                        priority 90;
                        authentication-type md5;
                        authentication-key "$9$NC-wgoaUiHmg4QF/9pu"; ## SECRET-DATA
                        track {
                            interface fe-0/2/3.0 {
                                priority-cost 20;
                            }
                        }
                    }
                }
            }
        }
    }
}

Verify operation:

admin@ROUTER:R2> show vrrp detail
Physical interface: fe-0/2/1, Unit: 0, Address: 10.0.1.3/24
  Index: 102, SNMP ifIndex: 657, VRRP-Traps: disabled
  Interface state: up, Group: 1, State: backup, VRRP Mode: Active
  Priority: 90, Advertisement interval: 1, Authentication type: md5
  Delay threshold: 100, Computed send rate: 0
  Preempt: yes, Accept-data mode: no, VIP count: 1, VIP: 10.0.1.1
  Dead timer: 3.101s, Master priority: 100, Master router: 10.0.1.2
  Virtual router uptime: 00:23:50
  Tracking: enabled
    Current priority: 90, Configured priority: 90
    Priority hold time: disabled
    Interface tracking: enabled, Interface count: 1
      Interface     Int state   Int speed   Incurred priority cost
      fe-0/2/3.0    up               100m                       0
    Route tracking: disabled

admin@ROUTER:R2> edit
Entering configuration mode

[edit]
admin@ROUTER:R2# set interfaces fe-0/2/3 unit 0 disable

[edit]
admin@ROUTER:R2# commit
run sh vrrp decommit complete

[edit]
admin@ROUTER:R2# run show vrrp detail
Physical interface: fe-0/2/1, Unit: 0, Address: 10.0.1.3/24  
Index: 102, SNMP ifIndex: 657, VRRP-Traps: disabled
  Interface state: up, Group: 1, State: backup, VRRP Mode: Active
  Priority: 70, Advertisement interval: 1, Authentication type: md5
  Delay threshold: 100, Computed send rate: 0
  Preempt: yes, Accept-data mode: no, VIP count: 1, VIP: 10.0.1.1
  Dead timer: 3.325s, Master priority: 100, Master router: 10.0.1.2
  Virtual router uptime: 00:24:40
  Tracking: enabled
    Current priority: 70, Configured priority: 90
    Priority hold time: disabled
    Interface tracking: enabled, Interface count: 1
      Interface     Int state   Int speed   Incurred priority cost
      fe-0/2/3.0    down                0                      20
    Route tracking: disabled

[edit]
admin@ROUTER:R2#

Route Tracking

You can add a tracking for one or multiple routes. You must specify the exact prefix and the routing-instance, which is for inet.0 the name “default”.

vrrpv2_route_tracking

admin@ROUTER:R2# show
interfaces {
    fe-0/2/1 {
        unit 0 {
            family inet {
                address 10.0.1.3/24 {
                    vrrp-group 1 {
                        virtual-address 10.0.1.1;
                        priority 90;
                        authentication-type md5;
                        authentication-key "$9$NC-wgoaUiHmg4QF/9pu"; ## SECRET-DATA
                        track {
                            route 20.0.0.0/8 routing-instance default priority-cost 20;
                        }
                    }
                }
            }
        }
    }
}

This example output show you the active route tracking for 20.0.0.0/8. Because the route is not present in inet.0 the priority-cost of 20 will be substracted from the configured priority.

admin@ROUTER:R2# run show vrrp detail
Physical interface: fe-0/2/1, Unit: 0, Address: 10.0.1.3/24
  Index: 102, SNMP ifIndex: 657, VRRP-Traps: disabled
  Interface state: up, Group: 1, State: backup, VRRP Mode: Active
  Priority: 70, Advertisement interval: 1, Authentication type: md5
  Delay threshold: 100, Computed send rate: 0
  Preempt: yes, Accept-data mode: no, VIP count: 1, VIP: 10.0.1.1
  Dead timer: 3.315s, Master priority: 100, Master router: 10.0.1.2
  Virtual router uptime: 00:35:49
  Tracking: enabled
    Current priority: 70, Configured priority: 90
    Priority hold time: disabled
    Interface tracking: disabled
    Route tracking: enabled, Route count: 1
      Route               VRF name     Route state      Priority cost
      20.0.0.0/8          default      down                        20
 
[edit]
admin@ROUTER:R2#