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:

R1 R2 R3 Multicast Boundary

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

Configurations

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

R1

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

R2

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

R3

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.

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 785 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

1506 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: ,


Forum Replies

  1. Good day!
    This topic makes me go deeper to multicast! And i’ll explain why)

    I could not understand why do we need 224.0.1.40 for R3 (permit rule in MULTICAST_FILTER acl). R3 is a client (receiver) of MC groups and all that we need for receiving multicast on R3 it is just sending IGMP report (join) toward the R2 (we can forget about PIM), and R2 knows where RP is.

    Hours of labing I understood, the main reason why we need acl with 224.0.1.40 in MULTICAST_FILTER acl is “R3 acts as PIM-DR

    I think that we do not pass packets with dst ip 224.0.1.40 through R2 is n

    ... Continue reading in our forum

  2. Ok, maybe a lot of letters…

    Why do not we see the interface Gi0/2 of R2 in the OIL of the (*,G) entry in R2 when we use “ip igmp join-group” command for 239.1.1.1 and 239.2.2.2?
    And why do we see it if R2 is PIM DR?

  3. Hello Evgeny

    I discussed this over with @ReneMolenaar and he said that the lesson may be somewhat confusing. Specifically, R3, as you correctly mentioned, plays the role of a multicast router as well as a multicast client. In the same way, R1 is a multicast source, and a multicast router. He said he would revise the content by adding a multicast source connected to R1 and a multicast client connected to R3 so these roles will be separate.

    Now having said that, looking at your comments, we can say the following:

    ... Continue reading in our forum

  4. Hello again Evgeny

    After labbing this up with @ReneMolenaar we found that Gi0/2 did indeed appear in the OIL of the (*,G) entry in R2. You must keep in mind that it may take several minutes for the topology to reconverge so that this appears. Can you take a look at your configuration again and let us know if you get the same results?

    I hope this has been helpful!

    Laz

7 more replies! Ask a question or join the discussion by visiting our Community Forum