Routing & Switching 
In my previous tutorials we looked at the different OSPF Network types (you can find Part 1 here, Part 2 here, Part 3 here, and Part 4 here) and also how they interact with each other. In this tutorial we will be looking at implementing OSPF over a partial mesh Frame-Relay network with multiple hubs and spokes. This is the last of the OSPF Network Types and Frame Relay series of articles….unless I find something cool! 
We will be implementing the following topology for this tutorial:
ghostios = true
sparsemem = true
model = 3640
[localhost]
[[3640]]
image = Program FilesDynamipsimagesc3640-jk9o3s-mz.124-12.bin
# On Linux / Unix use forward slashes:
# image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
ram = 128
[[ROUTER R1]]
f0/0 = LAN 1
s1/0 = FRAME 1
console = 2000
model = 3640
[[ROUTER R2]]
f0/0 = LAN 2
s1/0 = FRAME 2
console = 2001
model = 3640
[[ROUTER R3]]
f0/0 = LAN 3
s1/0 = FRAME 3
console = 2002
model = 3640
[[ROUTER R4]]
f0/0 = LAN 4
s1/0 = FRAME 4
console = 2003
model = 3640
[[FRSW FRAME]]
1:102 = 2:201
2:203 = 3:302
3:304 = 4:403
Lets have a look at the basic configuration for this topology:
hostname R1 ! no service timestamps debug uptime no service timestamps log uptime ! interface FastEthernet0/0 ip address 1.1.1.1 255.255.255.0 duplex auto speed auto ! interface Serial1/0 ip address 192.168.1.1 255.255.255.0 encapsulation frame-relay frame-relay map ip 192.168.1.2 102 broadcast frame-relay map ip 192.168.1.3 102 frame-relay map ip 192.168.1.4 102 no frame-relay inverse-arp
hostname R2 ! no service timestamps debug uptime no service timestamps log uptime ! interface FastEthernet0/0 ip address 2.2.2.2 255.255.255.0 duplex auto speed auto ! interface Serial1/0 ip address 192.168.1.2 255.255.255.0 encapsulation frame-relay frame-relay map ip 192.168.1.1 201 broadcast frame-relay map ip 192.168.1.3 203 broadcast frame-relay map ip 192.168.1.4 203 no frame-relay inverse-arp
hostname R3 ! no service timestamps debug uptime no service timestamps log uptime ! interface FastEthernet0/0 ip address 3.3.3.3 255.255.255.0 duplex auto speed auto ! interface Serial1/0 ip address 192.168.1.3 255.255.255.0 encapsulation frame-relay frame-relay map ip 192.168.1.1 302 frame-relay map ip 192.168.1.2 302 broadcast frame-relay map ip 192.168.1.4 304 broadcast no frame-relay inverse-arp
hostname R4 ! no service timestamps debug uptime no service timestamps log uptime ! interface FastEthernet0/0 ip address 4.4.4.4 255.255.255.0 duplex auto speed auto ! interface Serial1/0 ip address 192.168.1.4 255.255.255.0 encapsulation frame-relay frame-relay map ip 192.168.1.1 403 frame-relay map ip 192.168.1.2 403 frame-relay map ip 192.168.1.3 403 broadcast no frame-relay inverse-arp
Let’s take a close look at this configuration. You can see above we have a partial mesh configuration and it could be argued that we actually have two hubs. R2 and R3 could both be considered hubs. R2 is the hub for R1 and R3 spokes, and R3 is the hub for R2 and R4 spokes. The broadcast statements reflect this. R2 has broadcast statements in its frame-relay map for its spokes, and only its spokes. This is the same on R3, we have broadcast statements for R2 and R4 (its spokes only). This is to stop redundant broadcasts.
If we apply a broadcast statement to each and every frame-relay map statement this will cause redundant broadcasts frames to be sent. For example lets say we configure R4 as follows:
interface Serial1/0 ip address 192.168.1.4 255.255.255.0 encapsulation frame-relay frame-relay map ip 192.168.1.1 403 broadcast frame-relay map ip 192.168.1.2 403 broadcast frame-relay map ip 192.168.1.3 403 broadcast no frame-relay inverse-arp
Notice we have applied a broadcast option to every frame-relay map statement. When a broadcast frame is sent, it will create three packets with a layer2 header (frame relay) specifying DLCI 403, and a layer3 header (IP) specifying a destination of 192.168.1.255. R3 will receive all three of these frames.
R3 will look at the layer2 header of those frames and say “Oh this for me at layer2! Great, lets look at the layer3 header”. R3 will then de-encapsulate the layer2 header (the frame) and then take a look at the layer3 header which has a destination of 192.168.1.255. “Oh its a broadcast great, thats for me as well”, R3 says. Will it forward those back out the interface to the rest of the Routers? No. Think about this. When you get a broadcast packet on an ethernet network does your computer process it and then send it back out again. If it did this would result in a hell of a lot of broadcast traffic on our networks!
R3 will get three packets that have the broadcast as a destination address and process them. It will not resend those broadcast packets backout again. That is what it means by redundant broadcasts.
Let’s verify this:
R2#debug ip packet IP packet debugging is on
R3#debug ip packet IP packet debugging is on
R4#debug ip packet IP packet debugging is on
We have turned on ip packet debugging on all routers (don’t try this on a production router!). Let’s generate some packets on R4:
R4#ping 192.168.1.255 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.255, timeout is 2 seconds: IP: s=192.168.1.4 (local), d=255.255.255.255 (Serial1/0), len 100, sending broad/multicast IP: tableid=0, s=192.168.1.3 (Serial1/0), d=192.168.1.4 (Serial1/0), routed via RIB IP: s=192.168.1.3 (Serial1/0), d=192.168.1.4 (Serial1/0), len 100, rcvd 3 IP: tableid=0, s=192.168.1.3 (Serial1/0), d=192.168.1.4 (Serial1/0), routed via RIB IP: s=192.168.1.3 (Serial1/0), d=192.168.1.4 (Serial1/0), len 100, rcvd 3 IP: tableid=0, s=192.168.1.3 (Serial1/0), d=192.168.1.4 (Serial1/0), routed via RIB IP: s=192.168.1.3 (Serial1/0), d=192.168.1.4 (Serial1/0), len 100, rcvd 3 Reply to request 0 from 192.168.1.3, 80 ms Reply to request 0 from 192.168.1.3, 96 ms Reply to request 0 from 192.168.1.3, 88 ms -----Output Cut-----
R3# IP: s=192.168.1.4 (Serial1/0), d=255.255.255.255, len 100, rcvd 2 IP: tableid=0, s=192.168.1.3 (local), d=192.168.1.4 (Serial1/0), routed via FIB IP: s=192.168.1.3 (local), d=192.168.1.4 (Serial1/0), len 100, sending IP: s=192.168.1.4 (Serial1/0), d=255.255.255.255, len 100, rcvd 2 IP: tableid=0, s=192.168.1.3 (local), d=192.168.1.4 (Serial1/0), routed via FIB IP: s=192.168.1.3 (local), d=192.168.1.4 (Serial1/0), len 100, sending IP: s=192.168.1.4 (Serial1/0), d=255.255.255.255, len 100, rcvd 2 IP: tableid=0, s=192.168.1.3 (local), d=192.168.1.4 (Serial1/0), routed via FIB IP: s=192.168.1.3 (local), d=192.168.1.4 (Serial1/0), len 100, sending
You can see clearly in the output above that R3 got 3 ping packets for every one ping that was supposed to be sent. R3 then sent 3 unicast reply back to to R4 only. Be aware of this as I see a lot of people setting broadcast statement on every frame-relay map statement. I don’t know if you will loose marks on this in the CCIE Lab exam but it certainly helps to be aware of it.
On your hub, set a broadcast frame-relay map on all the DLCI’s leading to your spokes. On your spokes, set the broadcast frame-relay map on the DLCI leading to your hub.
This has implications for OSPF. It is why we usually want to make sure that the hub is the Designated Router (DR) in OSPF. The spokes send an update via a multicast (subset of broadcast) to 224.0.0.6 which the DR listens on. This is only applicable to network types that require a DR. The updates are then collated by the DR and sent out to the other spokes via the address 224.0.0.5. They are seperate broadcasts.
Let’s clean up before we move on to setting up OSPF across this network.
R2#un all All possible debugging has been turned off
R3#un all All possible debugging has been turned off
R4#un all All possible debugging has been turned off R4#conf t Enter configuration commands, one per line. End with CNTL/Z. R4(config)#default int s1/0 Building configuration... Interface Serial1/0 set to default configuration R4(config)# %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed state to down %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed state to up R4(config)#int s1/0 R4(config-if)# ip address 192.168.1.4 255.255.255.0 R4(config-if)# encapsulation frame-relay R4(config-if)# frame-relay map ip 192.168.1.1 403 R4(config-if)# frame-relay map ip 192.168.1.2 403 R4(config-if)# frame-relay map ip 192.168.1.3 403 broadcast R4(config-if)# no frame-relay inverse-arp R4(config-if)#no shut R4(config-if)#end
One of the things that you should be asking yourself looking at that topology is what OSPF network type do we use? We’ve already stated that there are essentially two hubs in that topology. Both R2 and R3 could be considered hubs. Well, if there are two hubs which one do we make the DR? Can we even use a network type that requires a DR in this topology? Let’s explore this first.
interface Serial1/0 ip ospf network broadcast ip ospf priority 0 ! router ospf 1 router-id 1.1.1.1 log-adjacency-changes network 1.1.1.1 0.0.0.0 area 0 network 192.168.1.1 0.0.0.0 area 0
interface Serial1/0 ip ospf network broadcast ! router ospf 1 router-id 2.2.2.2 log-adjacency-changes network 2.2.2.2 0.0.0.0 area 0 network 192.168.1.2 0.0.0.0 area 0
interface Serial1/0 ip ospf network broadcast ! router ospf 1 router-id 3.3.3.3 log-adjacency-changes network 3.3.3.3 0.0.0.0 area 0 network 192.168.1.3 0.0.0.0 area 0
interface Serial1/0 ip ospf network broadcast ip ospf priority 0 ! router ospf 1 router-id 4.4.4.4 log-adjacency-changes network 4.4.4.4 0.0.0.0 area 0 network 192.168.1.4 0.0.0.0 area 0
So we have activated ospf on all the interfaces in our topology. For simplicity sake we have used a single OSPF area (area 0) for our entire topology.
Let’s verify that we are able to establish adjacency on our routers:
R1#sh ip ospf nei Neighbor ID Pri State Dead Time Address Interface 2.2.2.2 1 FULL/DR 00:00:30 192.168.1.2 Serial1/0
R2#sh ip ospf nei Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 0 FULL/DROTHER 00:00:36 192.168.1.1 Serial1/0 3.3.3.3 1 FULL/DR 00:00:30 192.168.1.3 Serial1/0
R3#sh ip ospf nei Neighbor ID Pri State Dead Time Address Interface 2.2.2.2 1 FULL/BDR 00:00:32 192.168.1.2 Serial1/0 4.4.4.4 0 FULL/DROTHER 00:00:33 192.168.1.4 Serial1/0
R4#sh ip ospf nei Neighbor ID Pri State Dead Time Address Interface 3.3.3.3 1 FULL/DR 00:00:38 192.168.1.3 Serial1/0
At first glance, that looks fine. They all came up as fully adjacent, but take a look at those DR/BDR relationships. They are not consistent at all!
R1#sh ip ospf int s1/0 | inc Designated|Backup
Designated Router (ID) 2.2.2.2, Interface address 192.168.1.2
Backup Designated router (ID) 2.2.2.2, Interface address 192.168.1.2
Adjacent with neighbor 2.2.2.2 (Designated Router)
R2#sh ip ospf int s1/0 | inc Designated|Backup
Designated Router (ID) 3.3.3.3, Interface address 192.168.1.3
Backup Designated router (ID) 2.2.2.2, Interface address 192.168.1.2
Adjacent with neighbor 3.3.3.3 (Designated Router)
R3#sh ip ospf int s1/0 | inc Designated|Backup
Designated Router (ID) 3.3.3.3, Interface address 192.168.1.3
Backup Designated router (ID) 2.2.2.2, Interface address 192.168.1.2
Adjacent with neighbor 2.2.2.2 (Backup Designated Router)
R4#sh ip ospf int s1/0 | inc Designated|Backup
Designated Router (ID) 3.3.3.3, Interface address 192.168.1.3
Adjacent with neighbor 3.3.3.3 (Designated Router)
R1 believes that R2 is the DR. R2, R3, and R4 believe that R3 is the DR. How will this effect the routing tables?
R2#sh ip route | b Gateway
Gateway of last resort is not set
2.0.0.0/24 is subnetted, 1 subnets
C 2.2.2.0 is directly connected, FastEthernet0/0
3.0.0.0/24 is subnetted, 1 subnets
O 3.3.3.0 [110/65] via 192.168.1.3, 00:03:40, Serial1/0
4.0.0.0/24 is subnetted, 1 subnets
O 4.4.4.0 [110/65] via 192.168.1.4, 00:03:40, Serial1/0
C 192.168.1.0/24 is directly connected, Serial1/0
R3#sh ip route | b Gateway
Gateway of last resort is not set
2.0.0.0/24 is subnetted, 1 subnets
O 2.2.2.0 [110/65] via 192.168.1.2, 00:04:07, Serial1/0
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.3.0 is directly connected, FastEthernet0/0
4.0.0.0/24 is subnetted, 1 subnets
O 4.4.4.0 [110/65] via 192.168.1.4, 00:04:07, Serial1/0
C 192.168.1.0/24 is directly connected, Serial1/0
R4#sh ip route | b Gateway
Gateway of last resort is not set
2.0.0.0/24 is subnetted, 1 subnets
O 2.2.2.0 [110/65] via 192.168.1.2, 00:04:18, Serial1/0
3.0.0.0/24 is subnetted, 1 subnets
O 3.3.3.0 [110/65] via 192.168.1.3, 00:04:18, Serial1/0
4.0.0.0/24 is subnetted, 1 subnets
C 4.4.4.0 is directly connected, FastEthernet0/0
C 192.168.1.0/24 is directly connected, Serial1/0
It looks like R2, R3, and R4 can see each others Ethernet networks, but they have no visibility of R1′s Ethernet segment.
R1#sh ip route | b Gateway
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, FastEthernet0/0
C 192.168.1.0/24 is directly connected, Serial1/0
R1 has no visibility at all of the other networks even though we are fully adjacent with R2!
Let’s examine this a little closer. In the above topology, R2, R3, and R4 will be able to swap routes as they have a consitent DR. Updates will be sent to the DR, these will be collated by the DR and then resent out to the spokes. But R1 thinks R2 is the DR. R1 will send its updates to what it thinks is the DR (R2). R2 will not accept these routes because it believes R3 is the DR!
The biggest problem with this topology and OSPF network types that require a DR is “who do we make the DR?”. We usually make the hub in a hub and spoke topology the DR, but what happens when we effectively have 2 hubs? These types of topologies are simply not suited to OSPF network types that require a DR (broadcast, and non-broadcast). We can’t have 2 DR’s!
Let’s try the same thing with a Non-DR OSPF Network type. In this example we will be using the point-to-multipoint OSPF network type, although we could also use any of the other types that don’t require a DR.
Let’s take a look at the configuration:
interface Serial1/0 ip address 192.168.1.1 255.255.255.0 encapsulation frame-relay ip ospf network point-to-multipoint frame-relay map ip 192.168.1.2 102 broadcast frame-relay map ip 192.168.1.3 102 frame-relay map ip 192.168.1.4 102 no frame-relay inverse-arp ! router ospf 1 router-id 1.1.1.1 log-adjacency-changes network 1.1.1.1 0.0.0.0 area 0 network 192.168.1.1 0.0.0.0 area 0
interface Serial1/0 ip address 192.168.1.2 255.255.255.0 encapsulation frame-relay ip ospf network point-to-multipoint frame-relay map ip 192.168.1.1 201 broadcast frame-relay map ip 192.168.1.3 203 broadcast frame-relay map ip 192.168.1.4 203 no frame-relay inverse-arp ! router ospf 1 router-id 2.2.2.2 log-adjacency-changes network 2.2.2.2 0.0.0.0 area 0 network 192.168.1.2 0.0.0.0 area 0
interface Serial1/0 ip address 192.168.1.3 255.255.255.0 encapsulation frame-relay ip ospf network point-to-multipoint frame-relay map ip 192.168.1.1 302 frame-relay map ip 192.168.1.2 302 broadcast frame-relay map ip 192.168.1.4 304 broadcast no frame-relay inverse-arp ! router ospf 1 router-id 3.3.3.3 log-adjacency-changes network 3.3.3.3 0.0.0.0 area 0 network 192.168.1.3 0.0.0.0 area 0
interface Serial1/0 ip address 192.168.1.4 255.255.255.0 encapsulation frame-relay ip ospf network point-to-multipoint frame-relay map ip 192.168.1.1 403 frame-relay map ip 192.168.1.2 403 frame-relay map ip 192.168.1.3 403 broadcast no frame-relay inverse-arp ! router ospf 1 router-id 4.4.4.4 log-adjacency-changes network 4.4.4.4 0.0.0.0 area 0 network 192.168.1.4 0.0.0.0 area 0
Once again we have setup all our interfaces so that they are in area 0. We have used the ip ospf network point-to-multipoint command on all our routers so we have a consistent network type. This network type does not require a DR as OSPF will inject /32 route to all our end points. You can check out my previous tutorial on the point-to-multipoint OSPF network type on why this is so cool!
Our two hubs, R2 and R3 have frame-relay maps with broadcast statements to their respective spokes. R2 has a broadcast statement for R1 and R3 in its frame-relay map statement. R3 has a broadcast statement for R2 and R4 in its frame-relay maps. Once again, we don’t apply broadcast statements to all our traffic as we would receive redundant broadcast messages.
Let’s verify the routing table:
R1#sh ip route | b Gateway
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, FastEthernet0/0
2.0.0.0/24 is subnetted, 1 subnets
O 2.2.2.0 [110/65] via 192.168.1.2, 00:15:43, Serial1/0
3.0.0.0/24 is subnetted, 1 subnets
O 3.3.3.0 [110/129] via 192.168.1.2, 00:15:43, Serial1/0
4.0.0.0/24 is subnetted, 1 subnets
O 4.4.4.0 [110/193] via 192.168.1.2, 00:15:43, Serial1/0
192.168.1.0/24 is variably subnetted, 4 subnets, 2 masks
C 192.168.1.0/24 is directly connected, Serial1/0
O 192.168.1.3/32 [110/128] via 192.168.1.2, 00:15:43, Serial1/0
O 192.168.1.2/32 [110/64] via 192.168.1.2, 00:15:43, Serial1/0
O 192.168.1.4/32 [110/192] via 192.168.1.2, 00:15:43, Serial1/0
You can see clearly above OSPF has inserted an extra hop via R2 for R1 for all our routers in the 192.168.1.0/24 segment. OSPF’s point-to-multipoint network type creates next hops to make the layer 3 topology mirror that of the layer 2 topology.
R1 looks great, let’s verify R4′s routing table and see if we can ping across the furthest spokes:
R4#sh ip route | b Gateway
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnets
O 1.1.1.0 [110/193] via 192.168.1.3, 00:24:11, Serial1/0
2.0.0.0/24 is subnetted, 1 subnets
O 2.2.2.0 [110/129] via 192.168.1.3, 00:24:11, Serial1/0
3.0.0.0/24 is subnetted, 1 subnets
O 3.3.3.0 [110/65] via 192.168.1.3, 00:24:11, Serial1/0
4.0.0.0/24 is subnetted, 1 subnets
C 4.4.4.0 is directly connected, FastEthernet0/0
192.168.1.0/24 is variably subnetted, 4 subnets, 2 masks
O 192.168.1.1/32 [110/192] via 192.168.1.3, 00:24:11, Serial1/0
C 192.168.1.0/24 is directly connected, Serial1/0
O 192.168.1.3/32 [110/64] via 192.168.1.3, 00:24:11, Serial1/0
O 192.168.1.2/32 [110/128] via 192.168.1.3, 00:24:11, Serial1/0
The routing table looks great! Let’s check reachability:
R4#ping 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 20/47/136 ms
Looks like we have full reachability! Awesome!
So whats the moral of this story? On topologies that have one hub, make sure the hub becomes the DR by setting the ip ospf priority of the spokes to 0 (or use a network type that doesn’t require a DR!).
For a frame-relay topology that effectively has multiple hubs like our topology above we should use an OSPF network type that doesn’t require a DR.
If anybody has any other questions regarding OSPF networks and frame-relay, or has some weird topology that would make a great tutorial shoot me an email.
HTH. Now get back to labs!
Arden Packeer currently is a Cisco Certified Internetwork Expert (CCIE #20716) working in the Advanced Services team at Cisco Systems (Melbourne, Australia). He has more than 10 years with specialisations in datacentre networks, large scale service provider networks, and more recently virtualisation and cloud deployments. Arden also likes writing about himself in the third person because it makes him sound important. :)
Tutorial: OSPF Network Types & Frame-Relay Series
© 2012 Arden Packeer. All rights Reserved. | The views expressed herein are the opinion of the author, not my employer, any manufacturer (Cisco or otherwise), or any of their affiliates. | Trademarks: All trademarks and registered trademarks are the property of their respective owners. | Privacy Policy | Terms & Conditions
Comments (24)