IP Multicast Boundary

In this post we'll take a look at the ip multicast boundary interface-level command.  This command's function isn't hard to understand - it references a standard or extended access list, and either permits or denies multicast traffic through the interface.  It can also optionally manipulate auto-rp to remove groups you don't want advertised downstream.

The subnets are on the diagram.  Every router is using it's router number as the last octet; every router also has a loopback of X.X.X.X, where X is the router number.  Every router is running EIGRP on every interface, and pim sparse-dense mode on every interface. 

R1 is setup for auto-rp announcement & discovery via it's loopback 0 address:

ip access-list standard GRL
 permit 232.0.0.0 7.255.255.255
 permit 239.0.0.0 0.255.255.255
ip pim send-rp-announce Loopback0 scope 5 group-list GRL
ip pim send-rp-discovery Loopback0 scope 16

We can verify that R3 is receiving the mappings for these groups:

R3#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 232.0.0.0/5
  RP 1.1.1.1 (?), v2v1
    Info source: 1.1.1.1 (?), elected via Auto-RP
         Uptime: 00:07:33, expires: 00:02:13
Group(s) 239.0.0.0/8
  RP 1.1.1.1 (?), v2v1
    Info source: 1.1.1.1 (?), elected via Auto-RP
         Uptime: 00:07:33, expires: 00:02:13

Let's have R3's Lo0 interface join 239.1.1.1 and 232.1.1.1:

interface Lo0
 ip igmp join-group 239.1.1.1
 ip igmp join-group 224.1.1.1

And ping them from R1:

R1#ping 239.1.1.1
<output omitted>
Reply to request 0 from 192.168.23.3, 72 ms
R1#ping 224.1.1.1
<output omitted>
Reply to request 0 from 192.168.23.3, 112 ms
Now let's see if we can use R2 to selectively filter 239.0.0.0/8 from reaching R3:

R2:
ip access-list standard blockthings
 deny   239.0.0.0 0.255.255.255
 permit any
interface FastEthernet0/1
 ip multicast boundary blockthings out
R1:
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:
.
R2:
sh ip mroute 239.1.1.1
<output omitted>

(192.168.12.1, 239.1.1.1), 00:03:22/00:01:55, flags: PFT
  Incoming interface: FastEthernet0/0, RPF nbr 192.168.12.1
  Outgoing interface list: Null

It works!

However, on R3, we still think we can join the group:

R3#sh ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/5
  RP 1.1.1.1 (?), v2v1
    Info source: 1.1.1.1 (?), elected via Auto-RP
         Uptime: 00:00:53, expires: 00:02:05
Group(s) 239.0.0.0/8
  RP 1.1.1.1 (?), v2v1
    Info source: 1.1.1.1 (?), elected via Auto-RP
         Uptime: 00:00:53, expires: 00:02:04
We can fix that as well.

R2:
interface Fa0/1
  ip multicast boundary blockthings filter-autorp

Please note this command is in addition to the prior "blockthings out" statement, not in replacement.

R3#sh ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/5
  RP 1.1.1.1 (?), v2v1
    Info source: 1.1.1.1 (?), elected via Auto-RP
         Uptime: 00:00:04, expires: 00:02:53
... and it's gone from auto-rp, as well.

Now, let's change that access-list on R2 a bit:

no ip access-list standard blockthings
ip access-list standard blockthings
 deny 224.0.0.0 0.255.255.255
 permit any

R2 & R3:
clear ip pim rp-mapping

Now you'd think we'd be able to ping 239.1.1.1 and not 224.1.1.1, right?

R1#ping 224.1.1.1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
.
OK, that was expected.

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

R3#sh ip pim rp map
PIM Group-to-RP Mappings
R3#
More uh-oh.

So what happened?  We just blocked auto-rp.  Let's try this again:

no ip access-list standard blockthings
ip access-list standard blockthings
  permit 224.0.1.40 0.0.0.0
  deny 224.0.0.0 0.255.255.255
  permit any

If our auto-rp mapping agent were behind R2, we'd also want to permit 224.0.1.39.  In fact, it's best if you just permit both all the time if you're using auto-rp, just to be safe.

R1#ping 239.1.1.1
<output omitted>
Reply to request 0 from 192.168.23.3, 144 ms

R3#sh ip pim rp map
PIM Group-to-RP Mappings
Group(s) 239.0.0.0/8
  RP 1.1.1.1 (?), v2v1
    Info source: 1.1.1.1 (?), elected via Auto-RP
         Uptime: 00:00:03, expires: 00:02:53
Much happier.

There are many other things you can do with ip multicast boundary, which I will give a high-level view of here.

If you wanted to block R2 from being able to perform joins to 224.1.1.1 as well, you'd place the boundary on Fa0/0 as "in".  This is probably obvious but the command help is written in such a way that it leaves you scratching your head.

R2:
int lo0
 ip igmp join-group 224.1.1.1

R1#ping 224.1.1.1
<output omitted>
.
The interesting thing is the way this shows up on the mroute table on R2:
R2(config-if)#do sh ip mroute 224.1.1.1
<output omitted>

(192.168.12.1, 224.1.1.1), 00:02:03/00:01:12, flags: PT
  Incoming interface: FastEthernet0/0, RPF nbr 192.168.12.1
  Outgoing interface list: Null

The stream is allowed on to R2, but R2 won't allow Lo0 to be added to the OIL (Outgoing interface list).

Labbing up the extended access lists version of this can get rather tricky.  Tricky to the point where I really hope this never shows up on the lab.

In short, you can filter by (S,G) instead of just by group.  The format is:
permit ip <source ip> <source mask> <group address><group mask>

The catch is, you have to consider traffic from the RP, after the SPT join, etc.  Even the joins can have issues.  It's difficult to come up with a "clean" way of showing how to make this work.

...Here's hoping we all dodge that bullet.

Jeff Kronlage