[Dime] failover scenario
"Poscic, Kristian (Kristian)" <kristian.poscic@alcatel-lucent.com> Tue, 11 December 2012 00:39 UTC
Return-Path: <kristian.poscic@alcatel-lucent.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E3C21F86FB for <dime@ietfa.amsl.com>; Mon, 10 Dec 2012 16:39:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.382
X-Spam-Level:
X-Spam-Status: No, score=-7.382 tagged_above=-999 required=5 tests=[AWL=-1.134, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyY5TqLRi9td for <dime@ietfa.amsl.com>; Mon, 10 Dec 2012 16:39:54 -0800 (PST)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 55B9821F86FA for <dime@ietf.org>; Mon, 10 Dec 2012 16:39:48 -0800 (PST)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qBB0dgwa024587 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <dime@ietf.org>; Tue, 11 Dec 2012 01:39:46 +0100
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 11 Dec 2012 01:39:44 +0100
Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.227]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Mon, 10 Dec 2012 19:39:28 -0500
From: "Poscic, Kristian (Kristian)" <kristian.poscic@alcatel-lucent.com>
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: failover scenario
Thread-Index: Ac3XNgVVklLO7zbqTReQ9dDlPt2SKw==
Date: Tue, 11 Dec 2012 00:39:25 +0000
Message-ID: <7921F977B17D5B49B8DCC955A339D2F02AA28B4D@US70UWXCHMBA05.zam.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.18]
Content-Type: multipart/alternative; boundary="_000_7921F977B17D5B49B8DCC955A339D2F02AA28B4DUS70UWXCHMBA05z_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84
Subject: [Dime] failover scenario
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Dec 2012 00:39:56 -0000
Does anyone know what would be the mechanism in Base Diameter to handle the following scenario properly: - There are two NASes that run certain application (Gx in this case) - They are in standby/active mode - in other words, the NAS1 is active and has peering session with DMR-SRV. NAS2 is synched to NAS (Gx session are synched and diameter entities are synched too - origin-host, origin-realm, possibly more AVPs...). However NAS2 is standby and therefore quiet (no peering session is established with DMR-SRV) - If the NAS 1 fails, the NAS2 takes over (it detects the failure and activates itself along with application that is running on top of Base Diameter) - At this point, NAS2 will establish a peering session with DMR-SRV. The only difference between NAS2 and the failed NAS1 is the Host-IP-address (as AVP and also the source IP address in the transport => src IPs are not synched). - When the NAS2 sends CER and the peering session is established with DMR-SRV, will the DMR-SRV automatically update its routing table and see that nas.example.com is now at IP2 and not at IP1. Consequently all subsequent messages would be exchanged between NAS2 and DMR-SRV - All this presuppose that there are no changes on the application layer (Gx for example is completely synched between NASes) and the re-routing is handled at the Base Diameter. - Would this work and if not what would be the recommended approach that is compliant with Base Diameter so that the routing in DMR-SRV is updated properly? Origin-host = nas.example.com Origin-realm= example.com Host-IP-Address = IP1 --------- |NAS1 | ------------------- --------- | | -------------- |-----------------| DMR-SRV| --------- | -------------- |NAS2 |------------------- --------- Origin-host = nas.example.com Origin-realm= example.com Host-IP-Address = IP2 Thanks, Kris
- [Dime] failover scenario Poscic, Kristian (Kristian)