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 188.8.131.52 -u -T 32 -t 3600 -i 1
Receive the stream on VLAN 10:
iperf -s -u -B 184.108.40.206 -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 220.127.116.11 18.104.22.168 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.