Routing Protocols

Tutorial: OSPF Network Types and Frame Relay Part 4

In our previous tutorials (you can find Part 1 here, Part 2 here and Part 3 here) 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. Evil Proctors :)

Once again we will be using the following 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

You can download this dynagen .net configuration file for this tutorial here.

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)

In our next article in the OSPF Network Types and Frame-Relay series we will be putting all of these together and taking a look at how the OSPF network types work in conjunction with a large partial mesh network. Now back to labs! HTH!

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.

Resources:

• Dynamips/Dynagen .net configuration file

© 2008 Arden Packeer. All rights reserved. The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway. This material is not sponsored or endorsed by Cisco Systems, Inc. Cisco, Cisco Systems, CCIE and the CCIE Logo are trademarks of Cisco Systems, Inc. and its affiliates