Solved: Re: Cisco ACI Multicast flow mrib meaning

Americo Massotti · ‎10-19-2023

Hello everybody.

I'm studying about multicast Tenant overlay flow in Cisco ACI.

I'm following this Case Study reference: https://www.cisco.com/c/en/us/support/docs/cloud-systems-management/application-policy-infrastructure-controller-apic/211631-Case-Study-L3-Multicast-in-the-ACI-Fabr.html#:~:text=L3%20multicast%20flows%20run%20across,and%20external%20sources%20and%20r...

It's quite clear but I faced with some interpretation issue about the Mrib verification paragraph.

In this section the document analyzed the mroute entry on one Leaf that's also the multicast FHR on which we have the Multicast source streamer

!!!!! FHR of mcast sources in fabric
sleaf2# show ip mroute vrf common:default
IP Multicast Routing Table for VRF "common:default"

(10.101.101.115/32, 228.0.0.1/32), uptime: 00:17:54, ip pim
Incoming interface: Tunnel16, RPF nbr: 10.0.176.64 (pervasive)
Outgoing interface list: (count: 0)

(10.101.101.116/32, 228.0.0.1/32), uptime: 00:17:54, ip pim
Incoming interface: Tunnel16, RPF nbr: 10.0.176.64 (pervasive)
Outgoing interface list: (count: 0)

(10.101.101.117/32, 228.0.0.1/32), uptime: 00:17:54, ip pim
Incoming interface: Tunnel16, RPF nbr: 10.0.176.64 (pervasive)
Outgoing interface list: (count: 0)

Basically for my background multicast understanding there are some incongruence.

For example, because the leaf is the FHR, the RPF should be 0.0.0.0 (I'm the FHR the source it's directly connected on me) and the incoming interface should be the physical or logical interface on which we have the source multicast streamer endpoint.

However the RPF the document reported is the Spine (On real customer infrastructure however I see it's a BL, not the Spine) and the incoming interface it's a tunnel fabric interface through the leaf see all the BL that are PIM neighbor.

Why this, for my undestanding, multicast discrepancy respet traditional "legacy" FHR multicast enabled router?

Which is the logic of the output?

Thanks a lot

Americo

M02@rt37 · ‎10-19-2023

Hello @Americo Massotti,

The differences you're seeing in the output are due to the pervasive Gateway model used in Cisco ACI, which is designed to optimize multicast operation in the fabric and may not align with traditional multicast routing concepts.

In a traditional multicast environment, the incoming interface on the FHR would indeed be the interface where the source streamer is connected. In ACI, you're seeing a tunnel interface (Tunnel16) as the incoming interface. This is because in the pervaside Gateway model, ACI encapsulates multicast trafic in VXLAN tunnels within the fabric to reach the RPF neighbor (often a Spine or Border Leaf). This tunneling simplifies multicast handling within the fabric and allows the Spine or Border Leaf to perform efficient RPF checks.

As concerned RPF, in a traditional multicast environment, the RPF neighbor would typically be the next-hop router closer to the source, and for the FHR, it would indeed be the FHR itself. This is because the RPF check ensures that multicast traffic comes from a legitimate source on the shortest path. In Cisco "ACI's pervasive gatewaay model", the RPF neighbor, as shown in your output, is often the Spine (or Border Leaf) because multicast traffic is handled differently. The Spine or Border Leaf in ACI acts as a central point for RPF checks to optimize multicast distribution within the fabric. From my point of view, this setup simplifies multicast routing in ACI by having a central point for RPF checks, which can be more efficient in a large and complex fabric.

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.

View solution in original post

M02@rt37 · ‎10-19-2023

Hello @Americo Massotti,

The differences you're seeing in the output are due to the pervasive Gateway model used in Cisco ACI, which is designed to optimize multicast operation in the fabric and may not align with traditional multicast routing concepts.

In a traditional multicast environment, the incoming interface on the FHR would indeed be the interface where the source streamer is connected. In ACI, you're seeing a tunnel interface (Tunnel16) as the incoming interface. This is because in the pervaside Gateway model, ACI encapsulates multicast trafic in VXLAN tunnels within the fabric to reach the RPF neighbor (often a Spine or Border Leaf). This tunneling simplifies multicast handling within the fabric and allows the Spine or Border Leaf to perform efficient RPF checks.

As concerned RPF, in a traditional multicast environment, the RPF neighbor would typically be the next-hop router closer to the source, and for the FHR, it would indeed be the FHR itself. This is because the RPF check ensures that multicast traffic comes from a legitimate source on the shortest path. In Cisco "ACI's pervasive gatewaay model", the RPF neighbor, as shown in your output, is often the Spine (or Border Leaf) because multicast traffic is handled differently. The Spine or Border Leaf in ACI acts as a central point for RPF checks to optimize multicast distribution within the fabric. From my point of view, this setup simplifies multicast routing in ACI by having a central point for RPF checks, which can be more efficient in a large and complex fabric.

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.

Americo Massotti · ‎10-19-2023

Thanks a lot for your reply.

Basically even if the multicast source streamer is directly connected to the FHR leaf, from ACI fabric perspective the multicast source steamer is behind the Spine/BL thanks to the vxlan encapsulation of multicast traffic toward Spine/BL.

So the FHR (and also the other leaf) see the incoming interface and the RPF with the Spine/BL as root of any multicast tenant overlay flow.

At a glance is counterintuitive but after that...that's it

I have some other question about mcast on ACI but I'll open an other post.

Have you a nice day.

Americo