Pages

4.04.2013

OSPF Network Types Part 5 - NonBroadcast (NBMA)

If you haven't check out Part 4 on OSPF Broadcast network types it wouldnt hurt to run through it now. NBMA is pretty much the exact same as Broadcast with the same pitfalls mentioned before. The key difference between the two is NMBA is geared for,

wait for it...

wait for it...

non Broadcast networks :)

So, Broadcast is geared towards Ethernet segments and NBMA is geared towards Frame-Relay and ATM circuits. Got it!!

This also means multicast HELLOs and discovery will not happen (via 224.0.0.5 and 224.0.0.6) on NBMA networks so you must configure your neighbors manually. Here is a quick breakdown of features in NBMA and then we will dig into the pitfalls.
  • Default on multipoint NBMA media (Frame Relay main interface or multipoint FR interface)
  • HELLOs sent as unicast
  • Manually defined neighbors (only on DR and BDR)
  • Performs DR/BDR election
  • Hello/Dead timers 30/120
  • No DR preemption

So what issues does one need to know with NBMA networks? Remember how I keep saying to always use P2P and fully-meshed Frame-Relay? Well this is another one of those reasons.

By design. to optimize traffic flow through a network the OSPF DR will not update the next-hop value of a LSU generated by a DRother. This is the default behavior for both broadcast and NBMA network types.

Here is why.

In the below diagram R1 is the DR for this Ethernet segment between R1, R2, and R3. R2 will send an LSU advertising its loopback network 2.2.2.2 with a next-hop of itself. All LSUs will only be sent to R1 since it is the DR. R1 then propagates this LSU over to R3 but keeps the next-hop value in tact instead of updating it with its own link address.

The reason for this is when R3 tries to send traffic to R2's loopback network R3's RIB lookup will show R2 as the next hop and forward directly to R2. Easy, simple and efficient.



But, If R1 would have changed the next-hop value, like it does for routes outside the segment, R3 would then have to send all traffic towards the DR when it needs to reach any network hanging off R2 or any other router on the same segment. Not the most efficient approach. So it makes sense for the DR to leave the next-hop address alone.

Since the network above is an Ethernet segment which defaults to BROADCAST lets see what happens when we use a FR partial-mesh to accomplish the same thing.

We have a basic Frame-Relay setup with no static mappings. First, verify R1 can properly ping R2 and R3



Great! Now apply the below OSPF configuration to each router. Neighbor commands are only applied to R1 as discussed in Part 4.



Give it a minute and we can verify that R1 forms adjacencies with R2 and R3. R1 should also take over the DR role.If anything other than the Frame-Relay hub is elected DR then we run into the same issue described previously.



Just to make sure defaults applied the proper network type, verify that S0/0 on R3 is NON_BROADCAST and F0/0 is BROADCAST.



Show ip route on R3 shows a route to R2s loopback so lets ping it.



No dice... As we talked about before, look at the route for 2.2.2.2 in the above show ip route ospf above. The route points directly to R2 (10.0.123.2). Fire up a debug to see why R3 is having issues and send a ping to 2.2.2.2



Look at that! Man if ever in question about something debugs will show you what is really going on. Just wish there was a debug wife...

So R3 is failing at the layer-3 to layer-2 conversion. The first debug line shows that the RIB is being used for L3 look up and S0/0 was determined to be the exit point.

The next two lines show S0/0 failing to encapsulate the packet with a proper DLCI from the "Encaps failed--no map entry" and "encapsulation failed"

Since R4 is advertised into the segment by R3, R3 follows the rules and swaps out the next-hop value for its own link address. But, R2 will still  have the same issue reaching R4 since the DR does not change the next-hop to itself.



So how do we solve this issue?

Like I said before, you should always design with a full mesh or at minimum use P2P sub-interfaces when a full mesh is unreasonable. Another options that would also work but dosen't scale is to apply Frame-Repay maps on all routers for all spokes in the FR cloud.

So now you face the situation were you have a Frame-Relay partial mesh WAN that was initially setup without using sub-interfaces and your getting sick of creating tons of frame-maps for each site. What do you do?

No, you dont hire a CCNA whose sole mission is to create frame maps all day long.

You deploy the Point-to-Multipoint network type across your segment. Man!! This John T. Moy guy thought of everything!

So guess what network type is next?