Pages

4.04.2013

OSPF Network Types Part 6 - Multipoint

Alright, so you decided to go with a partial-mesh Frame-Relay WAN and read my last post on NBMA and choose the route of Multipoint. Great!

Now its time to look into the features of Multipoint or what is sometimes called Point-to-Multipoint (P2MP). The reason its called P2MP is because it acts just like a group of individual P2P links connected to the same hub. Awesome we love P2P links!

Here is a breakdown of Multipoint features for your enjoyment!
  • Treats network as a collection of P2P links
  • Sends hellos as Multicast to 224.0.0.5
  • Neighbor Discovery
  • No DR/BDR election (hence no 224.0.0.6)
  • Hello/Dead timers 30/120
Unlike Broadcast and NBMA Multipoint updates the next-hop value when forwarding an LSU sent from a DRother. This makes Multipoint the better of the three options to choose for your partial-mesh. But just like the other OSPF network types Multipoint has its pit-falls you need to watch out for.


Lets dig into the lab and see what we find.

Same network as the last post. I'm lazy and dont want to build another topology...

A basic Frame-Relay configuration is applied minus the neighbor statements and frame-relay maps.  Since this network will default to NON_BROADCAST we need to change the interface to Multipoint before adjacencies will come up.




Notice how the adjacencies show a FULL / - without a DR/BDR election. Also since P2MP supports neighbor discovery that means that it must be doing it with 224.0.0.5. Lets enable debugging with debug ip ospf events and then reset the OSPF process.



Yep, sure enough if you filter through the spew of debug output, you will see OSPF kicks out a HELLO to the multicast address 224.0.0.5. Both R2 and R3 respond to this and the adjacency process gets start.

As mentioned above the Multipoint network type treats all links like P2P links between the hub and spokes. This can be verified with show ip ospf database router [link-address].



The first entry shows the link between R1 and R2 listed as Point-to-point.

The last two entries are listed as stub networks since they are local IP addresses of R2.  By default since these links are treated as P2P links the local IPs are advertised as stubs just like a loopback interface. Notice the /32 mask.

Great now let look at the routing table and see what is happening with the next-hops since we had issues with them in our NBMA network.



Just as expected the loopback networks are being advertised with a next-hop of R1 (10.0.123.1).

You will also notice the additional routes for the Frame-Relay circuits (10.0.123.0/24). These links are also being advertised as P2P links which is why they are showing up separate instead of a single /24 route. You might have noticed they are being advertised as a /32.

YAY!! so everyone is happy and working perfectly and Ryan still hasn't complained about any pitfalls. Well, I'm getting there...

The only downside to Multipoint, is OSPF, by default, uses the cost of the outgoing interface (s0/0 in this case) for all circuits to calculate each routes metric. So if you have multiple paths through the Frame-Relay cloud to reach a single destination OSPF will calculate both metrics based on the exiting interfaces cost value.

This is fine as long as all circuits have the same bandwidth. But if you have differing bandwidths coming into the hub then your routes are not going to reflect the proper cost to calculate the routes metrics.

Oh no's!! What will we ever do!?!

Dont worry Cisco has an answer for this. Its my last post for OSPF Network Types...

Multipoint NonBroadcast.