From: Adhu Ajit (adhu_ajit@yahoo.com)
Date: Thu Nov 02 2006 - 21:00:31 ART
Victor, thanks for your email. It was helpful in more than one way. First, I did not know about "ip pim auto-rp listener". I read some documentation about this and the way I understand this works is as follows:
If you are forced to configure ip pim sparse-dense-mode just so that Auto-RP can run, you have another option.
Configure all your interfaces on all your routers in your domain for ip pim sparse-mode
Configure ip pim auto-rp listener on all routers in your network.
Configure candidate RPs and MAs as usual.
Auto-RP should run and distribute group to RP mappings for all routers in the domain.
Am I right? Are there any other caveats that I should know.
But I found something very strange. I made all my interfaces to sparse-mode. I configured 2 routers as RPs and another router as a mapping agent. But I did NOT configure auto-rp listener on any of the routers. But I still see that downstream routers are getting the RP-group mapping from the MA. (I'm running version 12.3, if at all that makes a difference) Since I configured the RPs and MAs, does it automatically treat it as a pim auto-rp listener mode ?
How is this possible ?
Thanks in advance.
Victor Cappuccio <vcappuccio@desca.com> wrote:
Hi Adhu...
Comments in line...
________________________________
De: Adhu Ajit [mailto:adhu_ajit@yahoo.com]
Enviado el: Jue 02/11/2006 01:20 p.m.
Para: Victor Cappuccio; ccielab@groupstudy.com
Asunto: RE: PIM Dense mode and NBMA
> Victor, if you go back to my first email, the scenario is about RP information distribution in a sparse-dense mode environment.
Hmmmmm I do not see that part in your first email....??
> As you might already know that Auto-RP actually runs in PIM dense mode fashion.
Yeap, but you can also run Auto RP in sparse-mode configuration with the use pim autorp listener,
Also the 224.0.1.40 is created even using sparse or dense..
R2(config)#do show ip int brief | ex un
Interface IP-Address OK? Method Status Prot
ocol
Virtual-Access1 1.1.12.2 YES TFTP up up
Virtual-Template1 1.1.12.2 YES NVRAM down down
Loopback0 2.2.2.2 YES NVRAM up up
R2(config)#int virtual-temp1
R2(config-if)#ip pim sparse
R2(config-if)#do show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 00:00:03/00:02:56, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Virtual-Access1, Forward/Sparse, 00:00:03/00:02:56
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 00:00:03/00:02:56, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Virtual-Access1, Forward/Sparse, 00:00:03/00:02:56
R2(config-if)#ip pim dense
R2(config-if)#do show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 00:00:12/00:02:48, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Virtual-Access1, Forward/Dense, 00:00:12/00:02:48
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 00:00:12/00:02:48, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Virtual-Access1, Forward/Dense, 00:00:12/00:02:48
> The problem that I was having was with the distribution of RP information ... which would imply that we have a problem with our PIM dense mode even though this is not a PIM dense mode environment per-se. (Hope I did not end up confusing you even more)
Nop very clear now..., try issuing no ip mroute-cache in every pim interface (show ip pim inter) and then at the exec do a deb ip mp, this should tell you if you are having OILs problems, Joins/Prunes send out by PIM Neighbors or by the DR of the Directly connected Group Member (C or L flag) towards the RP are also suceptible to the general rule 2 and also by the PIM-Sparse Rule 8 (see Beua Williamson for more details), So maybe you are experiencing problems because General Rule 4 or/and General Rule 2
please note that a Shared tree is build towards the root from group members and a Sorce Based Tree is build to the Source, (assuming that STP Switchover, was set to infinity ) you should have *,G with the incoming interface towards to RP (PIM SM Rule 2), and with the outgoing interface to members of the group or PIM Neighbors- Or your S,G toward the source in the incoming interface over the Source Tree, and the OIL pointing to the RP.-
>Adhu.
I hope not to be confuse you even more
Victor.-
Victor Cappuccio wrote:
Hi Adhu,
Maybe I'm missing something from your email, but from my understanding
IP PIM DENSE MODE is a Flood and Prune Technology, there is no need to
set a RP or a Mapping Agent, since all traffic is going to be flooded
out where they are neighbors, and prunes back the traffic in case that
they do not have a directly connected member or a downstream routers
that has an entry for that *,G.
This link is very useful
http://www.groupstudy.com/archives/ccielab/200502/msg00333.html
Many thanks
Victor.-
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Adhu Ajit
Sent: Jueves, 02 de Noviembre de 2006 12:15 a.m.
To: ccielab@groupstudy.com
Subject: PIM Dense mode and NBMA
Folks, I have a NBMA topology with Rtr A has the hub and Rtr B, C and D
as the spokes. Nothing fancy here. Rtr A is configured with NO
sub-interfaces and so are the other routers.
In a real-world scenario I would not do the following. (A disclaimer
to prevent a bunch of people pouncing on me that it does not make
practical sense. :-)) However, in my lab network, I made Rtr B (one of
the spokes) as the RP as well as the mapping agent.
Now, when I do show ip pim rp mappings on B and Rtr A, the display is
good. However, the spokes, C and D do not get the mapping information.
When I do a show ip mroute on the Auto-RP mapping agent address,
224.0.1.40 on Rtr A, since the incoming interface is the serial
interface the OIF does not contain the same serial interface. Makes
sense to me. Remember that I'm NOT using sub-interfaces for each of the
spokes. All of them are on the subnet and terminate on the same serial
interface on the hub.
Now, my comment is this. This scenario can never work. The solution is
to change the mapping agent to be the hub router, Rtr A, or create
sub-interfaces for each of the spoke if I still wish to keep Rtr B as
the mapping agent/RP.
Anyone care to comment ?
Thanks,
Adhu.
---------------------------------
Access over 1 million songs - Yahoo! Music Unlimited Try it today.
This archive was generated by hypermail 2.1.4 : Fri Dec 01 2006 - 08:05:45 ART