From vrrp-bounces@ietf.org Wed Sep 3 23:24:44 2008 Return-Path: X-Original-To: vrrp-archive@megatron.ietf.org Delivered-To: ietfarch-vrrp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D24F83A6834; Wed, 3 Sep 2008 23:24:44 -0700 (PDT) X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A85E63A6843 for ; Wed, 3 Sep 2008 23:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.464 X-Spam-Level: X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmThA2uX-WXi for ; Wed, 3 Sep 2008 23:22:32 -0700 (PDT) Received: from web52206.mail.re2.yahoo.com (web52206.mail.re2.yahoo.com [206.190.48.129]) by core3.amsl.com (Postfix) with SMTP id D52CA3A67AD for ; Wed, 3 Sep 2008 23:22:31 -0700 (PDT) Received: (qmail 82279 invoked by uid 60001); 4 Sep 2008 06:22:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=rzNZ57IWP3WikdEeeStvdsypVYNwwRBdgBNNVVpdP2kq2i6OX9PREMe2xRy8ARH8Xgsev4ySWKdfCl87TKG4iI16nTIF9brdCzQGyoLDybtstod1ocE+Aiios5TuwUkxQBi3uy1UheO+uOho55kUJOpLS4xOj3jvJMDrERDBIEA=; X-YMail-OSG: RWVrBtgVM1kjGA13vyh9vJO8YZUC5wwlkiScEaLgmxiFzFydog4gXeFhhXfAIHUNkBUsgsKDsl7YrIgmsd6w5ChgWVOFTtkR4qDBy2Shtmq0huzN_WSTq9uJ14sXtSzHjDA- Received: from [220.224.229.70] by web52206.mail.re2.yahoo.com via HTTP; Wed, 03 Sep 2008 23:22:38 PDT X-Mailer: YahooMailRC/1096.28 YahooMailWebService/0.7.218.2 Date: Wed, 3 Sep 2008 23:22:38 -0700 (PDT) From: ashok meti To: vrrp@ietf.org MIME-Version: 1.0 Message-ID: <273557.82158.qm@web52206.mail.re2.yahoo.com> Subject: [VRRP] Questions X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2077748856==" Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org --===============2077748856== Content-Type: multipart/alternative; boundary="0-1565015884-1220509358=:82158" --0-1565015884-1220509358=:82158 Content-Type: text/plain; charset=us-ascii Hi Vrrp Members 1. Can we Allow user to configure same IP on 2 routers in VRRP group. If no how it is handled??? 2. What happens when new Router with highest priority then Original master enters VRRP Group. 3. 3 or more routers with some routers as preemption enabled and others with preemption disabled. How it works when new router with highest priority enters VRRP Group. -Ashok --0-1565015884-1220509358=:82158 Content-Type: text/html; charset=us-ascii
Hi Vrrp Members
  1. Can we Allow user to configure same IP on 2 routers in VRRP group. If no how it is handled???
  2. What happens when new Router with highest priority then Original master enters VRRP Group.
  3. 3 or more routers with some routers as preemption enabled and others with preemption disabled. How it works when new router with highest priority enters VRRP Group.
-Ashok

--0-1565015884-1220509358=:82158-- --===============2077748856== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp --===============2077748856==-- From vrrp-bounces@ietf.org Thu Sep 4 05:50:43 2008 Return-Path: X-Original-To: vrrp-archive@megatron.ietf.org Delivered-To: ietfarch-vrrp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCDEE3A685A; Thu, 4 Sep 2008 05:50:43 -0700 (PDT) X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFBAA3A6A50 for ; Thu, 4 Sep 2008 05:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcCjha0IiRvu for ; Thu, 4 Sep 2008 05:47:51 -0700 (PDT) Received: from mail-gx0-f16.google.com (mail-gx0-f16.google.com [209.85.217.16]) by core3.amsl.com (Postfix) with ESMTP id B24A53A681D for ; Thu, 4 Sep 2008 05:47:51 -0700 (PDT) Received: by gxk9 with SMTP id 9so6224344gxk.13 for ; Thu, 04 Sep 2008 05:47:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=CiT0c4CHxX1ody/JRn/2svTaA2AZhly5GF17uPxTxLg=; b=WXCNgP3+rg+P7Qg9Ol1wfpZ5BPWNxrvV6ybFtViVnxopMgOtDo5gkCCS/MPV+vK6PQ EGeq9LDQ+1C7bV+vDGLLBuR5L22W2fVKslgkKqy1qniQgJcra6u5beSomPilLHxUpqiD Tv0Fh5dw28cw11QXOnI8wucxZBq0/vBkcnINc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=DFmSe7M88UZbVqk8o5og2vIjzhZhV0/SBYBGPbSIT2zXSEeqD+W6GNirSy89KUs+8I FWBwzcys0XsxtplYu/703eqgfMAb5BY0FfcQ4XoBQh9hi345vsudQG7C8sIz6nqAchix bNRKiHzlWqC5YNbjZMLz/Z4/5H2h/i3fmIMK8= Received: by 10.150.98.18 with SMTP id v18mr12037326ybb.174.1220532466276; Thu, 04 Sep 2008 05:47:46 -0700 (PDT) Received: by 10.151.141.1 with HTTP; Thu, 4 Sep 2008 05:47:46 -0700 (PDT) Message-ID: <972212c40809040547o3d9a8875n3ce960821a9d15ce@mail.gmail.com> Date: Thu, 4 Sep 2008 18:17:46 +0530 From: "Ananda krishnan" To: vrrp@ietf.org MIME-Version: 1.0 Subject: [VRRP] help X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1379118111==" Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org --===============1379118111== Content-Type: multipart/alternative; boundary="----=_Part_38436_10509181.1220532466293" ------=_Part_38436_10509181.1220532466293 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, I'm running Redudnacy between two routers Router 1 : 192.168.0.1 Router 2 : 192.168.0.2 In any given scenarios Scenario 1 : Both has same Priority. R1 already up and running (Configured as PRIMARY , Operational state PRIMARY ) R2 brought in to the network (Configured as PRIMARY) R2 will take over as PRIMARY and R1 will become standby Scenario 2 : R1 already up and running (but IP address is changed to 192.168.0.2 ) rest same as above R2 brought in to the network .(same as above ). Now R1 is retaining its OP_State as PRIMARY. I tired this with 3 and 4 switches , Which ever switch comes with the Highest IP address will become PRIMARY. Can anyone please let me know is this the way VRRP works Reragds Anand ------=_Part_38436_10509181.1220532466293 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi All,
    
         I'm running Redudnacy between two routers
 
Router 1 : 192.168.0.1
Router 2 : 192.168.0.2
 
In any given scenarios
 
        Scenario 1 :
Both has same Priority.
 
 R1 already up and running (Configured as PRIMARY ,
Operational state PRIMARY )
 R2 brought in to the network (Configured as PRIMARY)
              R2 will take over as PRIMARY and R1 will become standby
 
       Scenario 2 :
  R1 already up and running (but IP address is changed to 192.168.0.2 ) rest same as above
 
  R2 brought in to the network .(same as above ).
             Now R1 is retaining its OP_State as PRIMARY.
 
     I tired this with 3 and 4 switches , Which ever switch comes with the Highest IP address will become PRIMARY.
 
Can anyone please let me know is this the way VRRP works
 
 
Reragds
Anand
 
 
 
------=_Part_38436_10509181.1220532466293-- --===============1379118111== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp --===============1379118111==-- From vrrp-bounces@ietf.org Mon Sep 8 13:08:12 2008 Return-Path: X-Original-To: vrrp-archive@megatron.ietf.org Delivered-To: ietfarch-vrrp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 413963A69AD; Mon, 8 Sep 2008 13:08:12 -0700 (PDT) X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC3733A69AD for ; Mon, 8 Sep 2008 13:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56gaGmSvm9Fr for ; Mon, 8 Sep 2008 13:08:09 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id D54853A6926 for ; Mon, 8 Sep 2008 13:08:09 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1463525rvf.49 for ; Mon, 08 Sep 2008 13:08:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=XxJuoZlIYw08BIAo8ojkeKOo+YY5PSh4RMBYT6DlUOc=; b=kijcgcz1Qra0waOutyw13STb1831IEm0XNMJduzjCvp110VVc4UM2rVZ8lJ53vadHF r/hOyBwDATD5C6jBIz6qBsKEzMz81VV3bEq8/7z1IDxtO3m+BmgZcd/sWrILZqoUpDJK jWXLA4hBje02G5psCHfKmlgWpKWfv6EA8KmFU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=GKfK7icLMIR3YrOr+LO+fYDV9keo3jPdlzWcR3W5m/5JzoSTVAGoRBBanFJLOIvx/l MZ/pzQwGB/2rt6YR54FmSbzXAA0InUGe0jQr0mB9JrW6sizcGB6xbejLHAqkW/iVlpCP HupYi09BMW2510F8KqSaXQ2l376dPu3Ffo4iU= Received: by 10.140.201.1 with SMTP id y1mr9104912rvf.246.1220904491893; Mon, 08 Sep 2008 13:08:11 -0700 (PDT) Received: by 10.141.20.15 with HTTP; Mon, 8 Sep 2008 13:08:11 -0700 (PDT) Message-ID: <4e44781e0809081308n784c46cbt1aff3204cf167e2b@mail.gmail.com> Date: Mon, 8 Sep 2008 16:08:11 -0400 From: "G. C." To: Kalyan.Tata@nokia.com, pbanthia@alcatel-lucent.com, vrrp@ietf.org In-Reply-To: MIME-Version: 1.0 References: <4CA4E02EAF94EB429C5575E19181C58C01CB67AC@ILEXC3U01.ndc.lucent.com> Subject: Re: [VRRP] indexing order in vrrpAssociatedIpAddrTable in draft-ietf-vrrp-unified-mib-06.txt X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1609833455==" Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org --===============1609833455== Content-Type: multipart/alternative; boundary="----=_Part_89801_8873415.1220904491852" ------=_Part_89801_8873415.1220904491852 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Kaylan, We have cases where it is more efficient to search for all VRs within an IfIndex if the ordering is { vrrpOperationsInetAddrType, ifIndex, vrrpOperationsVrId} and {vrrpOperationsInetAddrType, ifIndex, vrrpOperationsVrId, vrrpAssociatedIpAddr} This would still satisfy Bert's request (vrrpOperationsInetAddrType as the first one). Is it too late to request this as a change? Thanks, Georges On Sun, Aug 17, 2008 at 7:59 PM, wrote: > Hi Prakash, > The order was as you suggested in the initial drafts. This was > discussed in one of the ietf meetings and I think > Wijnen, Bert suggested and every one agreed to change the order to what it > is right now. > The rational (as I remember it) for vrrpOperationsInetAddrType to be first > is that operators would like to walk on IPv4 or IPv6 virtual routers with > out actually knowing vrids or ifindexes. > > I do not remember the exact reason of the other part of the order. Am CCing > the WG to see if Mukesh or anyone else > remembers the discussion. > > Thanks, > Kalyan > > > ------------------------------ > *From:* ext Banthia, Prakash (Prakash) [mailto:pbanthia@alcatel-lucent.com] > > *Sent:* Thursday, August 14, 2008 3:43 PM > *To:* Tata Kalyan (Nokia-S&S/MtView) > *Cc:* Chung Kam Chung, Georges (Georges); Abdouni, Bassem (Bassem); > Bailey, Reva Sue (Reva) > *Subject:* indexing order in vrrpAssociatedIpAddrTable in > draft-ietf-vrrp-unified-mib-06.txt > > Kalyan, > Let me introduce myself. I am part of the team which is implementing > draft-ietf-vrrp-unified-mib-06.txt here at Alcatel-Lucent. > And I have a question on the indexing order in vrrpAssociatedIpAddrTable. > > From original VRRP-MIB, here is the indexing order: > vrrpAssoIpAddrEntry OBJECT-TYPE > INDEX { ifIndex, vrrpOperVrId, vrrpAssoIpAddr } > > From the new draft which support IPv6, here is the indexing order: > vrrpAssociatedIpAddrEntry OBJECT-TYPE > INDEX { vrrpOperationsInetAddrType, vrrpOperationsVrId, > ifIndex, vrrpAssociatedIpAddr } > > I would like to have vrrpOperationsInetAddrType and vrrpAssociatedIpAddr > objects together which is typically how ipv6 support is generally > implemented. Our utility routines always assume these to be together. > > So I would prefer the following INDEX for vrrpAssociatedIpAddrTable: > INDEX { vrrpOperationsVrId, ifIndex, vrrpOperationsInetAddrType, > vrrpAssociatedIpAddr } > > Let me know your thoughts on this. > Thanks. > --prakash > > _______________________________________________ > vrrp mailing list > vrrp@ietf.org > https://www.ietf.org/mailman/listinfo/vrrp > > ------=_Part_89801_8873415.1220904491852 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Kaylan,

We have cases where it is more efficient to search for all VRs within an IfIndex if the ordering is

  { vrrpOperationsInetAddrType, ifIndex, vrrpOperationsVrId}

and

   {vrrpOperationsInetAddrType, ifIndex, vrrpOperationsVrId, vrrpAssociatedIpAddr}

This would still satisfy Bert's request (
vrrpOperationsInetAddrType as the first one).  Is it too late to request this as a change?

Thanks,
Georges


On Sun, Aug 17, 2008 at 7:59 PM, <Kalyan.Tata@nokia.com> wrote:
Hi Prakash,
    The order was as you suggested in the initial drafts. This was discussed in one of the ietf meetings and  I think
Wijnen, Bert suggested and every one agreed to change the order to what it is right now.
The rational (as I remember it) for vrrpOperationsInetAddrType to be first is that operators would like to walk on IPv4 or IPv6 virtual routers with out actually  knowing vrids or ifindexes.
 
I do not remember the exact reason of the other part of the order. Am CCing the WG to see if Mukesh or anyone else
remembers the discussion.

Thanks,
Kalyan

 


From: ext Banthia, Prakash (Prakash) [mailto:pbanthia@alcatel-lucent.com]
Sent: Thursday, August 14, 2008 3:43 PM
To: Tata Kalyan (Nokia-S&S/MtView)
Cc: Chung Kam Chung, Georges (Georges); Abdouni, Bassem (Bassem); Bailey, Reva Sue (Reva)
Subject: indexing order in vrrpAssociatedIpAddrTable in draft-ietf-vrrp-unified-mib-06.txt

Kalyan,
Let me introduce myself. I am part of the team which is implementing draft-ietf-vrrp-unified-mib-06.txt here at Alcatel-Lucent.
And I have a question on the indexing order in vrrpAssociatedIpAddrTable.
 
From original VRRP-MIB, here is the indexing order:
vrrpAssoIpAddrEntry OBJECT-TYPE
    INDEX    { ifIndex, vrrpOperVrId, vrrpAssoIpAddr }
 
From the new draft which support IPv6, here is the indexing order:
vrrpAssociatedIpAddrEntry OBJECT-TYPE
    INDEX    { vrrpOperationsInetAddrType, vrrpOperationsVrId,
               ifIndex, vrrpAssociatedIpAddr }
 
I would like to have vrrpOperationsInetAddrType and vrrpAssociatedIpAddr objects together which is typically how ipv6 support is generally implemented. Our utility routines always assume these to be together.
 
So I would prefer the following INDEX for vrrpAssociatedIpAddrTable:
    INDEX    {  vrrpOperationsVrId, ifIndex, vrrpOperationsInetAddrType, vrrpAssociatedIpAddr }
 
Let me know your thoughts on this.
Thanks.
--prakash

_______________________________________________
vrrp mailing list
vrrp@ietf.org
https://www.ietf.org/mailman/listinfo/vrrp


------=_Part_89801_8873415.1220904491852-- --===============1609833455== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp --===============1609833455==--