Multicast Boundary Filtering

If you want to filter multicast traffic, you have a couple of options. One of them is setting the TTL when you configure PIM Auto RP. This limits your Auto RP traffic for a number of hops, but it’s difficult to use this to filter traffic in your entire topology. Another option is using access-lists which does the job, but what if you want to filter multicast traffic from certain sources?

That’s something we can do with the multicast boundary command that we are going to cover in this lesson. We can also use this to filter group information from Auto RP messages.

Configuration

Here is the topology we use:

We have three routers running OSPF and PIM sparse mode. R1 advertises its loopback interface (1.1.1.1) as the RP.

hostname R1
!
ip multicast-routing 
ip cef
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
 ip pim sparse-mode
!
interface GigabitEthernet0/1
 ip address 192.168.12.1 255.255.255.0
 ip pim sparse-mode
!
router ospf 1
 network 1.1.1.1 0.0.0.0 area 0
 network 192.168.12.0 0.0.0.255 area 0
!
ip pim send-rp-announce Loopback0 scope 10 group-list MULTICAST
ip pim send-rp-discovery Loopback0 scope 10
!
ip access-list standard MULTICAST
 permit 239.3.3.3
 permit 239.2.2.2
 permit 239.1.1.1
!
end

hostname R2
!
ip multicast-routing 
ip cef
!
interface GigabitEthernet0/1
 ip address 192.168.12.2 255.255.255.0
 ip pim sparse-mode
!
interface GigabitEthernet0/2
 ip address 192.168.23.2 255.255.255.0
 ip pim sparse-mode
!
router ospf 1
 network 192.168.12.0 0.0.0.255 area 0
 network 192.168.23.0 0.0.0.255 area 0
!
ip pim autorp listener
!
end

hostname R3
!
ip multicast-routing 
ip cef
!
interface GigabitEthernet0/1
 ip address 192.168.23.3 255.255.255.0
 ip pim sparse-mode
 ip igmp join-group 239.3.3.3
 ip igmp join-group 239.2.2.2
 ip igmp join-group 239.1.1.1
!
router ospf 1
 network 192.168.23.0 0.0.0.255 area 0
!
end

These three routers are pre-configured with PIM sparse mode. R1 is our RP for three multicast groups:

• 239.1.1.1
• 239.2.2.2
• 239.3.3.3

R3 has learned about these three multicast groups through Auto RP:

R3#show ip pim rp mapping 
PIM Group-to-RP Mappings

Group(s) 239.1.1.1/32
  RP 1.1.1.1 (?), v2v1
    Info source: 1.1.1.1 (?), elected via Auto-RP
         Uptime: 00:06:34, expires: 00:02:02
Group(s) 239.2.2.2/32
  RP 1.1.1.1 (?), v2v1
    Info source: 1.1.1.1 (?), elected via Auto-RP
         Uptime: 00:06:52, expires: 00:02:45
Group(s) 239.3.3.3/32
  RP 1.1.1.1 (?), v2v1
    Info source: 1.1.1.1 (?), elected via Auto-RP
         Uptime: 00:07:10, expires: 00:02:28

Let’s configure R3 to join all three multicast groups:

R3(config)#interface GigabitEthernet 0/1
R3(config-if)#ip igmp join-group 239.1.1.1
R3(config-if)#ip igmp join-group 239.2.2.2
R3(config-if)#ip igmp join-group 239.3.3.3

Right now, all multicast traffic is permitted. Let’s try a quick ping to 239.3.3.3 to see if R3 responds:

R1#ping 239.3.3.3
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.3.3.3, timeout is 2 seconds:

Reply to request 0 from 192.168.23.3, 68 ms

It does, so far so good. Let’s see if we can filter this with the multicast boundary command:

R2(config)#interface GigabitEthernet 0/2
R2(config-if)#ip multicast boundary ?
  <1-99>         Standard IP access-list number
  <100-199>      Extended IP access-list number
  <1300-1999>    Standard IP access-list number (expanded range)
  <2000-2699>    Extended IP access-list number (expanded range)
  WORD           IP Named Access list
  filter-autorp  Filter AutoRP packet contents
  in             Restrict (s,g) creation when this interface is the RPF
  out            Restrict interface addition to outgoing list

There are a bunch of options. We can choose between standard or extended access-lists, inbound or outbound traffic, and there’s an option to filter Auto RP packet contents. Let’s see if we can prevent certain multicast traffic from reaching R3.

Standard Access-List

Let’s keep it simple for now and use a standard access-list. I want to make sure that R3 is only able to receive traffic for multicast groups 239.1.1.1 and 239.2.2.2. The third group, 239.3.3.3 should be denied. Let’s create a standard access-list:

R2(config)#ip access-list standard MULTICAST_FILTER
R2(config-std-nacl)#permit 239.1.1.1
R2(config-std-nacl)#permit 239.2.2.2

And apply it to the interface on R2 that connects to R3:

R2(config)#interface GigabitEthernet 0/2
R2(config-if)#ip multicast boundary MULTICAST_FILTER out

Let’s try some more pings:

R1#ping 239.3.3.3
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.3.3.3, timeout is 2 seconds:
.

As expected, pings to 239.3.3.3 now fail. Let’s try the other two multicast groups:

R1#ping 239.1.1.1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
.

R1#ping 239.2.2.2
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.2.2.2, timeout is 2 seconds:
.

These also fail…why? You need to keep in mind we are using Auto RP which uses multicast group 224.0.1.40. The multicast boundary command applies to all multicast traffic so we’ll need to permit this traffic.

Here’s the multicast routing table of R3:

R3#show ip mroute | begin 224.0.1.40
(*, 224.0.1.40), 00:02:20/00:02:40, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet0/1, Forward/Sparse, 00:02:20/00:02:40

R3 only has a *,G entry for 224.0.1.40 and isn’t receiving anything. Let’s update our access-list:

R2(config)#ip access-list standard MULTICAST_FILTER
R2(config-std-nacl)#permit 224.0.1.40

R3 is now able to receive traffic to 224.0.1.40:

R3#show ip mroute | begin 224.0.1.40
(*, 224.0.1.40), 00:04:17/stopped, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet0/1, Forward/Sparse, 00:04:17/00:02:39

(1.1.1.1, 224.0.1.40), 00:00:20/00:02:39, flags: PLTX
  Incoming interface: GigabitEthernet0/1, RPF nbr 192.168.23.2
  Outgoing interface list: Null

Let’s try those pings again:

R1#ping 239.1.1.1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Reply to request 0 from 192.168.23.3, 82 ms

R1#ping 239.2.2.2
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.2.2.2, timeout is 2 seconds:

Reply to request 0 from 192.168.23.3, 82 ms

R1#ping 239.3.3.3
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.3.3.3, timeout is 2 seconds:
.

Now it is working as expected. Traffic to 239.1.1.1 and 239.2.2.2 is permitted, 239.3.3.3 is denied.

Extended Access-List

What about the extended access-list? The standard access-list lets you filter multicast group addresses, but with an extended access-list, you can also include the source.

Let’s see how this works. Right now, R3 has entries in the multicast routing table that look like this:

R3#show ip mroute 224.0.1.40

(*, 224.0.1.40), 00:00:58/stopped, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet0/1, Forward/Sparse, 00:00:58/00:02:35

(1.1.1.1, 224.0.1.40), 00:00:47/00:02:12, flags: PLTX
  Incoming interface: GigabitEthernet0/1, RPF nbr 192.168.23.2
  Outgoing interface list: Null

R3#show ip mroute 239.1.1.1

(*, 239.1.1.1), 00:00:25/stopped, RP 1.1.1.1, flags: SJPCL
  Incoming interface: GigabitEthernet0/1, RPF nbr 192.168.23.2
  Outgoing interface list: Null

(1.1.1.1, 239.1.1.1), 00:00:19/00:02:40, flags: PLTX
  Incoming interface: GigabitEthernet0/1, RPF nbr 192.168.23.2
  Outgoing interface list: Null

Let’s say we only want to receive Auto RP traffic and other multicast groups from our current RP, R1 with source 1.1.1.1.