ccie blog

Common Frame-Relay & OSPF Misunderstandings

Why do you sometimes see the following multipoint sub-interface command?

interface Serial1/0
encapsulation frame-relay
interface Serial1/0.10 multipoint


The reason is so that you can have multiple multi-point interfaces using only 1 physical interface. So say if you have 2 customers, and customer A has 5 sites and customer B also has 5 sites that need to be joined together using a multipoint network. You can configure 2 multi-point sub-interfaces and do your 5 frame-relay statements under each sub-interface.   If you only had one customer requiring a multipoint network, then there is no reason to use a multi-point sub-interface, just configure your frame-relay statements under the physical interface.


What’s the difference between the two OSPF network types: point-to-multipoint & point-to-multipoint non-broadcast?

First, the non-broadcast keyword means the interface will not send broadcasts or multicasts.

Secondly, the non-broadcast network type means you must configure a neighbor statement under the OSPF process on at least one side of an adjacency (either the spoke or the hub: but the hub is the preferred location).

Thirdly, the point-to-multipoint non-broadcast network type was created to allows us to configure the ospf cost on a per neighbor basis, rather than per interface basis.


Why do we need a neighbor statement under the OSPF process for non-broadcast networks?

On non-broadcast networks, no broadcasts/multicasts are possible. So the only way to send hellos between routers is via unicast.  The neighbor command allows the router to send unicast OSPF hello’s to the IP address in the neighbor statement.  We know how to get to the neighbor over the layer 2 frame-relay network because you will have used one of the commands below to relate the layer 2 address/DLCI with the layer 3 address of the neighbor. :

frame-relay map ip x.x.x.x [DLCI number]

frame-relay interface-dlci [DLCI]


In OSPF non-broadcast networks, why do we only need one of the routers to use the neighbor command under the OSPF process.  Why don’t we need to configure it on both routers?

The reason is because an OSPF hello is sent back to a router when a hello is received. So if we received a hello from a hub in a point-to-multipoint non-broadcast network, we would sent a hello back to the hub by default.  I also found out some very useful information about hello processing on NBMA networks from Alex Zinin’s book – Cisco IP Routing: Packet Forwarding and Intra-Domain Routing Protocols:

“On NBMA networks, Hello packets are sent as follows.

  • If eligible to become the DR, the router starts sending Hello packets to all eligible neighbors: those with a specified priority greater than 0. Note that eligible routers are supposed to be configured with a full list of neighbors.
  • If it has been elected as the DR or the BDR for the segment, the router starts sending Hello packets to all configured neighbors, eligible or not. The reason is that the DR and the BDR must establish adjacencies with all reachable neighbors.
  • If it is not eligible—its associated priority is 0—the router sends Hello packets only to the DR and the BDR. If the DR and the BDR are not yet known, the router does not send any Hello packets at all. The router also sends a Hello packet in reply to a Hello packet received from any eligible packet.”


What does the frame-relay map x.x.x.x [DLCI] broadcast command mean?

To explain this I’m going to use an example configuration.

#interface s1/0
#ip address
#encapsulation frame-relay
#no frame-relay inverse-arp
#frame-relay map ip 102 broadcast
#frame-relay map ip 103

If we were to send a layer 3 broadcast out s1/0 and this was Ethernet, the layer 3 destination IP would be & the layer 2 destination MAC would be FFFF.FFFF.FFFF. However, in frame-relay we don’t have a concept of a layer 2 source/destination MAC addresses. We only have the outgoing DLCI number. Because there’s no such thing as a layer 2 broadcast DLCI, frame-relay can’t send a layer 2 broadcast out s1/0. So this is why the (highlighted) broadcast keyword was created. What actually happens is that when a broadcast it needed to be sent, instead of sending an actual layer 2 broadcast, it sends multiple unicasts to any of the hosts configured with the broadcast key word in the frame-relay map statements.  So if a layer 2 broadcast was needed to be sent out on the network, the packet would be encapsulated into the 102 DLCI and unicast over to, but would never receive this broadcast message because the broadcast key word was not included in that particular frame-relay map statement.



[…] enable the broadcast keyword on the frame-relay map statements (more info on the broadcast keyword here). The other important thing, is that their is no requirement for R1 to have a DLCI to R2. Instead, […]

sokkhiangOctober 4th, 2013 at 4:42 pm

excellent explanation! m looking forwards to reading your next stuff.. Thnks

Brain2000September 29th, 2014 at 2:41 pm

You wrote:

“Thirdly, the point-to-multipoint non-broadcast network type was created to allows us to configure the ospf cost on a per neighbor basis, rather than per interface basis.”

Can you expand on this a bit? I thought you could specify a neighbor with a cost on any network type and it would work. Are you saying it only works with a point-to-multipoint non-broadcast?

StephenGarbettOctober 6th, 2014 at 1:52 pm

Hi Brian.

When configuring a cost, you do it on an per interface basis, for example:

int fa0/0
ip ospf cost 10

What happens if you just have a layer 2 switch connected at the end of fa0/0, with 5 routers connected to it all on the same subnet? Well there’s no possible way of influencing the cost to each particular router/neighbor because the cost command was configured on a per-interface basis. So because the interface cost was set to 10, all neighbors will have a OSPF cost of 10.

Now then, on a non-broadcast network type, you have to configure the neighbors statically under the ospf process. At this point, you can also set the cost for the neighbor. For example:

router ospf 100
neighbor cost 10

So if you have 5 routers on the same layer 2 network, like in the example I provided earlier, you could set the neighbor cost on a per-neighbor basis like this (example below):

router ospf 100
neighbor cost 10
neighbor cost 15
neighbor cost 20

etc etc

The reason this won’t work on a broadcast segment, for example, is because point-to-point non-broadcast uses only unicast to send hello’s and LSAs. Other network types that are not non-broadcast use multicast for hellos and updates, so there’s no way to influence their decision on a per-neighbor basis.

Brain2000October 6th, 2014 at 3:32 pm

Ahh, so you can’t even use neighbor commands on a “broadcast” or “point-to-point” interface. That I did not know.

But I always thought you could set the individual neighbor cost on an interface configured with “point-to-multipoint [broadcast]”. I just tried it in GNS3, and I see that it does not work. It does let you put them in, they just don’t do anything.

Thanks for the info!

Brain2000October 6th, 2014 at 5:49 pm

I made a mistake in my test. I tried it again and the “point-to-multipoint [broadcast]” setting does in fact work with individual neighbor costs.

So basically I have found that if you have a “multi-access” network, meaning there is a full mesh between all neighbors, then individual neighbor costs are not allowed. These include “broadcast”, “non-broadcast”, and “point-to-point” (technically point-to-point has a full mesh, but it is an exception, because there is only one neighbor).

If you have a non-multi-access network, meaning a hub-and-spoke topology between neighbors, then individual neighbor costs are allowed. These include “point-to-multipoint” and “point-to-multipoint non-broadcast”.

JavedOctober 23rd, 2014 at 6:51 am

Excellent.Keep it up.

Leave a comment

Your comment