home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1900s / rfc1966.txt < prev    next >
Text File  |  1996-06-09  |  14KB  |  396 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           T. Bates
  8. Request for Comments: 1966                                 cisco Systems
  9. Category: Experimental                                        R. Chandra
  10.                                                            cisco Systems
  11.                                                                June 1996
  12.  
  13.  
  14.                           BGP Route Reflection
  15.                     An alternative to full mesh IBGP
  16.  
  17. Status of this Memo
  18.  
  19.    This memo defines an Experimental Protocol for the Internet
  20.    community.  This memo does not specify an Internet standard of any
  21.    kind.  Discussion and suggestions for improvement are requested.
  22.    Distribution of this memo is unlimited.
  23.  
  24. Abstract
  25.  
  26.    The Border Gateway Protocol [1] is an inter-autonomous system routing
  27.    protocol designed for TCP/IP internets. BGP deployments are
  28.    configured such that that all BGP speakers within a single AS must be
  29.    fully meshed so that any external routing information must be re-
  30.    distributed to all other routers within that AS. This represents a
  31.    serious scaling problem that has been well documented with several
  32.    alternatives proposed [2,3].
  33.  
  34.    This document describes the use and design of a method known as
  35.    "Route Reflection" to alleviate the the need for "full mesh" IBGP.
  36.  
  37. 1.  Introduction
  38.  
  39.    Currently in the Internet, BGP deployments are configured such that
  40.    that all BGP speakers within a single AS must be fully meshed and any
  41.    external routing information must be re-distributed to all other
  42.    routers within that AS. This "full mesh" requirement clearly does not
  43.    scale when there are a large number of IBGP speakers as is common in
  44.    many of todays internet networks.
  45.  
  46.    For n BGP speakers within an AS you must maintain n*(n-1)/2 unique
  47.    IBGP sessions. With finite resources in both bandwidth and router CPU
  48.    this clearly does not scale.
  49.  
  50.    This scaling problem has been well documented and a number of
  51.    proposals have been made to alleviate this [2,3]. This document
  52.    represents another alternative in alleviating the need for a "full
  53.    mesh" and is known as "Route Reflection". It represents a change in
  54.    the commonly understood concept of IBGP and the addition of two new
  55.  
  56.  
  57.  
  58. Bates & Chandra               Experimental                      [Page 1]
  59.  
  60. RFC 1966                  BGP Route Reflection                 June 1996
  61.  
  62.  
  63.    optional transitive BGP attributes.
  64.  
  65. 2.  Design Criteria
  66.  
  67.    Route Reflection was designed to satisfy the following criteria.
  68.  
  69.            o Simplicity
  70.  
  71.              Any alternative must be both simple to configure as well
  72.              as understand.
  73.  
  74.            o Easy Migration
  75.  
  76.              It must be possible to migrate from a full mesh
  77.              configuration without the need to change either topology
  78.              or AS. This is an unfortunate management overhead of the
  79.              technique proposed in [3].
  80.  
  81.            o Compatibility
  82.  
  83.              It must be possible for non compliant IBGP peers
  84.              to continue be part of the original AS or domain
  85.              without any loss of BGP routing information.
  86.  
  87.    These criteria were motivated by operational experiences of a very
  88.    large and topology rich network with many external connections.
  89.  
  90. 3.  Route Reflection
  91.  
  92.    The basic idea of Route Reflection is very simple. Let us consider
  93.    the simple example depicted in Figure 1 below.
  94.  
  95.                         +------ +        +-------+
  96.                         |       |  IBGP  |       |
  97.                         | RTR-A |--------| RTR-B |
  98.                         |       |        |       |
  99.                         +-------+        +-------+
  100.                               \             /
  101.                           IBGP \   ASX     / IBGP
  102.                                 \         /
  103.                                  +-------+
  104.                                  |       |
  105.                                  | RTR-C |
  106.                                  |       |
  107.                                  +-------+
  108.  
  109.                          Figure 1: Full Mesh IBGP
  110.  
  111.  
  112.  
  113.  
  114. Bates & Chandra               Experimental                      [Page 2]
  115.  
  116. RFC 1966                  BGP Route Reflection                 June 1996
  117.  
  118.  
  119.    In ASX there are three IBGP speakers (routers RTR-A, RTR-B and RTR-
  120.    C).  With the existing BGP model, if RTR-A receives an external route
  121.    and it is selected as the best path it must advertise the external
  122.    route to both RTR-B and RTR-C. RTR-B and RTR-C (as IBGP speakers)
  123.    will not re-advertise these IBGP learned routes to other IBGP
  124.    speakers.
  125.  
  126.    If this rule is relaxed and RTR-C is allowed to reflect IBGP learned
  127.    routes, then it could re-advertise (or reflect) the IBGP routes
  128.    learned from RTR-A to RTR-B and vice versa. This would eliminate the
  129.    need for the IBGP session between RTR-A and RTR-B as shown in Figure
  130.    2 below.
  131.  
  132.                         +------ +        +-------+
  133.                         |       |        |       |
  134.                         | RTR-A |        | RTR-B |
  135.                         |       |        |       |
  136.                         +-------+        +-------+
  137.                              \             /
  138.                          IBGP \   ASX     / IBGP
  139.                                \         /
  140.                                  +-------+
  141.                                  |       |
  142.                                  | RTR-C |
  143.                                  |       |
  144.                                  +-------+
  145.  
  146.                       Figure 2: Route Reflection IBGP
  147.  
  148.    The Route Reflection scheme is based upon this basic principle.
  149.  
  150. 4.  Terminology and Concepts
  151.  
  152.    We use the term "Route Reflector" (RR) to represent an IBGP speaker
  153.    that participates in the reflection.  The internal peers of a RR are
  154.    divided into two groups:
  155.  
  156.            1) Client Peers
  157.  
  158.            2) Non-Client Peers
  159.  
  160.    A RR reflects routes between these groups.  A RR along with its
  161.    client peers form a Cluster. The Non-Client peer must be fully meshed
  162.    but the Client peers need not be fully meshed. The Client peers
  163.    should not peer with internal speakers outside of their cluster.
  164.    Figure 3 depicts a simple example outlining the basic RR components
  165.    using the terminology noted above.
  166.  
  167.  
  168.  
  169.  
  170. Bates & Chandra               Experimental                      [Page 3]
  171.  
  172. RFC 1966                  BGP Route Reflection                 June 1996
  173.  
  174.  
  175.                       / - - - - - - - - - - - - -  -\
  176.                       |           Cluster           |
  177.                         +-------+        +-------+
  178.                       | |       |        |       |  |
  179.                         | RTR-A |        | RTR-B |
  180.                       | |Client |        |Client |  |
  181.                         +-------+        +-------+
  182.                       |      \             /        |
  183.                          IBGP \           / IBGP
  184.                       |        \         /          |
  185.                                 +-------+
  186.                       |         |       |           |
  187.                                 | RTR-C |
  188.                       |         |  RR   |           |
  189.                                 +-------+
  190.                       |           /   \             |
  191.                       \ - - - - -/- - -\- - - - - - /
  192.                           IBGP  /       \  IBGP
  193.                        +-------+         +-------+
  194.                        | RTR-D |  IBGP   | RTR-E |
  195.                        |  Non- |---------|  Non- |
  196.                        |Client |         |Client |
  197.                        +-------+         +-------+
  198.  
  199.                           Figure 3: RR Components
  200.  
  201. 5. Operation
  202.  
  203.    When a route is received by a RR, it selects the best path based on
  204.    its path selection rule. After the best path is selected, it must do
  205.    the following depending on the type of the peer it is receiving the
  206.    best path from:
  207.  
  208.            1) A Route from a Non-Client peer
  209.  
  210.               Reflect to all other Clients.
  211.  
  212.            2) A Route from a Client peer
  213.  
  214.               Reflect to all the Non-Client peers and also to the
  215.               Client peers other than the originator. (Hence the
  216.               Client peers are not required to be fully meshed).
  217.  
  218.             3) Route from an EBGP peer
  219.  
  220.                Send to all the Client and Non-Client Peers.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Bates & Chandra               Experimental                      [Page 4]
  227.  
  228. RFC 1966                  BGP Route Reflection                 June 1996
  229.  
  230.  
  231.    An Autonomous System could have many RRs. A RR treats other RRs just
  232.    like any other internal BGP speakers. A RR could be configured to
  233.    have other RRs in a Client group or Non-client group.
  234.  
  235.    In a simple configuration the backbone could be divided into many
  236.    clusters.  Each RR would be configured with other RRs as Non-Client
  237.    peers (thus all the RRs will be fully meshed.). The Clients will be
  238.    configured to maintain IBGP session only with the RR in their
  239.    cluster.  Due to route reflection, all the IBGP speakers will receive
  240.    reflected routing information.
  241.  
  242.    It is normal in a Autonomous System to have BGP speakers that do not
  243.    understand the concept of Route-Reflectors (let us call them
  244.    conventional BGP speakers). The Route-Reflector Scheme allows such
  245.    conventional BGP speakers to co-exist. Conventional BGP speakers ould
  246.    be either members of a Non-Client group or a Client group. This
  247.    allows for an easy and gradual migration from the current IBGP model
  248.    to the Route Reflection model. One could start creating clusters by
  249.    configuring a single router as the designated RR and configuring
  250.    other RRs and their clients as normal IBGP peers. Additional clusters
  251.    can be created gradually.
  252.  
  253. 6.  Redundant RRs
  254.  
  255.    Usually a cluster of clients will have a single RR. In that case, the
  256.    cluster will be identified by the ROUTER_ID of the RR. However, this
  257.    represents a single point of failure so to make it possible to have
  258.    multiple RRs in the same cluster, all RRs in the same cluster must be
  259.    configured with a 4-byte CLUSTER_ID so that an RR can discern routes
  260.    from other RRs in the same cluster.
  261.  
  262. 7.  Avoiding Routing Information Loops
  263.  
  264.    As IBGP learned routes are reflected, it is possible through mis-
  265.    configuration to form route re-distribution loops. The Route
  266.    Reflection method defines the following attributes to detect and
  267.    avoid routing information loops.
  268.  
  269.    ORIGINATOR_ID
  270.  
  271.    ORIGINATOR_ID is a new optional, non-transitive BGP attribute of Type
  272.    code 9.  This attribute is 4 bytes long and it will be created by a
  273.    RR. This attribute will carry the ROUTER_ID of the originator of the
  274.    route in the local AS. A BGP speaker should not create an
  275.    ORIGINATOR_ID attribute if one already exists.  A route reflector
  276.    must never send routing information back to the router specified in
  277.    ORIGINATOR_ID.
  278.  
  279.  
  280.  
  281.  
  282. Bates & Chandra               Experimental                      [Page 5]
  283.  
  284. RFC 1966                  BGP Route Reflection                 June 1996
  285.  
  286.  
  287.    CLUSTER_LIST
  288.  
  289.    Cluster-list is a new optional, non-transitive BGP attribute of Type
  290.    code 10. It is a sequence of CLUSTER_ID values representing the
  291.    reflection path that the route has passed. It is encoded as follows:
  292.  
  293.  
  294.               0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  295.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  296.      |  Attr. Flags  |Attr. Type Code|   Length      | value ...
  297.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  298.  
  299.    Where Length is the number of octets.
  300.  
  301.    When a RR reflects a route from its Clients to a Non-Client peer, it
  302.    must append the local CLUSTER_ID to the CLUSTER_LIST. If the
  303.    CLUSTER_LIST is empty, it must create a new one. Using this attribute
  304.    an RR can identify if the routing information is looped back to the
  305.    same cluster due to mis-configuration. If the local CLUSTER_ID is
  306.    found in the cluster-list, the advertisement will be ignored.
  307.  
  308. 8.  Implementation and Configuration Considerations
  309.  
  310.    Care should be taken to make sure that none of the BGP path
  311.    attributes defined above can be modified through configuration when
  312.    exchanging internal routing information between RRs and Clients and
  313.    Non-Clients. This could result is looping of routes.
  314.  
  315.    In some implementations, modification of the BGP path attribute,
  316.    NEXT_HOP is possible. For example, there could be a need for a RR to
  317.    modify NEXT_HOP for EBGP learned routes sent to its internal peers.
  318.    However, it must not be possible for an RR to set on reflected IBGP
  319.    routes as this breaks the basic principle of Route Reflection and
  320.    will result in potential black holeing of traffic.
  321.  
  322.    An RR should not modify any AS-PATH attributes (i.e. LOCAL_PREF, MED,
  323.    DPA)that could change consistent route selection. This could result
  324.    in potential loops.
  325.  
  326.    The BGP protocol provides no way for a Client to identify itself
  327.    dynamically as a Client to an RR configured BGP speaker and the
  328.    simplest way to achieve this is by manual configuration.
  329.  
  330. 9.  Security Considerations
  331.  
  332.    Security issues are not discussed in this memo.
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Bates & Chandra               Experimental                      [Page 6]
  339.  
  340. RFC 1966                  BGP Route Reflection                 June 1996
  341.  
  342.  
  343. 10. Acknowledgments
  344.  
  345.    The authors would like to thank Dennis Ferguson, Enke Chen, John
  346.    Scudder, Paul Traina and Tony Li for the many discussions resulting
  347.    in this work. This idea was developed from an earlier discussion
  348.    between Tony Li and Dimitri Haskin.
  349.  
  350. 11. References
  351.  
  352.    [1]  Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
  353.         RFC 1771, March 1995.
  354.  
  355.    [2]  Haskin, D., "A BGP/IDRP Route Server alternative to a full mesh
  356.         routing", RFC 1863, October 1995.
  357.  
  358.    [3]  Traina, P., "Limited Autonomous System Confederations for BGP",
  359.         RFC 1965, June 1996.
  360.  
  361. 12. Authors' Addresses
  362.  
  363.    Tony Bates
  364.    cisco Systems
  365.    170 West Tasman Drive
  366.    San Jose, CA 95134
  367.  
  368.    Phone: +1 408 527 2470
  369.    EMail: tbates@cisco.com
  370.  
  371.  
  372.    Ravishanker Chandrasekeran
  373.    (Ravi Chandra)
  374.    cisco Systems
  375.    170 West Tasman Drive
  376.    San Jose, CA 95134
  377.  
  378.    EMail: rchandra@cisco.com
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Bates & Chandra               Experimental                      [Page 7]
  395.  
  396.