From: Ashok M A (ashok_ccie@yahoo.co.in)
Date: Tue Oct 11 2005 - 15:35:25 GMT-3
I see that if you spectify 224/4 in the access-list (
and this access-list includes the 224.0.1.39 and
224.0.1.40) then the auto-rp announcements/discovery
messages will be blocked, though you have not
specified the "filter-autorp" keyword.
I done little bit on "filter-autorp" keyword mentioned
below. I have two RPs for the group 224/5 and 232/5.
My intention is to block 224/5 when sending in the
auto-rp discovery and send 232/5 info.
R2 is MA, R5(5.5.5.5) and R6(6.6.6.6) are C-RPs. Only
R6 has connection to BB1 over f1/0.
I configured like this.
R6#sri f1/0
Building configuration...
Current configuration : 202 bytes
!
interface FastEthernet1/0
ip address 20.1.1.6 255.255.255.0
ip pim sparse-dense-mode
ip multicast boundary 6 filter-autorp
ip igmp access-group 1
no ip mroute-cache
speed auto
full-duplex
end
R6#
R6#show access-lists 6
Standard IP access list 6
10 permit 224.0.1.39 (26 matches)
20 permit 224.0.1.40 (22 matches)
30 deny 224.0.0.0, wildcard bits 7.255.255.255
(9 matches)
40 permit any (13 matches)
R6#
R6#show ip pim rp ma
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
Group(s) 224.0.0.0/5
RP 5.5.5.5 (?), v2v1
Info source: 7.7.7.7 (?), elected via Auto-RP
Uptime: 00:16:54, expires: 00:02:50
Group(s) 232.0.0.0/5
RP 6.6.6.6 (?), v2v1
Info source: 7.7.7.7 (?), elected via Auto-RP
Uptime: 00:16:47, expires: 00:02:53
R6#
And at BB1 i get the desired result:
BB1#sh ip pim rp ma
PIM Group-to-RP Mappings
Group(s) 232.0.0.0/5
RP 6.6.6.6 (?), v2v1
Info source: 7.7.7.7 (?), elected via Auto-RP
Uptime: 00:09:22, expires: 00:02:26
BB1#
Hope this helps.
Ashok
~~~~~~~~~~~~~
"ip multicast boundary 50" without the keyword
filter-autorp is filtering auto-rp announces.
Cisco doc says it is filtered only if the keyword is
specified.
Could you test this to check if the problem is my IOS
version?
R5 is hub of a multipoing frame-relay clould. R2 and
R1 are spokes.
R5 is the mapping agent.
R2 and R1 are RPs.
==========================
quoted
You can configure the filter-autorp keyword to examine
and filter Auto-RP discovery and announcement messages
at the administratively scoped boundary. Any Auto-RP
group range announcements from the Auto-RP packets
that are denied by the boundary access control list
(ACL) are removed
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcpt3/1cfmulti.htm#1002581
==========================
Before applying ip multicast boundary 50:
Rack2R5#deb ip pim auto-rp
PIM Auto-RP debugging is on
*Mar 1 15:41:24.694: Auto-RP(0): Received
RP-announce, from 142.20.2.1, RP_cnt 1, ht 181 *Mar 1
15:41:24.694: Auto-RP(0): Update (234.0.0.0/8,
RP:142.20.2.1), PIMv2 v1 *Mar 1 15:41:24.694:
Auto-RP(0): Received RP-announce, from 142.20.2.1,
RP_cnt 1, ht 181 *Mar 1 15:41:24.694: Auto-RP(0):
Update (234.0.0.0/8, RP:142.20.2.1), PIMv2 v1
*Mar 1 15:42:01.774: Auto-RP(0): Received
RP-announce, from 142.20.1.1, RP_cnt 1, ht 181 *Mar 1
15:42:01.778: Auto-RP(0): Update (235.0.0.0/8,
RP:142.20.1.1), PIMv2 v1 *Mar 1 15:42:01.778:
Auto-RP(0): Received RP-announce, from 142.20.1.1,
RP_cnt 1, ht 181 *Mar 1 15:42:01.778: Auto-RP(0):
Update (235.0.0.0/8, RP:142.20.1.1), PIMv2 v1
*Mar 1 15:42:24.792: Auto-RP(0): Received
RP-announce, from 142.20.2.1, RP_cnt 1, ht 181 *Mar 1
15:42:24.796: Auto-RP(0): Update (234.0.0.0/8,
RP:142.20.2.1), PIMv2 v1 *Mar 1 15:42:24.796:
Auto-RP(0): Received RP-announce, from 142.20.2.1,
RP_cnt 1, ht 181 *Mar 1 15:42:24.796: Auto-RP(0):
Update (234.0.0.0/8, RP:142.20.2.1), PIMv2 v1
*Mar 1 15:43:01.877: Auto-RP(0): Received
RP-announce, from 142.20.1.1, RP_cnt 1, ht 181 *Mar 1
15:43:01.877: Auto-RP(0): Update (235.0.0.0/8,
RP:142.20.1.1), PIMv2 v1 *Mar 1 15:43:01.877:
Auto-RP(0): Received RP-announce, from 142.20.1.1,
RP_cnt 1, ht 181 *Mar 1 15:43:01.877: Auto-RP(0):
Update (235.0.0.0/8, RP:142.20.1.1), PIMv2 v1
Rack2R5(config)#int ser 0/0
Rack2R5(config-if)# ip multicast boundary 50
*Mar 1 15:43:21.581: Auto-RP(0): Build RP-Discovery
packet *Mar 1 15:43:21.581: Auto-RP: Build mapping
(234.0.0.0/8, RP:142.20.2.1), PIMv2 v1, *Mar 1
15:43:21.581: Auto-RP: Build mapping (235.0.0.0/8,
RP:142.20.1.1), PIMv2 v1.
*Mar 1 15:43:21.581: Auto-RP(0): Send RP-discovery
packet on Ethernet0/0 (2 RP entries) *Mar 1
15:43:21.585: Auto-RP(0): Send RP-discovery packet on
Dialer100 (2 RP entries) *Mar 1 15:43:21.585:
Auto-RP(0): Send RP-discovery packet on Tunnel512 (2
RP entries) *Mar 1 15:43:21.585: Auto-RP: Send
RP-discovery packet on Loopback0 (2 RP entries)
*Mar 1 15:44:21.680: Auto-RP(0): Build RP-Discovery
packet *Mar 1 15:44:21.680: Auto-RP: Build mapping
(234.0.0.0/8, RP:142.20.2.1), PIMv2 v1, *Mar 1
15:44:21.680: Auto-RP: Build mapping (235.0.0.0/8,
RP:142.20.1.1), PIMv2 v1.
*Mar 1 15:44:21.680: Auto-RP(0): Send RP-discovery
packet on Ethernet0/0 (2 RP entries) *Mar 1
15:44:21.684: Auto-RP(0): Send RP-discovery packet on
Dialer100 (2 RP entries) *Mar 1 15:44:21.684:
Auto-RP(0): Send RP-discovery packet on Tunnel512 (2
RP entries) *Mar 1 15:44:21.684: Auto-RP: Send
RP-discovery packet on Loopback0 (2 RP entries)
Rack2R5#sh clock
*15:44:49.553 UTC Mon Mar 1 1993
Do you see? Auto-RP is not received anymore.
Here is the mroute table:
Rack2R5(config)#do sh ip mroute 224.0.1.39
(*, 224.0.1.39), 03:30:14/stopped, RP 0.0.0.0, flags:
DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/0, Forward/Sparse-Dense,
00:56:30/00:00:00
Tunnel512, Forward/Sparse-Dense, 03:10:54/00:00:00
Loopback0, Forward/Sparse-Dense, 03:30:14/00:00:00
Dialer100, Forward/Sparse-Dense, 03:30:14/00:00:00
(142.20.1.1, 224.0.1.39), 00:00:58/00:02:02, flags:
PLTX
Incoming interface: Serial0/0, RPF nbr 142.20.125.1
Outgoing interface list: Null
(142.20.2.1, 224.0.1.39), 00:00:37/00:02:22, flags:
PLTX
Incoming interface: Serial0/0, RPF nbr 142.20.125.2
Outgoing interface list: Null
Rack2R5(config)#do sh ip mroute 224.0.1.40
(*, 224.0.1.40), 03:31:24/00:02:14, RP 0.0.0.0, flags:
DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Dialer100, Forward/Sparse-Dense, 03:11:01/00:00:00
Tunnel512, Forward/Sparse-Dense, 03:11:11/00:00:00
Loopback0, Forward/Sparse-Dense, 03:31:24/00:00:00
If I explicity permit 224.0.1.39 on access-list 50, R5
receives the RP announce:
nfig)#
Rack2R5(config)#access-list 50 per
Rack2R5(config)#access-list 50 permit 224.0.1.39
0.0.0.0
*Mar 1 15:59:24.624: Auto-RP(0): Received
RP-announce, from 142.20.2.1, RP_cnt 1, ht 181 *Mar 1
15:59:24.628: Auto-RP(0): Added with (234.0.0.0/8,
RP:142.20.2.1), PIMv2 v1 *Mar 1 15:59:24.632:
Auto-RP(0): Build RP-Discovery packet *Mar 1
15:59:24.632: Auto-RP: Build mapping (234.0.0.0/8,
RP:142.20.2.1), PIMv2 v1, *Mar 1 15:59:24.632:
Auto-RP(0): Send RP-discovery packet on Ethernet0/0 (1
RP entries) *Mar 1 15:59:24.632: Auto-RP(0): Send
RP-discovery packet on Dialer100 (1 RP entries) *Mar
1 15:59:24.636: Auto-RP(0): Send RP-discovery packet
on Tunnel512 (1 RP entries) *Mar 1 15:59:24.636:
Auto-RP: Send RP-discovery packet on Loopback0 (1 RP
entries)
*Mar 1 15:59:24.640: Auto-RP(0): Received
RP-announce, from 142.20.2.1, RP_cnt 1, ht 181 *Mar 1
15:59:24.640: Auto-RP(0): Update (234.0.0.0/8,
RP:142.20.2.1), PIMv2 v1
I know it sounds crazy to use boundary between RP and
agent, I am just considering the lab is not design.
This archive was generated by hypermail 2.1.4 : Sun Nov 06 2005 - 22:00:50 GMT-3