Nortel Multicast Hammer 2.1 __EXCLUSIVE_

This is not meant to be a definitive guide to multicast. There are more detailed documents and white papers from Cisco and others on this subject. This is just an attempt to give a basic understanding and encourage you to learn more about this subject.

I work for a wireless communications vendor that uses multicasts as an integral part of the product. I have been onsite and on conference calls with customers trying to troubleshoot multicast issues. The issue almost always turns out that multicast packets are being blocked somewhere on the network. There seems to be a lot of confusion about what happens to multicast packets and how to prevent them from being blocked on your network. This blog will try to explain the paths the multicast packets take on the wireless and wired network.

Nortel Multicast Hammer 2.1 Download

Download Zip 🔥 https://tlniurl.com/2y7ZiZ 🔥

The topics I will cover in this blog are multicast packets on a controller-based network, configuring multicast on a Cisco Controller, IGMP snooping on the controller, troubleshooting multicast issues, troubleshooting using Multicast Hammer, Cisco commands and some links to blogs and articles I found helpful.

Multicast Group ID (MGID) is created by the controller and passed to each AP. The MGID is the ID number which maps multicast source, the multicast address and the VLAN. This helps the controller and APs to keep track of multicast groups.

There are two modes you can use on your controller; Multicast-Unicast and Multicast-Multicast. If you use Multicast-Unicast, then the controllers will make a copy of every multicast packet and sends these packets out as unicast packets to every AP. This would work OK for a smaller network but in a larger network, this would create too much traffic. In larger networks Multicast-Multicast mode is much more efficient use of bandwidth.

When an AP connects to a controller, the controller will tell the AP to join this multicast address you have chosen. All the APs will send a join message to this multicast address. When the controller receives a multicast packet it sends out one packet and all the APs who have joined the multicast group will receive this packet. Multicast can be best described as one to many, where unicast is described as one to one.

When the wireless client sends an IGMP join message to the AP, the AP sends this join message through the CAPWAP tunnel to the controller. The controller absorbs this join message and sends a new join message to the local router on the VLAN of the client using its own IP address (not the IP address of the client). The router then adds this multicast group to the interface creating a (*,G) entry.

When multicast packets are sent from a wireless client, the wireless client sends the packets to the AP as unicast packets to the multicast address. The AP then sends these unicast packets through the CAPWAP tunnel to the controller. The controller then makes two copies. One copy is sent out to the locally connected LAN where the router will forward these packets to the RP. The second copy the controller encapsulates in its multicast address and sends these multicast packets to all the APs on that controller. The AP strips the controller multicast address and sees the original multicast address. The AP checks its MGID table to see if it has a client for this multicast address If the AP has no clients that have subscribed to the multicast then the AP drops the packets. If the AP has clients that have subscribed to the Multicast address, then the AP sets the AID of that client in the DTIM section of the beacon. The AP then sends the packets down to the client immediately after the beacon.

Most multicast issues are caused by not having PIM set up correctly on your network. Two ways you can troubleshoot this are; 1) check all the VLANs where the multicast traffic will traverse or 2.) check to see if the join messages are being recorded on your router and switches (if you have snooping enabled).

Protocol-Independent Multicast (PIM) needs to be enabled or set on all your VLANs where multicast traffic will traverse. The VLANs you need to enable it on are the management VLAN, AP management VLAN (if different from the management VLAN), AP VLAN, the VLAN of the sending device and the VLAN of the receiving device. The management VLANs are very important since the controller sends multicast packets to the APs using either the management VLAN, AP management VLAN or the AP VLAN. These VLANs are often overlooked. Checking all the interfaces and VLANs where traffic will traverse always seems to cause Network Admin the most trouble. They usually ask me to list out all the interfaces where PIM needs to be enabled. This is difficult for them but impossible for an outsider with no direct knowledge or access to their network. We always recommend opening a case with Cisco (or your wireless vendor) to help find all the VLANs and interfaces where the multicast traffic may traverse.

Another common issue is multicast packets getting stuck at the core. If the multicast packets are flowing over the core, make sure the VLAN the EtherChannel/Port Channel have PIM enabled on them. I have seen issues where one EtherChannel had PIM enabled the other EtherChannel did not. This caused one multicast session to work and the next multicast session to fail.

After checking the VLANS for PIM and checking to see if the messages are traversing your network you should check other settings including DTIM, TKIP, RP, IGMP snooping, multicast buffering and roaming.

DTIM should be set to 1 especially if you are using multicast for voice. You can check this either on the GUI of the controller, in the controller config file or a wireless capture. The DTIM will be in the beacons of the wireless capture under the Traffic Indication Map. If DTIM count is set to 0 then you are seeing a DTIM beacon if the DTIM period is set to 1 then the next beacon will also be a DTIM beacon (see below).

We all know TKIP has been deprecated but you may still have it lingering on your network, if you have TKIP and AES on the same SSID this will cause issues with multicast. You can check this either on the GUI of the controller, the controller config file or you can look at the beacons in a wireless capture. The capture below shows AES in the Pairwise Cipher suite list. If TKIP was enabled, you would see it in the same section.

Multiple Rendezvous Points (RP) can cause issues with multicast if you have devices on multiple VLANs and each VLAN is directing you to different RPs. This will cause your devices on one VLAN to get the multicast traffic and the other devices on a different VLAN will never get the multicast traffic. If you have two RPs, they must communicate and update each other or better yet have one RP for the entire network.

If you are having issue with delivery of multicast packets you should verify you have IGMP snooping set on your switches. To verify if IGMP snooping is enabled on the switch run the command show ip igmp snooping

Multicast Hammer is a free tool that can help you troubleshoot multicast issues. You can download Multicast Hammer installer and setup instructions from the internet. It is a simple program to use and install that was created by Nortel (maybe the only thing left of Nortel in use these days). Multicast Hammer simulates multicast traffic on your network. It is a valuable tool that will remove questions about certain applications and show you raw multicast traffic (or lack of it) on your network. You should run MC Hammer on two machines that are on the same WLAN. Set one up as a server and one as a client. Run the test to see if data is flowing between machines. Once you see data you should move one of the machines to another network and retest. This will help you find out where multicast traffic is being blocked.

The set-up is rather simple. You want to make sure you have the server radio button selected, choose your network interface, and then choose an available Multicast address (not the MC address on your controller). After you hit start on the server and client you will see data flowing. If you only see the data on the server then you know multicast traffic is being blocked somewhere on your network.

The set-up is rather simple. You want to make sure you have the Client radio button selected, choose your network interface and then choose the same Multicast address as you chose in the server side of the application. After you hit start on the server and client you will see data flowing. If you only see the data on the server then you know multicast traffic is being blocked somewhere on your network.

Test and validate unicast and multicast configurations on your network with Multicast Hammer: an easy to use, Java-based testing tool. Since a multicast server does not typically know anything about the clients that it is sending traffic to, tracing or troubleshooting an issue in a multicast environment can be very challenging. Nortel IT created Multicast Hammer to help overcome these limitations, and has used it as a testing tool for trials of multicast products.

I know it is a little late for an answer but for anyone that may stumble upon this thread later. Nortel made a tool called multicast hammer (or MC Hammer). It works extremely well for testing multicast. It might be a little hard to find with the state of Nortel but it is worth looking for.

After multicast has been configured on the network, one of the biggest challenges tends to involve actually testing multicast functionality in between two Windows machines (physical or VMs) connected via the network.

The bitcontrol Multicast Server is a software to stream the MPEG-2 video data of different set top boxes as multicast over the local network. By this procedure the aquirement of additional receivers and the laying of the required infrastructure (antenna cable) is avoided.

Multicast Messenger provide a messenger for conference in local area network using multicast technology. Multicast Messenger is a useful tool which integrates a friendly graphical user interface and allows you to quickly access your local area network. 006ab0faaa