Multicast stub routing can be used for remote sites that are connected to the main site using low bandwidth links. When you use PIM dense mode these links might become overburdened with multicast traffic because of the flood and prune behavior of PIM dense mode. PIM sparse mode can also utilize the link because of rendezvous point announcements. The remote router has to accept RP discovery messages, build the RP cache and maintain states in the multicast routing table for all its local receivers.
When we configure a router as “multicast stub” then it will not process any PIM or IGMP messages. Instead, it will forward all these messages to the router on the main site. Let me give you an example topology:
Above we have a small network with 4 routers. R1 and R2 are on the “remote office,” and R3 and R4 are on the “main site”. Between R2 and R3 is a WAN serial link with limited capacity.
We will configure this network so that R1 is the receiver, R4 is the source and R2 will become our multicast stub router. Let’s get started!
R1,R2,R3,R4: (config)#router ospf 1 (config-router)#network 0.0.0.0 255.255.255.255 area 0
Let’s enable multicast routing on all routers:
R1,R2,R3,R4: (config)#ip multicast-routing
Now we will configure R3, the router on the “main site”…
R3(config)#ip pim rp-address 192.168.23.3 R3(config)#interface serial 0/0 R3(config-if)#ip pim sparse-mode R3(config-if)#ip pim neighbor-filter 1 R3(config-if)#interface fastethernet0/0 R3(config-if)#ip pim sparse-mode
R3(config)#access-list 1 deny host 192.168.23.2 R3(config)#access 1 permit any
I will configure R3 as the RP. We have to enable PIM on the serial0/0 interface because our router won’t forward multicast traffic out of a non-PIM-enabled interface. We don’t want R2 and R3 to become PIM neighbors because this would allow R2 to prune multicast traffic using PIM. Let’s configure R2 now:
R2(config)#interface fastEthernet 0/0 R2(config-if)#ip igmp helper-address 192.168.23.3 R2(config-if)#ip pim dense-mode R2(config-if)#exit R2(config)#interface serial0/0 R2(config-if)#ip pim dense-mode
igmp helper-address command is used to forward all IGMP traffic toward R3 instead of dealing with it ourselves. We will use PIM dense mode because it allows the router to flood ANY multicast traffic that we receive from R2 toward our clients.
Now let’s configure R1 as the receiver and R4 to send some multicast packets to see if our configuration works:
R1(config)#interface fastEthernet 0/0 R1(config-if)#ip igmp join-group 18.104.22.168
As soon as we join the group, you will see this on R3:
R3#show ip igmp groups 22.214.171.124 IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter Group Accounted 126.96.36.199 Serial0/0 00:00:20 00:02:39 192.168.23.2
The IGMP join has been forwarded from R2 toward R3. Now let’s send some traffic:
R4#ping 188.8.131.52 repeat 9999 Type escape sequence to abort. Sending 9999, 100-byte ICMP Echos to 184.108.40.206, timeout is 2 seconds: Reply to request 0 from 192.168.12.1, 4 ms Reply to request 1 from 192.168.12.1, 16 ms Reply to request 2 from 192.168.12.1, 4 ms
Our pings are working. Now let’s check the multicast routing table of R2 and R3:
why do you use IP PIM dens-mode in R2 ?
I did it to keep the stub router configuration simple, it will just forward anything.
I need to route multicast traffic on a Catalyst 3560 Layer 3 switch. Connected to the Layer 3 switch is connected Layer 2 switch which are connected to an Apple TV and wireless access points. I need the apple tv can route multicast traffic between different vlans. On a switch running the IP base image. The IP base image contains only PIM stub routing.
Please excuse my English.
thank you very much
The last time I worked with the Apple TV it was impossible to route between different VLANs because the Bonjour protocol uses a TTL of 1. Just to be sure, run Wireshark and check if it’s still the case.
If so…your only option is to have the Apple TV and the clients within the same VLAN.
A possible work around to this could be to unicast or broadcast the traffic and use a multicast helper to push the traffic to different layer 3 addresses.
Here is more info on how I implemented a broadcast to multicast solution, i had to do it both ways: