OSPF over Frame-Relay - Part 4: Point-To-Multipoint

http://ipexpert.ccieblog.com/ |  Networking, CCIE, frame relay

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)

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Answers - Powered by ITworld

ITworld Answers helps you solve problems and share expertise. Ask a question or take a crack at answering the new questions below.

Ask a Question
randomness