The OSPF RID has a much more significant role in a neighbor formation than with EIGRP, obviously because that it what it uses to identify its neighbor rather than the IP address of the physical interface the neighbor was learned on.
So what if two routers were to have the same Router ID? That question is answered in two ways, as the behaviors are a bit different if we are in a common Area together, or if it detects a router from another Area with a duplicate RID.
It’s pretty straight forward, I pulled R4 and R5 into the mix, first we’ll see what happens when I change the RID on R5 to match R1’s RID of 1.1.1.1:
R5(config-router)#do sh ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 1 FULL/BDR 00:00:38 172.12.15.1 FastEthernet0/1
R5(config-router)#router-id 1.1.1.1
Reload or use “clear ip ospf process” command, for this to take effect
R5(config-router)#do clear ip ospf proc
Reset ALL OSPF processes? [no]: yes
R5(config-router)#
*Mar 31 21:35:40.801: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached
R5(config-router)#
*Mar 31 21:35:43.262: %OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id 1.1.1.1 from 172.12.15.1 on interface FastEthernet0/1
R5(config-router)#
*Mar 31 21:36:51.141: %OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id 1.1.1.1 from 172.12.15.1 on interface FastEthernet0/1
R5(config-router)#
*Mar 31 21:37:56.376: %OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id 1.1.1.1 from 172.12.15.1 on interface FastEthernet0/1
R5(config-router)#
The duplicate router-id message continues to flow, despite not having any debugs running, also note that you must “clear ip ospf proc” when you change the “router-id #” value or if you make a new loopback and want that to take the place of the current RID.
So point of the story here is that in the same Area they will just give a duplicate RID error over and over until it is corrected, so I will configure 1.1.1.1 down on R4, and see what happens between R1-R3-R4path in reaction to this change along along with the LSA DB:
To verify we are all neighbors
R1#sh ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 0 FULL/DROTHER 00:01:52 172.12.123.2 Serial0/0/0
3.3.3.3 0 FULL/DROTHER 00:01:52 172.12.123.3 Serial0/0/0
5.5.5.5 1 FULL/BDR 00:00:31 172.12.15.5 FastEthernet0/1
R1#
ASR#3
[Resuming connection 3 to r3 … ]
R3#sh ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 1 FULL/DR 00:01:54 172.12.123.1 Serial0/2
4.4.4.4 1 FULL/DR 00:00:35 172.12.34.4 FastEthernet0/1
R3#
ASR#4
[Resuming connection 4 to r4 … ]
R4#sh ip
*May 17 19:48:31.915: %SYS-5-CONFIG_I: Configured from console by console
R4#sh ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
3.3.3.3 1 FULL/BDR 00:00:36 172.12.34.3 FastEthernet0/1
R4#
Now to throw thy wrench into thy mix:
R4(config)#router ospf 1
R4(config-router)#router-id 1.1.1.1
% OSPF: Reload or use “clear ip ospf process” command, for this to take effect
R4(config-router)#exit
R4(config)#exit
R4#clear ip ospf proc
Reset ALL OSPF processes? [no]: yes
R4#
*May 17 19:54:27.451: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached
R4#
*May 17 19:54:32.135: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on FastEthernet0/1 from LOADING to FULL, Loading Done
R4#sh ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
3.3.3.3 1 FULL/DR 00:00:32 172.12.34.3 FastEthernet0/1
R4#
So it didn’t kill R4’s Adjacency yet or do anything odd there, let’s look at R3:
R3#sh ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 1 FULL/DR 00:01:59 172.12.123.1 Serial0/2
1.1.1.1 1 FULL/BDR 00:00:31 172.12.34.4 FastEthernet0/1
R3#
So none of the routers are really giving me any messages that were in your face as Router ID Mismatch repeating over and over again, so I might have to dig into the OSPF LSA Database to find if I caused the behavior I’m expecting.
So I am going to need to post the entire LSA DB of R1 and R4 before and after I change the RID back to 4.4.4.4 on R4 to catch the difference in the LSA Database, so hold onto your seats for a lot of output! :
R1
R1#sh ip ospf data
OSPF Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 145 0x80000002 0x00DCA2 1
2.2.2.2 2.2.2.2 401 0x80000006 0x0096DB 1
3.3.3.3 3.3.3.3 120 0x80000002 0x00600D 1
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
172.12.123.1 1.1.1.1 119 0x80000002 0x0027BC
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
1.1.1.1 1.1.1.1 255 0x80000001 0x0047EC
2.2.2.2 2.2.2.2 1924 0x80000003 0x00F633
3.3.3.3 3.3.3.3 270 0x80000001 0x00AE75
172.12.34.0 3.3.3.3 235 0x80000005 0x0064EC
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 265 0x80000001 0x00D351 1
Summary Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
2.2.2.2 1.1.1.1 140 0x80000001 0x009B54
3.3.3.3 1.1.1.1 114 0x80000001 0x006D7E
172.12.34.0 1.1.1.1 114 0x80000001 0x002BF1
172.12.123.0 1.1.1.1 255 0x80000001 0x004A7A
R1#
R4
R4#
R4#sh ip ospf data
OSPF Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 34)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 314 0x80000004 0x00F377 1
3.3.3.3 3.3.3.3 320 0x80000008 0x00480F 1
Net Link States (Area 34)
Link ID ADV Router Age Seq# Checksum
172.12.34.3 3.3.3.3 320 0x80000001 0x00F24D
Summary Net Link States (Area 34)
Link ID ADV Router Age Seq# Checksum
1.1.1.1 3.3.3.3 180 0x80000001 0x008D5E
2.2.2.2 3.3.3.3 180 0x80000001 0x005F88
3.3.3.3 3.3.3.3 339 0x80000003 0x00AA77
172.12.123.0 3.3.3.3 180 0x80000001 0x000EAE
R4#
Now to change it back:
R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#router ospf 1
R4(config-router)#no router-id 1.1.1.1
% OSPF: Reload or use “clear ip ospf process” command, for this to take effect
R4(config-router)#do clear ip ospf proc
Reset ALL OSPF processes? [no]: yes
R4(config-router)#
*May 17 20:24:19.967: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached
R4(config-router)#
*May 17 20:24:59.979: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on FastEthernet0/1 from LOADING to FULL, Loading Done
R4(config-router)#
Done, now one more flood of the two LSA Databases for comparison with a fine tooth comb:
R1
R1#sh ip ospf data
OSPF Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 585 0x80000002 0x00DCA2 1
2.2.2.2 2.2.2.2 841 0x80000006 0x0096DB 1
3.3.3.3 3.3.3.3 560 0x80000002 0x00600D 1
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
172.12.123.1 1.1.1.1 559 0x80000002 0x0027BC
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
1.1.1.1 1.1.1.1 695 0x80000001 0x0047EC
2.2.2.2 2.2.2.2 341 0x80000004 0x00F434
3.3.3.3 3.3.3.3 710 0x80000001 0x00AE75
172.12.34.0 3.3.3.3 675 0x80000005 0x0064EC
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 705 0x80000001 0x00D351 1
Summary Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
2.2.2.2 1.1.1.1 580 0x80000001 0x009B54
3.3.3.3 1.1.1.1 554 0x80000001 0x006D7E
172.12.34.0 1.1.1.1 554 0x80000001 0x002BF1
172.12.123.0 1.1.1.1 695 0x80000001 0x004A7A
R1#
R4
R4#sh ip ospf data
OSPF Router with ID (4.4.4.4) (Process ID 1)
Router Link States (Area 34)
Link ID ADV Router Age Seq# Checksum Link count
3.3.3.3 3.3.3.3 740 0x80000008 0x00480F 1
4.4.4.4 4.4.4.4 99 0x80000002 0x001342 1
Net Link States (Area 34)
Link ID ADV Router Age Seq# Checksum
172.12.34.3 3.3.3.3 100 0x80000002 0x0087AB
Summary Net Link States (Area 34)
Link ID ADV Router Age Seq# Checksum
1.1.1.1 3.3.3.3 600 0x80000001 0x008D5E
2.2.2.2 3.3.3.3 600 0x80000001 0x005F88
3.3.3.3 3.3.3.3 760 0x80000003 0x00AA77
172.12.123.0 3.3.3.3 600 0x80000001 0x000EAE
R4#
I see no difference and no messages appeared on the console griping about it, but what this is supposed to do is create a condition between the routers called an LSA “Flood War” where their would be confusion between the two as to which network is advertising the correct LSA’s because it appears to be coming from itself.
However I have spent way too much time on that subject, so I am moving on, just know that a duplicate RID in the same Area will cause the Adjacency not to form with a RID mismatch and if they are in separate Areas it will cause an “LSA Flood War” between the routers that contain the same RID.
If you can see a difference in the above two LSA Databases, please comment on this post to let me know what I missed, because I just cannot see anything different.
OSPF MTU Mismatches
With MTU, even outside of OSPF, the rule applies that two routers connected by the same physical cable must have matching MTU’s or the router does one of two things:
- The DF Flag in the IP Header is set to 0, and the packet is fragmented and forwarded
- The DF Flag in the IP Header is set to 1, and the packet is discarded
The normal MTU size is 1500, and can vary as some packets might push that threshold a bit, which then gets fragmented and forwarded if the DF bit is not turned on in the IP header.
Now in regards to OSPF, a mis-match in MTU size can allow neighbors to begin to build a relationship up to a point, and then eventually go down because of the Mismatch in MTU.
The neighbors will reach the point of EXSTART, this is where neighbors begin to pass DBD’s (Database Descriptor) to each other, and if there is a mismatch in the MTU it will be indicated in the DBD.
EXSTART is meant to be a temporary state, indicating that two routers have agreed upon the right parameters to become neighbors, but have not yet began to exchange LSA’s with eachother.
Let us demonstrate this on the live equipment:
Changing the MTU
R1(config)#int fa0/1
R1(config-if)#ip mtu ?
<68-1500> MTU (bytes)
R1(config-if)#ip mtu 1000
Bouncing the interface
R1(config-if)#shut
R1(config-if)#no shut
*May 17 22:38:46.015: %OSPF-5-ADJCHG: Process 1, Nbr 5.5.5.5 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached
R1(config-if)#no shut
*May 17 22:38:48.011: %LINK-5-CHANGED: Interface FastEthernet0/1, changed state to administratively down
*May 17 22:38:49.011: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down
R1(config-if)#no shut
R1(config-if)#
*May 17 22:38:55.603: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up
OSPF Neighborship does not come back up, lets check the states
R1(config-if)#do sh ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 0 FULL/DROTHER 00:01:58 172.12.123.2 Serial0/0/0
3.3.3.3 0 FULL/DROTHER 00:01:52 172.12.123.3 Serial0/0/0
5.5.5.5 1 2WAY/DROTHER 00:00:34 172.12.15.5 FastEthernet0/1
R1(config-if)#do sh ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 0 FULL/DROTHER 00:01:51 172.12.123.2 Serial0/0/0
3.3.3.3 0 FULL/DROTHER 00:01:45 172.12.123.3 Serial0/0/0
5.5.5.5 1 2WAY/DROTHER 00:00:37 172.12.15.5 FastEthernet0/1
R1(config-if)#do sh ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 0 FULL/DROTHER 00:01:59 172.12.123.2 Serial0/0/0
3.3.3.3 0 FULL/DROTHER 00:01:45 172.12.123.3 Serial0/0/0
5.5.5.5 1 EXSTART/DR 00:00:36 172.12.15.5 FastEthernet0/1
R1(config-if)#do sh ip ospf nei
The eventual console message indicating the issue
R1(config-if)#
*May 17 22:41:38.447: %OSPF-5-ADJCHG: Process 1, Nbr 5.5.5.5 on FastEthernet0/1 from EXSTART to DOWN, Neighbor Down: Too many retransmissions
R1(config-if)#
*May 17 22:42:38.447: %OSPF-5-ADJCHG: Process 1, Nbr 5.5.5.5 on FastEthernet0/1 from DOWN to DOWN, Neighbor Down: Ignore timer expired
R1(config-if)#
So these two were forming a neighbor relationship, but never formed an Adjacency because their DBD’s couldn’t match on the MTU parameter.
So if you see something about a neighbor stuck in EXSTART, “Too many transmissions”, or “EXSTART to DOWN” on exam day immediately check the interface MTU on both sides of that link!
That’s it for this, next I’m going to hit a possibly length but necessary review of LSA’s and the LS Database, once I review my old articles and try to extract the best information possible from them if its possible to summarize it down any more than I did!
The DEVNET GRIND! 