Question #1 - when you add the "broadcast" keyword to your frame-relay map command, it allows the specified DLCI to forward broadcast and multicast packets. This of course only applies to static frame-relay mappings. The "frame-relay map" command applies to physical and multipoint subinterfaces only.
Dynamic mappings (frame-relay inverse ARP enable) allows IP "broadcasts" to got out the interface by default. You can verify this with the "sh frame-relay map" command and look for the "broadcast" word in the output. See example below.
R1#show frame-relay map
Serial0/0 (up): ip 192.168.1.2 dlci 102 (0x64,0x1840), dynamic,
broadcast,, status defined, active
Question #2 - This is because OSPF has many different "network" types when used with frame-relay. By default, physical and multipoint subinterfaces are non-broadcast with OSPF and require the "neighbor" command under the OSPF process. To get around this you can change the "default" OSPF network type by using the "ip ospf network" command.
In the case of dynamic frame-relay mappings you just need to use the "ip ospf network broadcast" command under the physical interface. If you are using dynamic frame-relay mappings with multipoint subinterfaces then you need the "frame-relay interface-dlci" command and your choice of one of the "ip ospf network" commands. I say this because depending on if you want a DR/BDR election or not, you will use a different keyword with the command. Such as the following:
ip ospf network non-broadcast <-- requires the "neighbor" command
ip ospf network broadcast
ip ospf network point-to-multipoint non-broadcast <-- requires the "neighbor" command
ip ospf network point-to-multipoint
If you are using static frame-relay mappings with multipoint subinterfaces then you use the "frame-relay map" command with "broadcast" keyword. Again, depending on whether you want a DR/BDR election, you will need to choose one of the "ip ospf network" commands.
Hope this helps.
I think the broadcast keyword has not lost it's meaning as far as EIGRP is concerned. Depending on packet type, EIGRP will use both unicast and multicasts by default for their transmission.
So its logical if you leave out the "broadcast keyword" on your map statements you will definately be prohibiting the L2 transmission of the multicast subset of packets EIGRP uses accross teh frame.
In the case you actually leave out the broadcast keyword, you can then tell EIGRP to rely _ exclusively_ on unicast transmission by using the passive command and neighbor statements in order for adjacencies to form between neighbors.
I must admit, I haven't tested this on a lab. Maybe Akshay you can test this bit of theory if its true or not? . Looks like a fun thing to do when i get time --> force EIGRP to use unicast only he he
All the people explain the theory of it.
I just found an awesome tutorial here:
He even configures it.
Thanks chemilo and Brian !
#1 FrameRelay cloud cannot perform broadcast/multicast replication. When you use "broadcast" keyword, you instruct the router to generate a pseudobroadcast, i.e. perform broadcast/multicast replication itself.
#2 OSPF reckognizes different network types. Multipoint FrameRelay interfaces are by default "non-broadcast" and as such will only send unicast hellos. Unicast hellos cannot be sent unless you manually specify neighbors. Since IEGRP doesn't have the concept of a non-broadcast interface, this is a non-issue with EIGRP. Technically, for OSPF the problem can be eliminated by changing the interface to either "broadcast" (ip ospf network broadcast) or "point-to-multipoint" (ip ospt network point-to-multipoint).
Marko Milivojevic - CCIE #18427 (SP R&S)
Senior CCIE Instructor - IPexpert
Hi Chemillio !
Thanks for the Lab.
But really EIGRP over NBMA is not that much difficult.
You just need to enter the frame relay commands using broadcast keyword, enter the network statements and it works !
With OSPF there are lots of network types, making it sometimes confusing.
Where do you find such labs ?
DO you have some labs for OSPF ?