01-16-2008 12:38 PM - edited 03-05-2019 08:31 PM
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
01-16-2008 01:12 PM
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.
01-16-2008 01:43 PM
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
01-16-2008 02:22 PM
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.
01-17-2008 03:38 AM
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
01-17-2008 06:14 AM
Not sure since you have a L2 problem, not a L3 problem.
___
Edison.
01-17-2008 06:57 AM
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
01-17-2008 10:42 AM
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
01-17-2008 11:32 AM
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
01-17-2008 03:53 PM
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
01-18-2008 12:34 AM
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.
01-18-2008 02:08 AM
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
01-18-2008 02:22 AM
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.
01-18-2008 03:11 AM
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
01-18-2008 03:29 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide