ASR9000/IOS-XR OSPF Fun With MTU

I’m going to start by saying IOS-XR has some pretty cool features, I mean just look at the addition of “commit”. It does, however, have some quirks that can confound you, especially when you are migrating from one architecture over to the ASR9000 series. In particular, I’m going to look at the OSPF implementation.

Here’s a sample config:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

router ospf 10
 log adjacency changes detail
 router-id 1.1.1.1
 nsf cisco
 auto-cost reference-bandwidth 10000
 default-information originate route-policy cond_ospf_default
 redistribute connected metric-type 2
 redistribute static route-policy static-ospf
 area 0
  interface Loopback0
  !
  interface TenGigE0/0/0/4
   network point-to-point
  !
  interface TenGigE0/0/0/5
   network point-to-point
  !
 !
 area 0.2.0.2
  interface TenGigE0/0/0/6
   authentication message-digest
   message-digest-key 10 md5 tacos
   network point-to-point
  !
 !
 area 0.2.0.3
  interface TenGigE0/0/0/7
   authentication message-digest
   message-digest-key 10 md5 tacos
   network point-to-point
  !
  interface TenGigE0/0/0/8
   authentication message-digest
   message-digest-key 10 md5 tacos
   network point-to-point
  !
 !
!

Looking at the config above you can see we’ve done away with network statements in favor of simply enabling the process on an interface, which is nice. This cuts down on the network command covering some undesired interfaces.

You can also see that I’ve enabled authentication per interface, and not per area, which means you can be more granular with passwords.

I’ve also adjusted the network type per interface right here int he process instead of under the interface configuration itself; this means all OSPF configuration is done from the process, so there is a single place to to view all OSPF configurations, which I really like.

A normal behavior of OSPF is once communication begins and DBDs begin to be exchanged by peers, OSPF will send these packets at the max MTU configured on the interface. This means that if you have an MTU mismatch between OSPF neighbors, then they won’t be able to properly exchange OSPF information, and the neighborship will fail. I mention all of this here because ASR9000s have a quirk with the configured MTU. Note my below interface configurations:

Cisco 7606:

1
2
3
4
5
6

TenGigabitEthernet1/7 is up, line protocol is up (connected)
  Hardware is C6k 10000Mb 802.3, address is 0019.07a8.4500 (bia 0019.07a8.4500)
  Description: [ to ASR9000 ]
  Internet address is 2.2.2.2/30
  MTU 1524 bytes, BW 10000000 Kbit/sec, DLY 10 usec,
     reliability 255/255, txload 2/255, rxload 1/255

Cisco ASR9006:

1
2
3
4
5
6
7
8
9
10
11
12

TenGigE0/0/0/4 is up, line protocol is up
  Interface state transitions: 1
  Dampening enabled: penalty 0, not suppressed
    half-life:        1        reuse:             750
    suppress:         2000     max-suppress-time: 4
    restart-penalty:  0
  Hardware is TenGigE, address is 78ba.f906.3cc4 (bia 78ba.f906.3cc4)
  Layer 1 Transport Mode is LAN
  Description: [ to 7606 ]
  Internet address is 2.2.2.1/30
  MTU 1524 bytes, BW 10000000 Kbit (Max: 10000000 Kbit)
     reliability 255/255, txload 0/255, rxload 2/255

Note in the configuration of both it shows an MTU of 1524. The problem here is there’s actually an MTU mismatch!
Here’s the Cisco doc on IOS-XR MTU. If I were to run a debug on OSPF between these peers I would see that my ASR9000 is 14 bytes less than my standard 7600. The Layer 2 header without any dot1q information is 14 bytes, so the standard ASR9000 configuration doesn’t take this into account like most other Cisco devices…so how do you fix the issue; increase the MTU by 14 Bytes:

Cisco ASR9000:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

interface ten0/0/0/4
mtu 1538
commit
!
RP/0/RSP0/CPU0:asr9000#show int te0/0/0/4
TenGigE0/0/0/4 is up, line protocol is up
  Interface state transitions: 1
  Dampening enabled: penalty 0, not suppressed
    half-life:        1        reuse:             750
    suppress:         2000     max-suppress-time: 4
    restart-penalty:  0
  Hardware is TenGigE, address is 78ba.f906.3cc4 (bia 78ba.f906.3cc4)
  Layer 1 Transport Mode is LAN
  Description: [ to 7606 ]
  Internet address is 2.2.2.1/30
  MTU 1538 bytes, BW 10000000 Kbit (Max: 10000000 Kbit)

So even though the MTU shows 1538 it now allows the OSPF neighbors to establish on this link where the configuration is:
7600 MTU 1524
ASR MTU 1538

Just another interesting twist you need to account for when connecting kit to your IOS-XR gear.

Thanks and let me know what you think in the comments below!