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
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 <bgp-route-reflector>`
+ 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
---------------
Sets the administrative distance for a particular route.
+.. _bgp-requires-policy:
+
+Require policy on EBGP
+-------------------------------
+
+.. index:: [no] bgp ebgp-requires-policy
+.. clicmd:: [no] bgp ebgp-requires-policy
+
+ This command requires incoming and outgoing filters to be applied for eBGP sessions. Without the incoming filter, no routes will be accepted. Without the outgoing filter, no routes will be announced.
+
.. _bgp-route-flap-dampening:
Route Flap Dampening
in iBGP topologies. This can occur with full-mesh iBGP, but is particularly
problematic in non-full-mesh iBGP topologies that further reduce the routing
information known to each speaker. This has primarily been documented with iBGP
-route-reflection topologies. However, any route-hiding technologies potentially
-could also exacerbate oscillation with MED.
+:ref:`route-reflection <bgp-route-reflector>` topologies. However, any
+route-hiding technologies potentially could also exacerbate oscillation with MED.
This second issue occurs where speakers each have only a subset of routes, and
there are cycles in the preferences between different combinations of routes -
Redistribute OSPF route to BGP process.
-.. index:: redistribute vpn
-.. clicmd:: redistribute vpn
+.. index:: redistribute vnc
+.. clicmd:: redistribute vnc
Redistribute VNC routes to BGP process.
+.. index:: redistribute vnc-direct
+.. clicmd:: redistribute vnc-direct
+
+ Redistribute VNC direct (not via zebra) routes to BGP process.
+
.. index:: update-delay MAX-DELAY
.. clicmd:: update-delay MAX-DELAY
peers ASN is the same as mine as specified under the :clicmd:`router bgp ASN`
command the connection will be denied.
+.. index:: [no] bgp listen range <A.B.C.D/M|X:X::X:X/M> peer-group PGNAME
+.. clicmd:: [no] bgp listen range <A.B.C.D/M|X:X::X:X/M> peer-group PGNAME
+
+ Accept connections from any peers in the specified prefix. Configuration
+ from the specified peer-group is used to configure these peers.
+
+.. note::
+
+ When using BGP listen ranges, if the associated peer group has TCP MD5
+ authentication configured, your kernel must support this on prefixes. On
+ Linux, this support was added in kernel version 4.14. If your kernel does
+ not support this feature you will get a warning in the log file, and the
+ listen range will only accept connections from peers without MD5 configured.
+
+ Additionally, we have observed that when using this option at scale (several
+ hundred peers) the kernel may hit its option memory limit. In this situation
+ you will see error messages like:
+
+ ``bgpd: sockopt_tcp_signature: setsockopt(23): Cannot allocate memory``
+
+ In this case you need to increase the value of the sysctl
+ ``net.core.optmem_max`` to allow the kernel to allocate the necessary option
+ memory.
+
.. _bgp-configuring-peers:
Configuring Peers
.. index:: [no] neighbor PEER maximum-prefix NUMBER
.. clicmd:: [no] neighbor PEER maximum-prefix NUMBER
-.. index:: [no] neighbor PEER local-as AS-NUMBER no-prepend
-.. clicmd:: [no] neighbor PEER local-as AS-NUMBER no-prepend
+ Sets a maximum number of prefixes we can receive from a given peer. If this
+ number is exceeded, the BGP session will be destroyed.
-.. index:: [no] neighbor PEER local-as AS-NUMBER no-prepend replace-as
-.. clicmd:: [no] neighbor PEER local-as AS-NUMBER no-prepend replace-as
+ In practice, it is generally preferable to use a prefix-list to limit what
+ prefixes are received from the peer instead of using this knob. Tearing down
+ the BGP session when a limit is exceeded is far more destructive than merely
+ rejecting undesired prefixes. The prefix-list method is also much more
+ granular and offers much smarter matching criterion than number of received
+ prefixes, making it more suited to implementing policy.
-.. index:: [no] neighbor PEER local-as AS-NUMBER
-.. clicmd:: [no] neighbor PEER local-as AS-NUMBER
+.. index:: [no] neighbor PEER local-as AS-NUMBER [no-prepend] [replace-as]
+.. clicmd:: [no] neighbor PEER local-as AS-NUMBER [no-prepend] [replace-as]
Specify an alternate AS for this BGP process when interacting with the
specified peer. With no modifiers, the specified local-as is prepended to
and will not be displayed as part of a `show run`. The no form
of the command turns off this ability.
+.. index:: [no] bgp default ipv4-unicast
+.. clicmd:: [no] bgp default ipv4-unicast
+
+ This command allows the user to specify that v4 peering is turned
+ on by default or not. This command defaults to on and is not displayed.
+ The `no bgp default ipv4-unicast` form of the command is displayed.
+
.. _bgp-peer-filtering:
Peer Filtering
This command defines a new peer group.
-.. index:: neighbor PEER peer-group WORD
-.. clicmd:: neighbor PEER peer-group WORD
+.. index:: neighbor PEER peer-group PGNAME
+.. clicmd:: neighbor PEER peer-group PGNAME
This command bind specific peer to peer group WORD.
Using AS Path in Route Map
--------------------------
-.. index:: match as-path WORD
-.. clicmd:: match as-path WORD
+.. index:: [no] match as-path WORD
+.. clicmd:: [no] match as-path WORD
+ For a given as-path, WORD, match it on the BGP as-path given for the prefix
+ and if it matches do normal route-map actions. The no form of the command
+ removes this match from the route-map.
-.. index:: set as-path prepend AS-PATH
-.. clicmd:: set as-path prepend AS-PATH
+.. index:: [no] set as-path prepend AS-PATH
+.. clicmd:: [no] set as-path prepend AS-PATH
- Prepend the given string of AS numbers to the AS_PATH.
+ Prepend the given string of AS numbers to the AS_PATH of the BGP path's NLRI.
+ The no form of this command removes this set operation from the route-map.
-.. index:: set as-path prepend last-as NUM
-.. clicmd:: set as-path prepend last-as NUM
+.. index:: [no] set as-path prepend last-as NUM
+.. clicmd:: [no] set as-path prepend last-as NUM
Prepend the existing last AS number (the leftmost ASN) to the AS_PATH.
+ The no form of this command removes this set operation from the route-map.
.. _bgp-communities-attribute:
``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
+ lost traffic when taking BGP sessions down for maintenance. The use
of the community needs to be supported from your peers side to
actually have any effect.
``llgr-stale``
``llgr-stale`` represents well-known communities value ``LLGR_STALE``
``0xFFFF0006`` ``65535:6``.
- Assigned and intented only for use with routers supporting the
+ Assigned and intended only for use with routers supporting the
Long-lived Graceful Restart Capability as described in
- :rfc:`draft-uttaro-idr-bgp-persistence`.
- Routers recieving routes with this community may (depending on
+ [Draft-IETF-uttaro-idr-bgp-persistence]_.
+ Routers receiving 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
+ Assigned and intended only for use with routers supporting the
Long-lived Graceful Restart Capability as described in
- :rfc:`draft-uttaro-idr-bgp-persistence`.
- Routers recieving routes with this community may (depending on
+ [Draft-IETF-uttaro-idr-bgp-persistence]_.
+ Routers receiving 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``.
- :rfc:`draft-agrewal-idr-accept-own-nexthop` describes
+ [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
- :rfc:`draft-agrewal-idr-accept-own-nexthop` for full details.
+ [Draft-IETF-agrewal-idr-accept-own-nexthop]_ for full details.
``blackhole``
``blackhole`` represents well-known communities value ``BLACKHOLE``
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] <https://tools.ietf.org/id/draft-uttaro-idr-bgp-persistence-04.txt>
+.. [Draft-IETF-agrewal-idr-accept-own-nexthop] <https://tools.ietf.org/id/draft-agrewal-idr-accept-own-nexthop-00.txt>
+
.. _bgp-community-lists:
Community Lists
There are two types of community list:
standard
- This type accepts an explicit value for the atttribute.
+ This type accepts an explicit value for the attribute.
expanded
This type accepts a regular expression. Because the regex must be
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.
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
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
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
to VPN.
Required parameters
-"""""""""""""""""""
+^^^^^^^^^^^^^^^^^^^
Routes exported from a unicast VRF to the VPN RIB must be augmented by two
parameters:
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
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:
Route Reflector
===============
-.. note:: This documentation is woefully incomplete.
+BGP routers connected inside the same AS through BGP belong to an internal
+BGP session, or IBGP. In order to prevent routing table loops, IBGP does not
+advertise IBGP-learned routes to other routers in the same session. As such,
+IBGP requires a full mesh of all peers. For large networks, this quickly becomes
+unscalable. Introducing route reflectors removes the need for the full-mesh.
-.. index:: bgp cluster-id A.B.C.D
-.. clicmd:: bgp cluster-id A.B.C.D
+When route reflectors are configured, these will reflect the routes announced
+by the peers configured as clients. A route reflector client is configured
+with:
.. index:: neighbor PEER route-reflector-client
.. clicmd:: neighbor PEER route-reflector-client
.. index:: no neighbor PEER route-reflector-client
.. clicmd:: no neighbor PEER route-reflector-client
+To avoid single points of failure, multiple route reflectors can be configured.
+
+A cluster is a collection of route reflectors and their clients, and is used
+by route reflectors to avoid looping.
+
+.. index:: bgp cluster-id A.B.C.D
+.. clicmd:: bgp cluster-id A.B.C.D
.. _routing-policy:
route-map rm-no-export permit 20
!
route-map rm-blackhole permit 10
- description blackhole, up-pref and ensure it cant escape this AS
+ description blackhole, up-pref and ensure it cannot escape this AS
set ip next-hop 127.0.0.1
set local-preference 10
set community additive no-export
projects / mirror_frr.git / blobdiff