PHPKB Knowledge Base Software Logo  
Guru Corner
Online Knowledgebase System  
Knowledge Base Home Knowledge Base Home
Home > All Categories > Cisco Systems > Routing > OSPF > OSPF Network Types and Frame Relay - Part 2
Question Title OSPF Network Types and Frame Relay - Part 2

In our previous tutorials we looked at the different OSPF network types and how they apply to a partial mesh Frame-Relay Hub and spoke topology. In normal situations that would be enough, but this is the CCIE we are preparing for! We have to understand how the different network types work together. This is incase the proctor decides to not allow you to use certain types of OSPF networks on one interface or does not allow you to use the ip ospf network commands on others.

Once again we will be using the following topology:

OSPF and Frame Relay - Point-to-Point Topology

We will be using the following dynagen .net file:

ghostios = True
sparsemem = True
model = 3640
reply
[localhost]

    [[3640]]
        image = \Program Files\Dynamips\images\c3640-jk9o3s-mz.124-12.bin
        # On Linux / Unix use forward slashes:
        # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
        ram = 96

    [[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

    [[FRSW FRAME]]
        1:102 = 2:201

Lets have a look at the initial configuration:

R1

hostname R1
!
interface FastEthernet0/0
 ip address 1.1.1.1 255.255.255.0
!
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
 no frame-relay inverse-arp
!
router ospf 1
 router-id 1.1.1.1
 log-adjacency-changes
 network 0.0.0.0 255.255.255.255 area 0

R2

hostname R2
!
interface FastEthernet0/0
 ip address 2.2.2.2 255.255.255.0
!
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
 no frame-relay inverse-arp
!
router ospf 1
 router-id 2.2.2.2
 log-adjacency-changes
 network 0.0.0.0 255.255.255.255 area 0

You can see with the configuration above we have set up both of the routers to be in area 0. We havenít changed the default network types so the s1/0 on both routers should be set to ospf non-broadcast network types. Lets check this:

R1#sh ip ospf int s1/0
Serial1/0 is up, line protocol is up
  Internet Address 192.168.1.1/24, Area 0
  Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 64
  Transmit Delay is 1 sec, State WAITING, Priority 1
  No designated router on this network
  No backup designated router on this network
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
    oob-resync timeout 120
    Hello due in 00:00:07
    Wait time before Designated router selection 00:01:37
  Supports Link-local Signaling (LLS)
  Index 2/2, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 1, Adjacent neighbor count is 0
  Suppress hello for 0 neighbor(s)

This is the same on R2. What about the routing table? Well we havenít had any neighbors come up, and this is because the network type is non-broadcast. With a non-broadcast network type we need to specify neighbors using the neighbor command under the ospf configuration.

Instead of setting up neighbors, lets play around with this. What would happen if we set one side to Broadcast networreplyk type and the other we left as non-broadcast? Lets see:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int s1/0
R2(config-if)#ip ospf network broadcast

If we take a look at our neighbors we will notice that we havenít formed an adjacency between the routers.

R1#sh ip ospf nei

R1#

What is the problem here? Well at first glance your probably thinking ďwell the network types donít match Arden!Ē. Thatís true, but matching network types is not one of the pre-requisites for forming an adjacency. What are the pre-requisites for forming an adjacency between two ospf neighbors?

Pre-Requisites for OSPF adjacencies:

  • Same Authentication type & Password
  • Stub Area flag
  • Same Area
  • Same Network Mask
  • Same Hello & Dead Timers

Looking at that list we have the same authentication type (weíre not using any!), same stub area flag (ie none!), same area (Area 0), and same mask. But what about the Hello & Dead timers? Lets compare the two routers:

R1

R1#sh ip ospf int s1/0
Serial1/0 is up, line protocol is up
  Internet Address 192.168.1.1/24, Area 0
  Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 64
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 1.1.1.1, Interface address 192.168.1.1
  No backup designated router on this network
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
    oob-resync timeout 120
    Hello due in 00:00:15
  Supports Link-local Signaling (LLS)
  Index 2/2, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 0, maximum is 1
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 0, Adjacent neighbor count is 0
  Suppress hello for 0 neighbor(s)

R2

R2#sh ip ospf int s1/0
Serial1/0 is up, line protocol is up
  Internet Address 192.168.1.2/24, Area 0
  Process ID 1, Router ID 2.2.2.2, Network Type BROADCAST, Cost: 64
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 2.2.2.2, Interface address 192.168.1.2
  No backup designated router on this network
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:00
  Supports Link-local Signaling (LLS)
  Index 2/2, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 0, maximum is 1
  Last flood scan time is 0 msec, maximum is 4 msec
  Neighbor Count is 0, Adjacent neighbor count is 0
  Suppress hello for 0 neighbor(s)

Looking at the output from the show ip ospf interface command you can clearly see that the Hello and Dead timers donít match up. A broadcast network type has timers of 10 and 40 seconds for hello and dead timers respectively. A non-broadcast network type has timers of 30 and 120 seconds for hello and dead timers respectively.

Lets change the timers on R1 and see if this helps:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int s1/0
R1(config-if)#ip ospf hello-interval 10
R1#sh ip ospf int s1/0
Serial1/0 is up, line protocol is up
  Internet Address 192.168.1.1/24, Area 0
  Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 64
  Transmit Delay is 1 sec, State WAITING, Priority 1
  No designated router on this network
  No backup designated router on this network
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:04
    Wait time before Designated router selection 00:01:45
  Supports Link-local Signaling (LLS)
  Index 2/2, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 16 msec
  Neighbor Count is 0, Adjacent neighbor count is 0
  Suppress hello for 0 neighbor(s)

We used the ip ospf hello-interval command to change the hello timers. You can see above that we didnít have to change the dead interval. By default the dead interval is set at 4x the hello interval. These timers now match R1 so we should see a neighbor adjacency form.

R1#
*Mar  1 05:42:18.118: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial1/0 from LOADING to FULL, Loading Done
R1#
R1#sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   FULL/DR         00:00:31    192.168.1.2     Serial1/0
R1#

Looks good. You can see there that R2 has become the DR for the frame relay segment. Remember that both Broadcast network types and Non-Broadcast network types require a DR.

R1ís s1/0 is an ospf non-broadcast network type. In this network type hello messages are sent unicast to neighbors. We donít have neighbours defined here so we will never initiate sending hello messages. R1 will still reply to helloís however. This is how an adjacency is formed. R2ís s1/0 is an ospf broadcast network type. We will multicast a hello to 224.0.0.5 on that segment. R1 is receives those helloís and unicasts a reply back. Lets verify this:

R2#debug ip ospf hello
OSPF hello events debugging is on
R2#
OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 2.2.2.2
OSPF: Send hello to 224.0.0.5 area 0 on Serial1/0 from 192.168.1.2
R2#
R1#debug ip ospf hello
R1#
OSPF: Rcv hello from 2.2.2.2 area 0 from Serial1/0 192.168.1.2
OSPF: End of hello processing
R1#
OSPF: Send hello to 192.168.1.2 area 0 on Serial1/0 from 192.168.1.1
R1#

A neighbor relationship forms now because all the pre-requisites that we mentioned before are met. R2 is elected the DR for this segment and all updates from R1 are sent to R2 via unicast to 192.168.1.2. Updates from R2 are sent to R1 via 224.0.0.5. R1 still listens on this address even though it does not send out lsa updates on this address.

The key thing here is that both the ospf broadcast and non-broadcast network types use DR to handle propogation of updates through ospf. Because of this they are able to share routes. Looking at the routing tables of both you can see we have full connectivity:

R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     1.0.0.0/24 is subnetted, 1 subnets
O       1.1.1.0 [110/65] via 192.168.1.1, 00:00:23, Serial1/0
     2.0.0.0/24 is subnetted, 1 subnets
C       2.2.2.0 is directly connected, FastEthernet0/0
C    192.168.1.0/24 is directly connected, Serial1/0

Looks good, but what would happen if we change R1 to a network type that didnít support a DR. Letís try it and see :)

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int s1/0
R1(config-if)#ip ospf network point-to-multipoint
R1#
%OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial1/0 from FULL to DOWN, Neighbor Down: Interface down or detached
%SYS-5-CONFIG_I: Configured from console by console
R1#
 %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial1/0 from LOADING to FULL, Loading Done

Looks like the adjacency worked! Why:

R1#sh ip ospf int s1/0
Serial1/0 is up, line protocol is up
  Internet Address 192.168.1.1/24, Area 0
  Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_MULTIPOINT, Cost: 64
  Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:05
  Supports Link-local Signaling (LLS)
  Index 2/2, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 16 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 2.2.2.2
  Suppress hello for 0 neighbor(s)

The point-to-multipoint network type has timers that match the broadcast network type set on R2. The adjacency pre-requisites are met so an adjacency is formed.

R1#sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/  -        00:00:36    192.168.1.2     Serial1/0
R2#sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   FULL/BDR        00:00:39    192.168.1.1     Serial1/0

Looking at the show ip ospf neighbor output of both neighbors we see a problem. R1 sees R2 as a neighbour but does not think a DR relationship is necessary on the Frame Segment. R2 thinks a DR is necessary on the frame segment. Herein lies the problem:

R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

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
C    192.168.1.0/24 is directly connected, Serial1/0
R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

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 and R2 are not swapping routes!

Lets have a think about why this is. Even though all the pre-requisites for neighbor adjacencies have been met, R1 will be unicasting updates to R2 and R2 will be sending updates to the multicast address 224.0.0.6 (all DR and BDRís). The link-state databases will not be kept synchronized properly.

The moral of the story: We can mix and match network types as long as the DR relationship is taken into account. This means we can mix and match the following network types:

Dont Need a DR:
Point-to-Point and Point-to-Multipoint (if you adjust timers)
Point-to-Point and Point-to-Multipoint non-broadcast (if you adjust timers)
Point-to-Multipoint and Point-to-Multipoint non-broadcast

Need a DR:
Broadcast and Non-Broadcast (if you adjust timers)

Summary:

  • An adjacency will be formed with routers running OSPF, as long as the authentication is the same, the stub flag is the same, the area is the same, and the timers are the same.
  • If we mix and match network types we might need to modify the timers so we can form an adjacency. This is done with the ip ospf hello-interval and ip ospf dead-interval commands.
  • You can mix and match network types as long as the network types involved have the same DR relationship. You canít mix network types that require a DR with those that donít require a DR.

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:

OSPF Network Types & Frame Relay Part 5 Topology

Dynagen / Dynamips .net Configuration File:

ghostios = true
sparsemem = true
model = 3640

[localhost]

    [[3640]]
    image = \Program Files\Dynamips\images\c3640-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:

R1

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

R2

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

R3

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

R4

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:

R4

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:

R2#debug ip packet
IP packet debugging is on

R3:

R3#debug ip packet
IP packet debugging is on

R4:

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:

R2#un all
All possible debugging has been turned off

R3:

R3#un all
All possible debugging has been turned off

R4:

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

Setting Up An OSPF Network Across A Partial-Mesh Frame-Relay Network

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.

OSPF DR Network Types:

R1:

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

R2:

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

R3:

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

R4:

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!

OSPF Non-DR Network Types:

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:
R1:

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

R2:

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

R3:

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

R4:

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.

Summary:

  • For topologies where you have one hub, ensure the hub is the DR or use a network type that doesnít require a DR
  • For topologies that have more than one hub, use a network type that doesnít require a DR
  • In partial mesh topologies, the hubs should use a broadcast frame-relay map on DLCIís to all connected spokes. This is to stop redundant broadcasts
  • In partial mesh topologies, the spokes should use a broadcast frame-relay map on DLCIís to the hub only. This is to stop redundant broadcasts
Authored by: Guru Corner
Click Here to View all the questions in OSPF category.
File Attachments File Attachments
There are no attachment file(s) related to this question.
Article Information Additional Information
Article Number: 32
Created: 2008-10-15 10:42 PM
Rating: No Rating
 
Article Options Article Options
Print Question Print this Question
Export to Adobe PDF Export to PDF File
Export to MS Word Export to MS Word
 
Search Knowledge Base Search Knowledge Base
 
 

Powered by Guru Corner