OSPF Non-Broadcast Network Type over Frame-Relay

Hello Nanu

Yes, I understand your concern. Keep in mind that EIRGP also has a split horizon rule, which states that any information that is learned via an interface is never advertised via that interface. This rule will prevent any “flooding” of EIGRP packets within a segment.

I hope this has been helpful!

Laz

Hello Laz,

Thank you so much for your guidance, this absolutely cleared my doubt.

Regards,
Nanu

2 Likes

Hello!

Make sure you have a frame-relay map statement with the broadcast keyword or you won’t be able to send multicast on your frame-relay network.

I can’t clearly understand the purpose of broadcast key word in dlci mapping (if inverse arp is disabled), because we are talking about NON-BROADCAST.
Is it right that this key word allows hub router to duplicate multicast ospf frames and send them to unicast addresses (that were configured by neighbor command)?

Hello Artem

Yes you are correct, that frame relay is a non-broadcast network type. This means that any broadcast OSPF packets that arrive at the hub must be propagated in the network. This can be done in one of two ways:

  1. Using the broadcast keyword on the frame relay maps. This essentially forwards any broadcast packets that have been received by the hub router to the IP address specified in the frame relay map as unicast packets. If the broadcast keyword is not there, no forwarding of broadcast packets will be performed, thus OSPF will not be able to send updates.

Yes that is correct.

  1. Inverse ARP. Inverse ARP when enabled will ask the “other end” what it’s IP address is. This allows dynamic mapping rather than static frame relay maps. If you have a static mapping with broadcast, you can safely turn off inverse arp.

I hope this has been helpful!

Laz

Thanks for the answer!
But I have one more question, it’s about BROADCAST network type and Frame Relay encap.
So it is clear for me now that in NON-BROADCAST network hub router will send ospf unicast packets to neighbors and hence it will use a certain DLCI of a certain neighbor on layer 2.
I’ve just tried the same topology as in the lesson(broadcast network type) in gns3 to figure out what dlci number will be in ospf multicast packet. But for some reason gns indicates that packets are encapsulated in HDLC (???),
So the question is: what DLCI number will the router put in frame relay header?

Hello Artem

By default, the encapsulation on a serial interface is HDLC. This means that if you don’t configure frame relay encapsulation, HDLC is what will be used. Are you sure you’ve successfully enabled frame relay encapsulation using the encapsulation frame-relay command on that specific serial interface? You might want to check that out.

As for the DLCI number used, let’s assume the following topology:

R1 ---------------dlci 122-------------- ---------dlci 221--------------R2

When R1 sends information to R2, it encapsulates the PDU using 122 as the DLCI or layer 2 address. This is the case even though the DLCI of the destination is 221. DLCIs are locally significant. R1 knows nothing of the DLCI that R2 is using.

I hope this has been helpful!

Laz

Hi Laz

You say this:

“The next two types of network are used to accommodate multi access technologies that don’t support broadcast. These technologies include Frame Relay and ATM.”

Yet in the Broadcast lesson, you use frame relay?

Hello Chris

Yes, I should clarify. Unlike Ethernet, Frame Relay is a Non Broadcast Multi Access (NBMA) network type. This means that it does not inherently support broadcasts. That is, there is no broadcast mechanism in the technology. So what has to be done is broadcast must be simulated over frame relay in order for OSPF to function correctly.

The serial interfaces used in the configuration are by default set to “point to point” network type. The ip ospf network broadcast command tells the router to treat the specific interface as a broadcast network type for OSFP, thus DRs and BDRs will be elected automatically and neighbour relationships will also be formed automatically. Because frame relay doesn’t support pure broadcast, it simulates a broadcast with multiple unicast packets to the destinations.

I hope this has been helpful!

Laz

Personnaly ; I got a little bit confused about the mapping possibilities between OSPF and Frame-Relay. Drawing the table below does help me get a better understanding of the subject.

OSPF-FR Table

1 Like

Hi Rene, I did the same configuration like you, I have full router neighbor relationship, but spoke1 can’t ping spoke2, can you please help me with this.

Hello Khan,

Do you have a frame-relay map statement on spoke1 for the IP address of spoke2 and another one on spoke2 for the IP address of spoke1?

Something like:

Spoke1

interface Serial 0/0
frame-relay map ip 192.168.123.3 201 

Spoke 2:

interface Serial 0/0
frame-relay map ip 192.168.123.2 301

Rene

Thank you Rene it is working now!!!

1 Like

Hi,
You said " This is where things can get funky! If we select the non-broadcast network type we are telling OSPF our network is multi-access but in reality it’s not…"
How we can tell a non broadcast network is a multi access network
Thanks

Hello Sims

A non broadcast network is one that uses technologies (such as Frame Relay) that do not support broadcast communication. Typically, non-broadcast technologies are not multi-access, since multi-access requires the functionality of broadcasts to operate.

So Frame Relay and other such technologies are never multi-access, like Ethernet is for example. They are based on point to point connections.

However, when you have a frame relay topology, such as this one, you may want OSPF to behave as if it is a multi access network. This is useful when we have a hub and spoke topology which mimics a multi access network without the broadcast functionality. This means that OSPF will expect to have a DR and BDR elected, but will expect us to manually configure them as well as the neighbour adjacecies.

I hope this has been helpful!

Laz

as I read 6 Lessons of OSPF Network types and all topics are related to Frame-relay.
Frame-relay is not being used in my daily work so These network types are related to frame-relay or I will see these networks in other circuit type also
Please let me know

Hello Kunal
The truth is that Frame Relay is not in widespread use anymore, however, OSPF network types are. They are not used very often in the real world, however, their existence should be known and understood.

Frame relay is the main network technology that is used with OSPF network types, however, other such technologies include ATM, X25 and home powerline networks. These too are quite limited in their use, however, once again, OSPF accommodates them and we must know these capabilities of OSPF.

I hope this has been helpful!

Laz

Ok it is working, but why if the inverse-arp is enabled.

And after that i saw too that in the hub router the neighbor commands are not necessary to add the loopback that i’ve propagated on spoke1 and spoke2.

Hello Giovanni

Take a look at this post, it may be helpful…

The key here is that Inverse-ARP only provides frame relay mappings between the hub and each spoke, but not between the spokes themselves. This is why manually configured frame relay maps are the solution here.

I hope this has been helpful!

Laz

Hi Rene,
In the document you mentioned:

There’s also a command you can use on the Hub router to make sure a spoke router never becomes a DR or BDR. Type in neighbor priority 0 and you are done. You have to do this under the OSPF process.

However in Nabrik Kocharian’s CCIE official guide I read that it’s actually not the case. As I understand it, OSPF process neighbor priority command is somewhat local to the router itself, in our case the Hub router. The router performs the DR/BDR election with non-zero priority neighbors and when the election is completed, then it’ll start sending Hellos to the others. Also the default priority in neighbor command is actually 0, so this command does not really have any direct impact.

Here is a related Cisco community case:

Thanks.

Hi Haniyeh,

You are right. When I wrote this a few years ago, I think I tested it real quick or looked at the command reference:

Priority: (Optional) A number that indicates the router priority value of the nonbroadcast neighbor associated with the IP address specified. The default is 0. This keyword does not apply to point-to-multipoint interfaces.

This is interesting though, there is more behind this command than you would think. I removed the sentence from this lesson. Thanks for sharing those links.

Rene

1 Like