sabato 18 gennaio 2014

IPV6 multicast Boundary with or without filter-autorp

So what is the use of "filter-autorp" option in the "ip multicast boundary" command? Let's explore it with an example:
Here R3 is the multicast source and R2 is the client. R1 is serving as RP the for multicast groups 226.0.0.0/8, 228.0.0.0/8, and 232.0.0.0/5. R1 ia also the mapping agent. Let's check the relevant configuration on those routers:
Rack1R3
ip multicast-routing
!
interface Serial1/2
 ip address 180.1.13.3 255.255.255.0
 ip pim sparse-mode
!
ip pim autorp listener

Rack1R1
ip multicast-routing
!
interface FastEthernet0/0
 ip address 180.1.12.1 255.255.255.0
 ip pim sparse-mode
!
interface Serial0/1
 ip address 180.1.13.1 255.255.255.0
 ip pim sparse-mode
!
ip pim autorp listener
ip pim send-rp-announce FastEthernet0/0 scope 16 group-list RP_GROUPS interval 5
ip pim send-rp-discovery FastEthernet0/0 scope 16 interval 5
!
ip access-list standard RP_GROUPS
 permit 232.0.0.0 7.255.255.255
 permit 226.0.0.0 0.255.255.255
 permit 228.0.0.0 0.255.255.255

Rack1R2
ip multicast-routing
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 ip pim sparse-mode
!
interface FastEthernet0/0
 ip address 180.1.12.2 255.255.255.0
 ip pim sparse-mode
!
ip pim autorp listener

Rack1R2#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 226.0.0.0/8
  RP 180.1.12.1 (?), v2v1
    Info source: 180.1.12.1 (?), elected via Auto-RP
         Uptime: 00:09:43, expires: 00:00:12
Group(s) 228.0.0.0/8
  RP 180.1.12.1 (?), v2v1
    Info source: 180.1.12.1 (?), elected via Auto-RP
         Uptime: 00:09:43, expires: 00:00:12
Group(s) 232.0.0.0/5
  RP 180.1.12.1 (?), v2v1
    Info source: 180.1.12.1 (?), elected via Auto-RP
         Uptime: 00:09:43, expires: 00:00:12
So from the above output we can see that R2 is learning auto-rp information from R1 (mapping-agent). Now we will simulate a multicast client on R2's loopback interface for one of the auto-rp group.
Rack1R2(config-if)#int lo0
Rack1R2(config-if)#ip add 2.2.2.2 255.255.255.255
Rack1R2(config-if)#ip pim sparse-mode
Rack1R2(config-if)#ip igmp join-group 228.0.0.1
Rack1R3#ping 228.0.0.1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 228.0.0.1, timeout is 2 seconds:
Reply to request 0 from 180.1.12.2, 32 ms   
So we can see that multicast traffic for group 228.0.0.1 flowing from the source (R3) to the client (R2). Now we will apply "ip multicast boundary" command on R2 without "filter-autorp" option:
Rack1R2(config)#ip access-list standard FILTER_MULTICAST
Rack1R2(config-std-nacl)#deny 228.0.0.0 0.255.255.255
Rack1R2(config-std-nacl)#permit any
Rack1R2(config-std-nacl)#int fa0/0
Rack1R2(config-if)#ip multicast boundary FILTER_MULTICAST
Rack1R3#ping 228.0.0.1 rep 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 228.0.0.1, timeout is 2 seconds:
...
Rack1R2(config-if)#do sh access-list FILTER_MULTICAST
Standard IP access list FILTER_MULTICAST
    10 deny   228.0.0.0, wildcard bits 0.255.255.255 (3 matches)
    20 permit any (15 matches)
Rack1R2(config-if)#do show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 226.0.0.0/8
  RP 180.1.12.1 (?), v2v1
    Info source: 180.1.12.1 (?), elected via Auto-RP
         Uptime: 01:17:04, expires: 00:00:13
Group(s) 228.0.0.0/8  RP 180.1.12.1 (?), v2v1
    Info source: 180.1.12.1 (?), elected via Auto-RP
         Uptime: 00:15:42, expires: 00:00:13
Group(s) 232.0.0.0/5
  RP 180.1.12.1 (?), v2v1
    Info source: 180.1.12.1 (?), elected via Auto-RP
         Uptime: 01:17:04, expires: 00:00:13
From the above example we can see that even though R2 blocked 228.0.0.0/8 group traffic, it is still learning auto-rp information for 228.0.0.0/8. Now we will add "filter-autorp" option and will see the differences:
Rack1R2(config-std-nacl)#int fa0/0
Rack1R2(config-if)#ip multicast boundary FILTER_MULTICAST filter-autorp
Rack1R2(config-if)#do show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 226.0.0.0/8
  RP 180.1.12.1 (?), v2v1
    Info source: 180.1.12.1 (?), elected via Auto-RP
         Uptime: 00:11:34, expires: 00:00:11
Group(s) 232.0.0.0/5
  RP 180.1.12.1 (?), v2v1
    Info source: 180.1.12.1 (?), elected via Auto-RP
         Uptime: 00:11:34, expires: 00:00:11
So now R2 is not only blocking the 228.0.0.0/8 group but also blocking the auto-rp information for that group.
Here comes a gotcha:
Rack1R2(config)#interface Loopback0
Rack1R2(config-if)#ip igmp join-group 234.0.0.1
Rack1R3#ping 234.0.0.1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 234.0.0.1, timeout is 2 seconds:
Reply to request 0 from 180.1.12.2, 36 ms
Rack1R2(config)#do sh access-list FILTER_MULTICAST
Standard IP access list FILTER_MULTICAST
    10 deny   228.0.0.0, wildcard bits 0.255.255.255 (19 matches)
    20 permit any (394 matches)
Rack1R2(config)#ip access-list standard FILTER_MULTICAST
Rack1R2(config-std-nacl)#15 deny 236.0.0.0 0.255.255.255
*May 08 11:17:12.655: %AUTORP-4-OVERLAP: AutoRP Discovery packet, group 232.0.0.0 with mask 248.0.0.0 removed because of multicast boundary for 236.0.0.0 with mask 255.0.0.0
Rack1R2(config-std-nacl)#do sh ip pim rp mapp
PIM Group-to-RP Mappings
Group(s) 226.0.0.0/8
  RP 180.1.12.1 (?), v2v1
    Info source: 180.1.12.1 (?), elected via Auto-RP
         Uptime: 01:36:12, expires: 00:00:13
Rack1R3#ping 234.0.0.1 rep 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 234.0.0.1, timeout is 2 seconds:
...
From the above output we can see that as soon as we blocked the 236.0.0.0/8 group, the entire group range 232.0.0.0/5 was filtered and removed from the Auto-RP message. That's why R2 has no auto-rp information for group 234.0.0.1, a subset of 232.0.0.0/5. We can fix this by running sparse-dense mode on the interfaces so that traffic for group 234.0.0.1 will be able to use dense-mode. Another option is to configure RP R1 to announce 234.0.0.0/8 and 236.0.0.0/8 group individually instead of advertising the group range of 232.0.0.0/5.
So the key point is ... With auto-rp configured, RP by default announces itself as the RP for all the multicast groups (224.0.0.0/4). Now if we filter any specific group using "filter-autorp" keyword, it will filter auto-rp information for all the multicast groups unless RP advertises specific multicast groups rather than advertising default 224.0.0.0/4.

Nessun commento:

Posta un commento