RE: IE Vol1 LAB 2 Multicast over Frame Relay Cloud

From: Greg Gombas (ggombas@hotmail.com)
Date: Wed Jan 04 2006 - 21:18:17 GMT-3

Next message: kwasi-ccie@comcast.net: "Authentication Proxy"
Previous message: Dennis Laganiere: "RE: Where to buy? 19" Relay Rack preferably under 6 feet in"
Maybe in reply to: Greg Gombas: "IE Vol1 LAB 2 Multicast over Frame Relay Cloud"
Next in thread: Scott Morris: "RE: IE Vol1 LAB 2 Multicast over Frame Relay Cloud"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

In this scenario (not to be confused with the other RPF thread) R1, R2, R3
are in a full mesh sharing subnet 132.1.0.x/24. All interfaces in the frame
relay mesh have PIM sparse mode enabled.

The join packet is coming from 132.1.0.1 which is the frame relay interface
of R1.
The packet is being forwarded to 132.1.0.3 which is the frame relay
interface of R3. R3 should forward the packet to 132.1.0.2 which is the
frame relay interface of R2, however its best route is via the direct
point-to-point link to R2. The point to point link does not have PIM
enabled.

[R6] (Source)
      |
    [R2]
  / .2 \ \
/.1 .3\ \
[R1]-----[R3]
|
[SW1] (Receiver)

I apologize if I am not articulating the scenario correctly.

----Original Message Follows----
From: "Scott Morris" <swm@emanon.com>
Reply-To: <swm@emanon.com>
To: "'Greg Gombas'"
<ggombas@hotmail.com>,<bmcgahan@internetworkexpert.com>,<ccielab@groupstudy.com>
Subject: RE: IE Vol1 LAB 2 Multicast over Frame Relay Cloud
Date: Wed, 4 Jan 2006 18:44:34 -0500

Where's that IP coming from? Are 131.1.0.1 and 131.1.0.2 the IP's on the
shared serial link? Which one? The PIM-enabled one or not?

-----Original Message-----
From: Greg Gombas [mailto:ggombas@hotmail.com]
Sent: Wednesday, January 04, 2006 5:25 PM
To: swm@emanon.com; bmcgahan@internetworkexpert.com; ccielab@groupstudy.com
Subject: RE: IE Vol1 LAB 2 Multicast over Frame Relay Cloud

Yes I did "debug ip mrouting rpf-events" on both routers and neither
generated any messages. I did have "no ip mroute-cache" configured on the
interfaces.

The only difference I noticed before and after adding the static mroute is
that mroute table now showed 132.1.0.2 as the RPF neighbor.

Before...

Rack1R3#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, 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

(*, 228.28.28.28), 01:51:37/00:03:24, RP 150.1.2.2, flags: S
    Incoming interface: Null, RPF nbr 0.0.0.0, Mroute
    Outgoing interface list:
      Serial1/0/0, 132.1.0.1, Forward/Sparse, 00:06:01/00:03:24

(*, 224.0.1.40), 03:19:22/00:02:57, RP 150.1.2.2, flags: SJCL
    Incoming interface: Null, RPF nbr 0.0.0.0, Mroute
    Outgoing interface list:
      FastEthernet1/0, Forward/Sparse, 03:19:15/00:02:57
      Serial1/0/0, 132.1.0.1, Forward/Sparse, 00:06:16/00:02:51

Rack1R3#

After...

(*, 228.28.28.28), 01:55:38/00:03:19, RP 150.1.2.2, flags: S
    Incoming interface: Serial1/0/0, RPF nbr 132.1.0.2, Mroute
    Outgoing interface list:
      Serial1/0/0, 132.1.0.1, Forward/Sparse, 00:10:02/00:03:19

(132.1.6.6, 228.28.28.28), 00:02:34/00:03:28, flags: T
    Incoming interface: Serial1/0/0, RPF nbr 132.1.0.2, Mroute
    Outgoing interface list:
      Serial1/0/0, 132.1.0.1, Forward/Sparse, 00:02:35/00:03:18

(132.1.26.6, 228.28.28.28), 00:02:35/00:03:27, flags: T
    Incoming interface: Serial1/0/0, RPF nbr 132.1.0.2, Mroute
    Outgoing interface list:
      Serial1/0/0, 132.1.0.1, Forward/Sparse, 00:02:35/00:03:18

(*, 224.0.1.40), 03:23:24/00:02:55, RP 150.1.2.2, flags: SJCL
    Incoming interface: Serial1/0/0, RPF nbr 132.1.0.2, Mroute
    Outgoing interface list:
      FastEthernet1/0, Forward/Sparse, 03:23:17/00:01:56
      Serial1/0/0, 132.1.0.1, Forward/Sparse, 00:10:18/00:02:54

Rack1R3#

----Original Message Follows----
From: "Scott Morris" <swm@emanon.com>
Reply-To: <swm@emanon.com>
To: "'Greg Gombas'"
<ggombas@hotmail.com>,<bmcgahan@internetworkexpert.com>,<ccielab@groupstudy.
com>
Subject: RE: IE Vol1 LAB 2 Multicast over Frame Relay Cloud
Date: Wed, 4 Jan 2006 16:58:17 -0500

When you were looking at this, on your router that is the RP (and this one),
had you done the "debug ip mrouting rpf-events" and see what was being
displayed? With the RP communications (as you see some messages there), it
really is two-way communications to get things set up.

Scott

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Greg
Gombas
Sent: Wednesday, January 04, 2006 4:24 PM
To: bmcgahan@internetworkexpert.com; ccielab@groupstudy.com
Subject: RE: IE Vol1 LAB 2 Multicast over Frame Relay Cloud

Debug ip mpacket shows absolutley no output. I did have "no ip mroute-cache"

on all interfaces.

When I do a debug ip pim, however, I get the following:

Rack1R3#
Rack1R3#debug ip pim
PIM debugging is on
Rack1R3#
*Jan 4 21:12:40.247: PIM(0): Received v2 Join/Prune on Serial1/0/0 from
132.1.0.1, to us *Jan 4 21:12:40.247: PIM(0): Join-list: (*, 224.0.1.40),
RPT-bit set, WC-bit set, S-bit set * *Jan 4 21:12:40.247: PIM(0): Update
Serial1/0/0/132.1.0.1 to (*, 224.0.1.40), Forward state, by PIM *G Join *Jan
4 21:12:52.067: PIM(0): Received v2 Join/Prune on Serial1/0/0 from
132.1.0.1, to us *Jan 4 21:12:52.067: PIM(0): Join-list: (*, 228.28.28.28),
RPT-bit set, WC-bit set, S-bit set *Jan 4 21:12:52.067: PIM(0): Update
Serial1/0/0/132.1.0.1 to (*, 228.28.28.28), Forward state, by PIM *G Join
*Jan 4 21:13:08.051: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit)
Prune message for 224.0.1.40 *Jan 4 21:13:10.951: PIM(0): Building Periodic
(*,G) Join / (S,G,RP-bit) Prune message for 228.28.28.28 *Jan 4
21:13:40.019: PIM(0): Received v2 Join/Prune on Serial1/0/0 from 132.1.0.1,
to us *Jan 4 21:13:40.019: PIM(0): Join-list: (*, 224.0.1.40), RPT-bit set,
WC-bit set, S-bit set *Jan 4 21:13:40.019: PIM(0): Update
Serial1/0/0/132.1.0.1 to (*, 224.0.1.40), Forward state, by PIM *G Join *Jan
4 21:13:51.639: PIM(0): Received v2 Join/Prune on Serial1/0/0 from
132.1.0.1, to us *Jan 4 21:13:51.639: PIM(0): Join-list: (*, 228.28.28.28),
RPT-bit set, WC-bit set, S-bit set *Jan 4 21:13:51.639: PIM(0): Update
Serial1/0/0/132.1.0.1 to (*, 228.28.28.28), Forward state, by PIM *G Join
Show ip mroute shows the following:
Rack1R3#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, 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

Rack1R3#
But once I enter the ip mroute, it all starts working...

ack1R3(config)#
Rack1R3(config)#ip mroute 0.0.0.0 0.0.0.0 132.1.0.2 *Jan 4 21:16:09.063:
PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for
224.0.1.40 *Jan 4 21:16:09.063: PIM(0): Insert (*,224.0.1.40) join in nbr
132.1.0.2's queue *Jan 4 21:16:09.063: PIM(0): Building Join/Prune packet
for nbr 132.1.0.2 *Jan 4 21:16:09.063: PIM(0): Adding v2 (150.1.2.2/32,
224.0.1.40), WC-bit, RPT-bit, S-bit Join *Jan 4 21:16:09.063: PIM(0): Send
v2 join/prune to 132.1.0.2 (Serial1/0/0) *Jan 4 21:16:09.463: PIM(0):
Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 228.28.28.28
*Jan 4 21:16:09.463: PIM(0): Insert (*,228.28.28.28) join in nbr
132.1.0.2's queue Rack1R3(config)# *Jan 4 21:16:09.463: PIM(0): Building
Join/Prune packet for nbr 132.1.0.2 *Jan 4 21:16:09.463: PIM(0): Adding v2
(150.1.2.2/32, 228.28.28.28), WC-bit, RPT-bit, S-bit Join *Jan 4
21:16:09.463: PIM(0): Send v2 join/prune to 132.1.0.2 (Serial1/0/0)
Rack1R3(config)# *Jan 4 21:16:23.479: IP(0): s=132.1.6.6 (Serial1/0/0)
d=228.28.28.28(Serial1/0/0) id=9679, ttl=253, prot=1, len=100(100), mforward

*Jan 4 21:16:23.487: PIM(0): Received v2 Join/Prune on Serial1/0/0 from
132.1.0.1, to us *Jan 4 21:16:23.487: PIM(0): Join-list: (132.1.26.6/32,
228.28.28.28), S-bit set *Jan 4 21:16:23.487: PIM(0): Add
Serial1/0/0/132.1.0.1 to (132.1.26.6, 228.28.28.28), Forward state, by PIM
SG Join *Jan 4 21:16:23.487: PIM(0): Insert (132.1.26.6,228.28.28.28) join
in nbr 132.1.0.2's queue *Jan 4 21:16:23.487: PIM(0): Building Join/Prune
packet for nbr 132.1.0.2 *Jan 4 21:16:23.487: PIM(0): Adding v2
(132.1.26.6/32, 228.28.28.28), S-bit Join *Jan 4 21:16:23.487: PIM(0): Send
v2 join/prune to 132.1.0.2 (Serial1/0/0) *Jan 4 21:16:23.499: PIM(0):
Received v2 Join/Prune on Serial1/0/0 from 132.1.0.1, to us *Jan 4
21:16:23.499: PIM(0): Join-list: (132.1.6.6/32, 228.28.28.28), S-bit set
*Jan 4 21:16:23.499: PIM(0): Add Serial1/0/0/132.1.0.1 to (132.1.6.6,
228.28.28.28), Forward state, by PIM SG Join *Jan 4 21:16:23.499: PIM(0):
Insert (132.1.6.6,228.28.28.28) join in nbr 132.1.0.2's queue *Jan 4
21:16:23.499: PIM(0): Building Join/Prune packet for nbr 132.1.0.2 *Jan 4
21:16:23.499: PIM(0): Adding v2 (132.1.6.6/32, 228.28.28.28), S-bit Join
*Jan 4 21:16:23.499: PIM(0): Send v2 join/prune to 132.1.0.2
(Serial1/0/0))# Rack1R3(config)# *Jan 4 21:16:25.671: PIM(0): Received
RP-Reachable on Serial1/0/0 from
150.1.2.2
*Jan 4 21:16:25.671: PIM(0): Received RP-Reachable on Serial1/0/0 from
150.1.2.2
*Jan 4 21:16:25.671: for group 228.28.28.28
*Jan 4 21:16:25.671: PIM(0): Forward RP-reachability for 228.28.28.28 on
Serial1/0/0

Rack1R3#

Can you explain why this only works with the static mroute?
I thought static mroute is configured to allow incoming traffic on a non-RPF
interface.
In this case it is the outgoing join message that was not being sent...

----Original Message Follows----
From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
To: "Greg Gombas" <ggombas@hotmail.com>,<ccielab@groupstudy.com>
Subject: RE: IE Vol1 LAB 2 Multicast over Frame Relay Cloud
Date: Wed, 4 Jan 2006 15:01:54 -0500

Send traffic from VLAN 6 to the destination and "debug ip mpacket"
on R3. Make sure to issue the "no ip mroute-cache" interface level command
on R3. What do these results tell you?

Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com

Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/

> -----Original Message-----
> From: Greg Gombas [mailto:ggombas@hotmail.com]
> Sent: Wednesday, January 04, 2006 1:36 PM
> To: Brian McGahan; ccielab@groupstudy.com
> Subject: RE: IE Vol1 LAB 2 Multicast over Frame Relay Cloud
>
> Hi Brian,
>
> In my first posting I forgot to mention the additional point to point
link
> between R2 and R3 which is exchanging EIGRP.
> This point-to-point link is the preffered path to the loopback address
of
> R2.
> Unfortunately the task requirement does not allow you to configure PIM
on
> this point to point link.
>
> It looks like this:
>
> R6 (Source)
> |
> R2-
> / \ \
> R1----R3
> |
> SW1 (Receiver)
>
> Can you tell me why an mroute on R3 pointing to the frame relay
interface
> of
> R2 allows this to work?
>
> ----Original Message Follows----
> From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
> To: "Greg Gombas" <ggombas@hotmail.com>,<ccielab@groupstudy.com>
> Subject: RE: IE Vol1 LAB 2 Multicast over Frame Relay Cloud
> Date: Wed, 4 Jan 2006 12:49:02 -0500
>
> If they are in a full mesh why would R1 see R3 as the next-hop to reach
> R2?
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
> 24/7 Support: http://forum.internetworkexpert.com
> Live Chat: http://www.internetworkexpert.com/chat/
>
> ________________________________
>
> From: nobody@groupstudy.com on behalf of Greg Gombas
> Sent: Tue 1/3/2006 4:40 PM
> To: ccielab@groupstudy.com
> Subject: IE Vol1 LAB 2 Multicast over Frame Relay Cloud
>
>
>
> Hello,
>
> I was hoping someone help me figure out this scenario.
>
> R6 (Source)
> |
> R2
> / \
> R1----R3
> |
> SW1 (Receiver)
>
> R1, R2 and R3 are connected via a full frame relay mesh.
> OSPF is runnig on the frame relay mesh in point-to-multipoint mode.
>
> R2 is acting as RP with static RP configured on all devices.
>
> R1 is showing R3 as next hop to RP.
>
> I am doing debug ip pim on all devices and I can see that R1 is sending
> the
> PIM join message from SW1 to R3 but R3 is not forwarding the join
message
> to
> R2.
>
> I did all the debugs I can think of on R3 but there is no indication of
an
> RPF failure. How can I troubleshoot this?
>
> Thanks,
> Greg
>
>

Next message: kwasi-ccie@comcast.net: "Authentication Proxy"
Previous message: Dennis Laganiere: "RE: Where to buy? 19" Relay Rack preferably under 6 feet in"
Maybe in reply to: Greg Gombas: "IE Vol1 LAB 2 Multicast over Frame Relay Cloud"
Next in thread: Scott Morris: "RE: IE Vol1 LAB 2 Multicast over Frame Relay Cloud"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

This archive was generated by hypermail 2.1.4 : Wed Feb 01 2006 - 07:45:47 GMT-3