Solved: Randezvous point for two segments

husycisco · ‎05-29-2008

Hi experts,

I drew a diagram by myself, simulated in dynamips. I ve connected virtual machines, and running a tiny software for sending and receiving multicast. Diagram is attached.

There is no route redistribution between routing protocols. When I run this in dense mode, all fine, both receivers do receive mcast trafic generated by source.

Maybe that happens due to a lack knowledge of mine here, but here is how I configure Auto RP

R1

ip pim send-rp-announce s0/0 scope 5

ip pim send-rp-announce s0/1 scope 5

R2

ip pim send-rp-discovery s0/0 scope 5

R3

ip pim send-rp-discovery s0/0 scope 5

Then I receive the following in R1

PIM-6-INVALID_RP_JOIN: Received (*, 239.255.255.250) Join from 172.16.8.250 for invalid RP 172.16.8.249 but after some time sh ip pim rp in 8.250 shows that RP is set for that group. But that error goes on prompting.

I start sending mcast traffic from mcast source connected to R1 to group 227.8.8.10. As I start, following appears in R1 debugs

Mar 1 00:38:50.331: PIM(0): Check RP 172.16.8.253 into the (*, 227.8.8.10) entry

*Mar 1 00:38:50.335: MRT(0): Create (*,227.8.8.10), RPF /0.0.0.0

*Mar 1 00:38:50.339: MRT(0): (192.168.1.4,227.8.8.10), RPF install from /0.0.0.0 to Ethernet0/0/0.0.0.0

*Mar 1 00:38:50.343: MRT(0): Reset the z-flag for (192.168.1.4, 227.8.8.10)

*Mar 1 00:38:50.347: MRT(0): Create (192.168.1.4,227.8.8.10), RPF Ethernet0/0/0.0.0.0

*Mar 1 00:38:57.223: PIM(0): Received v2 Join/Prune on Serial1/0 from 172.16.8.250, to us

*Mar 1 00:38:57.227: PIM(0): Join-list: (*, 239.255.255.250),, ignored, invalid RP 172.16.8.249 from 172.16.8.250

sh ip mroute output in R1 is as I want to see

(192.168.1.4, 227.8.8.10), 00:01:24/00:02:51, flags: PT

Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0

Outgoing interface list: Null

Now showtime. I start receiver in mcast destination 1, then I get the following logs

*Mar 1 00:41:34.195: IGMP(0): Received v2 Report on Ethernet1/0 from 172.16.5.2 for 227.8.8.10

*Mar 1 00:41:34.199: IGMP(0): Received Group record for group 227.8.8.10, mode 2 from 172.16.5.2 for 0 sources

*Mar 1 00:41:34.203: IGMP(0): WAVL Insert group: 227.8.8.10 interface: Ethernet1/0Successful

*Mar 1 00:41:34.207: IGMP(0): Switching to EXCLUDE mode for 227.8.8.10 on Ethernet1/0

*Mar 1 00:41:34.207: IGMP(0): Updating EXCLUDE group timer for 227.8.8.10

*Mar 1 00:41:34.211: IGMP(0): MRT Add/Update Ethernet1/0 for (*,227.8.8.10) by 0

*Mar 1 00:41:34.215: PIM(0): Check RP 172.16.8.249 into the (*, 227.8.8.10) entry

*Mar 1 00:41:34.219: MRT(0): (*,227.8.8.10), RPF change from /0.0.0.0 to Serial0/0/172.16.8.249

*Mar 1 00:41:34.219: MRT(0): Create (*,227.8.8.10), RPF Serial0/0/172.16.8.249

*Mar 1 00:41:34.223: MRT(0): WAVL Insert interface: Ethernet1/0 in (* ,227.8.8.10) Successful

and the following mroute table in R2

(*, 227.8.8.10), 00:00:58/00:02:31, RP 172.16.8.249, flags: SJC

Incoming interface: Serial0/0, RPF nbr 172.16.8.249

Outgoing interface list:

Ethernet1/0, Forward/Sparse, 00:00:58/00:02:31

sh ip pim rp

Group: 227.8.8.10, RP: 172.16.8.249, v2, v1, uptime 00:13:50, expires 00:02:17

Following from R1

*Mar 1 00:41:52.811: %PIM-6-INVALID_RP_JOIN: Received (*, 227.8.8.10) Join from 172.16.8.250 for invalid RP 172.16.8.249

Same above happens when I join mcast destination 2.

I am so sure that I am missing a very basic concept here, I hope you will shed light on this one.

Regards

Harold Ritter · ‎05-30-2008

Huseyin,

R1 will use either the address of s0/0 or s0/1 as the RP address, not both. If you do a "sh ip pim rp map" on R1, you will see that 172.16.8.253 is selected, hence PIM join sent to 172.16.8.249 being considered invalid.

You should use the looback interface address as the RP address to solve this issue.

On R1:

Interface Loopback0

ip address 172.16.8.xx

ip pim sparse-mode

!

no ip pim send-rp-announce s0/0

no ip pim send-rp-announce s0/1

ip pim send-rp-announce loopback0 scope 5

!

You will also need to advertise the loopback address in both ospf and eigrp.

Regards,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

View solution in original post

Harold Ritter · ‎05-30-2008

Huseyin,

R1 will use either the address of s0/0 or s0/1 as the RP address, not both. If you do a "sh ip pim rp map" on R1, you will see that 172.16.8.253 is selected, hence PIM join sent to 172.16.8.249 being considered invalid.

You should use the looback interface address as the RP address to solve this issue.

On R1:

Interface Loopback0

ip address 172.16.8.xx

ip pim sparse-mode

!

no ip pim send-rp-announce s0/0

no ip pim send-rp-announce s0/1

ip pim send-rp-announce loopback0 scope 5

!

You will also need to advertise the loopback address in both ospf and eigrp.

Regards,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

husycisco · ‎05-30-2008

Harold,

Makes perfect sense and works great! Thank You! One last question, how do you understand that RPF check is failed from an sh ip mroute output?

Regards

Harold Ritter · ‎05-30-2008

Huseyin,

It is not the RPF check that fails in this case but rather that R1 receives a PIM join destined to the RP identified as 172.16.8.249, while R1 recons that the RP is 172.16.8.253. This is what the following message indicates:

Mar 1 00:41:52.811: %PIM-6-INVALID_RP_JOIN: Received (*, 227.8.8.10) Join from 172.16.8.250 for invalid RP 172.16.8.249

Regards,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

husycisco · ‎05-30-2008

Thanks Harold, I understood the issue about this case. I just asked my second question in general. I mean when should I decide that its an RPF failure while looking at a sh ip mroute output? And are there any debug promtps that indicate RPF failure?

Harold Ritter · ‎05-31-2008

Huseyin,

Sorry I misunderstood your question. The RPF check failures can be obtained by specifying the count keyword on the show ip mroute command as can be seen below:

r1#sh ip mroute 239.1.1.1 count

IP Multicast Statistics

7 routes using 4348 bytes of memory

3 groups, 1.33 average sources per group

Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second

Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 239.1.1.1, Source count: 1, Group pkt count: 251

RP-tree: Forwarding: 0/0/0/0, Other: 0/0/0

Source: 192.168.34.4/32, Forwarding: 251/1/100/0, Other: 251/0/0

r1#

The second counter in the "Other:" section refers to the RPF failure.

Regards,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

husycisco · ‎06-02-2008

Harold,

Thank you :)

One last question, what is the difference when 0.0.0.0 is stated as RPF neighbor in show ip mroute and when a private IP is stated?

Regards

Harold Ritter · ‎06-02-2008

Huseyin,

You will normally see the RPF neighbor set to 0.0.0.0 when the local router is the root of the tree. In other words, on the RP for the RPT (AKA rendez-vous point tree or shared tree) or on the hirst-hop router for the SPT (AKA as shortest path tree or source tree).

Regards,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México