Routing Protocols on Frame Relay. What happens to their multicasts?

vazurahan

When the IP Address to DLCI mappings are learned through Inverse ARP or mapped with the command frame-relay map ip IP ADDRESS DLCI broadcast command I believe broadcast are automatically forwareded.

What happens to multicasts? Like, RIPv2, EIGRP, OSPF routing updates?

Are they forwarded too?

bermovick

If I'm remembering correctly, it doesn't actually broadcast; it converts the broadcast into a number of unicasts (you'll see where there's an EIGRP configuration to account for the increased traffic caused by the 1 broadcast -> N unicast effect). Multicasts get the same treatment.

SubnetZero

Yup bermovick is correct it basically creates something called a psuedu-broadcast, which is really just a replicated unicast.

This means that sending broadcasts and multicasts over Frame Relay can be pretty CPU intensive, since you're basically just punting everything over to the CPU in order to be process switched.

This is why you never want to use the "broadcast" keyword more than once per DLCI.

For example in some Cisco Docs you will see three or four maps to the same DLCI with the "broadcast" keyword at the end of every mapping statement.

Something like this:

interface Se0/0/0
encapsulation frame-relay
no frame-relay inverse arp
frame-relay map ip 150.2.1.2 202 broadcast
frame-relay map ip 150.2.3.2 202 broadcast
frame-relay map ip 150.2.3.2 202 broadcast
frame-relay map ip 150.2.4.2 202 broadcast

If you were to do this it would still work, however now you would have to generate four separate psuedu-broadcast instead of just one. So we only need the broadcast keyword once per DLCI so the correct configuration would be like this:

interface Se0/0/0
encapsulation frame-relay
no frame-relay inverse arp
frame-relay map ip 150.2.1.2 202 broadcast
frame-relay map ip 150.2.3.2 202
frame-relay map ip 150.2.3.2 202
frame-relay map ip 150.2.4.2 202

So broadcasts and multicast = replicated unicast over Frame Relay

HTH