// you’re reading...

Routing Protocols

Tutorial: OSPF Network Types and Frame Relay Part 1

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!

Knowing the OSPF Network Types and how they work with different frame relay topologies is one of those things that you should know inside out if you are attempting the CCIE lab. In this next series of articles we will be looking at the 5 OSPF network as well as how and when to use them in conjunction with a frame relay hub and spoke topology.

We will be using the following topology for this tutorial:

OSPF and Frame Relay Topology

Dynagen Configuration

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

    [[ROUTER R3]]
        f0/0 = LAN 3
        s1/0 = FRAME 3
        console = 2002
        model = 3640

    [[FRSW FRAME]]
        1:102 = 2:201
        1:103 = 3:301
    

You can download the .net file for dynagen/dynamips here.

Basic Configuration

First things first lets set up our hub and spoke frame-relay topology. You can see in the diagram above R1 will be our hub, and R2 and R3 will be our spokes.

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
 frame-relay map ip 192.168.1.3 103 broadcast
 no frame-relay inverse-arp

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
 serial restart-delay 0
 frame-relay map ip 192.168.1.1 201 broadcast
 frame-relay map ip 192.168.1.3 201
 no frame-relay inverse-arp

R3

hostname R3
!
interface fastEthernet0/0
 ip address 3.3.3.3 255.255.255.0
!
interface Serial1/0
 ip address 192.168.1.3 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 192.168.1.1 301 broadcast
 frame-relay map ip 192.168.1.2 301
 no frame-relay inverse-arp

We have disabled frame-relay inverse arp, and made sure that R1 does not recieve redundant network broadcasts.

OSPF Over Frame Relay - Non-Broadcast Network Type

The Non-Broadcast network types is used for topologies with no broadcast capability (or no broadcast capability configured!), or in topologies where you want OSPF to unicast its updates instead of broadcasting/multicasting. In the topology and configuration shown above we have configured the pseudo-broadcast capability of frame-relay. It doesn’t really broadcast because not all stations in the cloud will receive that, just the ones with the broadcast statement in the frame-relay map command.

Lets have a look our configuration for Non-Broadcast Frame-Relay networks:

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
 frame-relay map ip 192.168.1.3 103
 no frame-relay inverse-arp
 ip ospf network non-broadcast
!
router ospf 1
 router-id 1.1.1.1
 network 0.0.0.0 255.255.255.255 area 0
 neighbor 192.168.1.2
 neighbor 192.168.1.3

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
 serial restart-delay 0
 frame-relay map ip 192.168.1.1 201
 frame-relay map ip 192.168.1.3 201
 no frame-relay inverse-arp
 ip ospf network non-broadcast
 ip ospf priority 0
!
router ospf 1
 router-id 2.2.2.2
 network 0.0.0.0 255.255.255.255 area 0

R3

hostname R3
!
interface fastEthernet0/0
 ip address 3.3.3.3 255.255.255.0
!
interface Serial1/0
 ip address 192.168.1.3 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 192.168.1.1 301
 frame-relay map ip 192.168.1.2 301
 no frame-relay inverse-arp
 ip ospf network non-broadcast
 ip ospf priority 0
!
router ospf 1
 router-id 3.3.3.3
 network 0.0.0.0 255.255.255.255 area 0

You can see in the code above that we have disabled the broadcast capability of Frame-Relay by removing the broadcast statement from the frame-relay map statements.

When preparing for your CCIE, its important to be able to look at the above topology and recognise when potential problems might arise. OSPF network type Non-Broadcast requires a DR. I would recognise that R1 is the hub and should be made the DR in OSPF network types that require them. OSPF Non-Broadcast is one of our only options here (the other being the Point-to-Multipoint Non-Broadcast) as we have no capability to broadcast over that segment.

We have made sure that the spokes (R2 & R3) are ineligible to become the DR. We can use the ip ospf priority 0 over the frame-relay topology thereby ensuring R1 will become the DR for the segment. On R1 we have specified our neighbors to unicast routing updates to using the neighbor command.

Lets verify the configuration:

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

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/DROTHER    00:01:56    192.168.1.2     Serial1/0
3.3.3.3           0   FULL/DROTHER    00:01:55    192.168.1.3     Serial1/0

Looks like our neighbours have been brought up, lets check our routing table:

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:55, Serial1/0
     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:00:55, Serial1/0
C    192.168.1.0/24 is directly connected, Serial1/0

We have a route to R1, and R3’s f0/0 networks in R2’s routing table so R2 should have full reachability to those networks.

R2#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 = 96/153/248 ms
R2#ping 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 144/249/376 ms

Looks like we have full reachability. Lets verify the OSPF timers and network types. We can do this with the show ip ospf interface command.

R1#sh ip ospf int
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:19
  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 2
  Last flood scan time is 0 msec, maximum is 4 msec
  Neighbor Count is 2, Adjacent neighbor count is 2
    Adjacent with neighbor 2.2.2.2
    Adjacent with neighbor 3.3.3.3
  Suppress hello for 0 neighbor(s)
FastEthernet0/0 is up, line protocol is up
  Internet Address 1.1.1.1/24, Area 0
  Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 1.1.1.1, Interface address 1.1.1.1
  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:09
  Supports Link-local Signaling (LLS)
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 0, maximum is 0
  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)

You can see the default timers on the Serial interface is 30 seconds for the Hello packets with a dead interval of 120 seconds. On a Fast Ethernet interface the default timers are 10 seconds and 40 seconds for hello and dead intervals respectively. In fact Cisco uses a default of Hello interval of 10 seconds for all broadcast networks and 30 seconds for non-broadcast. A dead interval is 4x this value. These values can be changed with the ip ospf hello interval command. OSPF network type non-broadcast is the default network type if you are using a physical serial interface.

OSPF Over Frame Relay - Broadcast Network Type

The Broadcast Network type is the default network type on an Ethernet interface. A DR is election is performed and updates are sent via multicast packets. Frame relay will need to be configured for broadcast support to support the network type.

Lets have a look at the 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
 frame-relay map ip 192.168.1.3 103 broadcast
 no frame-relay inverse-arp
 ip ospf network broadcast
!
router ospf 1
 router-id 1.1.1.1
 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
 frame-relay map ip 192.168.1.3 201
 no frame-relay inverse-arp
 ip ospf network broadcast
 ip ospf priority 0
!
router ospf 1
 router-id 2.2.2.2
 network 0.0.0.0 255.255.255.255 area 0

R3

hostname R3
!
interface fastEthernet0/0
 ip address 3.3.3.3 255.255.255.0
!
interface Serial1/0
 ip address 192.168.1.3 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 192.168.1.1 301 broadcast
 frame-relay map ip 192.168.1.2 301
 ip ospf priority 0
 no frame-relay inverse-arp
 ip ospf network broadcast
!
router ospf 1
 router-id 3.3.3.3
 network 0.0.0.0 255.255.255.255 area 0

You can see above that the frame-relay map commands have the broadcast keywords added. If we use the OSPF broadcast network type, we have to make sure that our layer two topology supports broadcasts. Lets verify the configuration:

R1#
*Mar  1 01:17: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial1/0 from LOADING to FULL, Loading Done
*Mar  1 01:17: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial1/0 from LOADING to FULL, Loading Done

R1#sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/DROTHER    00:00:34    192.168.1.2     Serial1/0
3.3.3.3           0   FULL/DROTHER    00:00:34    192.168.1.3     Serial1/0
R1#sh run

If we have a look at the neighbors on R3, or R2 we should see that the only neighbour relationship formed is with the DR (R1 in this case).

R3#sh ip ospf nei

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

Looks like our neighbours have been brought up, lets check our routing table:

R3#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:09:29, Serial1/0
     2.0.0.0/24 is subnetted, 1 subnets
O       2.2.2.0 [110/65] via 192.168.1.2, 00:09:29, Serial1/0
     3.0.0.0/24 is subnetted, 1 subnets
C       3.3.3.0 is directly connected, FastEthernet0/0
C    192.168.1.0/24 is directly connected, Serial1/0
R3#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 = 136/176/220 ms
R3#ping 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 236/283/340 ms

You can see above, that even though R3 has no neighbour relationship with R2 we can still reach R2’s ethernet segment. We are learning this through the Designated Router R1. R1 is acting as a co-ordination point. R2 and R3 will send their updates to R1. R1 will collate these updates and distribute them out to the spokes. Hence why R2 and R3 only need to have a neighbor relationship with the DR.

Lets have a look at the timers and verify the network type:

R1#sh ip ospf int
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 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 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:01
  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 2
  Last flood scan time is 0 msec, maximum is 4 msec
  Neighbor Count is 2, Adjacent neighbor count is 2
    Adjacent with neighbor 2.2.2.2
    Adjacent with neighbor 3.3.3.3
  Suppress hello for 0 neighbor(s)
FastEthernet0/0 is up, line protocol is up
  Internet Address 1.1.1.1/24, Area 0
  Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 1.1.1.1, Interface address 1.1.1.1
  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:02
  Supports Link-local Signaling (LLS)
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 0, maximum is 0
  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)

Notice above how the hello and dead intervals are 10 and 40 seconds respecitively for both the ethernet and serial interfaces. As mentioned above, this is because CISCO uses a default Hellp Interval for broadcast networks and 30 seconds for non-broadcast. The OSPFv2 RFC 2328 doesn’t really have a required value for either Hello or Dead intervals but does suggest a hello interval of 10 seconds and a dead interval of 4X the hello interval.

That’s it for broadcast and non-broadcast networks. In the next article we will be looking at point-to-multipoint and point-to-multipoint non-broadcast networks. Stay tuned. Now back to labs!

Summary:

  • Non-Broadcast network type is the default on a physical serial interface with ospf configured
  • Non-Broadcast networks send unicast packets, so must be configured with neighbor statements
  • Non-Broadcast networks have Hello and Dead intervals of 30 seconds and 120 seconds respectively
  • Broadcast network types is the default on an ethernet interface.
  • Broadcast network types must support broadcasting capability on a layer 2 topology
  • Non-Broadcast and Broadcast network types require a DR. Care should be taken in DR placement (should be the Hub).

Resources:

Discussion

13 comments for “Tutorial: OSPF Network Types and Frame Relay Part 1”

  1. [...] Full article here [...]

    Posted by Tutorial: OSPF Network Types and Frame Relay by Arden Packeer : CCIE Journey | March 4, 2008, 7:37 am
  2. Good catch on losing the broadcast keyword on the NBMA. This is something much overlooked in many vendor workbooks. Good job!

    Darby

    Posted by Darby Weaver | March 16, 2008, 7:40 pm
  3. I added debug ip ospf events, I see hello updates to the 224.0.0.5 for broadcast network type and when neighbor xxxx config was put, it becomes a unicast ip add hello.

    Nice tutorial. Tnx.

    Posted by Mar Apuhin | July 13, 2008, 4:40 pm
  4. Awesome tutorial Arden now if only the Cisco Press materials were this succinct then I would be much further along my path :-)

    Posted by Ferret999 | July 25, 2008, 8:40 am
  5. without broadcast keyword at the spokes, i noticed update will get exchanged, any idea for the reason behind this ?

    Posted by ospfv2 | August 5, 2008, 4:21 am
  6. You don’t need the broadcast keyword in a non-broadcast network type (hence the name!). For a hub and spoke topology, all you need is a broadcast keyword on the hub for all your spokes. The spokes just require a broadcast keyword for the hub. Check out part 5 of the article as it goes through why.

    Posted by Arden Packeer, CCIE #20716 | August 5, 2008, 8:48 am
  7. Thank you, Arden! This is very helpful!

    Posted by rukia | August 29, 2008, 9:52 pm
  8. Very useful explanation…Thank you so much.

    Posted by Pavani | September 16, 2008, 3:18 am
  9. Hi Arden, was very helpful … and expecting some topics from Multicast using VPNV4 … if you are familiar with those technology ..

    Once again thxs alot for the help you are doing .. really appreciated :)

    Posted by Anil R S | February 5, 2009, 9:59 pm
  10. I noticed the neighbor commands are configured on the hub, but not on the spokes. I don’t know if that was intentional or not, but I found that when I configured neighbors on the spokes, as soon as I configure the ospf priority to be 0, the neighbor commands disappear from the running configuration. An ospf priority of anything but 0 makes the neighbor statements re-appear.

    Other people ran into this and it seemed to have caused them some headaches :

    http://ieoc.com/forums/p/6625/23367.aspx

    Apparently, it is a feature, not a bug :)

    Thanks for an excellent website btw. This is arguably one of the most important topics and you’ve explained it very well.

    Posted by Marcel Lammerse | June 22, 2009, 9:12 pm
  11. Hi Arden,
    I am bit confused by these sentence. Any chance you can clarify them pls.
    ” A DR is election is performed and updates are sent via multicast packets. Frame relay will need to be configured for broadcast support to support the network type.” and the other bit I didn’t understand was “You can see above that the frame-relay map commands have the broadcast keywords added. If we use the OSPF broadcast network type, we have to make sure that our layer two topology supports broadcasts”
    Thanks in advance.

    Posted by anderson2005 | July 3, 2009, 7:07 pm
  12. @anderson2005: Sure. Can you be more specific in what doesn’t make sense?

    Posted by Arden Packeer, CCIE #20716 | July 3, 2009, 7:45 pm
  13. Thank you for your quick response. My question is…

    “You can see above that the frame-relay map commands have the broadcast keywords added. If we use the OSPF broadcast network type, we have to make sure that our layer two topology supports broadcasts”

    In the sentence above, how do we make sure that layer two topology supports broadcasts. Can we change anything other then broad cast keywork at the end of the frame-relay map command.

    Other thing is, if the broadcast mode work in that manner across the frame-relay links then why do we acutally use the non-broadcast mode where we have to manually configure the neighbor relationships.

    Am I missing something here, Do we actually have to choose one mode over the other depending upone the frame-relay network our frame-relay provider provides us.

    Posted by anderson2005 | July 3, 2009, 8:52 pm

Post a comment


Twitter Feed...

Follow me...

View Arden Packeer's profile on LinkedIn Arden Packeer ClaimID Add to Technorati Favorites TwitterCounter for @ardenpackeer