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.

Want to take a look for yourself? Here you will find the startup configuration of each device.

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.

I’ll need to create a couple of entries then:

• One permit statement that allows Auto RP multicast traffic from 1.1.1.1 to 224.0.1.40.
• One permit statement that allows *,G multicast traffic for a group.
• One permit statement that allows S,G multicast traffic for a group.

I will create an access-list that permits Auto RP traffic, and that permits multicast traffic to 239.1.1.1 and 239.2.2.2 but only from source 1.1.1.1:

R2(config)#ip access-list extended R1_L0_MULTICAST_FILTER
R2(config-ext-nacl)#permit ip host 1.1.1.1 host 224.0.1.40
R2(config-ext-nacl)#permit ip host 0.0.0.0 host 239.1.1.1
R2(config-ext-nacl)#permit ip host 1.1.1.1 host 239.1.1.1
R2(config-ext-nacl)#permit ip host 0.0.0.0 host 239.2.2.2
R2(config-ext-nacl)#permit ip host 1.1.1.1 host 239.2.2.2

Let’s attach this to our multicast boundary command:

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

Let’s give this a try:

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, 18 ms

Excellent, this ping is working. However, only because it is sourced from 1.1.1.1. Let’s try the GigabitEthernet 0/1 interface as the source:

R1#ping 239.1.1.1 source GigabitEthernet 0/1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.12.1 
.

This ping fails because I don’t have a permit statement for source 192.168.12.1.

Let’s try a ping to 239.3.3.3:

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:
.

I don’t have any permit statements for 239.3.3.3, so this traffic is denied anyway.

Filter Auto RP

Even though we filtered multicast traffic, R3 still receives Group to RP mapping information through Auto RP. Take a look at this output:

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:39, expires: 00:02:15
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:57, expires: 00:02:57
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:15, expires: 00:02:36

R3 doesn’t need any information about 239.3.3.3 since it’s denied anyway. We can filter this information from Auto RP with the multicast boundary command. It only supports standard access-lists, so let’s create a new ACL:

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

And add it to the interface on R2:

R2(config)#interface GigabitEthernet 0/2
R2(config-if)#ip multicast boundary FILTER_AUTO_RP filter-autorp

Wait for the Auto RP information to expire or speed it up:

R3#clear ip pim rp-mapping

Here’s what the Group to RP mapping looks like now:

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:01:26, expires: 00:02:31
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:01:44, expires: 00:02:10

This is looking good, information about 239.3.3.3 is gone now.

Want to take a look for yourself? Here you will find the final configuration of each device.

Conclusion

You have now learned how to configure multicast boundary to restrict your multicast traffic:

• How to filter multicast traffic with a standard access-list.
• How to filter specific multicast S,G traffic with an extended access-list.
• How to filter multicast groups from Auto RP messages.

I hope you enjoyed this lesson. If you have any questions feel free to leave a comment!

Table of Content

---

Unit 1. Introduction to Multicast

• Introduction to Multicast
• Multicast IP Addresses Overview
• Multicast MAC to IP Address mapping

Unit 2: IGMP (Internet Group Management Protocol)

• Multicast IGMP Version 1
• Multicast IGMP Version 2
• Multicast IGMP Version 3
• Multicast IGMP Filter
• Multicast IGMP Proxy

Unit 3: Multicast L2

• Multicast IGMP Snooping
• IGMP Snooping without Router
• Multicast CGMP (Cisco Group Management Protocol)

Unit 4: Multicast L3

• Multicast Routing
• Multicast PIM Dense Mode
• Multicast PIM Sparse Mode
• Multicast PIM Sparse-Dense Mode
• Multicast PIM Auto RP
• Multicast PIM BSR (Bootstrap)
• RPF (Reverse Path Forwarding)
• Multicast Tunnel RPF Failure
• PIM Designated Router
• PIM Assert
• Multicast PIM Prune Override
• Multicast PIM Register Message
• Anycast RP
• Multicast MSDP SA Filtering
• Multicast Bidirectional PIM
• Multicast Stub Routing and IGMP Helper
• Source Specific Multicast
• Multicast PIM Accept RP
• Multicast PIM Accept Register
• Multicast Auto-RP Mapping agent behind Spoke
• PIM NBMA Mode
• Multicast Boundary Filtering
• Multicast PIM Snooping

Unit 5:  IPv6 Multicast

• IPv6 Multicast BSR and RP
• Embedded RP for IPv6