We have ran into a strange issue at one of my client sites that apparently started a few months ago as best we can tell. I will include an image of the topology I am working with but what we are seeing is the multicast receiver report being sent back to the multicast group of which the camera is a source is being received on the x690's as ingress traffic from the MLX on VLAN 91. This traffic should be tagged in VLAN 410 when ingressing the x690's from the MLX. The x690 and MLX are connected by a 4x10Gig LAG using LACP.
This is causing the MAC of the decoder server to be learned as coming from the MLX rather then the downstream 450-G2 where the host is actually connected.
I've been racking my brain over what may be causing this. We collapsed the LAG down to a single member and this issue still occurs (see pcap screengrab below. At this point I'm really looking for other ideas. We have multiple escalated tickets opened with Extreme already on this issue, but we've been working on this issue since August and it's still present.
What we think we know?
1. If a host in this building joins a multicast group sourced in this building its MAC will move as soon as Unicast traffic from or to that host pauses for 30-60 seconds which causes packet loss as the next-hop MAC is incorrect until the MAC is relearned on the correct port
2. If the host or source isn't participating in multicast this issue doesn't seem to occur.
3. No buffers appear to be congested on any equipment
4. No queues are in a high utilization condition that we can find
5. Doesn't matter which port we leave active on the LAG, the behavior continues.
6. If we statically assign the MAC this problem goes away, but this is not an option in our environment as it is highly dynamic
Other possibly useful information:
1. About 3Gbps of Multicast traffic steady state with nearly 3000 PIM Mcache entries
2. Network is running PIM Sparse mode
3. About 2.5Gbps of Unicast video in addition to Multicast video
Any ideas what I may be missing?
------------------------------
Shane Owens
Technology Assurance Labs
------------------------------
This is causing the MAC of the decoder server to be learned as coming from the MLX rather then the downstream 450-G2 where the host is actually connected.
I've been racking my brain over what may be causing this. We collapsed the LAG down to a single member and this issue still occurs (see pcap screengrab below. At this point I'm really looking for other ideas. We have multiple escalated tickets opened with Extreme already on this issue, but we've been working on this issue since August and it's still present.
What we think we know?
1. If a host in this building joins a multicast group sourced in this building its MAC will move as soon as Unicast traffic from or to that host pauses for 30-60 seconds which causes packet loss as the next-hop MAC is incorrect until the MAC is relearned on the correct port
2. If the host or source isn't participating in multicast this issue doesn't seem to occur.
3. No buffers appear to be congested on any equipment
4. No queues are in a high utilization condition that we can find
5. Doesn't matter which port we leave active on the LAG, the behavior continues.
6. If we statically assign the MAC this problem goes away, but this is not an option in our environment as it is highly dynamic
Other possibly useful information:
1. About 3Gbps of Multicast traffic steady state with nearly 3000 PIM Mcache entries
2. Network is running PIM Sparse mode
3. About 2.5Gbps of Unicast video in addition to Multicast video
Any ideas what I may be missing?
------------------------------
Shane Owens
Technology Assurance Labs
------------------------------
