Strange Multicast Forwarding Issue - 6500 (Kinda Urgent)

Unanswered Question
Jan 16th, 2008

Hi Guys,

I have a network setup as shown in the jpeg provided. Typical access switch connected in a diverse manor to two 6500 distribution switches. - L3 between the distribution pair and L2 to the access switch (no STP)

I see my multicast streams flow down to my access switch on port 5/2 from distribution switch2, but then also see them flow back up on port 5/1 to distribution switch1.

Now the 6500 CatOS multicast table (populated by IGMP) shows both ports 5/1 and 5/2 as members for the multicast GDAs, but I dont want the multicast traffic to flow back up to the distribution.

The only thing I can think of is that the S,G trees and default gateway are on switch2, but the IGMP querier is on switch1.

Is that the problem, and if not, how do I stop this traffic from flowing back from the access to the distribution?

Many thx for your help as always,

Ken

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Loading.
Edison Ortiz Wed, 01/16/2008 - 13:12

What you have is the end-result of having STP disabled in Vlan 100. Both ports are set to forwarding. I suggest you configuring STP in Vlan 100 to avoid any further L2 loops in your network.

HTH,

___

Edison.

Jon Marshall Wed, 01/16/2008 - 13:43

Hi Edison

Where is the loop in the network. The 2 distribution switches are interconnected with a L3 link not a L2 link.

Or am i being really dense - it has been a long day :)

Jon

Edison Ortiz Wed, 01/16/2008 - 14:22

Jon,

I will rephrase that. Replace loop with asymmetrical forwarding :)

The access switch sees two equal destination and it will chose the path with the lowest port number. What the OP is seeing is perfectly normal.

kfarrington Thu, 01/17/2008 - 03:38

Hi Guys,

Many thx for the responses and interest.

I have just found this out on the multicast troubleshooting page :-

http://doc.trecom.tomsk.su/cisco/cc/td/doc/product/core/cis7600/122sx/swcg/mcastmls.htm#1049755

It describes the actual behaviour "Non-RPF Traffic Processing" with potential fixes : "mls ip multicast stub" command on the redundant router which applies ACLs and rate limits on the ACLs.

I assume by this this topology must be a candidate for this type of configuration ????

Does anyone else use this configuration. I still have to read further to see what happens upon failure of the PIM DR??

Many thx once again,

Ken

Kevin Dorrell Thu, 01/17/2008 - 06:57

I have a few questions about this that might give us some clues.

1. Does switch 1 have a layer-3 presence in VLAN 100?

2. If so, do you have ip pim enabled on the SVI? If it is a multicast router on VLAN 100, then yes, it is eligible to get all the multicast traffic.

3. I presume we are talking sparse-mode here. Can you confirm that? Ah yes, your diagram says so!

4. Where is the RP? If it is switch 1, the switch 1 will get all the multicasts regardless.

5. Do you have IGMP snooping (or CGMP) enabled on the access switch? If not, everything is going to be flooded anyway.

6. show ip igmp snooping mrouter on the access switch? Does it include port 5/1 ?

7. I presume you do not have ip igmp join-group anywhere in switch 1?

Kevin Dorrell

Luxembourg

kfarrington Thu, 01/17/2008 - 10:42

Hi Edison and Kevin,

Hope you guys are well :)

So...

1. Yes it does. Switch1 is IP address .1

and switch2 is ip address .2 so switch2 is DR

2. VLAN100 SVI has PIM-Sparse-Mode enabled on the VLAN Interfaces on both switches

3. As above. Yup, sparse-mode only

4. The RP is somewhere 5 hops away in "Campus Net" and we are using static rp configuration for the group-to-RP mappings.

5. IGMP SNooping is enabled and working :)

6. On the access switch it is CatOS only. so if i do a show multicast router, it shows both ports 5/1 and 5/2

7. No, if I do a show ip igmp int vlan 100 I get the following

No multicast groups joined by this system

As the docs seem to indicate, this is normal behavior (I think and would like to confirm) but I still have no idea how to stop this with the multicast stub feature.

ie, Let say you have two 100Mbit streams running, why would you ever want it to go from one distribution to an access switch and for that access switch to flood it back to the other distribution switch?

I think I remember reading that if a vlan interface on both switches has PIM enabled on it, the L2 access switch will see this PIM GDA mac, and know that it is a router port, and THEN add the multicat router ports to EVERY multicast GDA the L2 switch has? Would that be correct?

Many thx for everyones help with this :)))

Kind regards,

Ken

kfarrington Thu, 01/17/2008 - 11:32

Also guys (If I May)

How does a switch know which port is a router port. I am reading some conflicting information here, or I am not paying attention :)

A router port can be discovered by:

- reception of a PIM hello

- Receicption of an IGMP message with a src.ip not 0.0.0.0

- A special type of IGMP message where the value of the type field is OX11 for a membership query sent by a router

- etc etc etc

Where is the (if any) exact documentation to say what is what?

Many thx all,

Ken

Kevin Dorrell Thu, 01/17/2008 - 15:53

Ken,

Yes, that's more or less right. If the switch detects a multicast router, (because it is talking PIM) then it will flood every multicast to that port, just in case the router needs to forward it to somewhere else.

I'm not sure how to correct that. I'll have to go away and think about it.

It's getting a bit late to do any research, but the switch config guide, chapter about IGMP snooping, should tell you about this. You may even be able to tweak the criteria.

Kevin Dorrell

Luxembourg

kfarrington Fri, 01/18/2008 - 00:34

You guys are Stars!!!

So, I will look into this multicast stub feature then. The info I have currently is (straight from the cisco doc) :-

Non-RPF Traffic Overview

In a redundant configuration where multiple routers connect to the same LAN segment, only one router

forwards the multicast traffic from the source to the receivers on the outgoing interfaces (see

Figure 18-1). In this kind of topology, only the PIM designated router (PIM DR) forwards the data in the

common VLAN, but the non-PIM DR receives the forwarded multicast traffic. The redundant router

(non-PIM DR) must drop this traffic because it has arrived on the wrong interface and fails the RPF

check. Traffic that fails the RPF check is called non-RPF traffic.

The Cisco 7600 series Internet router processes non-RPF traffic in hardware on the PFC3 by filtering

(dropping) or rate limiting the non-RPF traffic.

Filtering of RPF Failures for Stub Networks

The PFC3 and the DFCs support ACL-based filtering of RPF failures for sparse mode stub networks.

When you enable the ACL-based method of filtering RPF failures by entering the mls ip multicast stub

command on the redundant router, the following ACLs automatically download to the PFC3 and are

applied to the interface you specify:

access-list 100 permit ip A.B.C.0 0.0.0.255 any

access-list 100 permit ip A.B.D.0 0.0.0.255 any

access-list 100 permit ip any 224.0.0.0 0.0.0.255

access-list 100 permit ip any 224.0.1.0 0.0.0.255

access-list 100 deny ip any 224.0.0.0 15.255.255.255

The ACLs filter RPF failures and drop them in hardware so that they are not forwarded to the router.

Use the ACL-based method of filtering RPF failures only in sparse mode stub networks where there are

no downstream routers. For dense mode groups, RPF failure packets have to be seen on the router for

the PIM assert mechanism to function properly. Use CEF-based or NetFlow-based rate limiting to limit

the rate of RPF failures in dense mode networks and sparse mode transit networks.

Rate Limiting of RPF Failure Traffic

When you enable rate limiting of packets that fail the RPF check (non-RPF packets), most non-RPF

packets are dropped in hardware. According to the multicast protocol specification, the router needs to

receive the non-RPF packets for the PIM assert mechanism to function properly, so all non-RPF packets

cannot be dropped in hardware.

When a non-RPF packet is received, a NetFlow entry is created for each non-RPF flow.

When the first non-RPF packet arrives, the PFC3 bridges the packet to the MSFC3 and to any bridged

ports and creates a NetFlow entry that contains source, group, and ingress interface information, after

which the NetFlow entry handles all packets for that source and group, sending packets only to bridged

ports and not to the MSFC3.

To support the PIM assert mechanism, the PFC3 periodically forwards a percentage of the non-RPF flow

packets to the MSFC.

The first packets for directly connected sources in PIM sparse mode are also rate-limited and are processed

by the CPU.

Rate limiting of RPF failures is enabled by default.

Kevin Dorrell Fri, 01/18/2008 - 02:08

Ken,

Thanks for finding out that information ... it looks useful.

If I understand it right, the mls ip multicast stub solution is a solution but isn't.

Looking at your topology diagram, you would apply the config line on the downward-facing interface of each of your redundant routers, i'nit? That is, it does not prevent the propagation of the multicast up from your switch 3 to your switch 1, but it does make switch 1 drop the packets in hardware before they take up valuable CPU.

I take it that if the link S2-S3 fails, and suppose S1 and S2 were really redundant routers, then S1 would become the PIM DR for the segment, and so would remove the access list.

Kevin Dorrell

Luxembourg

kfarrington Fri, 01/18/2008 - 02:22

Well, That is the question.

Also, the text says

"When you enable the ACL-based method of filtering RPF failures by entering the mls ip multicast stub

command on the redundant router, the following ACLs automatically download to the PFC3 and are

applied to the interface you specify:

"

So enter the command only on the redundant router??????

That does not sound like a plan ?

I am going to try and see if I can glean more info on this command.

Cheers Kevin,

Will report back.

Kevin Dorrell Fri, 01/18/2008 - 03:11

I think you would enter it on both routers just for the sake of symetry. In a true redundant situation, it might not be immediately obvious which one is going to end up as the DR. If you apply it to both, then the non-DR router would apply the access list, and the DR would not. Reversing the access list if the rôles reverse, and removing it altogether if the non-DR router gets any forwarding entries, I suppose.

It still doesn't keep the unnecessary traffic of the (redundant) uplink, but it does save CPU on the non-DR router.

I'm at Networkers next week. I wonder if I can find Beau Williamson or Steve Simlo and ask one of them about this.

BTW, I presume that S1 really does need PIM on VLAN 100? That is, I presume it is a true reedundant multicast router from the core, or that it supplies other multicast groups to S3? If not, you could simply disable PIM on S1 VLAN 100, and your problem would be solved.

Kevin Dorrell

Luxembourg

kfarrington Fri, 01/18/2008 - 03:29

Hi Kevin,

If Mr B is there, that would be good.

Yes, we would have pim enabled on both, for redundancy (switch offline) so can't get away from that one :(

The only other way would be to only associate 1 mrouter per vlan, (ie: a kinda hsrp for igmp). In a stub type of environment only that would have to be :)

Cheers fella,

Ken

kfarrington Fri, 01/25/2008 - 01:03

Kevin, Many thx for that.

So, PIM Snooping or RGMP, having a read up on it

Section on RGMP

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/catos/8.x/configuration/guide/multi.html#wp1053832

So, I am not sure if this would work in the two router - one switch scenario? Is it just for backbone environments?

Can anyone comment on its use in the delta design I have (pls see diagram in first post)?

Once again, thx to all, this is becoming a very interesting thread :)

Kind regards,

Ken

Actions

This Discussion