RE: [ssm] Dual homed multicast src and SSM

Beau Williamson <bwilliam@cisco.com> Fri, 15 October 2004 00:35 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24971 for <ssm-archive@lists.ietf.org>; Thu, 14 Oct 2004 20:35:57 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIG1m-00058J-LD; Thu, 14 Oct 2004 20:33:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIG1M-00050c-Ts for ssm@megatron.ietf.org; Thu, 14 Oct 2004 20:32:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24669 for <ssm@ietf.org>; Thu, 14 Oct 2004 20:32:35 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIGCb-0001iC-V5 for ssm@ietf.org; Thu, 14 Oct 2004 20:44:15 -0400
Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 14 Oct 2004 17:32:59 -0700
X-BrightmailFiltered: true
Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i9F0W19b009433; Thu, 14 Oct 2004 17:32:02 -0700 (PDT)
Received: from bwilliam-t30.cisco.com (rcdn-bwilliam-3002-2.cisco.com [10.89.26.27]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA11214; Thu, 14 Oct 2004 17:32:00 -0700 (PDT)
Message-Id: <6.0.0.22.2.20041014192456.033f0ed0@edison.cisco.com>
X-Sender: bwilliam@edison.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
Date: Thu, 14 Oct 2004 19:32:27 -0500
To: "Field, Brian" <Brian_Field@cable.comcast.com>, ssm@ietf.org
From: Beau Williamson <bwilliam@cisco.com>
Subject: RE: [ssm] Dual homed multicast src and SSM
In-Reply-To: <6FEB46B4943AA348B0776325DA8EC37F02060FBB@entcoexch01.broad band.att.com>
References: <6FEB46B4943AA348B0776325DA8EC37F02060FBB@entcoexch01.broadband.att.com>
Mime-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b
X-BeenThere: ssm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Source-Specific Multicast <ssm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ssm@ietf.org>
List-Help: <mailto:ssm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1620614122=="
Sender: ssm-bounces@ietf.org
Errors-To: ssm-bounces@ietf.org

But what if the unix box fails??  Wouldn't it be better to have another box 
ready to take over the task?  This is anycast sources and would probably be 
a better solution.  The idea is that you have two sources in the network at 
different locations but using the same IP address.  The routers connected 
to these two sources each advertise routes to the source.  Each half of the 
network joins the SPT to nearest source based on the unicast routing 
information.  (Basic Anycasting).  Now if the GE link to the first source 
fails or the source itself fails then the only remaining route to the 
source is to the second source (which is using the same IP address).  Thus, 
in a perfect world, all the receivers in the network simple join to (S,G) 
via IGMPv3 and SSM. In a not so perfect world, we can accomplish the same 
thing with ASM.  We just have to have some RP's to bootstrap the flow via 
the Shared Tree and then just let the normal switch to the SPT do its thing.

If you still want to stick to the way you suggested (and ignore what 
happens if the source unix workstation fails) then you would have to write 
some code in the unix box to have it bring up the other GE interface when 
the first one fails.  Much harder to accomplish than the Anycast Sources I 
mentioned above.

Beau
At 10/13/2004 01:55 PM, Field, Brian wrote:

>Sorry for the confusion.
>
>By dual homed I mean a device which originates m-cast content and which is
>connected to two routers.  All devices are in the same ASN.  In an SSM
>environment, the S in the
>(S,G) would be an IP associated with this device.
>
>So think of a unix box with two GEs connected to two different routers and
>srcing traffic to an SSM channel.
>
>Since the device has two GEs, I'd like the unix box to be able to continue
>to src content to (S,G) even when one of the GE Links fails (or we do maint
>on one of the routers, etc.).  Think this means then that the S can't be
>associated with a GE physical link IP but more like a loopback like IP
>associated with the unix box.  So the question becomes, how do the directly
>connected routers Construct the right state on their GE interfaces to accept
>the Traffic being src'd by unix box.
>
>For this to work, does my unix box need to run PIM-SSM?  Or do I need to run
>HSRP to
>have the unix box appear to be an interface on both routers?  Or ... ?
>
>Thanks
>Brian
>
>
>
> > -----Original Message-----
> > From: Beau Williamson [mailto:bwilliam@cisco.com]
> > Sent: Wednesday, October 13, 2004 12:21 PM
> > To: Field, Brian; ssm@ietf.org
> > Subject: Re: [ssm] Dual homed multicast src and SSM
> >
> > Brian,
> >
> > There is nothing specific to SSM that would prevent the trees
> > from being setup between one AS and another.  The fact that
> > the source domain is dual-homed only means that there are two
> > paths form where Joins can arrive (from other domains).  This
> > is of course controlled with normal BGP metrics and is no
> > different from hosts in other AS's wishing to "send" unicast
> > traffic to the source host.
> >
> > Beau
> > At 10/12/2004 06:19 PM, Field, Brian wrote:
> >
> > >Consider a network operating in SSM and a dual homed multicast src
> > >device.  Is there a standard way to setup the forwarding between the
> > >routers and the src device to get the SSM trees built
> > properly?  Seems
> > >as if the device needs to eiter participate in routing and
> > announce the
> > >src IP or run something like HSRP.  Issues with these approaches?
> > >Other options?
> > >
> > >Thanks
> > >Brian
> > >
> > >_______________________________________________
> > >ssm mailing list
> > >ssm@ietf.org
> > >https://www1.ietf.org/mailman/listinfo/ssm
> >
_______________________________________________
ssm mailing list
ssm@ietf.org
https://www1.ietf.org/mailman/listinfo/ssm