BGP Route Reflector in Forwarding Path Juniper Networks, Inc.
1133 Innovation Way, Sunnyvale CA 94089 US kaliraj@juniper.net
Juniper Networks, Inc.
1133 Innovation Way, Sunnyvale CA 94089 US natv@juniper.net
The procedures in BGP Route Reflection (RR) spec primarily deal with scenarios where the RR is not in forwarding path, and is reflecting BGP routes with next hop unchanged. These procedures can sometimes result in traffic forwarding loops in deployments where the RR is in forwarding path, and is reflecting BGP routes with next hop set to self. This document specifies approaches to minimize possiblity of such traffic forwarding loops. One of those approaches updates path selection procedures specified in Section 9 of BGP RR. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC 2119 RFC 8174 when, and only when, they appear in all capitals, as shown here.
The procedures in BGP Route Reflection (RR) spec primarily deal with scenarios where the RR is not in forwarding path, and is reflecting BGP routes with next hop unchanged. These procedures can sometimes result in traffic forwarding loops in deployments where the RR is in forwarding path, and is reflecting BGP routes with next hop set to self. This document specifies approaches to minimize possiblity of such traffic forwarding loops. One of those approaches updates path selection procedures specified in Section 9 of BGP RR.
AS: Autonomous System NLRI: Network Layer Reachability Information AFI: Address Family Identifier SAFI: Subsequent Address Family Identifier SN: Service Node BN: Border Node PE: Provider Edge EP: Endpoint, e.g. a loopback address in the network MPLS: Multi Protocol Label Switching
[RR26] [RR27] [RR16] | | | | | | |+-[ABR23]--+|+--[ASBR21]---[ASBR13]-+|+--[PE11]--+ || ||| ` / ||| | [CE41]--[PE25]--[P28] [P29] `/ [P15] [CE31] | | | /` | | | | | | / ` | | | | | | / ` | | | +--[ABR24]--+ +--[ASBR22]---[ASBR14]-+ +--[PE12]--+ | AS2 | AS2 | | AS4 + region-1 + region-2 + AS1 + AS3 | | | | 203.0.113.41 ------------ Traffic Direction ----------> 203.0.113.31
A pair of redundant ABRs (ABR23, ABR24 in ), each acting as an RR with next hop self, may choose each other as best path towards egress PE11, instead of the upstream ASBR (ASBR21 or ASBR22), causing a traffic forwarding loop. This happens because of following the path selection rule specified in Section 9 of BGP RR that tie-breaks on ORIGINATOR_ID before CLUSTER_LIST. RFC4456 considers pure RR functionality which is not in forwarding path. When a RR is in forwarding path and reflects routes with next hop self, as is the case for ABR BNs in a BGP transport network, this rule may cause loops. This problem can happen for routes of any BGP address family, including BGP LU (1/4 or 2/4) and BGP CT (AFI/SAFIs: 1/76 or 2/76). Using one or more of the following approaches softens the possibility of such loops in a network with redundant ABRs.
Implementations SHOULD provide a way to alter the tie-breaking rule specified in Section 9 of BGP RR so as to tie-break on CLUSTER_LIST step before ORIGINATOR_ID step, when performing path selection for BGP routes. This document suggests the following modification to the BGP Decision Process Tie Breaking rules (Section 9.1.2.2 of ) that can be applied to path selection of BGP routes: The following rule SHOULD be inserted between Steps e) and f): a BGP Speaker SHOULD prefer a route with the shorter CLUSTER_LIST length. The CLUSTER_LIST length is zero if a route does not carry the CLUSTER_LIST attribute.
Taking into account some other deployment considerations can also help in avoiding this problem, e.g.,: IGP metric should be assigned such that "ABR to redundant ABR" cost is inferior to "ABR to upstream ASBR" cost. Using procedures described in , tunnels belonging to non 'best effort' Transport Classes SHOULD NOT be provisioned between ABRs. This will ensure that the BGP CT route received from an ABR with next hop self will not be usable at a redundant ABR.
This document makes no new requests of IANA.
This document does not change the underlying security issues inherent in the existing BGP protocol, such as those described in , and .
BGP Classful Transport Planes
The content in this document was introduced as part of . But because the described problem is not specific to BGP CT and is useful for other BGP families also, it is being extracted out to this separate document.
Juniper Networks, Inc.
1133 Innovation Way, Sunnyvale CA 94089 US dreshma@juniper.net
AT&T
2212 Avenida Mara, Chula Vista California 91914 USA israel.means@att.com
KIFU, Hungarian NREN
35 Vaci street, Budapest 1134 Hungary ietf@nop.hu
Extreme Networks
55 Commerce Valley Drive West, Suite 300, Thornhill, Toronto, Ontario L3T 7V9 Canada dgowda@extremenetworks.com
Juniper Networks, Inc.
Electra, Exora Business Park~Marathahalli - Sarjapur Outer Ring Road, Bangalore KA 560103 India balajir@juniper.net
Juniper Networks, Inc.
Electra, Exora Business Park~Marathahalli - Sarjapur Outer Ring Road, Bangalore KA 560103 India mrajesh@juniper.net
AT&T
200 S Laurel Ave, Middletown, NJ 07748 USA cy098d@att.com
Cox Communications Inc.
Atlanta GA USA mazen.khaddam@cox.com
Google.
1160 N Mathilda Ave, Bldg 5, Sunnyvale, CA 94089 USA szarecki@google.com
China Mobile
Beijing China xuxiaohu@cmss.chinamobile.com
The authors thank Jeff Haas, John Scudder, Susan Hares, Dongjie (Jimmy), Moses Nagarajah, Jeffrey (Zhaohui) Zhang, Joel Harpern, Jingrong Xie, Mohamed Boucadair, Greg Skinner, Simon Leinen, Navaneetha Krishnan, Ravi M R, Chandrasekar Ramachandran, Shradha Hegde, Colby Barth, Vishnu Pavan Beeram, Sunil Malali, William J Britto, R Shilpa, Ashish Kumar (FE), Sunil Kumar Rawat, Abhishek Chakraborty, Richard Roberts, Krzysztof Szarkowicz, John E Drake, Srihari Sangli, Jim Uttaro, Luay Jalil, Keyur Patel, Ketan Talaulikar, Dhananjaya Rao, Swadesh Agarwal, Robert Raszuk, Ahmed Darwish, Aravind Srinivas Srinivasa Prabhakar, Moshiko Nayman, Chris Tripp, Gyan Mishra, Vijay Kestur, Santosh Kolenchery for all the valuable discussions, constructive criticisms, and review comments. The decision to not reuse SAFI 128 and create a new address-family to carry these transport-routes was based on suggestion made by Richard Roberts and Krzysztof Szarkowicz.