OK so clearly I haven’t been updating a lot lately due to my very busy situation. I’m sorry for that but my former colleague Henri keeps nagging me for an update so I decided to write on some interesting tidbits of OSPF that I gathered in my notes recently.
We start with doing MD5 authentication to show something interesting.
R1#sh run int f0/0 Building configuration... Current configuration : 151 bytes ! interface FastEthernet0/0 ip address 188.8.131.52 255.255.255.0 ip ospf authentication message-digest ip ospf 1 area 0
The adjacency comes up even though no key has been configured, everything should be fine right? CCIE candidates don’t get off that easily, we need to verify.
%OSPF-5-ADJCHG: Process 1, Nbr 184.108.40.206 on FastEthernet0/0 from LOADING to FULL, Loading Done
R1#sh ip ospf int f0/0 | be Message Message digest authentication enabled No key configured, using default key id 0
So we are using a default key even though we didn’t configure any key! What is the next step in verifying? Debug…
R1#debug ip ospf adj OSPF adjacency events debugging is on R1# *Mar 1 00:08:11.327: OSPF: Send with youngest Key 0
Indeed, authentication is working without a key! Not that useful but still an interesting fact.
OSPF does not use key chains like EIGRP and RIP. What can we do if we want to change the key used without disrupting the adjacency? We start by defining a key with ID 3.
R1(config-if)#ip ospf message-digest-key 3 md5 cisco
Then we configure another key with ID 1.
R1(config-if)#ip ospf message-digest-key 1 md5 cisco1 R1#sh ip ospf int f0/0 | be Message Message digest authentication enabled Youngest key id is 1 Rollover in progress, 1 neighbor(s) using the old key(s): key id 3
So the old key is using ID 3 and the router will accept that key until the other side is also configured for key with ID 1. Now what happens if we configure another key with ID 5?
R1#sh ip ospf int f0/0 | be Message Message digest authentication enabled Youngest key id is 5 Rollover in progress, 1 neighbor(s) using the old key(s): key id 3 key id 1
So now we have two old keys and the newest one is the one with ID 5. I just wanted to show that the ID itself does not decide which one is newer, the last one you enter is the youngest key. So if we want to do a rollover we simply configure one side with the newer key and then the other side and the adjacency won’t flap.
When the keys are matching the output will look like this:
R1#sh ip ospf int f0/0 | be Message Message digest authentication enabled Youngest key id is 5
You might have heard that OSPF is distance vector between areas, how can we prove this? Lets try a simple 3 router setup looking like this.
We configure OSPF according to the topology and check that R3 is receiving the loopback of R1.
R3#sh ip route 220.127.116.11 Routing entry for 18.104.22.168/32 Known via "ospf 1", distance 110, metric 3, type inter area Last update from 22.214.171.124 on FastEthernet0/0, 00:00:02 ago Routing Descriptor Blocks: * 126.96.36.199, from 188.8.131.52, 00:00:02 ago, via FastEthernet0/0 Route metric is 3, traffic share count is 1
Which it is. Now what happens if we use a distribute-list on R2? OSPF is link state and LSA should still be advertised?
R2(config)#ip prefix-list DENY_R1_LO deny 184.108.40.206/32 R2(config)#ip prefix-list DENY_R1_LO permit 0.0.0.0/0 le 32 R2(config)#router ospf 1 R2(config-router)#distribute-list prefix DENY_R1_LO in
Is the prefix still in R3s routing table?
R3#sh ip route 220.127.116.11 % Network not in table R3#sh ip ospf data sum 18.104.22.168 OSPF Router with ID (22.214.171.124) (Process ID 1)
There is not even a LSA there. What about R2?
R2#sh ip route 126.96.36.199 % Network not in table R2#sh ip ospf data sum 188.8.131.52 OSPF Router with ID (184.108.40.206) (Process ID 1) Summary Net Link States (Area 0) Routing Bit Set on this LSA LS age: 344 Options: (No TOS-capability, DC, Upward) LS Type: Summary Links(Network) Link State ID: 220.127.116.11 (summary Network Number) Advertising Router: 18.104.22.168 LS Seq Number: 80000001 Checksum: 0x3ED4 Length: 28 Network Mask: /32 TOS: 0 Metric: 1
There is a type 3 LSA originating from R1 but R2 is not originating one for area 2. It is proven that OSPF is distance vector between areas!
Finally I want to show something that can be useful when you want to take a router out of service gracefully. Rather than just rebooting or shutting down links it can be down this way. First we announce loopback from R3 and verify that it is seen on R2.
R1#sh ip route 22.214.171.124 Routing entry for 126.96.36.199/32 Known via "ospf 1", distance 110, metric 3, type inter area Last update from 188.8.131.52 on FastEthernet0/0, 00:00:00 ago Routing Descriptor Blocks: * 184.108.40.206, from 220.127.116.11, 00:00:00 ago, via FastEthernet0/0 Route metric is 3, traffic share count is 1
OK, so the route is there. Now assume that we want to take R3 out of service. How can we do that? By setting the LSA to the maximum metric available. If there is any other path to reach the prefix that will be preferred.
Now we have a look at R2. All router LSAs from R3 now have a maximum metric of 65535. So the route is not installed in the RIB.
R2#sh ip ospf data router 18.104.22.168 OSPF Router with ID (22.214.171.124) (Process ID 1) Router Link States (Area 2) Routing Bit Set on this LSA LS age: 30 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 126.96.36.199 Advertising Router: 188.8.131.52 LS Seq Number: 80000005 Checksum: 0xEC21 Length: 36 Area Border Router Number of Links: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 184.108.40.206 (Link Data) Router Interface address: 220.127.116.11 Number of TOS metrics: 0 TOS 0 Metrics: 65535
This means that we can do work on a router and announce all router LSAs with the maximum metric and when we are done we remove the maximum metric and traffic will once again flow through the router. It’s a good option for those planned maintenance windows.
That’s all for this time!