What is the impact of this error message that we recently started seeing an increase on all our 6509 campus switches. We are suspecting it is due to the following client protocols used primary with new printers and apple access points. The protocol that is causing the aliasing is called zeroconf which includes other things like Multicast DNS and Link Local Addressing. An example of the error message is as followed:
2003 Apr 06 21:52:46 %MCAST-2-IGMP_ADDRAL:IGMP: Address Aliasing for 01-00-5e-00-00-01
2003 Apr 06 21:52:46 %MCAST-2-IGMP_FALLBACK:IGMP: Running in FALL BACK mode
2003 Apr 06 21:52:46 %MCAST-2-IGMP_ADDRALDETAILS:IGMP: Multicast address aliasing: From 00-03-93-20-a9-01 (22.214.171.124) on 3/5 to 01-00-5e-00-00-01 (126.96.36.199
This syslog message is generated when the switch is receiving excessive multicast traffic destined for a multicast MAC address in the 01-00-5e-00-00-xx range. IGMP snooping does not support multicast streams to addresses in this MAC address range because MAC addresses in this range are also used for IGMP control traffic (such as leaves, joins, general queries, and so on).
I've been to the url you provided. That's the reason we tracked down a few of these hosts and found out that zeroconf is responsible for the stream aliasing 01-00-5e-00-00-01. All the ones we found were apple basestations.
But it is still not clear to me what will break or what will be the performance impact while running in fallback mode. Will multicast IGMP joins fail during this time? or we will loose the benefit of stearing multicast traffic to ports that have members and actually flood it out on all ports?
I guess there is also a change that IGMP may switch to fallback mode permanently but when will this happen? What is the trigger point?
When the switch detects high rate of traffic to with destination MAC
01-00-5e-00-00-01, it stops snooping packets with the specified destination MAC address for a short period of time (this is the fall back mode) and then starts snooping again (this is called normal mode). So mutlicast traffic will be flooded when it is in fall back mode.
The messages seem to indicate that the client on port 3/5 00-03-93-20-a9-01 (188.8.131.52) is transmitting multicast traffic using a reserved multicast address (184.108.40.206). This will need to be isolated and changed for IGMP to operate properly.
I'm still gathering facts before we take any action against these devices. So let me see if I got this straight. While in fall back mode, will all multicast streams be flooded out to all ports? or will the multicast cam entries already setup stay intact limiting the flooding but as a side effect no new receivers can join the group?
Say there is a heavy multicast stream source and a handful of receivers active. The IGMP messages have been snooped before the switch went in to fallback and the dynamic cam table has been configured to limit flooding. Then someone sends excessive traffic to one of the reserved groups causing the switch to go in fall back mode. What happens to the active multicast streams and what happens to future event's leaves/joins?
This is actually a pretty cool feature, i didn't even know it existed until I was looking for a solution to advertise a subnet (prefix in BGP talk), only if a certain condition existed. This is exactly what conditional advertisements does
j ai une question j ai achete un routeur cisco 887VA-k9 , je le configuré avec la configuration ci- dessous
si je le lier avec mon pc portable sur l un de ses ports directement ça marche toute est bien ( la connexion internet + m...
Attached policy provides CLI access to the Cisco 4G router over text messaging. Two files are in the attached .tar file:
2. PDF with instructions on how to load and use the .tcl file.