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:
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:
Rack1R3So 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.
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
Rack1R2(config-if)#int lo0So 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-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
Rack1R2(config)#ip access-list standard FILTER_MULTICASTFrom 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)#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
Rack1R2(config-std-nacl)#int fa0/0So now R2 is not only blocking the 228.0.0.0/8 group but also blocking the auto-rp information for that group.
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
Here comes a gotcha:
Rack1R2(config)#interface Loopback0From 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.
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:
...
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