idnits 2.17.00 (12 Aug 2021) /tmp/idnits43159/draft-nitish-vrrp-bfd-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 12, 2015) is 2535 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Gupta 3 Internet-Draft A. Dogra 4 Intended status: Informational Cisco Systems, Inc. 5 Expires: December 14, 2015 C. Docherty 6 June 12, 2015 8 Fast failure detection using peer learning in VRRP with BFD 9 draft-nitish-vrrp-bfd-00 11 Abstract 13 This draft presents an enhanced failure detection mechanism to detect 14 the failure of VRRP Master router on the LAN using a peer learning 15 mode. Typically the VRRP protocol is able to perform the transparent 16 fail-over detection within a time period of 3 seconds with default 17 fail-over timers. Real-time protocols (voice/video/real-time 18 transactional) require a maximum network disruption in the order of 19 150ms for traffic on the network. A failure detection and fail-over 20 time of 150ms on conventionally configured VRRP protocol is extremely 21 aggressive and may impact the reliability and performance of the 22 network. 24 A more efficient mechanism for real-time failure detection can be 25 enabled in VRRP protocol by building a peer table, using a new VRRP 26 Advert packet type. This will help in forming a mesh of BFD 27 sessions. Once the BFD sessions are created, VRRP can receive faster 28 notification of failures, without the overhead of increased VRRP 29 protocol Advert messages. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on December 14, 2015. 48 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 66 3. Extension to VRRP protocol . . . . . . . . . . . . . . . . . . 6 67 3.1. VRRP Peer Table . . . . . . . . . . . . . . . . . . . . . 6 68 3.2. VRRP BACKUP ADVERTISEMENT Packet Type . . . . . . . . . . 7 69 4. Sample configuration . . . . . . . . . . . . . . . . . . . . . 8 70 5. Critical BFD session . . . . . . . . . . . . . . . . . . . . . 10 71 6. Operational Considerations . . . . . . . . . . . . . . . . . . 11 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 10.1. Informative References . . . . . . . . . . . . . . . . . . 15 77 10.2. Normative References . . . . . . . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 80 1. Introduction 82 Fast failure detection in the network is becoming increasingly 83 important. VRRP helps in providing redundant Virtual gateways in the 84 LAN, which is typically the first point of failure for end-hosts 85 sending traffic out of the LAN. A faster failure detection of VRRP 86 master becomes very critical as it can isolate all end-hosts that are 87 unable to detect any alternate path. In VRRP [RFC5798] protocol 88 specification, Backup routers depends on Advert packets generated at 89 a regular interval by the Master router, to detect the health of the 90 VRRP Master. Faster failure detection can be achieved within VRRP 91 protocol by reducing the Advert and hold down timers. But Aggressive 92 timers can put extra load on the network bandwidth which may not be 93 desirable. 95 As the VRRP protocol depends on the availability of L3 IPv4 or IPv6 96 between redundant peers, VRRP protocol can interact with the L3 97 variant of BFD as described in [RFC5881], to achieve a much faster 98 failure detection of the VRRP Master in the LAN. BFD as specified by 99 the RFC [RFC5880] can provide a much faster failure detection in the 100 range of 150ms. 102 BFD IPv4 or IPv6 [RFC5881] requires that for a BFD session to be 103 formed, both peers participating in a BFD session need to know to its 104 peer IPv4 or IPV6 address. This poses a unique problem with the 105 definition of the VRRP [RFC5798] protocol, that makes the operation 106 with BFD IPv4 or IPv6 [RFC5881] more challenging. As in VRRP it is 107 only the Master peer that sends Advert packets. This means that a 108 Master peer is not aware of any Backup peers, and Backup peers are 109 only aware of the Master peer. This also means that Backup peers are 110 not aware of other Backups in the Network. 112 Since BFD IPv4 or IPv6 [RFC5881] requires that a session be formed by 113 both peers using a full destination and source address, there needs 114 to be some external means to provide this information to BFD on 115 behalf of VRRP. Once the peer information is made available, VRRP 116 can form BFD sessions with each of the peers that exist in the 117 Virtual Router. The most important BFD session for a given Virtual 118 Router is identified as the Critical Path BFD Session, which is the 119 session that forms between the current VRRP Master, and the highest 120 priority Backup. Should the Critical Path BFD Session be identified 121 by the VRRP as having changed state from UP to DOWN, then this will 122 be interpreted by the VRRP state machine on the highest priority 123 Backup peer as a Master Down event. A Master Down event means that 124 the highest priority Backup peer will immediately become the new 125 Master for the Virtual Router. 127 NOTE: At all times, the normal fail-over mechanism defined in the 128 VRRP [RFC5798] will be unaffected, and the BFD fail-over mechanism 129 will always resort to normal VRRP fail-over. 131 This draft defines the mechanism used by VRRP protocol to Build a 132 peer table that will help in forming a mesh of BFD sessions and the 133 detection of Critical Path BFD session. If the Critical Path BFD 134 session were to go down it will signal a Master down event and make 135 the most preferred Backup router as the VRRP Master. This requires 136 an extension to the VRRP protocol. 138 This can be achieved by defining a new type in the VRRP Advert 139 packet, and allowing VRRP peers to build a peer table in any of the 140 operational state, Master or Backup. 142 2. Requirements Language 144 In this document, several words are used to signify the requirements 145 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 146 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 147 and "OPTIONAL" in this document are to be interpreted as described in 148 RFC 2119. [RFC2119] 150 3. Extension to VRRP protocol 152 In this mode of operation VRRP peers learn the adjacent peers, and 153 form BFD sessions between the learnt peers. In order to build the 154 peer table, all peers send VRRP Advert packets whilst in any of the 155 operational states (Master or Backup). Normally VRRP [RFC5798] peers 156 only send Advert packets whilst in the Master state, however in this 157 mode VRRP Backup peers will also send Advert packets with the type 158 field set to BACKUP ADVERTISEMENT type defined in Section 3.2. VRRP 159 Master peer will still continue to send packets with Advert type as 160 ADVERTISEMENT as defined in the VRRP [RFC5798] protocol. This is to 161 maintain inter-operability with peers complying to VRRP [RFC5798] 162 protocol. 164 Additionally Advert packets sent from Backup Peers must not use the 165 Virtual router MAC address as the source address. Instead it must 166 use the Interface MAC address as the source address from which the 167 packet is sent from. This is because the source MAC override feature 168 is used by the Master to send Advert packets from the Virtual Router 169 MAC address, which is used to keep the bridging cache on LAN switches 170 and bridging devices refreshed with the destination port for the 171 Virtual Router MAC. 173 3.1. VRRP Peer Table 175 VRRP peers can now form the peer table by learning the source address 176 in the ADVERTISEMENT or BACKUP ADVERTISEMENT packet sent by VRRP 177 Master or Backup peers. This allows all peers to create a mesh of 178 BFD sessions with all other operational peers. 180 3.2. VRRP BACKUP ADVERTISEMENT Packet Type 182 The following figure shows the VRRP packet as defined in VRRP 183 [RFC5798] RFC. 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | IPv4 Fields or IPv6 Fields | 189 ... ... 190 | | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 |Version| Type | Virtual Rtr ID| Priority |Count IPvX Addr| 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 |(rsvd) | Max Advert Int | Checksum | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | | 197 + + 198 | IPvX Address(es) | 199 + + 200 + + 201 + + 202 + + 203 | | 204 + + 205 | | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 The type field specifies the type of this VRRP packet. The type 209 field can have two values. Type 1 (ADVERTISEMENT) is used by the 210 VRRP Master Router. Type 2 (BACKUP ADVERTISEMENT) is used by the 211 VRRP Backup router. This is to distinguish the packets sent by the 212 VRRP backup Router. Rest of the fields in Advert packet remain the 213 same. 215 1 ADVERTISEMENT 216 2 BACKUP ADVERTISEMENT 218 A packet with unknown type MUST be discarded. 220 4. Sample configuration 222 The following figure shows a simple network with three VRRP routers 223 implementing one virtual router. 225 +-----------+ +-----------+ +-----------+ 226 | Rtr1 | | Rtr2 | | Rtr3 | 227 |(MR VRID=1)| |(BR VRID=1)| |(BR VRID=1)| 228 | (PR=200) | | (PR=150) | | (PR=100) | 229 | VRIPVX= A | | VRIPVX= A | | VRIPVX= A | 230 +-----------+ +-----------+ +-----------+ 231 B C D 232 | | | 233 | | | 234 | | | 235 ---------+--------+--------+---------+--------+--------- 236 Legend: 237 ---+---+---+-- = Ethernet, Token Ring, or FDDI 238 MR = Master Router 239 BR = Backup Router 240 PR = VRRP Router priority 241 VRID = VRRP Router ID 242 VRIPVX= IPv4 or IPv6 address protected by 243 the VRRP Router 244 B,C,D = Interface IPv4 or IPv6 address of 245 the Virtual Router 247 In the above configuration there are three routers on the LAN 248 protecting an IPv4 or IPv6 address associated to a Virtual Router ID 249 1. The Rtr1 is the master router as it has the highest priority 250 compared the Rtr2 and Rtr3. Now if peer learning extension is 251 enabled on all the peers. Rtr1 will send the Advert packet with type 252 field set to 1. While Rtr2 and Rtr3 will send the Advert packet with 253 type field set to 2. In the above configuration the peer table built 254 at each router is shown below: 256 Rtr1 Peer table 258 +------------------------------------+ 259 | Peer Address | Priority | 260 +------------------------------------+ 261 | C | 150 | 262 +------------------------------------+ 263 | D | 100 | 264 +------------------------------------+ 265 Rtr2 Peer table 267 +------------------------------------+ 268 | Peer Address | Priority | 269 +------------------------------------+ 270 | B | 200 | 271 +------------------------------------+ 272 | D | 100 | 273 +------------------------------------+ 275 Rtr3 Peer table 277 +------------------------------------+ 278 | Peer Address | Priority | 279 +------------------------------------+ 280 | B | 200 | 281 +------------------------------------+ 282 | C | 150 | 283 +------------------------------------+ 285 Once the peer tables are formed, VRRP on each router can form a mesh 286 of BFD sessions with all the learnt peers. 288 5. Critical BFD session 290 Critical BFD Session is determined to be the session between the VRRP 291 Master and the next best VRRP Backup. Failure of the Critical BFD 292 session indicates that the Master is no longer available and the most 293 preferred Backup will now become Master. 295 In the above example the Critical BFD session is shared between Rtr1 296 and Rtr2. If the BFD Session goes from UP to DOWN state, Rtr2 can 297 treat it as a Master down event and immediately assume the role of 298 VRRP Master router for VRID 1 and Rtr3 will become the critical 299 backup. 301 6. Operational Considerations 303 A VRRP [RFC5798] peer that forms a member of this Virtual Router, but 304 does not support this feature or extension must be configured with 305 the lowest priority, and will only operate as the Router of last 306 resort on failure of all other VRRP routers supporting this 307 functionality. 309 7. IANA Considerations 311 This draft includes no request to IANA. 313 8. Security Considerations 315 Security considerations are discussed in the Section 9 of VRRP 316 protocol [RFC5798] specification. There are no additional security 317 considerations identified by this draft. 319 9. Acknowledgements 321 The authors gratefully acknowledge the contributions of Gerry Meyer, 322 and Mouli Chandramouli, for their contributions to the draft. 324 10. References 326 10.1. Informative References 328 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 329 (BFD)", RFC 5880. 331 10.2. Normative References 333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", RFC 2119. 336 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 337 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881. 339 [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) 340 Version 3 for IPv4 and IPv6", RFC 5798. 342 Authors' Addresses 344 Nitish Gupta 345 Cisco Systems, Inc. 346 Sarjapur Outer Ring Road 347 Bangalore 560103 348 India 350 Phone: +91 80 4429 2530 351 Email: nitisgup@cisco.com 352 URI: http://www.cisco.com/ 354 Aditya Dogra 355 Cisco Systems, Inc. 356 Sarjapur Outer Ring Road 357 Bangalore 560103 358 India 360 Phone: +91 80 4429 2166 361 Email: addogra@cisco.com 362 URI: http://www.cisco.com/ 364 Colin Docherty 365 25 George Grieve Way 366 Tranent 367 East Lothian, Scotland EH332QT 368 United Kingdom 370 Email: colin@doch.org.uk