Re: [VRRP] : VRRP IPV6 Session Configuration with different link

Sreenatha Setty <sreenatha.setty@ibtechnology.com> Sat, 19 October 2013 07:07 UTC

Return-Path: <sreenatha.setty@ibtechnology.com>
X-Original-To: vrrp@ietfa.amsl.com
Delivered-To: vrrp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7EF11E8136 for <vrrp@ietfa.amsl.com>; Sat, 19 Oct 2013 00:07:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmepjX8Q0QTf for <vrrp@ietfa.amsl.com>; Sat, 19 Oct 2013 00:07:10 -0700 (PDT)
Received: from ipinternal.indiabulls.com (ipinternal.indiabulls.com [202.54.119.192]) by ietfa.amsl.com (Postfix) with ESMTP id C760721F9E01 for <vrrp@ietf.org>; Sat, 19 Oct 2013 00:07:08 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqQEADUuYlKsEMj1/2dsb2JhbABagz+sHZIaS4E7dIIlAQEBAQMBAQEtCjQLEgEIDQQDAQILBg4KByYeCgkBBAsDBQgBh2sDG7YwA4l1jGaBHhmBCDENgxmBCgOJPYxngxSLIYhjgWk
X-IronPort-AV: E=Sophos;i="4.93,527,1378837800"; d="scan'208";a="34354464"
Received: from GRGHEXCHANGE.grgh.indiabulls.com (172.16.200.21) by GGN-ICAS.grgh.indiabulls.com (172.16.200.245) with Microsoft SMTP Server id 14.3.123.3; Sat, 19 Oct 2013 12:36:49 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 19 Oct 2013 12:36:50 +0530
Message-ID: <DB36B077CF387C4989BCC57D685FA30102F2BF4D@GRGHEXCHANGE.grgh.indiabulls.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: : [VRRP] VRRP IPV6 Session Configuration with different link
Thread-Index: Ac7MltKzg5YQLaPoTeWzV0zMIQzcvA==
From: Sreenatha Setty <sreenatha.setty@ibtechnology.com>
To: vrrp@ietf.org
Content-Transfer-Encoding: quoted-printable
Cc: psandhya81@yahoo.com
Subject: Re: [VRRP] : VRRP IPV6 Session Configuration with different link
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Virtual Router Redundancy Protocol <vrrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vrrp>, <mailto:vrrp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vrrp>
List-Post: <mailto:vrrp@ietf.org>
List-Help: <mailto:vrrp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:vrrp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Oct 2013 07:07:14 -0000

Hi Sandhya,
     Normally Vendors will implement based on the standard RFC not on
the draft version, since drafts can undergo changes very frequently. I
am not sure for what reason you are referring that particular draft. 
I suggest you to refer latest VRRP v3 RFC: 5798 for better
understanding.

Coming to your query,  according to latest RFC 5798( section 7.1), " If
the packet was not generated by the address owner (Priority does not
equal 255 (decimal)), the receiver MUST drop the packet, otherwise
continue processing" condition is removed.  So router can accept vrrp
packets even if it is generated by other than the address owner if all
other conditions are met. (Mentioned in the above sections 7.1 of RFC
5798)

In your case, you mentioned different VIPs are configured. In the same
section only,  RFC tells, 
      - MAY verify that "Count IPvX Addrs" and the list of IPvX
      address(es) match the IPvX Address(es) configured for the VRID.

So according to this logic, both DUTs will discard the vrrp packets
since VIP address are different and both DUTs will become VRRP Masters.

And standard VRRP MIB(RFC 6527) specifies one statistics object to
represent these kind of address list errors:

vrrpv3StatisticsAddressListErrors OBJECT-TYPE
           SYNTAX       Counter64
           MAX-ACCESS   read-only
           STATUS       current
           DESCRIPTION
               "The total number of packets received for which the
               address list does not match the locally configured
               list for the virtual router.

               Discontinuities in the value of this counter can occur
               at re-initialization of the management system, and at
               other times as indicated by the value of
               vrrpv3StatisticsRowDiscontinuityTime."
           ::= { vrrpv3StatisticsEntry 10 }

Summary to your query:
    1. Both DUTs will detects VIP address error, discards the packets
and becomes the Masters.
    2. DUTs  increment the statistics variable
vrrpv3StatisticsAddressListErrors.


Additionally, if you configure different VRIDs, packets will be
discarded before checking the VIPs only. Both DUTs will become masters
and will increment vrrpv3RouterVrIdErrors statistics variable (RFC
6527).

vrrpv3RouterVrIdErrors OBJECT-TYPE
           SYNTAX       Counter64
           MAX-ACCESS   read-only
          STATUS       current
           DESCRIPTION
               "The total number of VRRP packets received with a
                VRID that is not valid for any virtual router on this
                router.

               Discontinuities in the value of this counter can occur
               at re-initialization of the management system, and at
               other times as indicated by the value of
               vrrpv3GlobalStatisticsDiscontinuityTime."

           REFERENCE "RFC 5798, Section 5.2.3"
           ::= { vrrpv3Statistics 3 }

Thanks & Regards,
B Sreenatha Setty
Senior Software Engineer
IB Technology

------------------------------------------------------------------------
--------------------------------------
Message: 1
Date: Thu, 17 Oct 2013 22:27:21 -0700 (PDT)
From: Sandhya Puppala <psandhya81@yahoo.com>
To: "vrrp@ietf.org" <vrrp@ietf.org>
Subject: [VRRP] VRRP IPV6 Session Configuration with different link
	local	addresses (as VIP)
Message-ID:
	<1382074041.37205.YahooMailNeo@web160103.mail.bf1.yahoo.com>
Content-Type: text/plain; charset="iso-8859-1"



Hi,


Consider the below topology,
DUT1 ----- DUT2

Configured DUT1 as owner with vip as fe80::ca35:b8ff:fea8:82fd.
And configured DUT2 as not-owner with vip as fe80::ca35:b8ff:fea8:8212

VIP on DUT1 and DUT2 are different.

What should be the states of DUT1 & DUT2?

According to draft
http://tools.ietf.org/html/draft-ietf-vrrp-ipv6-spec-07
section 7.1, 

If the packet was not generated by the address owner (Priority does not
equal 255 (decimal)), the receiver MUST drop the packet, otherwise
continue processing.

1. Does it need to compare the vip address of received packet and its
vip address?
??? If there are different what need to be done?

As per RFC "DUT2 should accept the packet from DUT1".
Does this mean DUT2 state should become backup?



Thanks,
Sandhya
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.ietf.org/mail-archive/web/vrrp/attachments/20131017/5babdb8d
/attachment.htm>

------------------------------

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


End of vrrp Digest, Vol 88, Issue 1
***********************************
Disclaimer : 
This email communication may contain privileged and confidential information and is intended for the use of the addressee only.If you are not an intended recipient you are requested not to reproduce, copy disseminate or in any manner distribute this email communication as the same is strictly prohibited. If you have received this email in error, please notify the sender immediately by return e-mail and delete the communication sent in error. Email communications cannot be guaranteed to be secure & error free and IB Technology is not liable for any errors in the email communication or for the proper, timely and complete transmission thereof.