Multicast routing on the 3750 with IP Base

So I wanted to use multicast with a 3750 that’s running IP Base. From previous experience I know I can’t just set up ip pim sparse-dense-mode on a VLAN interface if you’re running IP Base – you need IP Services for that.

PIM SDM is supported on a routed interface (using no switchport) but this is a pretty cumbersome way to use multicast. I guess it would be okay if you have a single physical server, and you can give it a dedicated IP subnet but most environments just aren’t designed that way – there’s no way this would work if you wanted your multicast source to be a VM!

Nonetheless, here’s how you’d go about it:
ip routing
ip multicast-routing
!
interface GigabitEthernet1/0/1
description Dedicated Interface to the Multicast Source
no switchport
ip address 10.10.10.10 255.255.255.0
ip pim sparse-dense-mode

Then you configure your server to use an IP in the 10.10.10.0/24 network, and start the multicast stream.

The documentation stated that the 3750 only supports PIM stub routing, but the Software Advisor Tool says that PIMv2 is indeed supported. I found that pretty confusing so I asked my SE, and he confirmed that PIM stub routing is supported. Now I’m not a multicast expert, but I didn’t even know if this meant it would work!

So the answer was to try. I built a lab with a 3750 and configured it to support multicast and used the only PIM framework available, pim passive like this:
ip routing
ip multicast-routing
!
interface Vlan10
description Client VLAN
ip pim passive
!
interface Vlan20
description Server VLAN
ip pim passive

I used iperf to generate and receive the multicast streams. Generate a stream from VLAN 20:
iperf -c 224.0.55.55 -u -T 32 -t 3600 -i 1
Receive the stream on VLAN 10:
iperf -s -u -B 224.0.55.55 -i 1

You can use show ip mroute to review the current multicast senders and receivers, and clear ip mroute * to refresh the table. I found myself doing this a few times, and also restarting the iperf server/client devices to make sure that I was seeing up-to-date information.

And it worked, but then to my dismay I found that anybody in either VLAN could spark up a new multicast stream and share it. This is probably okay because I’ve not heard of multicast being used in a malicious way before, but that could be because it isn’t widely deployed. In the interest of security, I decided that I had better lock this down so only the server VLAN could initiate a multicast stream, and I found that this worked:
ip routing
ip multicast-routing
!
ip access-list extended acl-allow-igmp-receive
permit igmp any any
!
ip access-list extended acl-block-igmp-source
deny ip any 224.0.0.0 15.255.255.255
permit ip any any
!
interface Vlan10
description Client VLAN
ip access-group acl-block-igmp-source in
ip pim passive
ip igmp access-group acl-allow-igmp-receive
!
interface Vlan20
description Server VLAN
ip pim passive

In this case the ACL acl-allow-igmp-receive allows multicast clients to receive ALL multicast streams, and the ACL acl-block-igmp-source blocks those clients from initiating streams of their own. Both ACLs are required to to allow the clients to receive but not send multicast.

Advertisement