August 10, 2009, 5:12 PM — In today’s blog we will continue our multi-part discussion on frame-relay and OSPF network-types by digging into point-to-multipoint. Point-to-multipoint OSPF network type over frame-relay is what I like to call the “cheater method”. Why? Well, you do NOT need a DR and you do NOT need neighbor commands. It is very simple. OK, WHY don’t we need a DR or neighbor commands? Well, with point-to-multipoint everybody just makes an adjacency with everybody they can, and routes are relayed from one router to the next within the area. So if one spoke advertises routes to the hub, the hub will then in turn advertise those routes down to the other hub over a separate adjacency. You could also use this type if you happened to be allowed to use a full mesh in your lab. What about the neighbor command? We don’t need this either…so long as we have the broadcast statement on our frame-relay maps, we are good to go!
The diagram we are working with is exactly the same as the one for non-broadcast, and broadcast!
Remember, point-to-ANYTHING never requires a DR!!! As far as timers, we have “slow” timers of 30 seconds hello and 120 seconds dead. IF your lab does not give you any restrictions, and you are comfortable with this stuff (and you will need to be if you expect a pass) go ahead and use this! It makes your life E-A-S-Y!!! I am going to setup a quick demo of this to show you just how simple this is. Remember, you can mix and match network types as well, so long as your timers match, and you agree on the presence (or lack thereof) of a DR. We will get deep into that during our last installment in this series. For now, let’s just setup a basic point-to-multipoint topology within frame-relay.
R2
interface Serial0/1/0.256 multipoint
ip address 100.100.100.2 255.255.255.0
ip ospf network point-to-multipoint
frame-relay map ip 100.100.100.2 206
frame-relay map ip 100.100.100.5 205 broadcast
frame-relay map ip 100.100.100.6 206 broadcast
R5
interface Serial0/1/0
ip address 100.100.100.5 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint
frame-relay map ip 100.100.100.2 502 broadcast
frame-relay map ip 100.100.100.5 502
frame-relay map ip 100.100.100.6 502
no frame-relay inverse-arp
R6
interface Serial0/1/0
ip address 100.100.100.6 255.255.255.0
encapsulation frame-relay
ip ospf network point-to-multipoint
frame-relay map ip 100.100.100.2 602 broadcast
frame-relay map ip 100.100.100.5 602
frame-relay map ip 100.100.100.6 602
no frame-relay inverse-arp
R2(config-subif)#do sh ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
100.100.26.6 0 FULL/ - 00:01:48 100.100.100.6 Serial0/1/0.256
100.100.25.5 0 FULL/ - 00:01:47 100.100.100.5 Serial0/1/0.256
Again, we can examine the output on R2 from “sh ip ospf neigh” and we should be able to see whats going on here…We have a priority of “0″ and a state of “FULL/ -” because there is no DR election!
This is how simple point-to-multipoint can be. Notice that even though the frame-relay interfaces themselves on the spokes are physical interfaces, we have the ability to change the OSPF network type to whatever we want! Again, in the real lab if you are not restricted, it is an easy way to get your OSPF over frame-relay up and running!
Keep checking the IPexpert blog for our next article on the final network type: the dreaded point-to-multipoint non-broadcast!
Thanks!
Joe (Post contributed by Joe Astorino - CCIE #24347 R&S)
