Re: Microsoft SOHO router multicast problem? - or maybe it's just doing what it's supposed to be doing...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chance Whaley wrote: | Sorry about that. Didn't look in detail. Saw the UDP port 6257 and | stopped. | | The mcast is coming from someplace upstream from | fastethernet-0-0.genoa-gw.amplex.net (that is if I did my mcast | MAC to mcast IP conversion right). Without knowing your topology | and seeing more traffic it's kinda hard to figure out. | | | If you want to send more traffic captures I will be happy to look | at them. | | .chance | The destination mac address the routers start using is 01:00:5e:76:6c:7e. The 01:00:5e is the ethernet multicast header. The 76:6c:7e is supposed to be the lower 23 bits of the Ethernet multicast address - which translates to 118.108.126.With the 23 bits from the multicast spec for encoding the IP address 118 is the correct conversion of 246 with the high bit stripped off. The gateway on this subnet is 64.246.108.126 (netmask is 255.255.255.0 but originally was .128 - hence the odd spot for the gateway). The routers decided to convert a mangled unicast packet to a multicast packet - for them to then loop on it is even stranger. It makes for a pretty good DOS attack. 2 or more of these routers in a broadcast domain can get ugly in a hurry. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCX3F2g0PQSWMG2wsRAhYaAKCDeTpKF1QuDhX82rQIOpPTQW4xwACggXhd uHRnFxzmWbrfHSvZGS9ljrs= =IcaN -END PGP SIGNATURE-
Microsoft SOHO router multicast problem? - or maybe it's just doing what it's supposed to be doing...
So which one of the gods of Multicast would like to take a look at a short tcpdump and tell me if the multicast broadcast storm is a problem with the protocol, the Microsoft implementation, or just a really weird coincidence? We run a fixed wireless network that for various reasons is bridged. Yes - it's a crappy design and we are working on changing it but that's not really the point. I have been trying to track down a broadcast storm that shows up on the network intermittently. I finally managed to capture the start of one tonight. The process starts with a slightly mangled packet (intentional? - can't tell yet) with the 'multicast promiscuous bit' set. All of the customers with Microsoft routers (and one Belkin) then rewrite the mangled packet into a multicast packet, decriment the TTL, and forward it back out the interface it came in on. This process then repeats with each of the Microsoft routers responding to the packets from the other routers and sending them out again. With 4 of these routers it manages to generate 20,000+ packets before all of the TTL's drop to 0. Needless to say this results in a little bit of a performance hit. I have blocked Multicast at several points on the network so the problem should be gone for now. The tcpdump file is at http://www.amplex.net/images/multicast.cap Mark Radabaugh Amplex
