August 03, 2009, 2:52 PM — 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)
