IEOC - Internetwork Expert's Online Community

Hello

I try to make R1 as Mapping Agent.

but I failed to make R1 as MA.

It seems R1 do not recieve RP announcement.

R1
interface Loopback0
 ip address 150.10.1.1 255.255.255.0
 ip pim sparse-mode
 ip ospf network point-to-point
interface Tunnel1
 ip unnumbered Loopback0
 ip pim sparse-mode
 tunnel source Loopback0
 tunnel destination 150.10.3.3
ip pim send-rp-discovery Loopback0 scope 10

Rack10R1#sh ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP-mapping agent (Loopback0)

Rack10R1#sh 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, z - MDT-data group sender,
       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

(*, 239.6.6.6), 01:03:37/00:02:35, RP 0.0.0.0, flags: SJC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet0/0, Forward/Sparse, 01:03:37/00:02:35

(*, 224.0.1.39), 01:05:07/stopped, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Tunnel0, Forward/Sparse, 01:03:38/00:00:00
    Serial0/0.1, Forward/Sparse, 01:04:39/00:00:00
    Loopback0, Forward/Sparse, 01:05:08/00:00:00
    Tunnel1, Forward/Sparse, 01:04:29/00:00:00
    FastEthernet0/0, Forward/Sparse, 01:05:08/00:00:00

(150.10.8.8, 224.0.1.39), 00:01:50/00:01:12, flags: L
  Incoming interface: Serial0/0.1, RPF nbr 155.10.0.5
  Outgoing interface list:
    FastEthernet0/0, Forward/Sparse, 00:01:50/00:00:00
    Tunnel1, Forward/Sparse, 00:01:50/00:00:00
    Loopback0, Forward/Sparse, 00:01:51/00:00:00
    Tunnel0, Forward/Sparse, 00:01:51/00:00:00

(150.10.10.10, 224.0.1.39), 00:01:30/00:01:31, flags: L
  Incoming interface: Serial0/0.1, RPF nbr 155.10.0.5
  Outgoing interface list:
    FastEthernet0/0, Forward/Sparse, 00:01:30/00:00:00
    Tunnel1, Forward/Sparse, 00:01:30/00:00:00
    Loopback0, Forward/Sparse, 00:01:30/00:00:00
    Tunnel0, Forward/Sparse, 00:01:30/00:00:00

(*, 224.0.1.40), 01:05:09/00:02:39, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Tunnel0, Forward/Sparse, 01:03:40/00:00:00
    Loopback0, Forward/Sparse, 01:05:09/00:00:00
    Serial0/0.1, Forward/Sparse, 01:04:10/00:00:00
    Tunnel1, Forward/Sparse, 01:04:30/00:00:00
    FastEthernet0/0, Forward/Sparse, 01:04:37/00:00:00

Rack10R1#sh ip pim interface

Address          Interface                Ver/   Nbr    Query  DR     DR
                                          Mode   Count  Intvl  Prior
150.10.1.1       Loopback0                v2/S   0      30     1      150.10.1.1
150.10.1.1       Tunnel0                  v2/S   1      30     1      0.0.0.0
150.10.1.1       Tunnel1                  v2/S   1      30     1      0.0.0.0
155.10.146.1     FastEthernet0/0          v2/S   2      30     100    155.10.146
.1
155.10.0.1       Serial0/0.1              v2/S   1      30     1      0.0.0.0

Rack10R1#sh ip pim autorp
AutoRP Information:
  AutoRP is enabled.
  AutoRP groups over sparse mode interface is enabled

PIM AutoRP Statistics: Sent/Received
  RP Announce: 0/40, RP Discovery: 65/20

Rack10R1#debug ip pim auto-rp
PIM Auto-RP debugging is on

Rack10R1#
*Mar  1 01:07:48.866: Auto-RP(0): Build RP-Discovery packet
*Mar  1 01:07:48.866: Auto-RP: no RP periodic mappings to send

do I make any mistakes?

Hi Gonzo,

I've just spent two evenings trying to get this excerise running myself and have found the exact same problem as you have.

I've got R1 setup as the MA and it receives a the initial Auto-RP announce messages from SW2 & SW4 via R5 on the FR-link.
However, after the initial announce messages, things go haywire. Basically R1 does not get anymore Auto-RP announce messages until the (S, 224.0.1.39) entries time out on R5's mroute table.
 
I've worked out that R3 and R4 are sending Prune messages for the Auto-RP-Announce groups, specifically (150.6.10.10, 224.0.1.39) & (150.6.8.8, 224.0.1.39), because they don't have any downstream PIM peers for these two groups. This causes R5 to put its Se1/0 interface into pruned state and hence the reason why R1 does not get anymore Auto-RP-Announce messages until the entries time out from R5's mroute table.
 
I've had a look at the solution and I don't see how the solution will work. I've moved the Auto-RP MA from R5 to R1 using the same command as in the solution (though I haven't implemented the tunnel between R1 & R3, but this tunnel would only be used for the Auto-RP-Discovery messages, not the Auto-RP-Announce messages so the fact that the tunnel config is irrelevant).

Is the solution wrong???
Perhaps someone from IE can tell us where we've gone astray.

Cheers,
Gavin

Hello Guys,

 

Oh, wait untill you come to 8.16 :) I spend some few hours (until lab time finished) trying to understand why neither Sw2, now Sw4 has any entries in Auto-RP cache with "ip pim send-rp-discovery Loopback0 scope 2"  command on R1. But when you use scope of 3 - both Switches happen to got entries. Later on more interesting this star happen :)

 

Gavin, did you put "ip pim nbma-mode" on your FR interface connection (presumably S1/0).

Gonzo, whats the output you get on R5 from "sh ip pim rp mapping" and "sh ip mroute"?

 

Andrius

"Make R3 another MA that preempts the existing MA in R5".. but the solution is to simply make R3 a MA and remove the MA config from R5. That doesn't sound like pre-emption to me...

Okay, this task is REALLY WRONG.

The task says to make R3 a MA, and make R1 able to hear discovery messages from R3

The config makes R1 a MA and makes R3 able to hear discovery messages from R1

The whole thing is completely perfectly backwards!

andrius.adamavicius:

Trying to understand why neither Sw2, now Sw4 has any entries in Auto-RP cache with "ip pim send-rp-discovery Loopback0 scope 2"  command on R1. But when you use scope of 3 - both Switches happen to got entries.

Weird... that one actually DID work for me...

check for RPF failures

 

kryolla:

check for RPF failures

 

 

I assume you're referring to his issue, not with the workbook being incorrect.

Read this:

An improperly-configured ip pim rp-announce-filter command may result in RP announcements being ignored. In addition, issuing the ip pim rp-announce-filter command on any other router but the mapping agent itself fails. This is because non-mapping agents do not listen to group 224.0.1.39. Even if non-mapping agents were to receive these messages, they still would not distribute the necessary group-to-RP mappings to everyone on the shared tree because they would not know what to do with them.

http://supportwiki.cisco.com/ViewWiki/index.php/PIM_auto-RP_mapping_agent_router_ignores_RP_announcement_messages

Hope it can help, it worked for me, i forgot to remove the rp-announce-filter  from R5.

Regards..

kryolla:

check for RPF failures

After using 'debug ip mpacket' I caught the RPF failures.   I try to mess around with the routing loop issues; and didn't have too much luck; so i just created two static routes on R1:

ip route 150.1.8.0 255.255.255.0 155.1.146.4
ip route 150.1.10.0 255.255.255.0 155.1.146.4

Also according to INE's documentation R5 is no longer making RP announcements, so I killed that off as well.    Now that I've done that, I've gotten all the output to match INEs.   

 

I wish INE would double-check their solutions to match the output their showing.

I had a problem with this one, too - it seems the solution is to tunnel R1 to SW2, SW4 and R3.

The following Cisco whitepaper addresses Auto-RP over NBMA:

http://www.cisco.com/en/US/docs/ios/solutions_docs/ip_multicast/White_papers/frm_rlay.html

The relevant quote is:

All candidate RPs must be connected to the MA.

All MAs must be connected to all PIM routers.

As SW2 and SW4 are the configured as RPs from task 8.12, you need to tunnel R1 (MA) to them...and then also tunnel from R1 to R3 so that R3 can learn about the RPs from R1.

INE's solution in the workbook doesn't reflect this at all, so perhaps there is a mistake somewhere, or I've gone down the wrong path with this one, but creating tunnels worked for me - if anyone wants the configs, just let me know and I'll post.

Hi,

While I haven't looked at the workbook (don't carry it with, and am on a
cuise ship at the moment, so downloading isn't an option either). But
"connected" is a variable term that simply means they need to be able to
talk.

We work through an exercise during the bootcamp where the RP is on the
hub, but the mapping agent is on one of the spokes, which of course
causes all sorts of different issues. :)

The general issue is that Auto-RP's groups operate in dense mode, and
the hub router won't forward packets back out the same interface they
came in on (from one spoke out same interface to another).

A tunnel would indeed solve it, as would making the hub have two
subinterfaces. If you work in sparse-mode only, dense mode will indeed
work, but only on local interfaces (e.g. no forwarding). There are
still ways to make things work! Just think outside the box!

Again, I am not looking at this particular scenario, so I can't comment
right now on accuracy or not, but I can tell you that rest assured
there are many ways of making things work when we get down to the
details of what IS really happening.

HTH,




*Scott Morris*, CCIE/x4/ (R&S/ISP-Dial/Security/Service Provider) #4713,

JNCIE-M #153, JNCIS-ER, CISSP, et al.

JNCI-M, JNCI-ER

evil@ine.com


Internetwork Expert, Inc.

http://www.InternetworkExpert.com

Toll Free: 877-224-8987

Outside US: 775-826-4344


Knowledge is power.

Power corrupts.

Study hard and be Eeeeviiiil......



Mr Crilson wrote:
>
> I had a problem with this one, too - it seems the solution is to
> tunnel R1 to SW2, SW4 and R3.
>
> The following Cisco whitepaper addresses Auto-RP over NBMA:
>
> http://www.cisco.com/en/US/docs/ios/solutions_docs/ip_multicast/White_papers/frm_rlay.html
>
> The relevant quote is:
>
> /All candidate RPs must be connected to the MA. /
>
> //
>
> /All MAs must be connected to all PIM routers./
>
> As SW2 and SW4 are the configured as RPs from task 8.12, you need to
> tunnel R1 (MA) to them...and then also tunnel from R1 to R3 so that R3
> can learn about the RPs from R1.
>
> INE's solution in the workbook doesn't reflect this at all, so perhaps
> there is a mistake somewhere, or I've gone down the wrong path with
> this one, but creating tunnels worked for me - if anyone wants the
> configs, just let me know and I'll post.
>
>
>
>
> Internetwork Expert - The Industry Leader in CCIE Preparation
> http://www.internetworkexpert.com
>
> Subscription information may be found at:
> http://www.ieoc.com/forums/ForumSubscriptions.aspx

While I haven't looked at the workbook (don't carry it with, and am on a
cuise ship at the moment, so downloading isn't an option either). But
"connected" is a variable term that simply means they need to be able to
talk.

We work through an exercise during the bootcamp where the RP is on the
hub, but the mapping agent is on one of the spokes, which of course
causes all sorts of different issues. :)

The general issue is that Auto-RP's groups operate in dense mode, and
the hub router won't forward packets back out the same interface they
came in on (from one spoke out same interface to another).

A tunnel would indeed solve it, as would making the hub have two
subinterfaces. If you work in sparse-mode only, dense mode will indeed
work, but only on local interfaces (e.g. no forwarding). There are
still ways to make things work! Just think outside the box!

Again, I am not looking at this particular scenario, so I can't comment
right now on accuracy or not, but I can tell you that rest assured
there are many ways of making things work when we get down to the
details of what IS really happening.

HTH,




*Scott Morris*, CCIE/x4/ (R&S/ISP-Dial/Security/Service Provider) #4713,

JNCIE-M #153, JNCIS-ER, CISSP, et al.

JNCI-M, JNCI-ER

evil@ine.com


Internetwork Expert, Inc.

http://www.InternetworkExpert.com

Toll Free: 877-224-8987

Outside US: 775-826-4344


Knowledge is power.

Power corrupts.

Study hard and be Eeeeviiiil......



Mr Crilson wrote:
>
> I had a problem with this one, too - it seems the solution is to
> tunnel R1 to SW2, SW4 and R3.
>
> The following Cisco whitepaper addresses Auto-RP over NBMA:
>
> http://www.cisco.com/en/US/docs/ios/solutions_docs/ip_multicast/White_papers/frm_rlay.html
>
> The relevant quote is:
>
> /All candidate RPs must be connected to the MA. /
>
> //
>
> /All MAs must be connected to all PIM routers./
>
> As SW2 and SW4 are the configured as RPs from task 8.12, you need to
> tunnel R1 (MA) to them...and then also tunnel from R1 to R3 so that R3
> can learn about the RPs from R1.
>
> INE's solution in the workbook doesn't reflect this at all, so perhaps
> there is a mistake somewhere, or I've gone down the wrong path with
> this one, but creating tunnels worked for me - if anyone wants the
> configs, just let me know and I'll post.
>
>
>
>
> Internetwork Expert - The Industry Leader in CCIE Preparation
> http://www.internetworkexpert.com
>
> Subscription information may be found at:
> http://www.ieoc.com/forums/ForumSubscriptions.aspx

Huh, weird.. this whole task worked for me once I corrected the workbook, so I'm having a bit of a difficult time following exactly what the problem is for everyone else