Pages

4.03.2013

OSPF Network Types Part 4 - Broadcast

Point-to-Point and Loopback network types are the only two I have had any real world experience with. By following best practice and proper design techniques, these are the only two you should need. P2P sub-interfaces on a mesh and partial-mesh Frame-Relay WAN are the recommended solution and keep things simple (as you will find out soon...)

But for the CCIE and a full grasp of OSPF, you need to understand the other 4 and their uses. So lets dig in.


Broadcast 

First up is broadcast. As you saw in the P2P post,  Ethernet or multiaccess broadcast segments defaults to BROADCAST. Here is a breakdown of features.
  • Used on multiaccess broadcast segments such as Ethernet
  • No neighbor discovery  (configured only on DR and BDR)
  • Hellos and updates sent via 224.0.0.5 (allSPFRouters) and 224.0.0.6 (allDRouters)
  • Hello/Dead Timers 10/40
  • Performs DR/BDR election 
For the most part, broadcast networks just work once the OSPF process is setup. DR and BDRs get elected and Type 2 LSAs start flying around. There is one case you must watch out for when using either BROADCAST or NBMA (NON_BROADCAST) network types.

The issue lies when you face a partial mesh Frame-Relay cloud. Below is the setup we will be working with and the relevant configuration from R1.




Neighbor statements are needed since the Frame-Relay cloud does not support multicast, hence the non-broadcast aspect. You only need to configure neighbor statements on one side. Once the other end sees unicast HELLOs coming its way it will swap over to unicast HELLOs as well.

Next we verify R1 has both adjacencies to R2 and R3. Lets also take a look at the routing table and see what we learned.




OK good! R1 is the DR for this segment and both loopback networks from R2 and R3 are being learned. We are also able to ping both loopback networks so all is good.



This configuration goes south when either R2 or R3 wins the DR election. To accomplish this we will set R3's S0/0 interface with ip ospf priority 100 and reset the ospf proccess.



R3 won the DR election and this is were we start to have issues. Lets first take a look at show ip route ospf on all three routers



Man! R2 shows no learned routes, while R1 and R3 show no learned routes from R2. 

The reason for this is LSU communications breakdown between the DR and other spoke devices, R2 in this case. Since R3 and R2 do not have full Layer 2 reachability through the partial-mesh these updates fail to make it past the hub, R1. 

Obviously the resolution to this issue is to insure all spoke routers are set with an OSPF priority of 0 and your Hub has the highest priority in the Frame-Relay cloud. Or go with the best solution and use P2P sub-interfaces. 

Now on to NBMA and its own little nasties!!