Multicast and eigrp

Hi
In the lab Multicast advanced, with eigrp i need to send the multicast address 224.0.0.10 but with sparse mode, this address can’t pass. One solution is spend to the sparse-dense mode. But is there a solution with sparse_mode (only).

Thanks for your help

regards

Arlette

Hello Veronese

The 224.0.0.10 address is used by EIGRP in order to allow EIGRP routers to share routing information with other EIGRP routers in a network segment. When setting up EIGRP, there is no need to configure any multicast routing or functionality as this is already preconfigured within the routers. Actually, this address, just like all addresses in the 224.0.0.0/24 network, are not routable and this is by design. These multicast addresses always remain within the same subnet. So you don’t need this address to “pass” to other networks, but to remain within its current subnet.

I’m not sure what you mean when you refer to the “multicast advanced” lab. Are you referring to the topology of a particular lesson on the site? If so, please let us know.

I hope this has been helpful!

Laz

Hi
thanks you, when i said lab Multicast advanced, i speak about that


The problem is that 224.0.0.10 is dropped in sparse mode and for the solution i think there is 2 solutions dense mode or ip mroute
I would like to know if there is another solution
Thanks

Arlette

Hello Veronese

Ah, I see, you are referring to a lab found on the GNS3Valut site. Thanks for clearing that up.

The multicast routing process that deals with routing multicast traffic is something that is independent of the multicast addresses used by routing protocols to share their data. Yes, within the multicast routing domain, 224.0.0.0/24 is not routed, but EIGRP is still able to exchange its routes using that address. EIGRP functions just fine in a multicast environment.

You simply have to ensure that your multicast addresses used in your topology are not in the 224.0.0.0/24 subnet, as these are reserved and actually, cannot be routed.

As mentioned in the previous post, these are unroutable by design, and will always be dropped by the multicast routing process, as described in RFC 5771. Using dense mode or ip mroute will not change this.

I hope this has been helpful!

Laz