[c-nsp] Enabling multicast routing on 3750G platform

Blake Dunlap ikiris at gmail.com
Fri Jan 30 13:32:41 EST 2015 

It's mostly used for clients that either are ignorant of igmp, or do
it poorly, along with for troubleshooting and a few weird edge cases.
It shouldn't be needed normally.

-Blake

On Fri, Jan 30, 2015 at 6:19 AM, Matthew Huff <mhuff at ox.com> wrote:
> Use igmp-join if you want the router itself to be a member of the multicast group. You don't need it if you are routing multicast through the router. It's rarely used and only for very specific circumstances, for example if a servers fails if there isn't at least one client joining, etc...
>
>
>
> ----
> Matthew Huff             | 1 Manhattanville Rd
> Director of Operations   | Purchase, NY 10577
> OTA Management LLC       | Phone: 914-460-4039
> aim: matthewbhuff        | Fax:   914-694-5669
>
> -----Original Message-----
> From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Lobo
> Sent: Thursday, January 29, 2015 9:00 PM
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Enabling multicast routing on 3750G platform
>
> Problem solved!
>
> You guys were right about VLC and its TTL.  Turns out there's a bug in the
> program where changing the TTL in the GUI doesn't affect streaming for some
> reason.  I added a ttl=30 to the string and the stream started flowing to
> the secondary port.  I even changed things back to vlans and it routed
> perfectly fine.
>
> I have a question about one comment that was made regarding the igmp-join
> command.  In all the documentation I've read, it says to put that command
> on the interfaces that plan on receiving the stream(s).  Some comments
> suggested removing it or not needing it and with my own testing it clearly
> works fine even without this command.  Why is that?
>
> This is the final show ip mroute:
>
> Switch#sh ip mroute
> IP Multicast Routing Table
> Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
>        L - Local, P - Pruned, R - RP-bit set, F - Register flag,
>        T - SPT-bit set, J - Join SPT, M - MSDP created entry,
>        X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
>        U - URD, I - Received Source Specific Host Report,
>        Z - Multicast Tunnel, z - MDT-data group sender,
>        Y - Joined MDT-data group, y - Sending to MDT-data group
>        V - RD & Vector, v - Vector
> Outgoing interface flags: H - Hardware switched, A - Assert winner
>  Timers: Uptime/Expires
>  Interface state: Interface, Next-Hop or VCD, State/Mode
>
> (*, 239.255.255.250), 02:45:34/00:02:34, RP 3.3.3.3, flags: SJC
>   Incoming interface: Null, RPF nbr 0.0.0.0
>   Outgoing interface list:
>     Vlan100, Forward/Sparse, 00:00:38/00:02:34
>     Vlan200, Forward/Sparse, 02:42:59/00:02:32
>
> (*, 239.0.0.1), 02:45:35/stopped, RP 3.3.3.3, flags: SJC
>   Incoming interface: Null, RPF nbr 0.0.0.0
>   Outgoing interface list:
>     Vlan200, Forward/Sparse, 02:42:15/00:02:33
>
> (1.1.1.1, 239.0.0.1), 00:00:40/00:02:58, flags: JT
>   Incoming interface: Vlan100, RPF nbr 0.0.0.0
>   Outgoing interface list:
>     Vlan200, Forward/Sparse, 00:00:40/00:02:33
>
> (*, 224.0.1.40), 02:45:35/00:02:28, RP 3.3.3.3, flags: SJCL
>   Incoming interface: Null, RPF nbr 0.0.0.0
>   Outgoing interface list:
>     Loopback0, Forward/Sparse, 02:45:36/00:02:27
>
> Switch#
>
>
> Thanks again for the tips everyone!
>
> Jose
>
> On Thu, Jan 29, 2015 at 7:23 AM, Adam Vitkovsky <avitkovsky at gammatelecom.com
>> wrote:
>
>> Hi Lobo,
>>
>> Ok so the SW is indeed a DR on port GigabitEthernet1/0/1 and it's
>> obviously receiving some stream in which case it should create an (s,g)
>> state and send a register msg to the RP and RP should update its group
>> cache (all should be done internally since the DR=RP).
>> However none of this is happening most likely because the switch doesn't
>> like something about the stream (destination mac address, ttl, som security
>> feature,..).
>> Can you do: debug ip pim
>> -to see if it shows why the switch ignores the incoming stream.
>> -or some other techniques to see why the incoming multicast frames are
>> being dropped silently.
>>
>>
>> adam
>> > -----Original Message-----
>> > From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
>> > Lobo
>> > Sent: 29 January 2015 00:57
>> > To: cisco-nsp at puck.nether.net
>> > Subject: Re: [c-nsp] Enabling multicast routing on 3750G platform
>> >
>> > I've moved the configuration on the switch so that the ports are routed
>> now
>> > instead of using vlans but still no go.
>> >
>> > Here is the output from a show ip mroute:
>> >
>> > Switch#sh ip mroute
>> > IP Multicast Routing Table
>> > Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C -
>> Connected,
>> > L - Local, P - Pruned, R - RP-bit set, F - Register flag,
>> > T - SPT-bit set, J - Join SPT, M - MSDP created entry,
>> > X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
>> > U - URD, I - Received Source Specific Host Report,
>> > Z - Multicast Tunnel, z - MDT-data group sender,
>> > Y - Joined MDT-data group, y - Sending to MDT-data group
>> > V - RD & Vector, v - Vector
>> > Outgoing interface flags: H - Hardware switched, A - Assert winner
>> > Timers: Uptime/Expires
>> > Interface state: Interface, Next-Hop or VCD, State/Mode
>> >
>> > (*, 239.255.255.250), 00:01:03/00:02:56, RP 3.3.3.3, flags: SJC
>> > Incoming interface: Null, RPF nbr 0.0.0.0
>> > Outgoing interface list:
>> > GigabitEthernet1/0/2, Forward/Sparse, 00:01:03/00:02:06
>> > GigabitEthernet1/0/1, Forward/Sparse, 00:01:03/00:02:56
>> >
>> > (*, 239.0.0.1), 00:01:22/00:02:56, RP 3.3.3.3, flags: SJCL
>> > Incoming interface: Null, RPF nbr 0.0.0.0
>> > Outgoing interface list:
>> > GigabitEthernet1/0/2, Forward/Sparse, 00:01:23/00:02:56
>> >
>> > (*, 224.0.1.40), 00:01:23/00:02:08, RP 3.3.3.3, flags: SJCL
>> > Incoming interface: Null, RPF nbr 0.0.0.0
>> > Outgoing interface list:
>> > Loopback0, Forward/Sparse, 00:01:23/00:02:08
>> >
>> > Switch#
>> >
>> > Switch#sh ip pim interface
>> >
>> > Address Interface Ver/ Nbr Query DR DR
>> > Mode Count Intvl Prior
>> > 3.3.3.3 Loopback0 v2/S 0 30 1
>> > 3.3.3.3
>> > 1.1.1.2 GigabitEthernet1/0/1 v2/S 0 30 1
>> > 1.1.1.2
>> > 2.2.2.2 GigabitEthernet1/0/2 v2/S 0 30 1
>> > 2.2.2.2
>> > Switch#
>> >
>> > The traffic is still coming in on port 1:
>> >
>> > Switch#sh int g1/0/1
>> > GigabitEthernet1/0/1 is up, line protocol is up (connected)
>> > Hardware is Gigabit Ethernet, address is 0018.73bf.12c1 (bia
>> > 0018.73bf.12c1)
>> > Internet address is 1.1.1.2/24
>> > MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
>> > reliability 255/255, txload 1/255, rxload 12/255
>> > Encapsulation ARPA, loopback not set
>> > Keepalive set (10 sec)
>> > Full-duplex, 100Mb/s, media type is 10/100/1000BaseTX
>> > <snip>
>> > 30 second input rate 4822000 bits/sec, 444 packets/sec
>> > 30 second output rate 0 bits/sec, 0 packets/sec
>> >
>> > but not exiting on port 2
>> >
>> > Switch#sh int g1/0/2
>> > GigabitEthernet1/0/2 is up, line protocol is up (connected)
>> > Hardware is Gigabit Ethernet, address is 0018.73bf.12c2 (bia
>> > 0018.73bf.12c2)
>> > Internet address is 2.2.2.2/24
>> > MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
>> > reliability 255/255, txload 1/255, rxload 1/255
>> > Encapsulation ARPA, loopback not set
>> > Keepalive set (10 sec)
>> > Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX
>> > <snip>
>> > 30 second input rate 4000 bits/sec, 6 packets/sec
>> > 30 second output rate 1000 bits/sec, 1 packets/sec
>> >
>> > I've changed the TTL on VLC to 10 and I've also changed things to
>> > sparse-mode and put it on the loopback as well.
>> >
>> > Any other suggestions?
>> >
>> > !
>> > interface Loopback0
>> > ip address 3.3.3.3 255.255.255.255
>> > ip pim sparse-mode
>> > !
>> > interface GigabitEthernet1/0/1
>> > no switchport
>> > ip address 1.1.1.2 255.255.255.0
>> > ip pim sparse-mode
>> > load-interval 30
>> > spanning-tree portfast
>> > !
>> > interface GigabitEthernet1/0/2
>> > no switchport
>> > ip address 2.2.2.2 255.255.255.0
>> > ip pim sparse-mode
>> > ip igmp join-group 239.0.0.1
>> > load-interval 30
>> > spanning-tree portfast
>> > !
>> > ip routing
>> > no ip domain-lookup
>> > !
>> > !
>> > ip multicast-routing distributed
>> > !
>> > !
>> > ip pim rp-address 3.3.3.3
>> > !
>> >
>> > Jose
>> >
>> > On Wed, Jan 28, 2015 at 4:43 PM, Lobo <lobotiger at gmail.com> wrote:
>> >
>> > > Thanks for the replies. I'll post a show mroute and tweak the VLC
>> > > parameters once I get access to the device tonight. BTW, all of this
>> > > testing is just on a single switch so no other topology exists.
>> > >
>> > > Jose
>> > >
>> > > On Wed, Jan 28, 2015 at 12:55 PM, Adrian Minta
>> > <adrian.minta at gmail.com>
>> > > wrote:
>> > >
>> > >> Hi,
>> > >> look for the stream TTL.
>> > >>
>> > >> On 28.01.2015 19:37, Lobo wrote:
>> > >>
>> > >>> Hi everyone. I've been trying to get multicast routing to work on a
>> > >>> single
>> > >>> 3750G switch between two vlans but for the life of me it just doesn't
>> > >>> work. When the host and receiver are on a single vlan the streaming
>> > >>> works
>> > >>> ....
>> > >>> The server streaming via VLC is 1.1.1.1 and is using 239.0.0.1 for
>> the
>> > >>> multicast address. The receiver is 2.2.2.1 and using VLC to stream. I
>> > >>> can
>> > >>> see the traffic coming in on port 1 but no traffic leaving the
>> switch's
>> > >>> other port.
>> > >>>
>> > >>> BTW, I tried dense-mode and sparse-mode as well with similar results.
>> > >>>
>> > >>> Any thoughts?
>> > >>>
>> > >>> Jose
>> > >>>
>> > >>>
>> > >> --
>> > >> Best regards,
>> > >> Adrian Minta
>> > >>
>> > >>
>> > >>
>> > >> _______________________________________________
>> > >> cisco-nsp mailing list cisco-nsp at puck.nether.net
>> > >> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> > >> archive at http://puck.nether.net/pipermail/cisco-nsp/
>> > >>
>> > >
>> > >
>> > _______________________________________________
>> > cisco-nsp mailing list cisco-nsp at puck.nether.net
>> > https://puck.nether.net/mailman/listinfo/cisco-nsp
>> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>
>> ------------------------------
>> This email has been scanned for email related threats and delivered safely
>> by Mimecast.
>> For more information please visit http://www.mimecast.com
>> ------------------------------
>>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

More information about the cisco-nsp mailing list