From mailman-bounces@ietf.org Fri Oct 1 06:10:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13221 for ; Fri, 1 Oct 2004 06:10:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJZS-00072f-IM for ssm-archive@lists.ietf.org; Fri, 01 Oct 2004 05:19:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ssm-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:04:18 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ssm-archive@lists.ietf.org: List Password // URL ---- -------- ssm@ietf.org mifemu https://www1.ietf.org/mailman/options/ssm/ssm-archive%40lists.ietf.org From ssm-bounces@ietf.org Tue Oct 12 19:39:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28159 for ; Tue, 12 Oct 2004 19:39:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHW9N-00087d-J2; Tue, 12 Oct 2004 19:33:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHVwD-0005U7-0G for ssm@megatron.ietf.org; Tue, 12 Oct 2004 19:20:13 -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 TAA27141 for ; Tue, 12 Oct 2004 19:20:10 -0400 (EDT) Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHW72-0006N9-0a for ssm@ietf.org; Tue, 12 Oct 2004 19:31:25 -0400 Message-ID: <6FEB46B4943AA348B0776325DA8EC37F02060EC0@entcoexch01.broadband.att.com> From: "Field, Brian" To: ssm@ietf.org Date: Tue, 12 Oct 2004 17:19:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [ssm] Dual homed multicast src and SSM X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org 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 From ssm-bounces@ietf.org Tue Oct 12 20:24:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01619 for ; Tue, 12 Oct 2004 20:24:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHWok-0004aq-Pk; Tue, 12 Oct 2004 20:16:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHWjZ-0002Ml-3F for ssm@megatron.ietf.org; Tue, 12 Oct 2004 20:11:13 -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 UAA00511 for ; Tue, 12 Oct 2004 20:11:11 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.197] helo=mproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHWuL-0007Fs-VA for ssm@ietf.org; Tue, 12 Oct 2004 20:22:25 -0400 Received: by mproxy.gmail.com with SMTP id 77so880486rnl for ; Tue, 12 Oct 2004 17:11:07 -0700 (PDT) Received: by 10.38.126.38 with SMTP id y38mr2594825rnc; Tue, 12 Oct 2004 17:11:07 -0700 (PDT) Received: by 10.38.66.53 with HTTP; Tue, 12 Oct 2004 17:11:07 -0700 (PDT) Message-ID: Date: Tue, 12 Oct 2004 20:11:07 -0400 From: Marshall Eubanks To: "Field, Brian" Subject: Re: [ssm] Dual homed multicast src and SSM In-Reply-To: <6FEB46B4943AA348B0776325DA8EC37F02060EC0@entcoexch01.broadband.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <6FEB46B4943AA348B0776325DA8EC37F02060EC0@entcoexch01.broadband.att.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: ssm@ietf.org X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marshall Eubanks List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear Brian; Routers set up trees, not edge devices (such as sources). Generally, by "dual homed" you mean "part of an Autonomous System / PIM domain with connections to two or more other AS / PIM Domains." This is done by routers, so if your source is _directly_ connected to interfaces leading to other domains, it will have to act like a router and send and receive PIM control traffic. However, generally sources are not directly attached to other domains, and sources and receivers do not participate in PIM and MBGP control traffic. The internal multicast routing protocol takes care of the tree creation inside the domain, and PIM and MBGP take care of the tree creation between domains. So, this does not seem like a problem to me - SSM introduces nothing new to multicast routing. If am am missing something, please let me know. Regards Marshall Eubanks On Tue, 12 Oct 2004 17:19:04 -0600, 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 From ssm-bounces@ietf.org Wed Oct 13 14:33:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22352 for ; Wed, 13 Oct 2004 14:33:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHnpr-0004Ey-8y; Wed, 13 Oct 2004 14:26:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHnkG-00039Q-5i for ssm@megatron.ietf.org; Wed, 13 Oct 2004 14:21:04 -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 OAA21511 for ; Wed, 13 Oct 2004 14:21:05 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHnvF-0002Ab-Bx for ssm@ietf.org; Wed, 13 Oct 2004 14:32:26 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 13 Oct 2004 11:26:54 -0700 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9DIKPYJ007771; Wed, 13 Oct 2004 11:20:25 -0700 (PDT) Received: from bwilliam-t30.cisco.com (rtp-vpn3-211.cisco.com [10.82.216.211]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA13198; Wed, 13 Oct 2004 11:20:29 -0700 (PDT) Message-Id: <6.0.0.22.2.20041013131802.0325ba60@edison.cisco.com> X-Sender: bwilliam@edison.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Wed, 13 Oct 2004 13:20:54 -0500 To: "Field, Brian" , ssm@ietf.org From: Beau Williamson Subject: Re: [ssm] Dual homed multicast src and SSM In-Reply-To: <6FEB46B4943AA348B0776325DA8EC37F02060EC0@entcoexch01.broad band.att.com> References: <6FEB46B4943AA348B0776325DA8EC37F02060EC0@entcoexch01.broadband.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org 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 From ssm-bounces@ietf.org Wed Oct 13 15:14:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26496 for ; Wed, 13 Oct 2004 15:14:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHoSH-0000mm-A3; Wed, 13 Oct 2004 15:06:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHoIM-000192-AC for ssm@megatron.ietf.org; Wed, 13 Oct 2004 14:56:18 -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 OAA23891 for ; Wed, 13 Oct 2004 14:56:19 -0400 (EDT) Received: from pacdcoavas05.cable.comcast.com ([208.17.33.54]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHoTN-0002pw-51 for ssm@ietf.org; Wed, 13 Oct 2004 15:07:41 -0400 Message-ID: <6FEB46B4943AA348B0776325DA8EC37F02060FBB@entcoexch01.broadband.att.com> From: "Field, Brian" To: Beau Williamson , ssm@ietf.org Subject: RE: [ssm] Dual homed multicast src and SSM Date: Wed, 13 Oct 2004 12:55:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-BeenThere: ssm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Source-Specific Multicast List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org 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 From ssm-bounces@ietf.org Thu Oct 14 20:35:57 2004 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 ; 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 ; 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" , ssm@ietf.org From: Beau Williamson 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1620614122==" Sender: ssm-bounces@ietf.org Errors-To: ssm-bounces@ietf.org --===============1620614122== Content-Type: multipart/alternative; boundary="=====================_3695463==.ALT" --=====================_3695463==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed 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 > > --=====================_3695463==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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@ci= sco.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=20
> 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
>
--=====================_3695463==.ALT-- --===============1620614122== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm --===============1620614122==--