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.<\/p>\n
Here’s a sample config:<\/p>\n
router ospf 10\r\n log adjacency changes detail\r\n router-id 1.1.1.1\r\n nsf cisco\r\n auto-cost reference-bandwidth 10000\r\n default-information originate route-policy cond_ospf_default\r\n redistribute connected metric-type 2\r\n redistribute static route-policy static-ospf\r\n area 0\r\n interface Loopback0\r\n !\r\n interface TenGigE0\/0\/0\/4\r\n network point-to-point\r\n !\r\n interface TenGigE0\/0\/0\/5\r\n network point-to-point\r\n !\r\n !\r\n area 0.2.0.2\r\n interface TenGigE0\/0\/0\/6\r\n authentication message-digest\r\n message-digest-key 10 md5 tacos\r\n network point-to-point\r\n !\r\n !\r\n area 0.2.0.3\r\n interface TenGigE0\/0\/0\/7\r\n authentication message-digest\r\n message-digest-key 10 md5 tacos\r\n network point-to-point\r\n !\r\n interface TenGigE0\/0\/0\/8\r\n authentication message-digest\r\n message-digest-key 10 md5 tacos\r\n network point-to-point\r\n !\r\n !\r\n!<\/code><\/pre>\nLooking 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.<\/p>\n
You can also see that I’ve enabled authentication per interface, and not per area, which means you can be more granular with passwords.<\/p>\n
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.<\/p>\n
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<\/strong> 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:<\/p>\nCisco 7606:<\/p>\n
TenGigabitEthernet1\/7 is up, line protocol is up (connected)\r\n Hardware is C6k 10000Mb 802.3, address is 0019.07a8.4500 (bia 0019.07a8.4500)\r\n Description: [ to ASR9000 ]\r\n Internet address is 2.2.2.2\/30\r\n MTU 1524 bytes, BW 10000000 Kbit\/sec, DLY 10 usec,\r\n reliability 255\/255, txload 2\/255, rxload 1\/255<\/code><\/pre>\nCisco ASR9006:<\/p>\n
TenGigE0\/0\/0\/4 is up, line protocol is up\r\n Interface state transitions: 1\r\n Dampening enabled: penalty 0, not suppressed\r\n half-life: 1 reuse: 750\r\n suppress: 2000 max-suppress-time: 4\r\n restart-penalty: 0\r\n Hardware is TenGigE, address is 78ba.f906.3cc4 (bia 78ba.f906.3cc4)\r\n Layer 1 Transport Mode is LAN\r\n Description: [ to 7606 ]\r\n Internet address is 2.2.2.1\/30\r\n MTU 1524 bytes, BW 10000000 Kbit (Max: 10000000 Kbit)\r\n reliability 255\/255, txload 0\/255, rxload 2\/255<\/code><\/pre>\n