From: Scott Morris (smorris@ipexpert.com)
Date: Sat Sep 15 2007 - 03:47:36 ART
In a shared tree (*,G) the RPF check is against the RP's address, not the
original source of the IP multicast packet. So you may be referencing the
wrong address in your mroute command.
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE
#153, CISSP, et al.
CCSI/JNCI-M/JNCI-J
VP - Technical Training - IPexpert, Inc.
IPexpert Sr. Technical Instructor
A Cisco Learning Partner - We Accept Learning Credits!
smorris@ipexpert.com
Telephone: +1.810.326.1444
Fax: +1.810.454.0130
http://www.ipexpert.com
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Steeneken, Robert
Sent: Saturday, September 15, 2007 2:37 AM
To: NET HE; ryan.alt@berbee.com; ccielab@groupstudy.com
Subject: RE: mroute
I tried that also but no difference, want I find strange is that the RPF
check stays the same when I add the mroute.
________________________________
From: NET HE [mailto:he_net@hotmail.com]
Sent: Sat 15-9-2007 3:22
To: ryan.alt@berbee.com; Steeneken, Robert; ccielab@groupstudy.com
Subject: RE: mroute
You need add another mroute at R7 for multicast source RPF check.
In your mail, you said "In the routing table on R7 is R5 the next hop to
reach to R4 R2 and R1", so when multicast stream coming down to R7, R7 sees
the source is from R6 instead of R5, RPF check fails.
Best Regards,
Net (Xin) He
>From: "Alt, Ryan" <ryan.alt@berbee.com>
>Reply-To: "Alt, Ryan" <ryan.alt@berbee.com>
>To: <robert.steeneken@getronics.com>, <ccielab@groupstudy.com>
>Subject: RE: mroute
>Date: Fri, 14 Sep 2007 16:46:23 -0500
>MIME-Version: 1.0
>Received: from lists.groupstudy.com ([207.44.210.9]) by
>bay0-mc9-f18.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668);
>Fri,
>14 Sep 2007 14:59:28 -0700
>Received: (from sympa@localhost)by lists.groupstudy.com
>(8.12.11.20060308/8.11.6) id l8ELxFmq020193;Fri, 14 Sep 2007 17:59:15
>-0400
>Received: from groupstudy.com (www.groupstudy.com [209.51.144.7])by
>lists.groupstudy.com (8.12.11.20060308/8.11.6) with ESMTP id
>l8ELlRnU020034for <ccielab@lists.groupstudy.com>; Fri, 14 Sep 2007
>17:47:28 -0400
>Received: from groupstudy.com (groupstudy.com [127.0.0.1])by
>groupstudy.com
>(8.12.11.20060308/8.12.11) with ESMTP id l8ELlYjb002671GroupStudy
>Mailer; Fri, 14 Sep 2007 17:47:34 -0400
>Received: (from listserver@localhost)by groupstudy.com
>(8.12.11.20060308/8.12.11/Submit) id l8ELlXu3002668for ccielabxhiddenx;
>Fri, 14 Sep 2007 17:47:33 -0400
>Received: from ctg-msnexc01.staff.berbee.com (msn-office-flr2.binc.net
>[64.73.12.254]) by groupstudy.com (8.12.11.20060308/8.12.11) with
>ESMTP id
>l8ELlViX002624 GroupStudy Mailer; Fri, 14 Sep 2007 17:47:31 -0400
>X-Message-Delivery: Vj0zLjQuMDt1cz0wO2k9MDtsPTA7YT0w
>X-Message-Info:
>KsclG709nLT3IBjEF4JczAge/tkLBRdX95Ovb3Nxlo9XcXyJkW8PGd6e3xcRRzxJfJwMHea
>z687gjujiwIA0pwoHoV7HiB+S
>Content-class: urn:content-classes:message
>Thread-Topic: mroute
>Thread-Index: Acf3D/y8N8lxWoU8T1Sr7ACBSi+gOAACLS81
>References: <sympa.1189800107.17865.667@groupstudy.com>
>X-MIME-Autoconverted: from quoted-printable to 8bit by groupstudy.com
>id
>l8ELlViX002624
>X-ASK-Info: Whitelist match [from ryan\.alt@berbee\.com] (2007/09/14
>17:47:33)
>X-Loop: ccielab@groupstudy.com
>X-Sequence: 1397
>Errors-to: ccielab-owner@groupstudy.com
>Precedence: bulk
>X-no-archive: yes
>List-Id: <ccielab.groupstudy.com>
>List-Help: <mailto:sympa@groupstudy.com?subject=help>
>List-Subscribe:
><mailto:sympa@groupstudy.com?subject=subscribe%20ccielab>
>List-Unsubscribe:
><mailto:sympa@groupstudy.com?subject=unsubscribe%20ccielab>
>List-Post: <mailto:ccielab@groupstudy.com>
>List-Owner: <mailto:ccielab-request@groupstudy.com>
>Return-Path: ccielab-owner@groupstudy.com
>X-OriginalArrivalTime: 14 Sep 2007 21:59:29.0035 (UTC)
>FILETIME=[85DC0DB0:01C7F71A]
>
>The first solution that comes to mind is a GRE tunnel, but I'm not sure
>exactly why it doesn't work. That's an interesting problem...
>
>________________________________
>
>From: nobody@groupstudy.com on behalf of robert.steeneken@getronics.com
>Sent: Fri 9/14/2007 3:23 PM
>To: ccielab@groupstudy.com
>Subject: mroute
>
>
>
>A question about mroute on a lan. I have the following situation.
> R1
> |
> R2 (RP)
> |
> R4
> / \
> / \
> R5 R6
> __|______|__
> |
> R7
>
>On R5 is multicast not enabled.
>In the routing table on R7 is R5 the next hop to reach to R4 R2 and R1
>So on R7 the rpf check fails, when I add the next mroute
>
> *, 224.2.2.2), 00:13:55/00:02:56, RP 140.40.2.2, flags: SCL
> Incoming interface: FastEthernet0.56, RPF nbr 140.40.56.5
> Outgoing interface list:
> Loopback0, Forward/Sparse, 00:13:55/00:02:56
>
>R7(config)#ip mroute 140.40.2.2 255.255.255.255 140.40.56.6
>
>(*, 224.2.2.2), 00:00:02/00:02:57, RP 140.40.2.2, flags: SCL
> Incoming interface: FastEthernet0.56, RPF nbr 140.40.56.5, Mroute
> Outgoing interface list:
> Loopback0, Forward/Sparse, 00:00:02/00:02:57
>
>A ping to 224.2.2.2 (both loopbacks on R6 and R7 have a igmp join) only
>shows a result for R6 and not R7
>
>But when i divide the lan between R5 R6 R7 in two seperated vlans and I
>change the mroute
>
>ip mroute 140.40.2.2 255.255.255.255 140.40.76.6
>
>(*, 224.2.2.2), 00:01:04/00:02:59, RP 140.40.2.2, flags: SCL
> Incoming interface: FastEthernet0.76, RPF nbr 140.40.76.6, Mroute
> Outgoing interface list:
> Loopback0, Forward/Sparse, 00:01:04/00:02:25
>
>Now the RPF check don't fails and a ping to 224.2.2.2 works.
>
>What did I wrong in the first situation? Or how could I have fixed the
>RPF with a mroute.
>
>Robert.
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Oct 06 2007 - 12:01:12 ART