OSPF over Frame-Relay – Part 5: Point-To-Multipoint Nonbroadcast

In The first four parts of this series, we took a look at the OSPF network types of broadcast, non-broadcast, point-to-point, and point-to-multipoint and how each worked over a frame-relay topology.  Today we will be wrapping up this multipart series by discussing the point-to-multipoint non-broadcast OSPF network type when used over frame-relay.

This is a definite topic of confusion for many CCIE candidates, so don’t worry you are not alone!  The first thing I would like to note is that Cisco came out with this for specific reasons, and it is therefore a Cisco only OSPF network type.  It is important that if you do not understand the point-to-multipoint network type, that you go back and read the previous blog because basically the way the point-to-multipoint non-broadcast network type works is exactly the same – except, you guessed it – no broadcasts are allowed!

So if you have been following our series, you know that we have talked about the fact that when you are starting off with setting up a particular OSPF network type you need to ask yourself first “Do I need a DR” ?  The answer here is most certainly NO!  Remember, point-to-ANYTHING never requires a DR!  The next question we need to be asking ourselves is “Can I broadcast?” If not, you need to unicast by configuring the neighbor command.  It seems quite obvious that with a network type name that includes “non-broadcast” we can NOT broadcast, and thus need the neighbor command.  Finally, we need to be thinking about timers.  Our timers in this case will be “slow” timers of 30 seconds and 120 seconds.

Let’s take a look at a common scenario where we would implement this network type.  Check out the diagram below:

There are a couple major things I want to point out that should help you realize what is going on here.  First, we see this “criss-cross” type of DLCI layout going on.  Whenever you see something like this, you need to be going back in your mind and thinking about HOW OSPF is going to work.  Can we even have a DR in this situation?  Well, what does the DR do?  It sends routes to everybody in the area right?  Therefore, it needs a connection to every router in the area.  Does any router in this setup have a direct PVC to EVERY other router?

The answer of course is no.  Since no one single router has a connection to every other router, we can’t possibly have a DR.  That rules out the broadcast and the non-broadcast network types right off the bat.  Now, we could implement point-to-point if we wanted to put a different subnet between each router.  We could also implement point-to-multipoint if we are allowed to broadcast.  But what if our lab tells us something like “You may not use the point-to-point network type, and you may not utilize multicast.”  That statement should narrow things down for us.  What we are going to setup here is a single subnet for the entire frame cloud of 100.100.100.0/24 using point-to-multipoint non-broadcast network type in OSPF.

What we have here on the frame-relay side of things is essentially two hubs – R2 and R6.  We will set up our frame with this mindset.  Here are the underlying frame configs.

R2

interface Serial0/1/0

ip address 100.100.100.2 255.255.255.0

encapsulation frame-relay

frame-relay map ip 100.100.100.2 206

frame-relay map ip 100.100.100.5 205

frame-relay map ip 100.100.100.6 206

no frame-relay inverse-arp

R4

interface Serial0/0/0

ip address 100.100.100.4 255.255.255.0

encapsulation frame-relay

frame-relay map ip 100.100.100.4 406

frame-relay map ip 100.100.100.6 406

no frame-relay inverse-arp

R5

interface Serial0/1/0

ip address 100.100.100.5 255.255.255.0

encapsulation frame-relay

frame-relay map ip 100.100.100.2 502

frame-relay map ip 100.100.100.5 502

no frame-relay inverse-arp

R6

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

frame-relay map ip 100.100.100.4 604

frame-relay map ip 100.100.100.6 604

no frame-relay inverse-arp

OK.  Now let’s get to setting up our frame-relay.  We will also add in some loopbacks to show full connectivity here.

R5(config-line)#int lo1

R5(config-if)#ip add 5.5.5.5 255.255.255.255

R5(config-if)#router ospf 1

R5(config-router)#network 5.5.5.5 0.0.0.0 area 0

R5(config-router)#network 100.100.100.5 0.0.0.0 area 0

R4(config-router)#neighbor 100.100.100.2

R5(config-router)#int s0/1/0

R5(config-if)#ip ospf network point-to-multipoint non-broadcast

R2(config-line)#int lo1

R2(config-if)#ip add 2.2.2.2 255.255.255.255

R2(config-if)#router ospf 1

R2(config-router)#network 2.2.2.2 0.0.0.0 area 0

R2(config-router)#network 100.100.100.2 0.0.0.0 area 0

R2(config-router)#neighbor 100.100.100.5

R2(config-router)#neighbor 100.100.100.6

R2(config-router)#int s0/1/0

R2(config-if)#ip ospf network point-to-multipoint non-broadcast

R6(config-line)#int lo1

R6(config-if)#ip add 6.6.6.6 255.255.255.255

R6(config-if)#router ospf 1

R6(config-router)#network 6.6.6.6 0.0.0.0 area 0

R6(config-router)#network 100.100.100.6 0.0.0.0 area 0

R6(config-router)#neighbor 100.100.100.2

R6(config-router)#neighbor 100.100.100.4

R6(config-router)#int s0/1/0

R6(config-if)#ip ospf network point-to-multipoint non-broad

R4(config-line)#int lo1

R4(config-if)#ip add 4.4.4.4 255.255.255.255

R4(config-if)#router ospf 1

R4(config-router)#network 4.4.4.4 0.0.0.0 area 0

R4(config-router)#network 100.100.100.4 0.0.0.0 area 0

R4(config-router)#neighbor 100.100.100.6

R4(config-router)#int s0/0/0

R4(config-if)#ip ospf network point-to-multipoint non-broad

OK sweet!  That wasn’t so bad.  Let’s see how we did starting from the left side on R5.

R5(config-router)#do sh ip ospf neigh

Neighbor ID     Pri   State           Dead Time   Address         Interface

2.2.2.2           0   FULL/  -        00:01:57    100.100.100.2   Serial0/1/0

R5(config-router)#do sh ip route ospf

2.0.0.0/32 is subnetted, 1 subnets

O       2.2.2.2 [110/65] via 100.100.100.2, 00:01:53, Serial0/1/0

100.0.0.0/8 is variably subnetted, 4 subnets, 2 masks

O       100.100.100.4/32 [110/192] via 100.100.100.2, 00:01:53, Serial0/1/0

O       100.100.100.6/32 [110/128] via 100.100.100.2, 00:01:53, Serial0/1/0

O       100.100.100.2/32 [110/64] via 100.100.100.2, 00:01:53, Serial0/1/0

4.0.0.0/32 is subnetted, 1 subnets

O       4.4.4.4 [110/193] via 100.100.100.2, 00:01:53, Serial0/1/0

6.0.0.0/32 is subnetted, 1 subnets

O       6.6.6.6 [110/129] via 100.100.100.2, 00:01:53, Serial0/1/0

R5(config-router)#do ping 4.4.4.4 so lo1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:

Packet sent with a source address of 5.5.5.5

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 128/130/132 ms

Boom!  Awesome, we have end-to-end connectivity between our two furthest points (R5 loop1 and R4 loop1).  I want you guys to notice a few subtle things here.  First off, in the frame-relay setup notice that I only mapped routers that I had a direct PVC to.  Why???  Check out the show ip route output above.  Notice that the next hop is ALWAYS the router you are directly connected to.  This is DIFFERENT than in a typical frame-relay OSPF setup where you are using the non-broadcast or broadcast network types.  In those situations you will see the next-hop is actually the originating router.

For sake of length, let’s just make sure we have our neighbors on the other three routers here.  Notice the priority of 0 and the state of “Full/ – “.  This should tell us there is no DR as well!!!

R2(config-if)#do sh ip ospf neigh

Neighbor ID     Pri   State           Dead Time   Address         Interface

5.5.5.5           0   FULL/  -        00:01:43    100.100.100.5   Serial0/1/0

6.6.6.6           0   FULL/  -        00:01:48    100.100.100.6   Serial0/1/0

R6(config-if)#do sh ip ospf neigh

Neighbor ID     Pri   State           Dead Time   Address         Interface

2.2.2.2           0   FULL/  -        00:01:53    100.100.100.2   Serial0/1/0

4.4.4.4           0   FULL/  -        00:01:30    100.100.100.4   Serial0/1/0

R4(config-router)#do sh ip ospf neigh

Neighbor ID     Pri   State           Dead Time   Address         Interface

6.6.6.6           0   FULL/  -        00:01:49    100.100.100.6   Serial0/0/0

This is probably one of the more complex if not the most complex situations you can run into with OSPF over frame-relay.  Now that we have covered each and every OSPF network-type, next we will be digging into troubleshooting!  I can see this technology being a big one for possible troubleshooting in the new CCIE 4.0 lab exam!  Next time we will look at how to troubleshoot an OSPF network over frame-relay effectively.  I hope this article has been helpful for you!  Until next time, happy studying!!!

Thanks!

Joe (Post contributed by Joe Astorino – CCIE #24347 R&S)

OSPF over Frame-Relay - Part 5: Point-To-Multipoint Nonbroadcast, 2.5 out of 5 based on 6 ratings

Tags: ccie lab, CCIE R&S 4.0 Lab, ipexpert