OSPF_Base_Topology

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:

  1. The DF Flag in the IP Header is set to 0, and the packet is fragmented and forwarded
  2. 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!