From c8a5e5e190407734a4d59963cfdf8d9f7e98d384 Mon Sep 17 00:00:00 2001 From: Quentin Young Date: Mon, 17 Sep 2018 19:18:47 +0000 Subject: [PATCH] doc: clarify documentation on BGP multiple AS Documentation on how to use multiple autonomous systems was inaccurate and a bit scattered. Clarify usage of VRFs with multiple autonomous systems, how to configure them, and their distinction from views. Also moves a block on L3VPN VRFs out of the 'Basic Concepts' section. Signed-off-by: Quentin Young --- doc/user/bgp.rst | 245 +++++++++++++++++++++++++---------------------- 1 file changed, 129 insertions(+), 116 deletions(-) diff --git a/doc/user/bgp.rst b/doc/user/bgp.rst index d9d496f7fc..b84a9e8f82 100644 --- a/doc/user/bgp.rst +++ b/doc/user/bgp.rst @@ -181,20 +181,6 @@ will establish the connection with unicast only capability. When there are no common capabilities, FRR sends Unsupported Capability error and then resets the connection. -.. _bgp-concepts-vrfs: - -VRFs: Virtual Routing and Forwarding ------------------------------------- - -*bgpd* supports :abbr:`L3VPN (Layer 3 Virtual Private Networks)` :abbr:`VRFs -(Virtual Routing and Forwarding tables)` for IPv4 :rfc:`4364` and IPv6 -:rfc:`4659`. L3VPN routes, and their associated VRF MPLS labels, can be -distributed to VPN SAFI neighbors in the *default*, i.e., non VRF, BGP -instance. VRF MPLS labels are reached using *core* MPLS labels which are -distributed using LDP or BGP labeled unicast. *bgpd* also supports inter-VRF -route leaking. General information on FRR's VRF support can be found in -:ref:`zebra-vrf`. - .. _bgp-router-configuration: BGP Router Configuration @@ -228,6 +214,122 @@ internal or external. not enabled *bgpd* can't get interface information so `router-id` is set to 0.0.0.0. So please set router-id by hand. + +.. _bgp-multiple-autonomous-systems: + +Multiple Autonomous Systems +--------------------------- + +FRR's BGP implementation is capable of running multiple autonomous systems at +once. Each configured AS corresponds to a :ref:`zebra-vrf`. In the past, to get +the same functionality the network administrator had to run a new *bgpd* +process; using VRFs allows multiple autonomous systems to be handled in a +single process. + +When using multiple autonomous systems, all router config blocks after the +first one must specify a VRF to be the target of BGP's route selection. This +VRF must be unique within respect to all other VRFs being used for the same +purpose, i.e. two different autonomous systems cannot use the same VRF. +However, the same AS can be used with different VRFs. + +.. note:: + + The separated nature of VRFs makes it possible to peer a single *bgpd* + process to itself, on one machine. This can be used for prototyping and + other purposes. + +Configuration of additional autonomous systems, or of a router that targets a +specific VRF, is accomplished with the following command: + +.. index:: router bgp ASN vrf VRFNAME +.. clicmd:: router bgp ASN vrf VRFNAME + + ``VRFNAME`` is matched against VRFs configured in the kernel. When ``vrf + VRFNAME`` is not specified, the BGP protocol process belongs to the default + VRF. + +An example configuration with multiple autonomous systems might look like this: + +.. code-block:: frr + + router bgp 1 + neighbor 10.0.0.1 remote-as 20 + neighbor 10.0.0.2 remote-as 30 + ! + router bgp 2 vrf blue + neighbor 10.0.0.3 remote-as 40 + neighbor 10.0.0.4 remote-as 50 + ! + router bgp 3 vrf red + neighbor 10.0.0.5 remote-as 60 + neighbor 10.0.0.6 remote-as 70 + ... + +In the past this feature done differently and the following commands were +required to enable the functionality. They are now deprecated. + +.. deprecated:: 5.0 + This command is deprecated and may be safely removed from the config. + +.. index:: bgp multiple-instance +.. clicmd:: bgp multiple-instance + + Enable BGP multiple instance feature. Because this is now the default + configuration this command will not be displayed in the running + configuration. + +.. deprecated:: 5.0 + This command is deprecated and may be safely removed from the config. + +.. index:: no bgp multiple-instance +.. clicmd:: no bgp multiple-instance + + In previous versions of FRR, this command disabled the BGP multiple instance + feature. This functionality is automatically turned on when BGP multiple + instances or views exist so this command no longer does anything. + +.. seealso:: :ref:`bgp-vrf-route-leaking` +.. seealso:: :ref:`zebra-vrf` + + +.. _bgp-views: + +Views +----- + +In addition to supporting multiple autonomous systems, FRR's BGP implementation +also supports *views*. + +BGP views are almost the same as normal BGP processes, except that routes +selected by BGP are not installed into the kernel routing table. The view +functionality allows the exchange of BGP routing information without affecting +the kernel routing tables. + +.. index:: router bgp AS-NUMBER view NAME +.. clicmd:: router bgp AS-NUMBER view NAME + + Make a new BGP view. You can use an arbitrary word for the ``NAME``. Routes + selected by the view are not installed into the kernel routing table. + + With this command, you can setup Route Server like below. + + .. code-block:: frr + + ! + router bgp 1 view 1 + neighbor 10.0.0.1 remote-as 2 + neighbor 10.0.0.2 remote-as 3 + ! + router bgp 2 view 2 + neighbor 10.0.0.3 remote-as 4 + neighbor 10.0.0.4 remote-as 5 + +.. index:: show [ip] bgp view NAME +.. clicmd:: show [ip] bgp view NAME + + Display the routing table of BGP view ``NAME``. + + Route Selection --------------- @@ -1609,32 +1711,23 @@ Large Communities in Route Map overwriting other values. Multiple large-community values can be specified. -.. _bgp-vrfs: +.. _bgp-l3vpn-vrfs: -VRFs ----- +L3VPN VRFs +---------- -BGP supports multiple VRF instances with the following command: - -.. index:: router bgp ASN vrf VRFNAME -.. clicmd:: router bgp ASN vrf VRFNAME +*bgpd* supports :abbr:`L3VPN (Layer 3 Virtual Private Networks)` :abbr:`VRFs +(Virtual Routing and Forwarding)` for IPv4 :rfc:`4364` and IPv6 :rfc:`4659`. +L3VPN routes, and their associated VRF MPLS labels, can be distributed to VPN +SAFI neighbors in the *default*, i.e., non VRF, BGP instance. VRF MPLS labels +are reached using *core* MPLS labels which are distributed using LDP or BGP +labeled unicast. *bgpd* also supports inter-VRF route leaking. -``VRFNAME`` is matched against VRFs configured in the kernel. When -``vrf VRFNAME`` is not specified, the BGP protocol process belongs to the -default VRF. -With VRF, you can isolate networking information. Having BGP VRF allows you to -have several BGP instances on the same system process. This solution solves -scalabiliy issues where the network administrator had previously to run -separately several BGP processes on each namespace. Now, not only BGP VRF -solves this, but also this method applies to both kind of VRFs backend: default -VRF from Linux kernel or network namespaces. Also, having separate BGP -instances does not imply that the AS number has to be different. For internal -purposes, it is possible to do iBGP peering from two differents network -namespaces. +.. _bgp-vrf-route-leaking: VRF Route Leaking -^^^^^^^^^^^^^^^^^ +----------------- BGP routes may be leaked (i.e. copied) between a unicast VRF RIB and the VPN SAFI RIB of the default VRF for use in MPLS-based L3VPNs. Unicast routes may @@ -1648,7 +1741,7 @@ to a unicast VRF, whereas ``export`` refers to routes leaked from a unicast VRF to VPN. Required parameters -""""""""""""""""""" +^^^^^^^^^^^^^^^^^^^ Routes exported from a unicast VRF to the VPN RIB must be augmented by two parameters: @@ -1682,7 +1775,7 @@ When using the shortcut syntax for vrf-to-vrf leaking, the RD and RT are auto-derived. General configuration -""""""""""""""""""""" +^^^^^^^^^^^^^^^^^^^^^ Configuration of route leaking between a unicast VRF RIB and the VPN SAFI RIB of the default VRF is accomplished via commands in the context of a VRF @@ -1781,86 +1874,6 @@ address-family: Disables automatic leaking from vrf VRFNAME to the current VRF using the VPN RIB as intermediary. -.. _bgp-instances-and-views: - -Instances and Views -------------------- - -A BGP *instance* is a normal BGP process. Routes selected by BGP are installed -into the kernel routing table. - -.. note:: - In previous versions of FRR, running multiple AS's from the same BGP process - was not supported; in order to run multiple AS's it was necessary to run - multiple BGP processes. This had to be explicitly configured with the - ``bgp multiple-instance`` command. Recent versions of FRR support multiple - BGP AS's within the same process by simply defining multiple - ``router bgp X`` blocks, so the ``multiple-instance`` command is now - unnecessary and deprecated. - -.. index:: router bgp AS-NUMBER -.. clicmd:: router bgp AS-NUMBER - - Make a new BGP instance. You can use an arbitrary word for the `name`. - - .. code-block:: frr - - router bgp 1 - neighbor 10.0.0.1 remote-as 2 - neighbor 10.0.0.2 remote-as 3 - ! - router bgp 2 - neighbor 10.0.0.3 remote-as 4 - neighbor 10.0.0.4 remote-as 5 - -.. deprecated:: 5.0 - This command does nothing and can be safely removed. - -.. index:: bgp multiple-instance -.. clicmd:: bgp multiple-instance - - Enable BGP multiple instance feature. Because this is now the default - configuration this command will not be displayed in the running - configuration. - -.. deprecated:: 5.0 - This command does nothing and can be safely removed. - -.. index:: no bgp multiple-instance -.. clicmd:: no bgp multiple-instance - - In previous versions of FRR, this command disabled the BGP multiple instance - feature. This functionality is automatically turned on when BGP multiple - instances or views exist so this command no longer does anything. - -BGP views are almost same as normal BGP processes, except that routes selected -by BGP are not installed into the kernel routing table. The view functionality -allows the exchange of BGP routing information only without affecting the -kernel routing tables. - -.. index:: router bgp AS-NUMBER view NAME -.. clicmd:: router bgp AS-NUMBER view NAME - - Make a new BGP view. You can use arbitrary word for the ``NAME``. Routes selected by the view are not installed into the kernel routing table. - view's route selection result does not go to the kernel routing table. - - With this command, you can setup Route Server like below. - - .. code-block:: frr - - ! - router bgp 1 view 1 - neighbor 10.0.0.1 remote-as 2 - neighbor 10.0.0.2 remote-as 3 - ! - router bgp 2 view 2 - neighbor 10.0.0.3 remote-as 4 - neighbor 10.0.0.4 remote-as 5 - -.. index:: show [ip] bgp view NAME -.. clicmd:: show [ip] bgp view NAME - - Display the routing table of BGP view ``NAME``. .. _bgp-cisco-compatibility: -- 2.39.5