Strange Multicast Issue

dlwanuradha · ‎10-16-2008

Issue Summary,

As per the diagram, we have two server access switches attached to each other with a port channel and attached to distribution switches.

Sdi02 has been configured to act as the DR and man02 has been configured to be the RP for the multicast group. Both SAC switches are configured to have VLAN19 and 18.

Problem I'm having is when I server 10.3.19.54 send multicast traffic to x.x.x.1 group only other servers in VLAN19 can see it. However the same server can talk and listen to multicast group x.x.x.2 without any issues. Also Server 10.3.18.185 doesn't have any problem with the group x.x.x.1 and there are other servers in the group without any issues.

When I do show ip mroute on SDI01, I can see server 10.3.19.54 however it's not appearing on SDI02 which is supposed to be the DR.

If I do â€œshow ip igmp group x.x.x.1â€ I can see the server 10.3.19.54 on both SDI01 and SDI02. Also I can see the port connecting 10.3.19.54 registering to the multicast group on â€œshow cam staticâ€ on the server access switche SAC09 and all port channels on both switches.

Problem is 10.3.19.54 is not registering on the RP and it's not going anywhere afer SDI01. As per the config theory it should take the port channel connecting SAC09 and SAC10 and then hit SDI02 and then talk to the RP.

After doing may troubleshooting, clearing mroute, clearing static cam, clearing igmp group, nothing works.

I've changed the server IP and still no luck (server IP was changed to ruled out any port issues on the port channel - once I changed the IP channel hash took a different port).

I've plugged a laptop on to the same SAC switch and used â€œUDPSENDâ€ to subscribe to the same multicast group and VLAN also I used the server OLD IP address as well, however the laptop didn't register on DR or RP but it registered on SDI01.

To fix the issue I had to put a static cam entries on both SAC switches and after that clear mroute on both SDI switches and it started working for the group x.x.x.1. All good.

UNTIL today we started having a similar issue on the multicast group x.x.x.3 with the same symptoms. So I'm wondering there is an underlined issue to this.

CAM aging is set to 1200 on the SAC switches and 300 on the SDI switches and port fast has been enabled on all SAC switch ports.

ANY LIGHT ON THIS ISSUE IS HIGHLY APPRICIATED.

Giuseppe Larosa · ‎10-16-2008

Hello Anuradha,

first basic check is

sh ip pim interface vlan19

sh ip pim interface vlan18

on distribution switches.

On SDI1,2 verify the ip pim rp mapping for all the involved groups.

do

sh ip pim rp mapping

if your interfaces is configured for ip pim sparse-mode only (no ip pim sparse-dense-mode on interfaces) if the group is not mapped to an RP the shared tree is not built.

If you see different behaviours for groups x.x.x.1 no ok

x.x.x.2 ok

x.x.x.3 no ok

with bootstrap protocol the multicast space can be mapped to multiple RPs in a similar way.

>> When I do show ip mroute on SDI01, I can see server 10.3.19.54 however it's not appearing on SDI02 which is supposed to be the DR.

If I do â€œshow ip igmp group x.x.x.1â€ I can see the server 10.3.19.54 on both SDI01 and SDI02

check the STP config for vlan18 e vlan19

sh spanning-tree vlan 18

sh spanning-tree vlan 19

verify who is the root bridge (SDI1 or SDI2 expected) and see what is the root port for sac9 for vlan 18 and vlan19.

Hope to help

Giuseppe

dlwanuradha · ‎10-16-2008

Hi Giuseppe,

Thank you for your reply.

All basic checks seems to be fine. I can't see any difference on distribution switches. And they are configured with ip pim spars-mode.

When I do sh spanning-tree vlan 19 and 18,

Both switches seems to be acting as root.

For VLAN 18 on sdi02

Interface Role Sts Cost Prio.Nbr Type

---------------- ---- --- --------- -------- --------------------------------

Po18 Root FWD 3 128.1671 P2p

For VLAN 18 on SDI01

Interface Role Sts Cost Prio.Nbr Type

---------------- ---- --- --------- -------- --------------------------------

Po18 Root FWD 3 128.1671 P2p

And same for VLAN 19.

Thanks,

Anu

francisco_1 · ‎10-16-2008

if you have trunking between the sac's and sdi switches, make sure you are not restricting any vlans on the trunk interfaces (vlan 18/19 are allowed on the trunks) and the vlan 18/19 exist on all switches (sh vlan brief).

If the above is ok then post your configs.

Francisco.

Giuseppe Larosa · ‎10-16-2008

Hello Anuradha,

the show means that both switches see in Po18 the root port not that each thinks to be the root bridge so none of them is the root bridge for vlan 18 (there are no root ports on the root bridge)

Now, the point is what device is on the other side of Po18 on SDI01 and SDI02 ?

do sh ethercha sum

get the list of member links for Po18, let's suppose g2/9 is one of them do

sh cdp n g2/9 det

verify with sh spanning-tree vlan 18 and sh spanning-tree vlan 19 on both DS01 and SDI02 that the Root Bridge ID is the same for each vlan (they agree on Root BID on a vlan basis) if it is not the same you have a partitioned broadcast domain as suggested by Francisco and this could explain the strange issue you see.

you can also check with:

sh spanning-tree summary

on SD01 and SD02 I would expect one of them to be root bridge for every vlan including vlan 18 and vlan 19.

Hope to help

Giuseppe

dlwanuradha · ‎10-17-2008

All ports in the port-channel has been configured to allow both VLAN 18 and 19. Also I see the same Root Bridge ID for each VLAN.

Bizare thing is the very same host can talk to other multicast groups without any problem. And there are many servers in these two access switches subscribing to many multicast groups without any issues.

However last night I put a static CAM entry for the multicast group MAC including all ports and VLAN on both access switches. Then removed it after about 10 mins. Then cleared IP igmp group on both distribution switches and things started working.

As I mentioned earlier this is the second time this happened. Earlier it was VLAN 19 and this time it's VLAN 18. (on the same switches). So I do think there is an underline issue.