Hi Willow,
I see... Well, you are going far beyond CCNA requirements, and Packet Tracer is specifically created only for CCNA-level training and knowledge. What you are trying to do is understand in depth how OSPF is designed and how it interacts with various network topologies under different circumstances. However, Packet Tracer does not fully implement OSPF, and so it is in fact quite dangerous to infer the properties of OSPF by testing them on Packet Tracer. In many places, Packet Tracer's emulation of OSPF may be significantly different.
In other words, for your in-depth and keen studying style, Packet Tracer is not suitable, and it can do more harm than good. If possible, I suggest you use real IOSes - GNS3 or VIRL.
the other question (about the timers) is still a mystery, since it never seems you really need to adjust the timers: just neighbor up the NBMA parts of the network, choose your DR and it just works. when does that "sync timers" come into play?
Any time two routers are supposed to talk to each other :)
Consider the following scenario: R1 uses physical interface for FR connectivity to talk to R2, R2 uses a subinterface:
R1:
interface Serial1/0
description => To FR <=
ip address 10.0.0.1 255.255.255.0
encapsulation frame-relay IETF
serial restart-delay 0
R2:
interface Serial1/0
description => To FR <=
no ip address
encapsulation frame-relay IETF
serial restart-delay 0
!
interface Serial1/0.201 point-to-point
ip address 10.0.0.2 255.255.255.0
snmp trap link-status
frame-relay interface-dlci 201
Because R1 is configured on physical interface, OSPF defaults to the NBMA network type there. On R2 that uses a point-to-point subinterface, OSPF also defaults to point-to-point network type.
After starting OSPF on R1 and R2, no OSPF adjacency comes up. Running debug ip ospf adj on R1 tells us:
R1#
*Mar 1 01:15:20.395: OSPF: Rcv hello from 10.0.0.2 area 0 from Serial1/0 10.0.0.2
*Mar 1 01:15:20.399: OSPF: Mismatched hello parameters from 10.0.0.2
*Mar 1 01:15:20.403: OSPF: Dead R 40 C 120, Hello R 10 C 30 Mask R 255.255.255.0 C 255.255.255.0
Note the complaint about mismatched hello parameters: Dead interval: Received=40, Configured=120, Hello interval: Received=10, Configured=30.
As a result, this Hello is not accepted, and OSPF adjacency never comes up - R1 and R2 do not see each other in OSPF at all, not even in the INIT state (the first state of an adjacency).
In addition, even if I tweaked the timers to be identical, the OSPF routers would establish a full adjacency but they would not see their networks - the routing tables would stay empty. This is because these two routers use incompatible approaches to representing this network: R1 with NBMA thinks that the DR must be elected and that the DR will represent the adjacencies of all routers on the network, while R2 with P2P thinks that there is no DR and adjacent routers indicate their adjacency by referring to each other directly. If we were to draw an internal representation in of the network in these routers' link state databases, this would be the approximate state:
Because R1 engages into DR/BDR elections while R2 does not, R1 will become the DR and there will be no BDR on this network. Furthermore, because R1 is the DR, it thinks it is entitled to represent the network on this interface, so what it inserts into the link-state database is
- itself
- the information about the network
- a link from itself to the network
- a link from the network back to every router R1 can hear including itself, that is, R1 and R2
R2 does not know about this. It thinks that if it hears R1, there's only a point-to-point link between these two, not a network that can hold two or more routers, and so it does not know that it also should indicate an adjacency to the network. Instead, it indicates an adjacency directly back to R1. So what R2 inserts into the link-state database is this:
- itself
- a link from itself to R1
Notice the asymmetry in how R1 and R2 treat the same interconnection between these two. Now, when they both start the SPF algorithm and start computing the shortest paths, there is a clause that says: After you follow an arrow (that is, a link) from one object to another, see if the target object points back by its own link to the object you have just left. If not, ignore this object.
Notice that this check prevents R1 and R2 from ever considering themselves in the computation. R2 will follow the link from R2 to R1 but will find out that R1 doesn't point back to R2, so it will ignore it, and there are no further outgoing links from R2. So, R2's routing table remains empty.
Similarly, when R1 proceeds from itself to the object representing the entire network and then from this network object follows to R2, it finds out that R2 does not point back to the network object, so again, R1 will ignore R2's topological information, and R1's routing table will remain empty as well.
Therefore, having the same timers alone won't make OSPF happy. Two routers have to agree on how they represent the network.
Best regards,
Peter
Willow,
Perhaps, in addition, the following figure shows you a correct OSPF model of a network - the upper one is with DR (BMA, NBMA), the bottom one is with point-to-point. Any of these is correct; the hybrid in my previous post isn't, and that's what you get when you have a mix of NBMA and point-to-point on a single network segment.
Best regards,
Peter
