Multicast, hub-and-spoke, frame-relay

[Kevin Dorrell]

I am considering what happens to multicast routing in frame-relay hub-and-spoke topologies.

As I understand it, there are two problems to be overcome when doing multicast in hub-and-spoke. One is that the multicast router will not forward a multicast out the same interface it came in, which makes it difficult to multicast from spoke to spoke. The other is (I think) specific to dense mode, and occurs when the source is behind the hub. It is that a prune from one spoke will cut off the feed to another spoke as it is on the same interface at the hub.

Now, I know that nbma-mode at the hub can solve both problems by treating each PVC as a seperate point-to-point link (a bit like point-to-multipoint in OSPF). But what I have never understood clearly is why nbma-mode is allowed with sparse-mode, but it is not allowed with dense-mode. Surely it would be an ideal solution to all dense-mode's problems with hub-and-spoke.

And, BTW, what about nbma-mode and spare-dense-mode? Does nbma-mode suddenly become feasible as soon as the RP is found?

I would be grateful if someone could talk me through the reasoning behind this.

Kevin Dorrell

Luxembourg

[Edison Ortiz]

Kevin,

That's a very good question and here is the logic behind it.

Dense Mode uses a push model to flood multicast traffic to every corner of the network. If nbma-mode was to work in a Hub and Spoke scenario, the hub receives a multicast packet from one spoke and it will try to resend this packet back to the spoke the packet was received from (push method).

Sparse Mode uses a pull model to deliver multicast traffic. Only network segments with active receivers that have explicitly requested the data will receive the traffic. Therefore, you won't have any multicast loop with nbma-mode enabled.

As for your other query:

> what about nbma-mode and spare-dense-mode? Does nbma-mode suddenly become feasible as soon as the RP is found?

The answer is Yes ! Any multicast group that is dense, in a hub and spoke, won't be relayed back out the same interface. That's when you need to build GRE tunnels -or- autorp listerner if running auto-rp.

[Kevin Dorrell]

Edison,

Thanks for the reply, but it is still not clear yet. Please excuse me if I am in dense-mode at the moment ;-)

Let us suppose for a moment that we could put nbma-mode in dense mode. Surely the correct behavior would be for the hub to receive the stream from one spoke, and to push it out to every spoke except the one where it is expecting to find the source. Which, after all, we already know becuse we have just done the RPF check. That way there should not be any loop. Of course you would only need to put nbma-mode on the hub.

So, I'm afraid it has not quite clicked yet. Could you explain how the loop could occur please?

Thanks in advance.

Kevin Dorrell

Luxembourg

[Edison Ortiz]

With Dense mode, there isn't an exception. It will push out the multicast traffic to every single destination out of every single multicast enabled interface - including the device where the packet came from.

[Kevin Dorrell]

OK, I didn't know that. So what stops any multicast packets going round loops, is it only the TTL? Wouldn't that result in repeated packets until the TTL dies?

KJD

[deeshar]

Kevin,

As far as I know with TTL Scoping concept; router will forward the multicast packet only on the those interfaces whose TTL value is less than or equal to the TTL value of the multicast packet. As we know default TTL of interfaces on Cisco router is "0" so we can avoid such situation by changing the TTL value so that there should not be any forwarding of mulicast group. However if there are multiple groups with different TTL then it could be a problem.

Thanks,

Deepak

[Edison Ortiz]

> OK, I didn't know that

Kevin, before creating any confusion, my previous statement was based on having the ability to enable nbma on dense mode - which isn't allowed.

The loop prevention is implemented by sending the multicast traffic out of every multicast enabled interface except the interface the packet came from.

In a multi-point serial connection, multicast treats the interface as a single interface - multicast packets come via that interface but can't never leave out that same interface.

As you stated, by enabling nbma, the OIL will list every single link (by IP address) on a serial interface (this information can be seen with show ip mroute). Since Dense mode pushes the information, it will push the traffic out to every single OIL destination while Sparse mode pulls the information, the neighbors will ask for the information if they needed, if they don't ask - they won't receive it.

[Kevin Dorrell]

Edison, this has been very helpful, but I'm afraid there is still something I am missing, something that ... che non mi torna. I think I am going to have to lab it to investigate.

I cannot remember in sparse mode and nbma-mode, whether the (*,G) entries include all the spoke links in the OIL, or only those that have received a PIM join. Futhermore, I cannot remember if a spoke is generating a stream and has a listener, whether it appears in both the incoming interface and the OIL for the (S,G) entry. I guess the OIL contains only those spokes that are listening.

I still do not see why you cannot have a dense NBMA mode that has all the spokes in the OIL except the one that fits the RPF check, and then set the prune flag on the ones that say they do not want the stream. Effectively that would be treating the spokes as a set of individual point-to-point links.

I wonder what Beau Williamson would say. I see he will be at Networkers in January, so I'll see if I can ask him the question then.

Kevin Dorrell

Luxembourg