Options
Multicast Issues/Configuration
peanutnoggin
Member Posts: 1,096 ■■■□□□□□□□
in CCNP
TE,
[DISCLAIMER]I'm not really familiar with the configuration of multicast and I know there is a lot to learn about multicast!![/DISCLAIMER]
I have a general idea of what multicast can do/does. I setup multicast on my CME to get my music on hold to work. I did not configure any other aspect of my router/switch to deal with multicast.
After applying this config... all worked well. I then noticed my trunk link between my CME router and my switch had an unreal amount of activity (blinking lights). All of the lights on my switch that were configured for VoIP phones blinked at an alarming rate. I first thought that I had a spanning-tree loop/broadcast storm... I looked at the cpu utilization and it was very minimal on both the switch and the router... this prompted me to run wireshark on a SPAN port... sure enough, I noticed I was receiving multiple multicast packets every second. Once I negated the multicast command, my switch returned to its normal activity on each port.
I said all that to lead into my questions...
1) Is this normal for multicast?
2) Is there a multicast best design practice?
3) Is multicast a topic in the BSCI/ROUTE path, CCVP subject or what?
4) I'm eager to gain some more knowledge about multicast... does anyone have a book/video they recommend for learning about multicast?
Thanks in advanced.
-Peanut
[DISCLAIMER]I'm not really familiar with the configuration of multicast and I know there is a lot to learn about multicast!![/DISCLAIMER]
I have a general idea of what multicast can do/does. I setup multicast on my CME to get my music on hold to work. I did not configure any other aspect of my router/switch to deal with multicast.
moh music-on-hold.au multicast moh 239.1.1.100 port 2000
After applying this config... all worked well. I then noticed my trunk link between my CME router and my switch had an unreal amount of activity (blinking lights). All of the lights on my switch that were configured for VoIP phones blinked at an alarming rate. I first thought that I had a spanning-tree loop/broadcast storm... I looked at the cpu utilization and it was very minimal on both the switch and the router... this prompted me to run wireshark on a SPAN port... sure enough, I noticed I was receiving multiple multicast packets every second. Once I negated the multicast command, my switch returned to its normal activity on each port.
I said all that to lead into my questions...
1) Is this normal for multicast?
2) Is there a multicast best design practice?
3) Is multicast a topic in the BSCI/ROUTE path, CCVP subject or what?
4) I'm eager to gain some more knowledge about multicast... does anyone have a book/video they recommend for learning about multicast?
Thanks in advanced.
-Peanut
We cannot have a superior democracy with an inferior education system!
-Mayor Cory Booker
-Mayor Cory Booker
Comments
-
Options
Ryan82
Member Posts: 428
Deploying IP Multicast Networks is generally regarded as the definitive text on multicast. Multicast is also in the BSCI curriculum but appears to be removed from the new ROUTE exam. The BSCI multicast coverage will get your feet wet, but the coverage in the text isn't that thorough. Which is unfortunate because the exam coverage is surprisingly heavy.
I don't know anything about the voice world, but as far as multicast in general, depending on which model you choose sparse or dense mode determines how multicast traffic will behave. In dense mode you would have an initial flooding of multicast being sent out all links and then it would start pruning off links if there are no users subscribing to that multicast group residing on that link (in your case 239.1.1.100). This is known as a push method.
In sparse mode it uses a pull method where a central reference known as a rendezvous point will announce that it is the address that subscribers will point to in the event that they want to subscribe to a particular multicast group. Once the rendezvous point receives a join message it knows where to point to the actual source of multicast traffic.
Also, unless your switch is configured to recognize multicast traffic through the use of igmp snooping (industry standard) or cgmp (cisco proprietary) it will treat all of that multicast traffic as a broadcast. What may be happening (and this is a wild guess because I have no idea how the music on hold stuff works), is that it is continually sending multicast moh traffic which is being treated as broadcast traffic by your switch.
I hope my explanations make sense, I am certainly no expert myself.
-
Optionspeanutnoggin
Member Posts: 1,096 ■■■□□□□□□□
Ryan... Thank you. I definitely believe my switch was handling the multicast traffic as if it was broadcast traffic. Thank you for the write up. I have the BSCI book at home and I'll be taking a look at the multicast stuff to see if I can understand a little more of it. I greatly appreciate your response. Take care.
-PeanutWe cannot have a superior democracy with an inferior education system!
-Mayor Cory Booker