Hello Rene,
As mentioned in the 9th point of troubleshooting OSPF neighbors,
“On a multi-access network like Ethernet OSPF will do a DR/BDR election if the network type is broadcast or non-broadcast.”
but in this example there are only two routers and it is not even a multi-access network then why are we checking the network type?
also when verifying the network type, I see the routers have priority 1 I am confused?
Can we say that both the router’s priority will not be same?
Hello Annesha
A multi-access network is one that uses a multi-access technology such as Ethernet. It doesn’t matter if there are only two routers, if Ethernet is used, it is still considered multi-access. As such, it is possible to change the network type. If you do so, even on an Ethernet interface, and make it something other than broadcast or non-broadcast, then OSPF will not automatically have a DR/BDR election, and the OSPF configuration will fail.
When verifying the network type, you don’t see the value of the priority for the OSPF router. Take a look at this output:
R1#show ip ospf interface | include Network Type
Process ID 1, Router ID 192.168.12.1, Network Type BROADCAST, Cost: 1
What you see there is the cost that is advertised by that router. Now in the example in the lesson, the OSPF priority is indeed set to 0 which is what resulted in the specific 2WAY/DROTHER state.
I hope this has been helpful!
Laz
Hi Lazaro,
What about port channel L3 link? I have full state by two routers with different mask over L3 port channel. Does it mean that port channel is also considered as point to point?
P.S. Just checked with show ip ospf interfaces command. Output states:
Port-channel1 is up, line protocol is up
Internet address is 10.0.0.2/8, Area 1
Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 0
So now I am confused completely.
Hello Shahlar
I just went in and labbed this up and found that OSPF neighbors will not form if the subnet mask is different. For example, I had an L3 EtherChannel created between two switches, and the IP address on one port-channel interface was 192.168.12.1/24 and the IP address on the other was 192.168.12.2/25. The interfaces can ping each other successfully, but because of the different subnet masks (/24 and /25), they failed to become neighbors. Notice that we’re talking about the subnet masks of the interfaces used to create the neighborship.
Can you recheck your configuration and let us know if you get different results? If so, you may want to share your config with us so we can further discuss it.
Concerning the BROADCAST network type, the PortChannel is not considered a point-to-point link, because of the fact that Ethernet, which is a multi-access technology, is being used. Take a look at this post, which should clarify further.
I hope this has been helpful!
Laz
Hi guys. I would like to share (and propose, as you can add them to the lesson) some additional debug commands I’ve discovered that can be used to better troubleshoot the scenarios in the lesson.
1. OSPF Network Command
R1#sh ip ospf database
OSPF Router with ID (192.168.12.1) (Process ID 1)
R2#sh ip ospf database
OSPF Router with ID (192.168.12.2) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
192.168.12.2 192.168.12.2 210 0x80000001 0x00DDE6 1
The commands help to figure out that OSPF at R1 doesn’t know any network to “advertise” via LSAs. It’s a good hint to figure out later that there is a typo on the configured network.
2. OSPF Passive Interface
R2#debug ip ospf hello
OSPF hello debugging is on
*Jun 11 16:24:14.426: OSPF-1 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 192.168.12.2
R1#debug ip ospf packet
OSPF packet debugging is on
*Jun 11 16:24:33.489: OSPF-1 PAK Et0/0: Drop packet, OSPF not running or passive
These debugs show that R2 is sending hellos, but R1 is not accepting them.
Also, taking a look at R2, we see that hello expire counters decreases until eventually timeout:
R2#show ip ospf interface Ethernet 0/0 | include Hello due
Hello due in 00:00:02
3. OSPF Multicast Filtering
R1#debug ip ospf hello
OSPF hello debugging is on
*Jun 11 16:48:28.374: OSPF-1 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 192.168.12.1
R1#
*Jun 11 16:48:32.202: OSPF-1 HELLO Et0/0: Rcv hello from 192.168.12.2 area 0 192.168.12.2
*Jun 11 16:48:32.202: OSPF-1 HELLO Et0/0: No more immediate hello for nbr 192.168.12.2, which has been sent on this intf 2 times
R2#debug ip ospf hello
OSPF hello debugging is on
*Jun 11 16:48:32.202: OSPF-1 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 192.168.12.2
These commands show that R2 is sending hellos to R1, and R1 is receiving R2 hellos. It also shows that R1 is sending hellos to R2, but R2 doesn’t seem to be replying to them.
4. OSPF Subnet Mask, 5. OSPF Hello & Dead Interval and 6. OSPF Authentication
Nothing to contribute here 
.
7. OSPF Area Mismatch
R1#show ip ospf database
OSPF Router with ID (192.168.12.1) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
192.168.12.1 192.168.12.1 121 0x80000014 0x00D072 0
192.168.12.2 192.168.12.2 503 0x80000013 0x009D9D 1
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count
192.168.12.1 192.168.12.1 89 0x80000003 0x00E9DA 1
192.168.12.2 192.168.12.2 104 0x80000001 0x00C18B 1
We see the same router IPs (192.168.12.1, 192.168.12.2) advertised as “Router Link States” in both areas (Area 0 and Area 1), which is a good hint for the cause of the issue.
After solving the issue:
R1#show ip ospf database
OSPF Router with ID (192.168.12.1) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
192.168.12.1 192.168.12.1 7 0x80000015 0x00A595 1
192.168.12.2 192.168.12.2 8 0x80000017 0x009F96 1
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
192.168.12.2 192.168.12.2 8 0x80000001 0x00CE8E
Now router IPs “Router Link States” are in Area 0. Note that the whole network will also appear in “Net Link States” also in Area 0.
8. OSPF Area Type Mismatch
Nothing to add
9. OSPF DR/BDR Election
R1#debug ip ospf adj
OSPF adjacency debugging is on
R1#clear ip ospf process
Reset ALL OSPF processes? [no]: yes
[...]
*Jun 11 19:46:53.542: OSPF-1 ADJ Et0/0: Interface going Up
*Jun 11 19:47:01.142: OSPF-1 ADJ Et0/0: 2 Way Communication to 192.168.12.2, state 2WAY
*Jun 11 19:47:04.693: OSPF-1 ADJ Et0/0: end of Wait on interface
*Jun 11 19:47:04.693: OSPF-1 ADJ Et0/0: DR/BDR election
*Jun 11 19:47:04.693: OSPF-1 ADJ Et0/0: Elect BDR 0.0.0.0
*Jun 11 19:47:04.693: OSPF-1 ADJ Et0/0: Elect DR 0.0.0.0
*Jun 11 19:47:04.693: OSPF-1 ADJ Et0/0: DR: none
*Jun 11 19:47:04.693: OSPF-1 ADJ Et0/0: BDR: none
The debug shows that no DR/BDR was elected, hence the phases stopped in the 2WAY. It doesn’t help much since it doesn’t explain why (i.e. that both routers have priority zero), but it’s cool to see the debug messages.
After solving the issue:
*Jun 11 19:58:18.862: OSPF-1 ADJ Et0/0: DR/BDR election
*Jun 11 19:58:18.862: OSPF-1 ADJ Et0/0: Elect BDR 192.168.12.1
*Jun 11 19:58:18.862: OSPF-1 ADJ Et0/0: Elect DR 192.168.12.1
*Jun 11 19:58:18.862: OSPF-1 ADJ Et0/0: Elect BDR 0.0.0.0
*Jun 11 19:58:18.862: OSPF-1 ADJ Et0/0: Elect DR 192.168.12.1
*Jun 11 19:58:18.862: OSPF-1 ADJ Et0/0: DR: 192.168.12.1 (Id)
*Jun 11 19:58:18.862: OSPF-1 ADJ Et0/0: BDR: none
*Jun 11 19:58:18.862: OSPF-1 ADJ Et0/0: Nbr 192.168.12.2: Prepare dbase exchange
*Jun 11 19:58:18.862: OSPF-1 ADJ Et0/0: Send DBD to 192.168.12.2 seq 0x5D9 opt 0x52 flag 0x7 len 32
*Jun 11 19:58:21.020: OSPF-1 ADJ Et0/0: Rcv DBD from 192.168.12.2 seq 0x1F0E opt 0x52 flag 0x7 len 32 mtu 1500 state EXSTART
*Jun 11 19:58:21.020: OSPF-1 ADJ Et0/0: NBR Negotiation Done. We are the SLAVE
[...]
*Jun 11 19:58:21.021: OSPF-1 ADJ Et0/0: Synchronized with 192.168.12.2, state FULL
Now, the DR/BDR election happened. Note that only R1 proposed itself to be the DR (R2 didn’t, as it continues to have priority=0).
10. OSPF Network Type
There are 2 solutions in the example. In the first one, we explicitly set the neighbors (as the network type for OSPF is NON_BROADCAST).
I think it’s worth to add the neighbor command output:
R1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.12.2 0 FULL/DROTHER 00:00:05 192.168.12.2 Ethernet0/0
Note that the state is FULL, but there is no DR/BDR now in this case, which is expected (since it’s not a multi-point/broadcast link).
Hello Rarylson
Thanks for sharing these suggestions, I will let Rene know to take a look and consider any modifications or additions to the lesson.
Thanks again!
Laz
Hello Laz ,
in "Multicast Filtering "section in the Access List there is a statement 30 permit icmp any any why did the Ping to multicast address 224.0.0.5 fail ? although the permit Statement allows all Icmp Traffic ?
Thanks very Much for your Support .
Hello Mohammad
I labbed this up and confirmed that I was still able to ping the multicast address of 224.0.0.5 even though the access list was enabled. I then tried to block ICMP packets using the access list and the pings to the multicast address were then blocked.
So you are correct, you should still be able to ping the 224.0.0.5 address even though the OSPF neighborship was not established. I will let Rene know to make any corrections he sees fit.
Thanks for pointing that out!
Laz
Hi Network Lessons Team,
first and foremost, thank you for the valuable work Rene and Team!
My question is concerning the access-list related to Multicast IP 224.0.0.5 “BLOCKSTUFF”
Was this access-list attached to OSPF process to take affect, or is the access-list by itself enough to take affect?
Thank your for your response.
BR,
Jason
Hello Jason
Initially, we can see that the access list is applied to the Fa0/0 interface in an outbound direction. This alone is enough to block any OSPF packets from exiting the interface, since OSPF does not use UDP or TCP.
The resolution to the problem is to permit packets of type “OSPF” which is applied simply by adding the entry 5 permit ospf any any. Neither the access list nor the actual access list entry is directly associated with the OSPF process.
I hope this has been helpful!
Laz
I have a question about Dr/BDR election . Why would OSPF fail to elect a DR when one of the interface has highest IP address in Router ID ?
R1#show ip ospf interface | include Network Type
Process ID 1, Router ID 192.168.12.1, Network Type BROADCAST, Cost: 1
R2#show ip ospf interface | include Network Type
Process ID 1, Router ID 192.168.12.2, Network Type BROADCAST, Cost: 1
Hello Jesteen
In the scenario found in the lesson, the priority of both routers is set to 0. When you set the priority to zero using the ip ospf priority 0 command on the interface, you are essentially saying that you don’t want this OSPF router to take part in the DR/BDR elections on this particular network segment.
So if this is set, the additional methods of choosing a DR and BDR (like the highest router ID) are not applied at all, resulting in a failure of the election.
I hope this has been helpful!
Laz
Hi Lazaros,
Sorry for late reply. That was really helpful I was not aware of that information that setting priority 0 would prevent participating in the DR/BDR election.
Regards,
Jesteen.
Hello Jesteen
Actually, I’d like to clarify. By setting the priority to zero, you are essentially saying that you don’t want this router to participate in an election. In other words, it states that this router is ineligible to become the DR or the BDR. It will necessarily become a DROTHER.
Now if all routers within a network segment are set with a priority of 0, no router will be eligible to become a DR or BDR, and thus the election will fail.
I hope this has been helpful!
Laz
Hi,
What’s is the best way to troubleshoot a mis-matched network type on a link e.g. point-to-point connected to broadcast.
I know sh ip ospf neighbor shows the different network types (b’cast has a DR and P2P doesn’t), but I was wondering if there was another way to find the issue, for example, by using debugs or some other show command. Because when you look at the routers on either end of the link individually, it shows FULL, and the misconfiguration could be missed.
Thanks,
Sam
Hello Samir
Sometimes it depends on the mismatch. For example, if you have broadcast on one end and non-broadcast on the other, the adjacency won’t form. If you have broadcast on one end and point to point on the other, an adjacency will form, but you will get a Syslog message like so:
*Dec 19 06:51:24.260: %OSPF-4-NET_TYPE_MISMATCH: Received Hello from 2.2.2.2 on GigabitEthernet0/1 indicating a potential
network type mismatch
But you’ll get that only once upon creation of the adjacency, and if you miss it you may be in trouble.
So for your question, I’m assuming you are referring to mismatches that will create an adjacency, assuming we missed that first syslog message.
Other than the show ip ospf neighbor some additional commands that can help you to troubleshoot such situations include:
debug ip ospf adj: This command will show you the OSPF adjacency process in real-time. If there’s a mismatch in network type, you will see an error message stating that the network types do not match.sh run | section router ospf: This command will display the OSPF configuration section of the running configuration. You can check to see if ‘network point-to-point’ or ‘network broadcast’ is configured under the OSPF process.I hope this has been helpful!
Laz
Hi Laz,
Some can be found by debugging OSPF hello packets, like the broadcast NBMA combo as they have mis-matched hello timers.
But it’s the ones that form FULL adjacencies that are difficult to spot. I though there might be way other than that one syslog message or doing a side-by-side config comparisons. I guess not.
…Thought you might be interested but I left the mismatched config running overnight and saw the following the next morning:
*Dec 26 20:20:08.530: %SYS-5-CONFIG_I: Configured from console by console
*Dec 26 20:49:30.835: %OSPF-4-NET_TYPE_MISMATCH: Received Hello from 5.5.5.5 on GigabitEthernet0/1 indicating a potential
network type mismatch
*Dec 26 21:49:31.645: %OSPF-4-NET_TYPE_MISMATCH: Received Hello from 5.5.5.5 on GigabitEthernet0/1 indicating a potential
network type mismatch
*Dec 26 22:49:32.128: %OSPF-4-NET_TYPE_MISMATCH: Received Hello from 5.5.5.5 on GigabitEthernet0/1 indicating a potential
network type mismatch
*Dec 26 23:49:33.664: %OSPF-4-NET_TYPE_MISMATCH: Received Hello from 5.5.5.5 on GigabitEthernet0/1 indicating a potential
network type mismatch
*Dec 27 00:49:35.461: %OSPF-4-NET_TYPE_MISMATCH: Received Hello from 5.5.5.5 on GigabitEthernet0/1 indicating a potential
network type mismatch
*Dec 27 01:49:42.999: %OSPF-4-NET_TYPE_MISMATCH: Received Hello from 5.5.5.5 on GigabitEthernet0/1 indicating a potential
network type mismatch
*Dec 27 02:49:49.932: %OSPF-4-NET_TYPE_MISMATCH: Received Hello from 5.5.5.5 on GigabitEthernet0/1 indicating a potential
network type mismatch
*Dec 27 03:49:55.188: %OSPF-4-NET_TYPE_MISMATCH: Received Hello from 5.5.5.5 on GigabitEthernet0/1 indicating a potential
network type mismatch
*Dec 27 04:49:56.967: %OSPF-4-NET_TYPE_MISMATCH: Received Hello from 5.5.5.5 on GigabitEthernet0/1 indicating a potential
network type mismatch
*Dec 27 05:50:04.735: %OSPF-4-NET_TYPE_MISMATCH: Received Hello from 5.5.5.5 on GigabitEthernet0/1 indicating a potential
network type mismatch
*Dec 27 06:50:09.693: %OSPF-4-NET_TYPE_MISMATCH: Received Hello from 5.5.5.5 on GigabitEthernet0/1 indicating a potential
network type mismatch
*Dec 27 07:50:16.086: %OSPF-4-NET_TYPE_MISMATCH: Received Hello from 5.5.5.5 on GigabitEthernet0/1 indicating a potential
network type mismatch
*Dec 27 08:50:18.766: %OSPF-4-NET_TYPE_MISMATCH: Received Hello from 5.5.5.5 on GigabitEthernet0/1 indicating a potential
network type mismatch
*Dec 27 09:50:27.545: %OSPF-4-NET_TYPE_MISMATCH: Received Hello from 5.5.5.5 on GigabitEthernet0/1 indicating a potential
network type mismatch
*Dec 27 10:50:31.545: %OSPF-4-NET_TYPE_MISMATCH: Received Hello from 5.5.5.5 on GigabitEthernet0/1 indicating a potential
So the message looks like the repeats every 1 hour, by default.
Thanks.
Sam
Hello Sam
Indeed, those can be tricky. There’s no way that I know of beyond what I shared in my previous post. However, if you have a network monitor system and you want to keep an eye out for such OSPF errors, you can always set up a syslog alarm, where if such a syslog does indeed appear, you can have the system notify you. Or, if you’re using SNMP, you can use the appropriate trap to be informed of any such situations. To be honest, this is quite a specialized error, and it’s not something that crops up often. It’s also not something that can spontaneously happen, because it’s the result of a deliberate configuration process. I hope this gives you some insight into how to approach this.
I hope this has been helpful!
Laz
Hi @lagapidis
In Section 9, OSPF DR/BDR election, we go onto change the OSPF priority. However, if the priorities are the same, the OSPF router-id should serve as a tie breaker ?? Eventually in section 9 R2 should have become the OSPF DR for that segment. Why do we need to change the priority explicitly? Please clarify.
Thanks,
Adi
Hello Adhithya
When the OSPF priority is set to 0, you are explicitly stating that this router will not take part in the DR/BDR election. Therefore it will never become DR or BDR. For this reason, it will not fall back to the next tie breaker of using the router ID. The result will be what you see in the lesson, that both routers will show the other router as DROTHER.
The router ID tie breaker will only kick in if the OSPF priority of both routers is the same, AND, it is not set to 0.
For more information, take a look at this NetworkLessons note on the topic.
I hope this has been helpful!
Laz