idnits 2.17.00 (12 Aug 2021) /tmp/idnits42423/draft-nitish-vrrp-bfd-03.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 (April 13, 2016) is 2229 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == 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: Standards Track Cisco Systems, Inc. 5 Expires: October 15, 2016 C. Docherty 7 G. Mirsky 8 J. Tantsura 9 Ericsson 10 April 13, 2016 12 Fast failure detection in VRRP with BFD 13 draft-nitish-vrrp-bfd-03 15 Abstract 17 This document describes how Bidirectional Forwarding Detection (BFD) 18 can be used to support sub-second detection of a Master Router 19 failure in the Virtual Router Redundancy Protocol (VRRP). 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 15, 2016. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 57 3. Applicability of Single-hop BFD . . . . . . . . . . . . . . . 3 58 3.1. Extension to VRRP protocol . . . . . . . . . . . . . . . 4 59 3.2. VRRP Peer Table . . . . . . . . . . . . . . . . . . . . . 4 60 3.3. VRRP BACKUP ADVERTISEMENT Packet Type . . . . . . . . . . 4 61 3.4. Sample configuration . . . . . . . . . . . . . . . . . . 5 62 3.5. Critical BFD session . . . . . . . . . . . . . . . . . . 7 63 4. Applicability of p2mp BFD . . . . . . . . . . . . . . . . . . 7 64 5. Scalability Considerations . . . . . . . . . . . . . . . . . 8 65 6. Operational Considerations . . . . . . . . . . . . . . . . . 8 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 69 10. Normative References . . . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 The Virtual Router Redundancy Protocol (VRRP) provides redundant 75 Virtual gateways in the Local Area Network (LAN), which is typically 76 the first point of failure for end-hosts sending traffic out of the 77 LAN. Fast failure detection of VRRP Master is critical in supporting 78 high availability of services and improved Quality of Experience to 79 users. In VRRP [RFC5798] specification, Backup routers depend on 80 VRRP packets generated at a regular interval by the Master router, to 81 detect the health of the VRRP Master. Faster failure detection can 82 be achieved within VRRP protocol by reducing the Advertisement 83 Interval and hold down timers. However, aggressive timers can put 84 extra load on CPU and the network bandwidth which may not be 85 desirable. 87 Since the VRRP protocol depends on the availability of Layer 3 IPv4 88 or IPv6 connectivity between redundant peers, the VRRP protocol can 89 interact with the Layer 3 variant of BFD as described in [RFC5881] 90 or [I-D.draft-ietf-bfd-multipoint] to achieve a much faster failure 91 detection of the VRRP Master on the LAN. BFD, as specified by the 92 [RFC5880] or [I-D.draft-ietf-bfd-multipoint] can provide a much 93 faster failure detection in the range of 150ms, if implemented in the 94 part of a Network device which scales better than VRRP when 95 aggressive timers are used. 97 2. Requirements Language 99 In this document, several words are used to signify the requirements 100 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 101 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 102 and "OPTIONAL" in this document are to be interpreted as described in 103 RFC 2119. [RFC2119] 105 3. Applicability of Single-hop BFD 107 BFD for IPv4 or IPv6 (Single Hop) [RFC5881] requires that in order 108 for a BFD session to be formed both peers participating in a BFD 109 session need to know to its peer IPv4 or IPV6 address. This poses a 110 unique problem with the definition of the VRRP protocol, that makes 111 the use of BFD for IPv4 or IPv6 [RFC5881] more challenging. In VRRP 112 it is only the Master router that sends Advert packets. This means 113 that a Master router is not aware of any Backup routers, and Backup 114 routers are only aware of the Master router. This also means that a 115 Backup router is not aware of any other Backup routers in the 116 Network. 118 Since BFD for IPv4 or IPv6 [RFC5881] requires that a session be 119 formed by both peers using a full destination and source address, 120 there needs to be some external means to provide this information to 121 BFD on behalf of VRRP. Once the peer information is made available, 122 VRRP can form BFD sessions with each of the peers that exist in the 123 Virtual Router. The most important BFD session for a given Virtual 124 Router is identified as the Critical Path BFD Session, which is the 125 session that forms between the current VRRP Master router, and the 126 highest priority Backup router. When the Critical Path BFD Session 127 identified by VRRP as having changed state from Up to Down, then this 128 will be interpreted by the VRRP state machine on the highest priority 129 Backup router as a Master Down event. A Master Down event means that 130 the highest priority Backup peer will immediately become the new 131 Master for the Virtual Router. 133 NOTE: At all times, the normal fail-over mechanism defined in the 134 VRRP [RFC5798] will be unaffected, and the BFD fail-over mechanism 135 will always resort to normal VRRP fail-over. 137 This draft defines the mechanism used by the VRRP protocol to build a 138 peer table that will help in forming a mesh of BFD sessions and the 139 detection of Critical Path BFD session. If the Critical Path BFD 140 session were to go down, it will signal a Master Down event and make 141 the most preferred Backup router as the VRRP Master router. This 142 requires an extension to the VRRP protocol. 144 This can be achieved by defining a new type in the VRRP Advert 145 packet, and allowing VRRP peers to build a peer table in any of the 146 operational state, Master or Backup. 148 3.1. Extension to VRRP protocol 150 In this mode of operation VRRP peers learn the adjacent routers, and 151 form BFD sessions between the learnt routers. In order to build the 152 peer table, all routers send VRRP Advert packets whilst in any of the 153 operational states (Master or Backup). Normally VRRP peers only send 154 Advert packets whilst in the Master state, however in this mode VRRP 155 Backup peers will also send Advert packets with the type field set to 156 BACKUP ADVERTISEMENT type defined in Section 3.3 of this document. 157 The VRRP Master router will still continue to send packets with the 158 Advert type as ADVERTISEMENT as defined in the VRRP protocol. This 159 is to maintain inter-operability with peers complying to VRRP 160 protocol. 162 Additionally Advert packets sent from Backup Peers must not use the 163 Virtual router MAC address as the source address. Instead it must 164 use the Interface MAC address as the source address from which the 165 packet is sent from. This is because the source MAC override feature 166 is used by the Master to send Advert packets from the Virtual Router 167 MAC address, which is used to keep the bridging cache on LAN switches 168 and bridging devices refreshed with the destination port for the 169 Virtual Router MAC. 171 3.2. VRRP Peer Table 173 VRRP peers can now form the peer table by learning the source address 174 in the ADVERTISEMENT or BACKUP ADVERTISEMENT packet sent by VRRP 175 Master or Backup peers. This allows all peers to create a mesh of 176 BFD sessions with all other operational peers. 178 A peer entry should be removed from the peer table if Advert is not 179 received from a peer for a period of (3 * the Advert interval). 181 3.3. 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 3.4. Sample configuration 221 The following figure shows a simple network with three VRRP routers 222 implementing one virtual router. 224 +-----------+ +-----------+ +-----------+ 225 | Rtr1 | | Rtr2 | | Rtr3 | 226 |(MR VRID=1)| |(BR VRID=1)| |(BR VRID=1)| 227 | (PR=200) | | (PR=150) | | (PR=100) | 228 | VRIPVX= A | | VRIPVX= A | | VRIPVX= A | 229 +-----------+ +-----------+ +-----------+ 230 B C D 231 | | | 232 | | | 233 | | | 234 ---------+--------+--------+---------+--------+--------- 235 Legend: 236 ---+---+---+-- = Ethernet, Token Ring, or FDDI 237 MR = Master Router 238 BR = Backup Router 239 PR = VRRP Router priority 240 VRID = VRRP Router ID 241 VRIPVX= IPv4 or IPv6 address protected by 242 the VRRP Router 243 B,C,D = Interface IPv4 or IPv6 address of 244 the Virtual Router 246 In the above configuration there are three routers on the LAN 247 protecting an IPv4 or IPv6 address associated to a Virtual Router ID 248 1. Rtr1 is the Master router since it has the highest priority 249 compared to Rtr2 and Rtr3. Now if peer learning extension is enabled 250 on all the peers. Rtr1 will send the Advert packet with type field 251 set to 1. While Rtr2 and Rtr3 will send the Advert packet with type 252 field set to 2. In the above configuration the peer table built at 253 each router is shown below: 255 Rtr1 Peer table 257 +------------------------------------+ 258 | Peer Address | Priority | 259 +------------------------------------+ 260 | C | 150 | 261 +------------------------------------+ 262 | D | 100 | 263 +------------------------------------+ 264 Rtr2 Peer table 266 +------------------------------------+ 267 | Peer Address | Priority | 268 +------------------------------------+ 269 | B | 200 | 270 +------------------------------------+ 271 | D | 100 | 272 +------------------------------------+ 274 Rtr3 Peer table 276 +------------------------------------+ 277 | Peer Address | Priority | 278 +------------------------------------+ 279 | B | 200 | 280 +------------------------------------+ 281 | C | 150 | 282 +------------------------------------+ 284 Once the peer tables are formed, VRRP on each router can form a mesh 285 of BFD sessions with all the learnt peers. 287 3.5. Critical BFD session 289 The Critical BFD Session is determined to be the session between the 290 VRRP Master and the next best VRRP Backup. Failure of the Critical 291 BFD session indicates that the Master is no longer available and the 292 most preferred Backup will now become Master. 294 In the above example the Critical BFD session is shared between Rtr1 295 and Rtr2. If the BFD Session goes from Up to Down state, Rtr2 can 296 treat it as a Master down event and immediately assume the role of 297 VRRP Master router for VRID 1 and Rtr3 will become the critical 298 Backup. 300 4. Applicability of p2mp BFD 302 [I-D.draft-ietf-bfd-multipoint] provides an alternative solution that 303 uses default route rather than dynamic routing. This approach can be 304 an efficient in some network deployments. Each redundancy group 305 presents itself as p2mp BFD session with its Master being the root 306 and Backup routers being tails of the p2mp BFD session. The Master 307 router starts transmitting BFD control packets with VRID as source IP 308 address. Backup router demultiplexes p2mp BFD test sessions based on 309 VRID that it been configured with. Once Backup router accepts p2mp 310 session from the new Master router backup router the Backup router 311 MAY use My Discriminator from received p2mp BFD control packet to 312 demultiplex p2mp BFD sessions. When a Backup router detects failure 313 of the Master router it re-evaluates its role in the VRID. As 314 result, the Backup router may become the Master router of the given 315 VRID or continue as a Backup router. If the former is the case, then 316 the new Master router MUST select My Discriminator and start 317 transmitting p2mp BFD control packets using Master IP address as 318 source IP address for p2mp BFD control packets. If the latter is the 319 case, then the Backup router MUST wait for p2mp BFD control packet 320 with source IP address set to VRID. 322 5. Scalability Considerations 324 When forming mesh of BFD sessions one possible scenario can occur if 325 the system is not able to scale well with the increased load of 326 multiple BFD sessions. To mitigate this problem sharing of BFD 327 sessions with other protocols and opening less number of BFD sessions 328 should be considered, i.e. between Master and the most preferred 329 Backup router of the VRRP instance. 331 To reduce the number of packets generated at a regular interval, 332 Backup Advert packets may be sent at a reduced rate as compared to 333 Advert packets sent by the VRRP Master. 335 In a Data Centre with VXLAN extending the Layer 2 network, when 336 implementing Section 4 of this document, inherently multicast traffic 337 is flooded or replicated to all the Virtual Tunneling End Points by 338 means of multicast traffic in the underlay network. The amount of 339 replication or flooding depends on the number of Virtual Tunnelling 340 End Points connected to the VXLAN network. VRRP is typically 341 deployed on the Virtual Tunneling End Points. If Multipoint BFD is 342 used for tracking the state of VRRP Master Router the Multipoint BFD 343 packets will get carried over the Layer 2 Overlay, this can lead to a 344 lot of traffic getting flooded on the overlay as the rate at which 345 BFD packets are generated will be typically in sub second range. 346 Which is the problem if VRRP is configured with sub second timers. 347 So in such scenarios where flooding of Multicast traffic is a 348 concern, it is recommended to use Point to Point BFD sessions to 349 avoid inherent flooding of Multicast traffic and configure VRRP to 350 default or slow timers. 352 6. Operational Considerations 354 A VRRP peer that forms a member of this Virtual Router, but does not 355 support this feature or extension must be configured with the lowest 356 priority, and will only operate as the Router of last resort on 357 failure of all other VRRP routers supporting this functionality. 359 It is recommended that mechanism defined by this draft, to interface 360 VRRP with BFD should be used when BFD can support more aggressive 361 monitoring timers than VRRP. Otherwise it is desirable not to 362 interface VRRP with BFD for determining the health of VRRP Master. 364 This Draft does not preclude the possibility of the peer table being 365 populated by means of manual configuration, instead of using the 366 BACKUP ADVERTISEMENT as defined by the Draft. 368 7. IANA Considerations 370 This draft includes no request to IANA. 372 8. Security Considerations 374 Security considerations discussed in [RFC5798], [RFC5880] and 375 [I-D.draft-ietf-bfd-multipoint], apply to this document. There are 376 no additional security considerations identified by this draft. 378 9. Acknowledgements 380 The authors gratefully acknowledge the contributions of Gerry Meyer, 381 and Mouli Chandramouli, for their contributions to the draft. The 382 authors will also like to thank Jeffrey Haas, Maik Pfeil and Vengada 383 Prasad Govindan for their comments and suggestions. 385 10. Normative References 387 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 388 (BFD)", RFC 5880, 2010. 390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 391 Requirement Levels", RFC 2119, 1997. 393 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 394 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 2010. 396 [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) 397 Version 3 for IPv4 and IPv6", RFC 5798, 2010. 399 [I-D.draft-ietf-bfd-multipoint] 400 Katz, D., Ward, D., and S. Pallagatti, "BFD for Multipoint 401 Networks", Work in Progress draft-ietf-bfd-multipoint-07, 402 2015. 404 Authors' Addresses 406 Nitish Gupta 407 Cisco Systems, Inc. 408 Sarjapur Outer Ring Road 409 Bangalore 560103 410 India 412 Phone: +91 80 4429 2530 413 Email: nitisgup@cisco.com 414 URI: http://www.cisco.com/ 416 Aditya Dogra 417 Cisco Systems, Inc. 418 Sarjapur Outer Ring Road 419 Bangalore 560103 420 India 422 Phone: +91 80 4429 2166 423 Email: addogra@cisco.com 424 URI: http://www.cisco.com/ 426 Colin Docherty 427 25 George Grieve Way 428 Tranent 429 East Lothian, Scotland EH332QT 430 United Kingdom 432 Email: colin@doch.org.uk 434 Greg Mirsky 435 Ericsson 437 Email: gregory.mirsky@ericsson.com 439 Jeff Tantsura 440 Ericsson 442 Email: jeff.tantsura@ericsson.com