Multicast Access list (Boundary ) And Auto Rp

I prefer access-list because of it comes easy for me.

ip access-list extended MULTICAST_TRAFFIC
 permit ip any host 239.1.1.1

ip access-list extended MULTICAST_TRAFFIC
 permit ip any host 239.1.1.1

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.

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.

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/2 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.

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
 ip multicast boundary FILTER_AUTO_RP filter-autorp
 ip multicast boundary R1_L0_MULTICAST_FILTER out
!
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
!
ip access-list standard FILTER_AUTO_RP
 permit 239.2.2.2
 permit 239.1.1.1
ip access-list standard MULTICAST_FILTER
 permit 224.0.1.40
 permit 239.2.2.2
 permit 239.1.1.1
!
ip access-list extended R1_L0_MULTICAST_FILTER
 permit ip host 1.1.1.1 host 224.0.1.40
 permit ip host 1.1.1.1 host 239.1.1.1
 permit ip host 1.1.1.1 host 239.2.2.2
 permit ip host 0.0.0.0 host 239.1.1.1
 permit ip host 0.0.0.0 host 239.2.2.2
!
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