idnits 2.17.00 (12 Aug 2021) /tmp/idnits41922/draft-nitish-vrrp-bfd-01.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 25, 2015) is 2522 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-bfd-multipoint has been published as RFC 8562 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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 27, 2015 C. Docherty 6 June 25, 2015 8 Fast failure detection using peer learning in VRRP with BFD 9 draft-nitish-vrrp-bfd-01 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 27, 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. Scalability Considerations . . . . . . . . . . . . . . . . . . 11 72 7. Operational Considerations . . . . . . . . . . . . . . . . . . 12 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 75 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 11.1. Informative References . . . . . . . . . . . . . . . . . . 16 78 11.2. Normative References . . . . . . . . . . . . . . . . . . . 16 79 Appendix A. Using Multipoint BFD sessions . . . . . . . . . . . . 17 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 82 1. Introduction 84 Fast failure detection in the network is becoming increasingly 85 important. VRRP helps in providing redundant Virtual gateways in the 86 LAN, which is typically the first point of failure for end-hosts 87 sending traffic out of the LAN. A faster failure detection of VRRP 88 master becomes very critical as it can isolate all end-hosts that are 89 unable to detect any alternate path. In VRRP [RFC5798] protocol 90 specification, Backup routers depends on Advert packets generated at 91 a regular interval by the Master router, to detect the health of the 92 VRRP Master. Faster failure detection can be achieved within VRRP 93 protocol by reducing the Advert and hold down timers. But Aggressive 94 timers can put extra load on the network bandwidth which may not be 95 desirable. 97 As the VRRP protocol depends on the availability of L3 IPv4 or IPv6 98 between redundant peers, VRRP protocol can interact with the L3 99 variant of BFD as described in [RFC5881], to achieve a much faster 100 failure detection of the VRRP Master in the LAN. BFD as specified by 101 the RFC [RFC5880] can provide a much faster failure detection in the 102 range of 150ms. 104 BFD IPv4 or IPv6 [RFC5881] requires that for a BFD session to be 105 formed, both peers participating in a BFD session need to know to its 106 peer IPv4 or IPV6 address. This poses a unique problem with the 107 definition of the VRRP [RFC5798] protocol, that makes the operation 108 with BFD IPv4 or IPv6 [RFC5881] more challenging. As in VRRP it is 109 only the Master peer that sends Advert packets. This means that a 110 Master peer is not aware of any Backup peers, and Backup peers are 111 only aware of the Master peer. This also means that Backup peers are 112 not aware of other Backups in the Network. 114 Since BFD IPv4 or IPv6 [RFC5881] requires that a session be formed by 115 both peers using a full destination and source address, there needs 116 to be some external means to provide this information to BFD on 117 behalf of VRRP. Once the peer information is made available, VRRP 118 can form BFD sessions with each of the peers that exist in the 119 Virtual Router. The most important BFD session for a given Virtual 120 Router is identified as the Critical Path BFD Session, which is the 121 session that forms between the current VRRP Master, and the highest 122 priority Backup. Should the Critical Path BFD Session be identified 123 by the VRRP as having changed state from UP to DOWN, then this will 124 be interpreted by the VRRP state machine on the highest priority 125 Backup peer as a Master Down event. A Master Down event means that 126 the highest priority Backup peer will immediately become the new 127 Master for the Virtual Router. 129 NOTE: At all times, the normal fail-over mechanism defined in the 130 VRRP [RFC5798] will be unaffected, and the BFD fail-over mechanism 131 will always resort to normal VRRP fail-over. 133 This draft defines the mechanism used by VRRP protocol to Build a 134 peer table that will help in forming a mesh of BFD sessions and the 135 detection of Critical Path BFD session. If the Critical Path BFD 136 session were to go down it will signal a Master down event and make 137 the most preferred Backup router as the VRRP Master. This requires 138 an extension to the VRRP protocol. 140 This can be achieved by defining a new type in the VRRP Advert 141 packet, and allowing VRRP peers to build a peer table in any of the 142 operational state, Master or Backup. 144 2. Requirements Language 146 In this document, several words are used to signify the requirements 147 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 148 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 149 and "OPTIONAL" in this document are to be interpreted as described in 150 RFC 2119. [RFC2119] 152 3. Extension to VRRP protocol 154 In this mode of operation VRRP peers learn the adjacent peers, and 155 form BFD sessions between the learnt peers. In order to build the 156 peer table, all peers send VRRP Advert packets whilst in any of the 157 operational states (Master or Backup). Normally VRRP [RFC5798] peers 158 only send Advert packets whilst in the Master state, however in this 159 mode VRRP Backup peers will also send Advert packets with the type 160 field set to BACKUP ADVERTISEMENT type defined in Section 3.2. VRRP 161 Master peer will still continue to send packets with Advert type as 162 ADVERTISEMENT as defined in the VRRP [RFC5798] protocol. This is to 163 maintain inter-operability with peers complying to VRRP [RFC5798] 164 protocol. 166 Additionally Advert packets sent from Backup Peers must not use the 167 Virtual router MAC address as the source address. Instead it must 168 use the Interface MAC address as the source address from which the 169 packet is sent from. This is because the source MAC override feature 170 is used by the Master to send Advert packets from the Virtual Router 171 MAC address, which is used to keep the bridging cache on LAN switches 172 and bridging devices refreshed with the destination port for the 173 Virtual Router MAC. 175 3.1. VRRP Peer Table 177 VRRP peers can now form the peer table by learning the source address 178 in the ADVERTISEMENT or BACKUP ADVERTISEMENT packet sent by VRRP 179 Master or Backup peers. This allows all peers to create a mesh of 180 BFD sessions with all other operational peers. 182 A peer entry should be removed from the peer table if Advert is not 183 received from a peer for a period of (3 * the Advert interval). 185 3.2. VRRP BACKUP ADVERTISEMENT Packet Type 187 The following figure shows the VRRP packet as defined in VRRP 188 [RFC5798] RFC. 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | IPv4 Fields or IPv6 Fields | 194 ... ... 195 | | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 |Version| Type | Virtual Rtr ID| Priority |Count IPvX Addr| 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 |(rsvd) | Max Advert Int | Checksum | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | | 202 + + 203 | IPvX Address(es) | 204 + + 205 + + 206 + + 207 + + 208 | | 209 + + 210 | | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 The type field specifies the type of this VRRP packet. The type 214 field can have two values. Type 1 (ADVERTISEMENT) is used by the 215 VRRP Master Router. Type 2 (BACKUP ADVERTISEMENT) is used by the 216 VRRP Backup router. This is to distinguish the packets sent by the 217 VRRP backup Router. Rest of the fields in Advert packet remain the 218 same. 220 1 ADVERTISEMENT 221 2 BACKUP ADVERTISEMENT 223 A packet with unknown type MUST be discarded. 225 4. Sample configuration 227 The following figure shows a simple network with three VRRP routers 228 implementing one virtual router. 230 +-----------+ +-----------+ +-----------+ 231 | Rtr1 | | Rtr2 | | Rtr3 | 232 |(MR VRID=1)| |(BR VRID=1)| |(BR VRID=1)| 233 | (PR=200) | | (PR=150) | | (PR=100) | 234 | VRIPVX= A | | VRIPVX= A | | VRIPVX= A | 235 +-----------+ +-----------+ +-----------+ 236 B C D 237 | | | 238 | | | 239 | | | 240 ---------+--------+--------+---------+--------+--------- 241 Legend: 242 ---+---+---+-- = Ethernet, Token Ring, or FDDI 243 MR = Master Router 244 BR = Backup Router 245 PR = VRRP Router priority 246 VRID = VRRP Router ID 247 VRIPVX= IPv4 or IPv6 address protected by 248 the VRRP Router 249 B,C,D = Interface IPv4 or IPv6 address of 250 the Virtual Router 252 In the above configuration there are three routers on the LAN 253 protecting an IPv4 or IPv6 address associated to a Virtual Router ID 254 1. The Rtr1 is the master router as it has the highest priority 255 compared the Rtr2 and Rtr3. Now if peer learning extension is 256 enabled on all the peers. Rtr1 will send the Advert packet with type 257 field set to 1. While Rtr2 and Rtr3 will send the Advert packet with 258 type field set to 2. In the above configuration the peer table built 259 at each router is shown below: 261 Rtr1 Peer table 263 +------------------------------------+ 264 | Peer Address | Priority | 265 +------------------------------------+ 266 | C | 150 | 267 +------------------------------------+ 268 | D | 100 | 269 +------------------------------------+ 270 Rtr2 Peer table 272 +------------------------------------+ 273 | Peer Address | Priority | 274 +------------------------------------+ 275 | B | 200 | 276 +------------------------------------+ 277 | D | 100 | 278 +------------------------------------+ 280 Rtr3 Peer table 282 +------------------------------------+ 283 | Peer Address | Priority | 284 +------------------------------------+ 285 | B | 200 | 286 +------------------------------------+ 287 | C | 150 | 288 +------------------------------------+ 290 Once the peer tables are formed, VRRP on each router can form a mesh 291 of BFD sessions with all the learnt peers. 293 5. Critical BFD session 295 Critical BFD Session is determined to be the session between the VRRP 296 Master and the next best VRRP Backup. Failure of the Critical BFD 297 session indicates that the Master is no longer available and the most 298 preferred Backup will now become Master. 300 In the above example the Critical BFD session is shared between Rtr1 301 and Rtr2. If the BFD Session goes from UP to DOWN state, Rtr2 can 302 treat it as a Master down event and immediately assume the role of 303 VRRP Master router for VRID 1 and Rtr3 will become the critical 304 backup. 306 6. Scalability Considerations 308 When forming mesh of BFD sessions one possible scenario can occur if 309 the system is not able to scale well with the increased load of 310 multiple BFD sessions. To mitigate this problem sharing of BFD 311 sessions with other protocols and opening less number of BFD sessions 312 should be considered, i.e between Master and the most preferred 313 Backup router part of the VRRP instance. 315 To reduce the number of packets generated at a regular interval, 316 Backup Advert packets may be sent at a reduced rate as compared to 317 Advert packets sent by the VRRP Master. 319 7. Operational Considerations 321 A VRRP [RFC5798] peer that forms a member of this Virtual Router, but 322 does not support this feature or extension must be configured with 323 the lowest priority, and will only operate as the Router of last 324 resort on failure of all other VRRP routers supporting this 325 functionality. 327 It is recommended that mechanism defined by this draft, to interface 328 VRRP with BFD should be used when BFD can support more aggressive 329 monitoring timers than VRRP. Otherwise it is desirable not to 330 interface VRRP with BFD for determining the health of VRRP Master. 332 This Draft does not preclude the possibility of the peer table being 333 populated by means of manual configuration, instead of using the 334 BACKUP ADVERTISEMENT as defined by the Draft. 336 8. IANA Considerations 338 This draft includes no request to IANA. 340 9. Security Considerations 342 Security considerations are discussed in the Section 9 of VRRP 343 protocol [RFC5798] specification. There are no additional security 344 considerations identified by this draft. 346 10. Acknowledgements 348 The authors gratefully acknowledge the contributions of Gerry Meyer, 349 and Mouli Chandramouli, for their contributions to the draft. The 350 authors will also like to thank Jeffrey Hass, Maik Pfeil and Vengada 351 Prasad Govindan for their comments and suggestions. 353 11. References 355 11.1. Informative References 357 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 358 (BFD)", RFC 5880. 360 11.2. Normative References 362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 363 Requirement Levels", RFC 2119. 365 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 366 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881. 368 [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) 369 Version 3 for IPv4 and IPv6", RFC 5798. 371 [I-D.draft-ietf-bfd-multipoint] 372 Katz, D., Ward, D., and S. Pallagatti, "BFD for Multipoint 373 Networks", Work in Progress draft-ietf-bfd-multipoint-06. 375 Appendix A. Using Multipoint BFD sessions 377 Possibility of detecting the failure of VRRP Master using Multipoint 378 BFD [I-D.draft-ietf-bfd-multipoint] sessions is still under 379 consideration. 381 Authors' Addresses 383 Nitish Gupta 384 Cisco Systems, Inc. 385 Sarjapur Outer Ring Road 386 Bangalore 560103 387 India 389 Phone: +91 80 4429 2530 390 Email: nitisgup@cisco.com 391 URI: http://www.cisco.com/ 393 Aditya Dogra 394 Cisco Systems, Inc. 395 Sarjapur Outer Ring Road 396 Bangalore 560103 397 India 399 Phone: +91 80 4429 2166 400 Email: addogra@cisco.com 401 URI: http://www.cisco.com/ 403 Colin Docherty 404 25 George Grieve Way 405 Tranent 406 East Lothian, Scotland EH332QT 407 United Kingdom 409 Email: colin@doch.org.uk