Solved: PIM strange behavior after hardware change ( 6500 )

alexiff1987 · ‎04-05-2013

Hello !

Intro :

1 core vlan in which 3 switches ( 6500 + 2x3560E ) connected to each other using ipv4 subnet + bgp.

Pim is configured on every switch as "ip pim sparse-mode"

6500 is a main switch/router. Multicast streams comes from uplink via pim+mbgp+msdp to 6500

3560E switches rounting our customers and multicast iptv for them.

Previously in a place of 6500 was cisco 4900M and everything was just perfect

As soon as we put 6500 in place of 4900M pim started to act realy strange - as soon as i configure "ip pim sparse-mode" command on 3560E(core vlan) it starting to join ALL multicast groups - 300groups and ~600mbit.... even if nothing else is connected to him ( no customers and no networks )

ios : 6500 - 12.2(33)SXI6, 3560E - 12.2(55)SE

mulicast configuration :

ip multicast-routing /ip multicast-routing distributed

ip pim sparse-mode.

6500 is a designated router.

Thanks in advice,

Alex

Giuseppe Larosa · ‎04-05-2013

Hello Aleksandr,

the L2 switch detects the presence of an IP multicast enabled router on a port from PIM messages (and IGMP queries, if any only IGMP querier sends out regular queries). It does not understand them but it is able to say there is a multicast router out of this port and applies a logic " let him receive all the multicast flows I see in this broadcast domain" This is part of IGMP snooping activities.

On the other hand, the router is attempting to stop to receive unwanted multicast flows by sending PIM prune messages. It cannot do more.

As already suggested PIM snooping would be needed here or its ancestor RGMP protocol.

Another option is to connect the two C3560 directly to the C6500 bypassing the C4900M.

Third option is to make the C4900M a L3 device and to become a PIM router itself in this way it will be able to understand the messages from the neighbors. With appropriate feature licenses it should not be an issue for the C4900M.

Hope to help

Giuseppe

View solution in original post

Muhammad Thanveer · ‎04-05-2013

I am not sure but there can be chances for igmp version mismatch

http://www.cisco.com/en/US/docs/wireless/module/wlsm/release/notes/wlsmrn21.html

This problem is caused by an IGMP version mismatch between the Catalyst 6500 and the 3550 switch. The Supervisor 720 drops and does not process IGMP version 2 packets, but the 3550 switch continues to flood IGMP version 2 packets to the Catalyst 6500, causing the heavy CPU use.

This problem is can be resolved by one of the following actions:

–Limit the rate of IGMP packets by applying an IP IGMP snooping rate of 100-600.

–Apply IP IGMP version 3 to all tunnel or interfaces with mulitcast enabled.

you can find the documents here

http://www.cisco.com/en/US/docs/ios-xml/ios/ipmulti_pim/configuration/12-2sx/imc_basic_cfg.html#GUID-4ABBEE03-CEA0-45AD-99DE-3CA70997945E

http://www.cisco.com/en/US/docs/ios-xml/ios/ipmulti_igmp/configuration/12-2sx/imc_customizing_igmp.html

Pleae rate the helpful posts

Regards
Thanveer
"Everybody is genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is a stupid."

alexiff1987 · ‎04-05-2013

Im very sorry I forgot to mention

that there is layer2 switch between all those l3 6500 and 3560 switches.

So as i understand this l2 swich in the middle is a problem and can be fixed with PIM snooping i suppose but this switch - 4900m doesnt have it.

So can someone explain why in situation when there is a layer2 switch between l3 routers/switches this l2 swich send multicast traffic to all port where pim is enabled ( pim sparse ) and why do l3 switch with no client on it starts to send Join messages as soon as pim-sparse is enabled on it?

Debug :

Apr 5 20:39:09.729: %PIM-5-NBRCHG: neighbor XX.242.0.2 UP on interface Vlan50

Apr 5 20:39:09.737: PIM(0): Update Vlan50/XX.242.0.2 to (*, 224.0.1.40), Forward state, by PIM *G Join

Apr 5 20:39:09.737: PIM(0): Changing DR for Vlan50, from 0.0.0.0 to XX.242.0.2

Apr 5 20:39:09.737: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to XX.242.0.2 on interface Vlan50

Apr 5 20:39:09.737: %PIM-5-NBRCHG: neighbor XX.242.0.15 UP on interface Vlan50

Apr 5 20:39:09.821: PIM(0): Building Graft message for 224.0.1.40, Vlan50: no entries

Apr 5 20:39:09.829: PIM(0): Check RP 95.140.80.245 into the (*, 224.200.202.84) entry

Apr 5 20:39:09.829: PIM(0): Check RP 95.140.80.245 into the (*, 224.200.202.58) entry

Apr 5 20:39:09.838: PIM(0): Check RP 95.140.80.245 into the (*, 224.200.202.79) entry

Apr 5 20:39:09.838: PIM(0): Check RP 95.140.80.245 into the (*, 224.200.202.200) entry

Apr 5 20:39:09.846: PIM(0): Check RP 93.100.195.16 into the (*, 239.195.0.13) entry

Apr 5 20:39:09.846: PIM(0): Check RP 95.140.80.245 into the (*, 224.200.202.94) entry

Apr 5 20:39:09.855: PIM(0): Check RP 93.100.195.16 into the (*, 239.195.0.27) entry

Apr 5 20:57:45.476: PIM(0): Check DR after interface: Vlan50 came up!

Apr 5 20:57:45.476: PIM(0): Changing DR for Vlan50, from 0.0.0.0 to XX.242.0.18 (this system)

Apr 5 20:57:45.476: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to XX.242.0.18 on interface Vlan50

Apr 5 20:57:45.484: PIM(0): Building Graft message for 224.0.1.40, Vlan50: no entries

Apr 5 21:00:10.273: PIM(0): Check RP 93.100.195.16 into the (*, 239.195.1.46) entry

Apr 5 21:00:10.324: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 224.200.202.24

Apr 5 21:00:10.324: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 224.200.202.42

Apr 5 21:00:10.324: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 224.200.202.107

Apr 5 21:00:10.324: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 239.195.0.24

Apr 5 21:00:10.324: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 239.195.0.37

Apr 5 21:00:10.391: PIM(0): Check RP 93.100.195.16 into the (*, 239.195.0.15) entry

Apr 5 21:00:10.525: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 224.200.202.79

Apr 5 21:00:10.525: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 239.195.0.23

Apr 5 21:00:10.626: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 239.195.1.3

Apr 5 21:00:10.726: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 224.200.202.86

Apr 5 21:00:10.726: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 224.200.202.84

Apr 5 21:00:10.726: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 239.195.0.54

Apr 5 21:00:10.726: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 239.195.1.26

Apr 5 21:00:10.835: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 239.195.2.3

Received v2 Join/Prune on Vlan50 from XX.242.0.15, not to us

Apr 5 21:00:17.102: PIM(0): Join-list: (*, 239.195.1.8), RPT-bit set, WC-bit set, S-bit set

Apr 5 21:00:18.050: PIM(0): Received RP-Reachable on Vlan50 from 93.100.195.16

Apr 5 21:00:18.050: for group 239.195.1.1

Apr 5 21:00:18.410: PIM(0): Received v2 Join/Prune on Vlan50 from XX.242.0.15, not to us

Apr 5 21:00:18.410: PIM(0): Join-list: (95.140.93.66/32, 224.200.202.61), S-bit set

Apr 5 21:00:19.534: PIM(0): Received v2 Join/Prune on Vlan50 from XX.242.0.15, not to us

IGMp

Muhammad Thanveer · ‎04-05-2013

I found this and it can be helpful to you

In networks where a Layer 2 switch interconnects several routers, the switch floods IP Multicast packets to all multicast router ports by default, even if there are no multicast receivers downstream. In these environments, PIM snooping should be used to constrain the multicast to the interested routers.

With PIM snooping enabled, the switch restricts multicast packets for each IP multicast group to only those multicast router ports that have downstream receivers joined to that group. When you enable PIM snooping, the switch learns which multicast router ports need to receive the multicast traffic within a specific VLAN by listening to the PIM hello messages, PIM join and prune messages, and bidirectional PIM designated forwarder-election messages.

Point-to-point interfaces will avoid the additional complexity that requires PIM snooping.

Please refer to below links:

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6552/ps6592/whitepaper_c11-474791.html

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/snooppim.pdf

Please rate the helpful posts......!!1

Regards
Thanveer
"Everybody is genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is a stupid."

alexiff1987 · ‎04-05-2013

Yes, exactly. But.. Why router sends

"PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for " ?

And how exactly l2 switch sense the multicast router on his port ( pim router ) ?

Giuseppe Larosa · ‎04-05-2013