OSPF over Frame-Relay – Part 1: Non-Broadcast

OSPF is a topic that must be absolutely mastered for the CCIE lab exam.  Many students understand the fundamental concepts, but get thrown for a loop when it comes to OSPF running over a frame-relay topology.  There are so many different network types and variations, that it can quickly become confusing.  This is the first part in a multi-part series that will cover each and every OSPF network type and how it relates to frame-relay.  By the end of this tutorial series, you should have a solid understanding of all the different network types, when you can use them, and in what scenarios.

To start off our series, we are going to look at the default OSPF network type with respect to frame-relay physical and multipoint sub-interfaces: non-broadcast.  It is important to ask yourself the question “Why IS the default non-broadcast anyways?”  Great question, I’m glad you asked : )  When you break down the technology, and understand the technology, putting these things together becomes second nature.  So, why non-broadcast by default?  Remember, frame-relay is a non-broadcast multi-access medium by nature.  Frame-relay by design cannot send a broadcast frame out to all members of the frame cloud.  OK, so what?  Well, think about how OSPF works.  OSPF uses multicast by default, which is also considered by the router to be of the broadcast variety.  If frame-relay by default cannot send broadcasts and OSPF by default needs them to work (hellos, etc) then we need to change something!  Enter the OSPF non-broadcast network type.

Let’s assume that in our lab today we have a basic frame-relay hub-and-spoke topology with R2 being our hub, and R4, R5, and R6 being our spokes.  Each spoke only has a PVC up to the hub.  Our frame-relay is working fine, but we need to implement OSPF and are told to ONLY use the default network types.  Let’s first verify our configuration, then get into things. Check out our diagram:

Here is our frame config right out of the box:

R2

interface Serial0/1/0

no ip address

encapsulation frame-relay

no frame-relay inverse-arp

!

interface Serial0/1/0.256 multipoint

ip address 100.100.100.2 255.255.255.0

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

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

end

R6

interface Serial0/1/0

ip address 100.100.100.6 255.255.255.0

encapsulation frame-relay

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

end

As you can see there, we have a fairly straight forward hub-and-spoke setup.  Let’s setup our basic OSPF and start looking at some things.

R2(config)#router ospf 1

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

R2(config-router)#do sh ip ospf int s0/1/0.256 | i Network Type

Process ID 1, Router ID 100.100.100.2, Network Type NON_BROADCAST, Cost: 64

You can see that right off the bat, without doing anything special, we have a non-broadcast network type because that is the default.  This should lead us into thinking about 3 things specifically.  First, do I need a DR?  Secondly, will my OSPF communicate via multicast or unicast? Finally, what are my timers, and will they affect me?  We most certainly do need a designated router (DR) in a non-broadcast network type.  In a frame-relay hub-and-spoke deployment you ALWAYS want the frame hub to be the DR.  Why?  Remember, the DR sends the routes out to all the other routers in the area.  Therefore, it needs connectivity to every router in the area.  The hub is the only router that has connectivity to every other router.  So, how can we force it to be the DR?  Set the priority!  Highest priority wins.  Also, since we never want our spokes to be the DR/BDR we will set their priority to 0 meaning they can never be elected DR/BDR.

Question #2 is how will our OSPF network communicate?  By default, OSPF uses multicasts. We are on a non-broadcast network medium.  Hmmmmmm….Can we use unicast?  Yes, we can and need to!  How do we do it?  We use the neighbor command.  Technically, you can put this on either the hub or the spoke or both.  I typically do it just on my hub because it is a good logical place since it is right in the middle of things.

Finally, the non-broadcast network type in OSPF uses “slow” timers meaning 30 second hello and 120 second dead-time. A good way to remember this is that frame-relay is a WAN technology. Compared to Ethernet it is “slow” so we use the slower timers. For this basic setup it won’t effect us since all our network types will match.

OK! With that being said lets set our priority and neighbor commands on the hub!

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

R2(config-subif)#ip ospf priority 255

R2(config-subif)#

R2(config-subif)#router ospf 1

R2(config-router)#neighbor 100.100.100.5

R2(config-router)#neighbor 100.100.100.6

OK, now let’ get our OSPF rolling on our spoke routers. Don’t forget the priority!

R5(config-if)#ip ospf priority 0

R5(config-if)#

R5(config-if)#router ospf 1

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

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

R6(config-if)#ip ospf pri 0

R6(config-if)#

R6(config-if)#router ospf 1

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

If we did things correctly, we should see this on our hub after a short time…

*Jun 27 08:00:06.313: %OSPF-5-ADJCHG: Process 1, Nbr 100.100.100.5 on Serial0/1/0.256 from LOADING to FULL, Loading Done

*Jun 27 08:00:08.385: %OSPF-5-ADJCHG: Process 1, Nbr 100.100.100.6 on Serial0/1/0.256 from LOADING to FULL, Loading Done

Awesome! So our neighbors came up!  Verify…

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

Neighbor ID     Pri   State           Dead Time   Address         Interface

100.100.100.5     0   FULL/DROTHER    00:01:45    100.100.100.5   Serial0/1/0.256

100.100.100.6     0   FULL/DROTHER    00:01:30    100.100.100.6   Serial0/1/0.256

Great, we have neighbors!  What is FULL/DROTHER?  That means our adjacency is up (full) and the state of the neighbor is “DR Other” meaning it is not a DR/BDR but we have a peering to it. Exactly what we want!

So let’s review.  Frame-relay is inherently a non-broadcast medium.  Therefore, the default OSPF network type on frame-relay physical and multipoint sub-interfaces is non-broadcast.  Therefore, we need to tell OSPF to use unicast using the neighbor command on either our hub our spokes, or both.  We need a DR, and we manipulate OSPF in such a way that the hub always becomes the DR.  That’s it for non-broadcast OSPF over frame!

Thanks!

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

OSPF over Frame-Relay – Part 1: Non-Broadcast, 1.5 out of 5 based on 2 ratings

Tags: Frame Relay, OSPF