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