[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04

Network Working Group                                           N. Gupta
Internet-Draft                                                  A. Dogra
Intended status: Informational                       Cisco Systems, Inc.
Expires: December 27, 2015                                   C. Docherty
                                                           June 25, 2015


      Fast failure detection using peer learning in VRRP with BFD
                        draft-nitish-vrrp-bfd-01

Abstract

   This draft presents an enhanced failure detection mechanism to detect
   the failure of VRRP Master router on the LAN using a peer learning
   mode.  Typically the VRRP protocol is able to perform the transparent
   fail-over detection within a time period of 3 seconds with default
   fail-over timers.  Real-time protocols (voice/video/real-time
   transactional) require a maximum network disruption in the order of
   150ms for traffic on the network.  A failure detection and fail-over
   time of 150ms on conventionally configured VRRP protocol is extremely
   aggressive and may impact the reliability and performance of the
   network.

   A more efficient mechanism for real-time failure detection can be
   enabled in VRRP protocol by building a peer table, using a new VRRP
   Advert packet type.  This will help in forming a mesh of BFD
   sessions.  Once the BFD sessions are created, VRRP can receive faster
   notification of failures, without the overhead of increased VRRP
   protocol Advert messages.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 27, 2015.

Copyright Notice



Gupta, et al.           Expires December 27, 2015               [Page 1]


Internet-Draft                  VRRP BFD                       June 2015


   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  5
   3.  Extension to VRRP protocol . . . . . . . . . . . . . . . . . .  6
     3.1.  VRRP Peer Table  . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  VRRP BACKUP ADVERTISEMENT Packet Type  . . . . . . . . . .  7
   4.  Sample configuration . . . . . . . . . . . . . . . . . . . . .  8
   5.  Critical BFD session . . . . . . . . . . . . . . . . . . . . . 10
   6.  Scalability Considerations . . . . . . . . . . . . . . . . . . 11
   7.  Operational Considerations . . . . . . . . . . . . . . . . . . 12
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     11.1. Informative References . . . . . . . . . . . . . . . . . . 16
     11.2. Normative References . . . . . . . . . . . . . . . . . . . 16
   Appendix A.  Using Multipoint BFD sessions . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18


















Gupta, et al.           Expires December 27, 2015               [Page 2]


Internet-Draft                  VRRP BFD                       June 2015


1.  Introduction

   Fast failure detection in the network is becoming increasingly
   important.  VRRP helps in providing redundant Virtual gateways in the
   LAN, which is typically the first point of failure for end-hosts
   sending traffic out of the LAN.  A faster failure detection of VRRP
   master becomes very critical as it can isolate all end-hosts that are
   unable to detect any alternate path.  In VRRP [RFC5798] protocol
   specification, Backup routers depends on Advert packets generated at
   a regular interval by the Master router, to detect the health of the
   VRRP Master.  Faster failure detection can be achieved within VRRP
   protocol by reducing the Advert and hold down timers.  But Aggressive
   timers can put extra load on the network bandwidth which may not be
   desirable.

   As the VRRP protocol depends on the availability of L3 IPv4 or IPv6
   between redundant peers, VRRP protocol can interact with the L3
   variant of BFD as described in [RFC5881], to achieve a much faster
   failure detection of the VRRP Master in the LAN.  BFD as specified by
   the RFC [RFC5880] can provide a much faster failure detection in the
   range of 150ms.

   BFD IPv4 or IPv6 [RFC5881] requires that for a BFD session to be
   formed, both peers participating in a BFD session need to know to its
   peer IPv4 or IPV6 address.  This poses a unique problem with the
   definition of the VRRP [RFC5798] protocol, that makes the operation
   with BFD IPv4 or IPv6 [RFC5881] more challenging.  As in VRRP it is
   only the Master peer that sends Advert packets.  This means that a
   Master peer is not aware of any Backup peers, and Backup peers are
   only aware of the Master peer.  This also means that Backup peers are
   not aware of other Backups in the Network.

   Since BFD IPv4 or IPv6 [RFC5881] requires that a session be formed by
   both peers using a full destination and source address, there needs
   to be some external means to provide this information to BFD on
   behalf of VRRP.  Once the peer information is made available, VRRP
   can form BFD sessions with each of the peers that exist in the
   Virtual Router.  The most important BFD session for a given Virtual
   Router is identified as the Critical Path BFD Session, which is the
   session that forms between the current VRRP Master, and the highest
   priority Backup.  Should the Critical Path BFD Session be identified
   by the VRRP as having changed state from UP to DOWN, then this will
   be interpreted by the VRRP state machine on the highest priority
   Backup peer as a Master Down event.  A Master Down event means that
   the highest priority Backup peer will immediately become the new
   Master for the Virtual Router.

   NOTE: At all times, the normal fail-over mechanism defined in the



Gupta, et al.           Expires December 27, 2015               [Page 3]


Internet-Draft                  VRRP BFD                       June 2015


   VRRP [RFC5798] will be unaffected, and the BFD fail-over mechanism
   will always resort to normal VRRP fail-over.

   This draft defines the mechanism used by VRRP protocol to Build a
   peer table that will help in forming a mesh of BFD sessions and the
   detection of Critical Path BFD session.  If the Critical Path BFD
   session were to go down it will signal a Master down event and make
   the most preferred Backup router as the VRRP Master.  This requires
   an extension to the VRRP protocol.

   This can be achieved by defining a new type in the VRRP Advert
   packet, and allowing VRRP peers to build a peer table in any of the
   operational state, Master or Backup.






































Gupta, et al.           Expires December 27, 2015               [Page 4]


Internet-Draft                  VRRP BFD                       June 2015


2.  Requirements Language

   In this document, several words are used to signify the requirements
   of the specification.  The key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" in this document are to be interpreted as described in
   RFC 2119.  [RFC2119]












































Gupta, et al.           Expires December 27, 2015               [Page 5]


Internet-Draft                  VRRP BFD                       June 2015


3.  Extension to VRRP protocol

   In this mode of operation VRRP peers learn the adjacent peers, and
   form BFD sessions between the learnt peers.  In order to build the
   peer table, all peers send VRRP Advert packets whilst in any of the
   operational states (Master or Backup).  Normally VRRP [RFC5798] peers
   only send Advert packets whilst in the Master state, however in this
   mode VRRP Backup peers will also send Advert packets with the type
   field set to BACKUP ADVERTISEMENT type defined in Section 3.2.  VRRP
   Master peer will still continue to send packets with Advert type as
   ADVERTISEMENT as defined in the VRRP [RFC5798] protocol.  This is to
   maintain inter-operability with peers complying to VRRP [RFC5798]
   protocol.

   Additionally Advert packets sent from Backup Peers must not use the
   Virtual router MAC address as the source address.  Instead it must
   use the Interface MAC address as the source address from which the
   packet is sent from.  This is because the source MAC override feature
   is used by the Master to send Advert packets from the Virtual Router
   MAC address, which is used to keep the bridging cache on LAN switches
   and bridging devices refreshed with the destination port for the
   Virtual Router MAC.

3.1.  VRRP Peer Table

   VRRP peers can now form the peer table by learning the source address
   in the ADVERTISEMENT or BACKUP ADVERTISEMENT packet sent by VRRP
   Master or Backup peers.  This allows all peers to create a mesh of
   BFD sessions with all other operational peers.

   A peer entry should be removed from the peer table if Advert is not
   received from a peer for a period of (3 * the Advert interval).



















Gupta, et al.           Expires December 27, 2015               [Page 6]


Internet-Draft                  VRRP BFD                       June 2015


3.2.  VRRP BACKUP ADVERTISEMENT Packet Type

   The following figure shows the VRRP packet as defined in VRRP
   [RFC5798] RFC.


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             IPv4 Fields or IPv6 Fields                        |
   ...                                                             ...
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Version| Type  | Virtual Rtr ID|    Priority   |Count IPvX Addr|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |(rsvd) |    Max Advert Int     |        Checksum               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                   IPvX Address(es)                            |
    +                                                               +
    +                                                               +
    +                                                               +
    +                                                               +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The type field specifies the type of this VRRP packet.  The type
   field can have two values.  Type 1 (ADVERTISEMENT) is used by the
   VRRP Master Router.  Type 2 (BACKUP ADVERTISEMENT) is used by the
   VRRP Backup router.  This is to distinguish the packets sent by the
   VRRP backup Router.  Rest of the fields in Advert packet remain the
   same.

      1 ADVERTISEMENT
      2 BACKUP ADVERTISEMENT

   A packet with unknown type MUST be discarded.











Gupta, et al.           Expires December 27, 2015               [Page 7]


Internet-Draft                  VRRP BFD                       June 2015


4.  Sample configuration

   The following figure shows a simple network with three VRRP routers
   implementing one virtual router.

       +-----------+     +-----------+      +-----------+
       |   Rtr1    |     |   Rtr2    |      |   Rtr3    |
       |(MR VRID=1)|     |(BR VRID=1)|      |(BR VRID=1)|
       | (PR=200)  |     | (PR=150)  |      | (PR=100)  |
       | VRIPVX= A |     | VRIPVX= A |      | VRIPVX= A |
       +-----------+     +-----------+      +-----------+
            B                 C                  D
            |                 |                  |
            |                 |                  |
            |                 |                  |
   ---------+--------+--------+---------+--------+---------
   Legend:
           ---+---+---+--    =  Ethernet, Token Ring, or FDDI
                       MR    =  Master Router
                       BR    =  Backup Router
                       PR    =  VRRP Router priority
                       VRID  =  VRRP Router ID
                       VRIPVX=  IPv4 or IPv6 address protected by
                                the VRRP Router
                       B,C,D =  Interface IPv4 or IPv6 address of
                                the Virtual Router


   In the above configuration there are three routers on the LAN
   protecting an IPv4 or IPv6 address associated to a Virtual Router ID
   1.  The Rtr1 is the master router as it has the highest priority
   compared the Rtr2 and Rtr3.  Now if peer learning extension is
   enabled on all the peers.  Rtr1 will send the Advert packet with type
   field set to 1.  While Rtr2 and Rtr3 will send the Advert packet with
   type field set to 2.  In the above configuration the peer table built
   at each router is shown below:

   Rtr1 Peer table

   +------------------------------------+
   |  Peer Address  |     Priority      |
   +------------------------------------+
   |     C          |       150         |
   +------------------------------------+
   |     D          |       100         |
   +------------------------------------+





Gupta, et al.           Expires December 27, 2015               [Page 8]


Internet-Draft                  VRRP BFD                       June 2015


   Rtr2 Peer table

   +------------------------------------+
   |  Peer Address  |     Priority      |
   +------------------------------------+
   |     B          |       200         |
   +------------------------------------+
   |     D          |       100         |
   +------------------------------------+

   Rtr3 Peer table

   +------------------------------------+
   |  Peer Address  |     Priority      |
   +------------------------------------+
   |     B          |       200         |
   +------------------------------------+
   |     C          |       150         |
   +------------------------------------+

   Once the peer tables are formed, VRRP on each router can form a mesh
   of BFD sessions with all the learnt peers.





























Gupta, et al.           Expires December 27, 2015               [Page 9]


Internet-Draft                  VRRP BFD                       June 2015


5.  Critical BFD session

   Critical BFD Session is determined to be the session between the VRRP
   Master and the next best VRRP Backup.  Failure of the Critical BFD
   session indicates that the Master is no longer available and the most
   preferred Backup will now become Master.

   In the above example the Critical BFD session is shared between Rtr1
   and Rtr2.  If the BFD Session goes from UP to DOWN state, Rtr2 can
   treat it as a Master down event and immediately assume the role of
   VRRP Master router for VRID 1 and Rtr3 will become the critical
   backup.







































Gupta, et al.           Expires December 27, 2015              [Page 10]


Internet-Draft                  VRRP BFD                       June 2015


6.  Scalability Considerations

   When forming mesh of BFD sessions one possible scenario can occur if
   the system is not able to scale well with the increased load of
   multiple BFD sessions.  To mitigate this problem sharing of BFD
   sessions with other protocols and opening less number of BFD sessions
   should be considered, i.e between Master and the most preferred
   Backup router part of the VRRP instance.

   To reduce the number of packets generated at a regular interval,
   Backup Advert packets may be sent at a reduced rate as compared to
   Advert packets sent by the VRRP Master.







































Gupta, et al.           Expires December 27, 2015              [Page 11]


Internet-Draft                  VRRP BFD                       June 2015


7.  Operational Considerations

   A VRRP [RFC5798] peer that forms a member of this Virtual Router, but
   does not support this feature or extension must be configured with
   the lowest priority, and will only operate as the Router of last
   resort on failure of all other VRRP routers supporting this
   functionality.

   It is recommended that mechanism defined by this draft, to interface
   VRRP with BFD should be used when BFD can support more aggressive
   monitoring timers than VRRP.  Otherwise it is desirable not to
   interface VRRP with BFD for determining the health of VRRP Master.

   This Draft does not preclude the possibility of the peer table being
   populated by means of manual configuration, instead of using the
   BACKUP ADVERTISEMENT as defined by the Draft.



































Gupta, et al.           Expires December 27, 2015              [Page 12]


Internet-Draft                  VRRP BFD                       June 2015


8.  IANA Considerations

   This draft includes no request to IANA.
















































Gupta, et al.           Expires December 27, 2015              [Page 13]


Internet-Draft                  VRRP BFD                       June 2015


9.  Security Considerations

   Security considerations are discussed in the Section 9 of VRRP
   protocol [RFC5798] specification.  There are no additional security
   considerations identified by this draft.














































Gupta, et al.           Expires December 27, 2015              [Page 14]


Internet-Draft                  VRRP BFD                       June 2015


10.  Acknowledgements

   The authors gratefully acknowledge the contributions of Gerry Meyer,
   and Mouli Chandramouli, for their contributions to the draft.  The
   authors will also like to thank Jeffrey Hass, Maik Pfeil and Vengada
   Prasad Govindan for their comments and suggestions.













































Gupta, et al.           Expires December 27, 2015              [Page 15]


Internet-Draft                  VRRP BFD                       June 2015


11.  References

11.1.  Informative References

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880.

11.2.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119.

   [RFC5881]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881.

   [RFC5798]  Nadas, S., "Virtual Router Redundancy Protocol (VRRP)
              Version 3 for IPv4 and IPv6", RFC 5798.

   [I-D.draft-ietf-bfd-multipoint]
              Katz, D., Ward, D., and S. Pallagatti, "BFD for Multipoint
              Networks", Work in Progress draft-ietf-bfd-multipoint-06.






























Gupta, et al.           Expires December 27, 2015              [Page 16]


Internet-Draft                  VRRP BFD                       June 2015


Appendix A.  Using Multipoint BFD sessions

   Possibility of detecting the failure of VRRP Master using Multipoint
   BFD [I-D.draft-ietf-bfd-multipoint] sessions is still under
   consideration.














































Gupta, et al.           Expires December 27, 2015              [Page 17]


Internet-Draft                  VRRP BFD                       June 2015


Authors' Addresses

   Nitish Gupta
   Cisco Systems, Inc.
   Sarjapur Outer Ring Road
   Bangalore  560103
   India

   Phone: +91 80 4429 2530
   Email: nitisgup@cisco.com
   URI:   http://www.cisco.com/


   Aditya Dogra
   Cisco Systems, Inc.
   Sarjapur Outer Ring Road
   Bangalore  560103
   India

   Phone: +91 80 4429 2166
   Email: addogra@cisco.com
   URI:   http://www.cisco.com/


   Colin Docherty
   25 George Grieve Way
   Tranent
   East Lothian, Scotland  EH332QT
   United Kingdom

   Email: colin@doch.org.uk




















Gupta, et al.           Expires December 27, 2015              [Page 18]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/