PIM Boundaries with AutoRP

Load multicast.multi.domain.init.cfg

#IOS-XE
config replace flash:multicast.multi.domain.init.cfg
 
#IOS-XR
configure
load bootflash:multicast.multi.domain.init.cfg
commit replace
y

Configure the group of routers circled on the left as a sub-PIM domain. R6 should be the RP for group range 239.10.0.0/24. This information should be propagated using AutoRP and should not leak outside this sub domain.

Configure R9 as the RP for group range 239.20.0.0/24 using AutoRP. This group range should be for domain-wide traffic, and should propagate to all routers in the topology.

Note that an interface has been added between R9 and XR2.

Answer

#R5-10
ip pim autorp listen

#R9
int lo0
 ip pim sparse-mode
!
ip access-list standard DOMAIN_SCOPE_RANGE
 10 permit 239.20.0.0 0.0.0.255
!
ip pim send-rp-discovery lo0 scope 255
ip pim send-rp-announce Loopback0 scope 255 group-list DOMAIN_SCOPE_RANGE

#R6
int lo0
 ip pim sparse-mode
!
ip access-list standard LOCAL_SCOPE_RANGE
 10 permit 239.10.0.0 0.0.0.255
!
ip pim send-rp-discovery lo0 scope 255
ip pim send-rp-announce Loopback0 scope 255 group-list LOCAL_SCOPE_RANGE
!
access-l 1 deny 239.10.0.0 0.0.0.255
access-l 1 permit any
!
int GigabitEthernet2.562
 ip multicast boundary 1 filter-autorp
int GigabitEthernet2.569
 ip multicast boundary 1 filter-autorp

#XR4
ipv4 access-list BOUNDARY_ACL
 10 deny ipv4 239.10.0.0/24 any
 20 deny ipv4 host 224.0.1.40 any
 30 permit ipv4 any any
!
multicast-routing
 address-family ipv4
  interface GigabitEthernet0/0/0/0.524
   boundary BOUNDARY_ACL
  !
  interface GigabitEthernet0/0/0/0.594
   boundary BOUNDARY_ACL
!
router ospf 1
 area 0
  interface GigabitEthernet0/0/0/0.524
   cost 100
  !
  interface GigabitEthernet0/0/0/0.594
   cost 100

#R7
int GigabitEthernet2.574
 ip ospf cost 100

Explanation

PIM’s use of the underlying unicast topology makes PIM an overlay technology. The PIM domain is overlaid ontop of the unicast underlay. Routers also do not have the ability to run multiple PIM processes like they do for an IGP. This means that the PIM domain is essentially bounded by the collection of routers that share RP mapping information.

In some scenarios, you may want to create multiple PIM sub domains within a single IGP. The easiest way to do this is to limit the propagation of RP information to each sub domain.

In this lab, we have a sub domain that is circled on the left, yet we also want to create a topology-wide domain of all PIM routers. This makes it tricky to bound the sub domain’s RP advertisements.

To begin, we advertise RP mappings in AutoRP just like before. AutoRP actually lets us define the TTL of the C-RP and MA messages, but this is very rarely a good tool for bounding the domain. For example, on R6, if we make the TTL=2, R9 will still learn the mappings but R7 will not.

#R5-10
ip pim autorp listen

#R9
int lo0
 ip pim sparse-mode
!
ip access-list standard DOMAIN_SCOPE_RANGE
 10 permit 239.20.0.0 0.0.0.255
!
ip pim send-rp-discovery lo0 scope 255
ip pim send-rp-announce Loopback0 scope 255 group-list DOMAIN_SCOPE_RANGE

#R6
int lo0
 ip pim sparse-mode
!
ip access-list standard LOCAL_SCOPE_RANGE
 10 permit 239.10.0.0 0.0.0.255
!
ip pim send-rp-discovery lo0 scope 255
ip pim send-rp-announce Loopback0 scope 255 group-list LOCAL_SCOPE_RANGE

Next, we use the multicast boundary feature to prohibit the advertisement of the sub domain’s AutoRP mapping to router that don’t belong to the sub domain. On IOS-XE, we can actually filter the content of the AutoRP messages. Any mappings that are not permitted by the ACL are filtered out of the AutoRP message.

#R6
access-l 1 deny 239.10.0.0 0.0.0.255
access-l 1 permit any
!
int GigabitEthernet2.562
 ip multicast boundary 1 filter-autorp
int GigabitEthernet2.569
 ip multicast boundary 1 filter-autorp

By using debug ip pim auto-rp we can watch that R6 is filtering the 239.10.0.0/24 mapping from Auto-RP messages sent in/out of Gi2.562 and Gi2.569:

IOS-XR does not have this ability. Instead, all we can do is filter the Auto-RP RP-discovery packets entirely. In addition, IOS-XR denies the local multicast group 239.10.0.0/24. This prevents multicast traffic in this group range from using these interfaces, as this traffic should be bound to the local sub domain.

#XR4
ipv4 access-list BOUNDARY_ACL
 10 deny ipv4 239.10.0.0/24 any
 20 deny ipv4 host 224.0.1.40 any
 30 permit ipv4 any any
!
multicast-routing
 address-family ipv4
  interface GigabitEthernet0/0/0/0.524
   boundary BOUNDARY_ACL
  !
  interface GigabitEthernet0/0/0/0.594
   boundary BOUNDARY_ACL

Note that if all we had was IOS-XR routers on the edge between the sub domain and the rest of the topology, we could not use AutoRP for disseminating RP information, as there would be no way to selectively permit the 239.20.0.0/24 RP mapping but deny 239.10.0.0/24.

We’ve also introduced another problem: Now R7 and XR4 are only receiving the 239.20.0.0/24 RP mapping information through XR1, which is not the shortest path. For this reason, the (R9, 224.0.1.40) traffic does not pass the RPF check (remember this is basic dense mode traffic). XR4’s route to R9 is via the direct link. And R7’s best route to R9 is via XR4.

To fix this, we can increase the IGP cost of the links towards R9 via XR4-R9 link so that the RPF check will pass.

#XR4
router ospf 1
 area 0
  interface GigabitEthernet0/0/0/0.524
   cost 100
  !
  interface GigabitEthernet0/0/0/0.594
   cost 100

#R7
int GigabitEthernet2.574
 ip ospf cost 100

On all routers in the sub domain, we should see two RP mappings:

On a router that does not belong to the sub domain, we should only see an RP mapping for the 239.20.0.0/24 group range:

A note on AutoRP filtering

When you apply the AutoRP filter, it appears to also work as a normal, data plane boundary. So you must ensure that the 224.0.1.40 group is permited through.

In this lab, we simply had a permit all statement:

#R6
access-l 1 deny 239.10.0.0 0.0.0.255
access-l 1 permit any
!
int GigabitEthernet2.562
 ip multicast boundary 1 filter-autorp
int GigabitEthernet2.569
 ip multicast boundary 1 filter-autorp

However, if you use inverse logic, only permitting groups you want to pass the filter, you must ensure to add permit host 224.0.1.40.

Last updated