Routing Protocols

Tutorial: OSPF Network Types and Frame Relay Part 5

Thanks for visiting! If you're new here, you may want to subscribe to my RSS feed. This blog posts regular tutorials, news, and study tips about networking, especially about Cisco CCIE related topics. Go ahead, subscribe to the rss feed! You can also receive updates from this blog via email. Thanks for visiting!

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:

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 

You can download the dynagen .net configuration file for this topology here.

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.

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!

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

Resources:

• Dynamips/Dynagen .net configuration file

Related posts

• Tutorial: OSPF Network Types and Frame Relay Part 1
• Tutorial: OSPF Network Types and Frame Relay Part 4
• Tutorial: OSPF Network Types and Frame Relay Part 3
• Tutorial: OSPF Network Types and Frame Relay Part 2

© 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