How to troubleshoot BUM multicasting?

[AAlexS]

Hello
We have an SD-Access infrastructure and L2-only vlan with PXE hosts. The FW is a DG for that VLAN and it connected thru L2 handoff.

The problem is that PXE hosts can't boot for dozens of minutes after reloading the edge switch they are connected to. When the switch boot up it establishes LISP sessions, registers MAC address on a MS/MR, but not forward BUM traffic from PXE hosts to multicast. It may continues for 5-40 minutes. Then suddenly the edge switch starts forwarding BUM traffic to the multicast group.

The question is how to troubleshoot the BUM traffic multicasting?

Thank you in advance for any suggestions

[georgehewittuk1]

I know it does eventually work but silly questions do you have Layer-2 flooding enabled on the IP Pool? And do you have a RP configured and underlay multicast configured?

Identify the mcast group address that's being used in the fabric for the VLAN then below:

Show ip pim rp - identify RP 

Show ip route mroute x.x.x.x on the L2 Border, RP, and Fabric Edge.

May give a starting indication of if there is an mcast issue/where traffic gets too. Could also debug multicast packets.

[AAlexS]

Thank you @georgehewittuk1. I checked all topics you mentioned. The multicast configured well in underlay. Multicast routing table populated quickly after switch restart. The switch build shared-tree for group 239.0.17.1 and sparse-trees to other edges and a border. L2-flooding is enabled on this vlan.

The switch receive BUM traffic from other edges and a border but do not forward own.

[AAlexS]

I have found that the problem is in pruned multicast group on the affected edge switch.

Thru some time after reload the multicast group for forwarding local BUM traffic went to a pruned state for some minutes.

(10.10.10.10, 239.0.17.1), 00:55:27/00:01:37, flags: PFT
Incoming interface: Null0, RPF nbr 0.0.0.0
Outgoing interface list: Null

10.10.10.10 is an own address of the affected edge switch

The switch drops all local BUM traffic and not forward it outside while this group is in pruned state

I suppose that it happens because all hosts connected to the switch are the PXE hosts and they are silent while not booted yet.
So I have to configure the affected switch  to generate some synthetic traffic for keeping this group in not pruned state.

[georgehewittuk1 · Accepted solution]

In the past I've had to create IP SLA traffic for SD-A when i had an issue with directed broadcast with silent hosts to get the control plane to kick in. I used IP SLA - in theory you can use it here for multicast traffic generation too in the global routing table. -  https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipsla/configuration/xe-16-10/sla-xe-16-10-book/sla-mcast-suppt.html "

Configuring Multicast UDP Jitter Operations"