X-Git-Url: https://git.proxmox.com/?a=blobdiff_plain;f=doc%2Fuser%2Fbgp.rst;h=a27243ea7771f1dd2616f786d23b1000af8eee22;hb=510ccb8d36d56b86e2f1e1bdddf79b2bfe884f88;hp=734c9cabd0ab58cd0f09c6daa1d345d374318500;hpb=f503378408bee31f97647b0990e45ffe80ae78c2;p=mirror_frr.git diff --git a/doc/user/bgp.rst b/doc/user/bgp.rst index 734c9cabd..a27243ea7 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,126 @@ 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. Note that this can be done fully within + BGP without a corresponding VRF in the kernel or Zebra, which enables some + practical use cases such as :ref:`route reflectors ` + and route servers. + +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. Each BGP view +provides an independent set of routing information which is only distributed +via BGP. Multiple views can be supported, and BGP view information is always +independent from other routing protocols and Zebra/kernel routes. BGP views use +the core instance (i.e., default VRF) for communication with peers. + +.. 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 --------------- @@ -845,6 +951,23 @@ Configuring Peers specified number of hops away will be allowed to become neighbors. This command is mutually exclusive with *ebgp-multihop*. +.. index:: [no] neighbor PEER capability extended-nexthop +.. clicmd:: [no] neighbor PEER capability extended-nexthop + + Allow bgp to negotiate the extended-nexthop capability with it's peer. + If you are peering over a v6 LL address then this capability is turned + on automatically. If you are peering over a v6 Global Address then + turning on this command will allow BGP to install v4 routes with + v6 nexthops if you do not have v4 configured on interfaces. + +.. index:: [no] bgp fast-external-failover +.. clicmd:: [no] bgp fast-external-failover + + This command causes bgp to not take down ebgp peers immediately + when a link flaps. `bgp fast-external-failover` is the default + and will not be displayed as part of a `show run`. The no form + of the command turns off this ability. + .. _bgp-peer-filtering: Peer Filtering @@ -879,6 +1002,14 @@ Peer Filtering Peer Groups ^^^^^^^^^^^ +Peer groups are used to help improve scaling by generating the same +update information to all members of a peer group. Note that this means +that the routes generated by a member of a peer group will be sent back +to that originating peer with the originator identifier attribute set to +indicated the originating peer. All peers not associated with a +specific peer group are treated as belonging to a default peer group, +and will share updates. + .. index:: neighbor WORD peer-group .. clicmd:: neighbor WORD peer-group @@ -889,6 +1020,13 @@ Peer Groups This command bind specific peer to peer group WORD. +.. index:: neighbor PEER solo +.. clicmd:: neighbor PEER solo + + This command is used to indicate that routes advertised by the peer + should not be reflected back to the peer. This command only is only + meaningful when there is a single peer defined in the peer-group. + Capability Negotiation ^^^^^^^^^^^^^^^^^^^^^^ @@ -996,6 +1134,75 @@ is 4 octet long. The following format is used to define the community value. ``internet`` ``internet`` represents well-known communities value 0. +``graceful-shutdown`` + ``graceful-shutdown`` represents well-known communities value + ``GRACEFUL_SHUTDOWN`` ``0xFFFF0000`` ``65535:0``. :rfc:`8326` implements + the purpose Graceful BGP Session Shutdown to reduce the amount of + lost traffic when taking BGP sessions down for maintainance. The use + of the community needs to be supported from your peers side to + actually have any effect. + +``accept-own`` + ``accept-own`` represents well-known communities value ``ACCEPT_OWN`` + ``0xFFFF0001`` ``65535:1``. :rfc:`7611` implements a way to signal + to a router to accept routes with a local nexthop address. This + can be the case when doing policing and having traffic having a + nexthop located in another VRF but still local interface to the + router. It is recommended to read the RFC for full details. + +``route-filter-translated-v4`` + ``route-filter-translated-v4`` represents well-known communities value + ``ROUTE_FILTER_TRANSLATED_v4`` ``0xFFFF0002`` ``65535:2``. + +``route-filter-v4`` + ``route-filter-v4`` represents well-known communities value + ``ROUTE_FILTER_v4`` ``0xFFFF0003`` ``65535:3``. + +``route-filter-translated-v6`` + ``route-filter-translated-v6`` represents well-known communities value + ``ROUTE_FILTER_TRANSLATED_v6`` ``0xFFFF0004`` ``65535:4``. + +``route-filter-v6`` + ``route-filter-v6`` represents well-known communities value + ``ROUTE_FILTER_v6`` ``0xFFFF0005`` ``65535:5``. + +``llgr-stale`` + ``llgr-stale`` represents well-known communities value ``LLGR_STALE`` + ``0xFFFF0006`` ``65535:6``. + Assigned and intented only for use with routers supporting the + Long-lived Graceful Restart Capability as described in + [Draft-IETF-uttaro-idr-bgp-persistence]_. + Routers recieving routes with this community may (depending on + implementation) choose allow to reject or modify routes on the + presence or absence of this community. + +``no-llgr`` + ``no-llgr`` represents well-known communities value ``NO_LLGR`` + ``0xFFFF0007`` ``65535:7``. + Assigned and intented only for use with routers supporting the + Long-lived Graceful Restart Capability as described in + [Draft-IETF-uttaro-idr-bgp-persistence]_. + Routers recieving routes with this community may (depending on + implementation) choose allow to reject or modify routes on the + presence or absence of this community. + +``accept-own-nexthop`` + ``accept-own-nexthop`` represents well-known communities value + ``accept-own-nexthop`` ``0xFFFF0008`` ``65535:8``. + [Draft-IETF-agrewal-idr-accept-own-nexthop]_ describes + how to tag and label VPN routes to be able to send traffic between VRFs + via an internal layer 2 domain on the same PE device. Refer to + [Draft-IETF-agrewal-idr-accept-own-nexthop]_ for full details. + +``blackhole`` + ``blackhole`` represents well-known communities value ``BLACKHOLE`` + ``0xFFFF029A`` ``65535:666``. :rfc:`7999` documents sending prefixes to + EBGP peers and upstream for the purpose of blackholing traffic. + Prefixes tagged with the this community should normally not be + re-advertised from neighbors of the originating network. It is + recommended upon receiving prefixes tagged with this community to + add ``NO_EXPORT`` and ``NO_ADVERTISE``. + ``no-export`` ``no-export`` represents well-known communities value ``NO_EXPORT`` ``0xFFFFFF01``. All routes carry this value must not be advertised to @@ -1015,9 +1222,17 @@ is 4 octet long. The following format is used to define the community value. it is considered as external BGP peer, so the route will not be announced to the peer. +``no-peer`` + ``no-peer`` represents well-known communities value ``NOPEER`` + ``0xFFFFFF04`` ``65535:65284``. :rfc:`3765` is used to communicate to + another network how the originating network want the prefix propagated. + When the communities attribute is received duplicate community values in the attribute are ignored and value is sorted in numerical order. +.. [Draft-IETF-uttaro-idr-bgp-persistence] +.. [Draft-IETF-agrewal-idr-accept-own-nexthop] + .. _bgp-community-lists: Community Lists @@ -1053,7 +1268,8 @@ expanded This command defines a new expanded community list. ``COMMUNITY`` is a string expression of communities attribute. ``COMMUNITY`` can be a regular expression (:ref:`bgp-regular-expressions`) to match the communities - attribute in BGP updates. + attribute in BGP updates. The expanded community is only used to filter, + not `set` actions. .. deprecated:: 5.0 It is recommended to use the more explicit versions of this command. @@ -1151,6 +1367,8 @@ The ollowing commands can be used in route maps: If ``none`` is specified as the community value, the communities attribute is not sent. + It is not possible to set an expanded community list. + .. index:: set comm-list WORD delete .. clicmd:: set comm-list WORD delete @@ -1391,6 +1609,10 @@ BGP Extended Communities in Route Map This command set Site of Origin value. + +Note that the extended expanded community is only used for `match` rule, not for +`set` actions. + .. _bgp-large-communities-attribute: Large Communities Attribute @@ -1502,33 +1724,26 @@ Large Communities in Route Map large-community list. The third will add a large-community value without overwriting other values. Multiple large-community values can be specified. +Note that the large expanded community is only used for `match` rule, not for +`set` actions. -.. _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 @@ -1542,7 +1757,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: @@ -1576,7 +1791,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 @@ -1675,86 +1890,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: