BGP
***
-:abbr:`BGP` stands for a Border Gateway Protocol. The lastest BGP version is 4.
-It is referred as BGP-4. BGP-4 is one of the Exterior Gateway Protocols and
-de-fact standard of Inter Domain routing protocol. BGP-4 is described in
-:rfc:`1771`.
+:abbr:`BGP` stands for a Border Gateway Protocol. The latest BGP version is 4.
+BGP-4 is one of the Exterior Gateway Protocols and the de facto standard
+interdomain routing protocol. BGP-4 is described in :rfc:`1771`.
-Many extensions have been added to :rfc:`1771`. :rfc:`2858` provides
-multiprotocol support to BGP-4.
+Many extensions have been added to :rfc:`1771`. :rfc:`2858` adds multiprotocol
+support to BGP-4.
.. _starting-bgp:
.. program:: bgpd
-.. option:: -p <port>
-.. option:: --bgp_port <port>
+.. option:: -p, --bgp_port <port>
- Set the bgp protocol's port number.
+ Set the bgp protocol's port number. When port number is 0, that means do not
+ listen bgp port.
-.. option:: -r
-.. option:: --retain
+.. option:: -r, --retain
When program terminates, retain BGP routes added by zebra.
-.. option:: -l
-.. option:: --listenon
+.. option:: -l, --listenon
Specify a specific IP address for bgpd to listen on, rather than its
default of INADDR_ANY / IN6ADDR_ANY. This can be useful to constrain bgpd
The advantage of this is that the route-selection (at this point) will be
more deterministic. The disadvantage is that a few or even one lowest-ID
- router may attract all trafic to otherwise-equal paths because of this
+ router may attract all traffic to otherwise-equal paths because of this
check. It may increase the possibility of MED or IGP oscillation, unless
other measures were taken to avoid these. The exact behaviour will be
sensitive to the iBGP and reflection topology.
.. index:: network A.B.C.D/M
.. clicmd:: network A.B.C.D/M
- This command adds the announcement network.::
+ This command adds the announcement network.
- router bgp 1
- address-family ipv4 unicast
- network 10.0.0.0/8
- exit-address-family
+ .. code-block:: frr
+
+ router bgp 1
+ address-family ipv4 unicast
+ network 10.0.0.0/8
+ exit-address-family
This configuration example says that network 10.0.0.0/8 will be
announced to all neighbors. Some vendors' routers don't advertise
.. index:: aggregate-address A.B.C.D/M summary-only
.. clicmd:: aggregate-address A.B.C.D/M summary-only
- This command specifies an aggregate address. Aggreated routes will
+ This command specifies an aggregate address. Aggregated routes will
not be announce.
.. index:: no aggregate-address A.B.C.D/M
(End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached
Established is considered an implicit-EOR.
If the establish-wait optional value is given, then BGP will wait for
- peers to reach established from the begining of the update-delay till the
+ peers to reach established from the beginning of the update-delay till the
establish-wait period is over, i.e. the minimum set of established peers for
which EOR is expected would be peers established during the establish-wait
window, not necessarily all the configured neighbors.
.. clicmd:: neighbor PEER remote-as ASN
Creates a new neighbor whose remote-as is ASN. PEER can be an IPv4 address
- or an IPv6 address or an interface to use for the connection.::
+ or an IPv6 address or an interface to use for the connection.
- router bgp 1
- neighbor 10.0.0.1 remote-as 2
+ .. code-block:: frr
+
+ router bgp 1
+ neighbor 10.0.0.1 remote-as 2
In this case my router, in AS-1, is trying to peer with AS-2 at 10.0.0.1.
This command must be the first command used when configuring a neighbor. If
- the remote-as is not specified, *bgpd* will complain like this:::
+ the remote-as is not specified, *bgpd* will complain like this: ::
can't find neighbor 10.0.0.1
This command specifies an announced route's nexthop as being equivalent to
the address of the bgp router if it is learned via eBGP. If the optional
- keyword `all` is specified the modifiation is done also for routes learned
+ keyword `all` is specified the modification is done also for routes learned
via iBGP.
.. index:: neighbor PEER update-source <IFNAME|ADDRESS>
Specify the IPv4 source address to use for the :abbr:`BGP` session to this
neighbour, may be specified as either an IPv4 address directly or as an
interface name (in which case the *zebra* daemon MUST be running in order
- for *bgpd* to be able to retrieve interface state).::
+ for *bgpd* to be able to retrieve interface state).
+
+ .. code-block:: frr
router bgp 64555
neighbor foo update-source 192.168.0.1
This command enforces Generalized TTL Security Mechanism (GTSM), as
specified in RFC 5082. With this command, only neighbors that are the
specified number of hops away will be allowed to become neighbors. This
- command is mututally exclusive with *ebgp-multihop*.
+ command is mutually exclusive with *ebgp-multihop*.
.. _peer-filtering:
BGP Community Lists
-------------------
-BGP community list is a user defined BGP communites attribute list. BGP
+BGP community list is a user defined BGP communities attribute list. BGP
community list can be used for matching or manipulating BGP communities
attribute in updates.
These commands delete community lists specified by NAME. All of
community lists shares a single name space. So community lists can be
- removed simpley specifying community lists name.
+ removed simply specifying community lists name.
.. index:: show ip community-list
.. clicmd:: show ip community-list
.. index:: ip community-list NAME permit|deny COMMUNITY
.. clicmd:: ip community-list NAME permit|deny COMMUNITY
- When community list type is not specifed, the community list type is
+ When community list type is not specified, the community list type is
automatically detected. If COMMUNITY can be compiled into communities
attribute, the community list is defined as a standard community list.
Otherwise it is defined as an expanded community list. This feature is left
- for backward compability. Use of this feature is not recommended.
+ for backward compatibility. Use of this feature is not recommended.
.. _bgp-community-in-route-map:
This command perform match to BGP updates using community list WORD. When
the one of BGP communities value match to the one of communities value in
- community list, it is match. When `exact-match` keyword is spcified, match
+ community list, it is match. When `exact-match` keyword is specified, match
happen only when BGP updates have completely same communities value
specified in the community list.
attribute. AS 7675 provides upstream Internet connection to AS 100.
When following configuration exists in AS 7675, AS 100 networks
operator can set local preference in AS 7675 network by setting BGP
-communities attribute to the updates.::
+communities attribute to the updates.
+
+
+.. code-block:: frr
router bgp 7675
neighbor 192.168.0.1 remote-as 100
Following configuration announce 10.0.0.0/8 from AS 100 to AS 7675.
The route has communities value 7675:80 so when above configuration
exists in AS 7675, announced route's local preference will be set to
-value 80.::
+value 80.
+
+.. code-block:: frr
router bgp 100
network 10.0.0.0/8
communities attribute. This configuration only permit BGP routes
which has BGP communities value 0:80 or 0:90. Network operator can
put special internal communities value at BGP border router, then
-limit the BGP routes announcement into the internal network.::
+limit the BGP routes announcement into the internal network.
+
+.. code-block:: frr
router bgp 7675
neighbor 192.168.0.1 remote-as 100
match community 1
-Following exmaple filter BGP routes which has communities value 1:1.
+Following example filter BGP routes which has communities value 1:1.
When there is no match community-list returns deny. To avoid
-filtering all of routes, we need to define permit any at last.::
+filtering all of routes, we need to define permit any at last.
+
+.. code-block:: frr
router bgp 7675
neighbor 192.168.0.1 remote-as 100
standard community lists. In below example `internet` act as
match any. It matches all of BGP routes even if the route does not
have communities attribute at all. So community list ``INTERNET``
-is same as above example's ``FILTER``.::
+is same as above example's ``FILTER``.
+
+.. code-block:: frr
ip community-list standard INTERNET deny 1:1
ip community-list standard INTERNET permit internet
Following configuration is an example of communities value deletion.
With this configuration communities value 100:1 and 100:2 is removed
from BGP updates. For communities value deletion, only `permit`
-community-list is used. `deny` community-list is ignored.::
+community-list is used. `deny` community-list is ignored.
+
+.. code-block:: frr
router bgp 7675
neighbor 192.168.0.1 remote-as 100
These commands delete extended community lists specified by `name`. All of
extended community lists shares a single name space. So extended community
- lists can be removed simpley specifying the name.
+ lists can be removed simply specifying the name.
.. index:: show ip extcommunity-list
.. clicmd:: show ip extcommunity-list
.. clicmd:: show ip extcommunity-list NAME
This command displays current extcommunity-list information. When `name` is
- specified the community list's information is shown.
+ specified the community list's information is shown.::
-::
-
- # show ip extcommunity-list
+ # show ip extcommunity-list
.. _bgp-extended-communities-in-route-map:
BGP VRFs
========
-Bgpd supports multiple VRF instances via the *router bgp* command:
+BPGD supports multiple VRF instances via the *router bgp* command:
.. index:: router bgp ASN vrf VRFNAME
.. clicmd:: router bgp ASN vrf VRFNAME
BGP routes may be leaked (i.e., copied) between a unicast VRF RIB and the VPN
safi RIB of the default VRF (leaking is also permitted between the unicast RIB
-of the default VRF and VPN). A common application of this feature is to
+of the default VRF and VPN) or routes may be leaked directly between two BGP
+VRF instances. A common application of the VPN-VRF feature is to
connect a customer's private routing domain to a provider's VPN service.
Leaking is configured from the point of view of an individual VRF: ``import``
refers to routes leaked from VPN to a unicast VRF, whereas ``export`` refers to
topologies are possible through use of additional route-targets to augment the
leaking of sets of routes in various ways.
+For direct VRF to VRF leaking the RD and RT are auto-derived.
+
Configuration
-------------
Deletes any previously-configured import or export route-target list.
-.. index:: label vpn export (0..1048575)
-.. clicmd:: label vpn export (0..1048575)
+.. index:: label vpn export (0..1048575)|auto
+.. clicmd:: label vpn export (0..1048575)|auto
Specifies an optional MPLS label to be attached to a route exported from the
- current unicast VRF to VPN.
+ current unicast VRF to VPN. If label is specified as ``auto``, the label
+ value is automatically assigned from a pool maintained by the zebra
+ daemon. If zebra is not running, automatic label assignment will not
+ complete, which will block corresponding route export.
-.. index:: no label vpn export [(0..1048575)]
-.. clicmd:: no label vpn export [(0..1048575)]
+.. index:: no label vpn export [(0..1048575)|auto]
+.. clicmd:: no label vpn export [(0..1048575)|auto]
Deletes any previously-configured export label.
.. clicmd:: route-map vpn import|export MAP
Specifies an optional route-map to be applied to routes imported or exported
- betwen the current unicast VRF and VPN.
+ between the current unicast VRF and VPN.
.. index:: no route-map vpn import|export [MAP]
.. clicmd:: no route-map vpn import|export [MAP]
.. index:: import|export vpn
.. clicmd:: import|export vpn
- Enables import or export of routes betwen the current unicast VRF and VPN.
+ Enables import or export of routes between the current unicast VRF and VPN.
.. index:: no import|export vpn
.. clicmd:: no import|export vpn
- Disables import or export of routes betwen the current unicast VRF and VPN.
+ Disables import or export of routes between the current unicast VRF and VPN.
+.. index:: import vrf VRFNAME
+.. clicmd:: import vrf VRFNAME
+
+ Enables direct importation of VRF routes to another VRF. The RD and RT
+ are auto derived and are not needed for VRF - VRF route leaking.
+
+.. index:: no import vrf VRFNAME
+.. clicmd:: no import vrf VRFNAME
+
+ Disables direct VRF to VRF route leaking.
.. _displaying-bgp-information:
Negotiation. *bgpd* use this Capability Negotiation to detect the remote peer's
capabilities. If a peer is only configured as an IPv4 unicast neighbor, *bgpd*
does not send these Capability Negotiation packets (at least not unless other
-optional BGP features require capability negotation).
+optional BGP features require capability negotiation).
By default, FRR will bring up peering with minimal common capability for the
both sides. For example, if the local router has unicast and multicast
not sent to the neighbor. When ``bgp config-type cisco`` is specified, the
community attribute is not sent to the neighbor by default. To send the
community attribute user has to specify *neighbor A.B.C.D send-community*
-command.::
+command.
+
+.. code-block:: frr
!
router bgp 1
Make a new BGP instance. You can use an arbitrary word for the `name`.
- ::
+ .. code-block:: frr
- bgp multiple-instance
- !
- 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
+ bgp multiple-instance
+ !
+ 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
BGP view is almost same as normal BGP process. The result of route selection
With this command, you can setup Route Server like below.
- ::
+ .. code-block:: frr
bgp multiple-instance
!
--------------
You can set different routing policy for a peer. For example, you can set
-different filter for a peer.::
+different filter for a peer.
+
+.. code-block:: frr
bgp multiple-instance
!
How to set up a 6-Bone connection
=================================
-::
+.. code-block:: frr
- bgpd configuration
- ==================
+ ! bgpd configuration
+ ! ==================
!
! MP-BGP configuration
!
BGP Configuration Examples
==========================
-Example of a session to an upstream, advertising only one prefix to it.::
+Example of a session to an upstream, advertising only one prefix to it.
+
+.. code-block:: frr
router bgp 64512
bgp router-id 10.236.87.1
global prefixes and NO_EXPORT prefixes and providing actions for customer
routes based on community values. Extensive use of route-maps and the 'call'
feature to support selective advertising of prefixes. This example is intended
-as guidance only, it has NOT been tested and almost certainly containts silly
+as guidance only, it has NOT been tested and almost certainly contains silly
mistakes, if not serious flaws.
-::
+.. code-block:: frr
router bgp 64512
bgp router-id 10.236.87.1
.. include:: rpki.rst
-.. [#med-transitivity-rant] For some set of objects to have an order, there *must* be some binary ordering relation that is defined for *every* combination of those objects, and that relation *must* be transitive. I.e.:, if the relation operator is <, and if a < b and b < c then that relation must carry over and it *must* be that a < c for the objects to have an order. The ordering relation may allow for equality, i.e. a < b and b < a may both be true amd imply that a and b are equal in the order and not distinguished by it, in which case the set has a partial order. Otherwise, if there is an order, all the objects have a distinct place in the order and the set has a total order)
+.. [#med-transitivity-rant] For some set of objects to have an order, there *must* be some binary ordering relation that is defined for *every* combination of those objects, and that relation *must* be transitive. I.e.:, if the relation operator is <, and if a < b and b < c then that relation must carry over and it *must* be that a < c for the objects to have an order. The ordering relation may allow for equality, i.e. a < b and b < a may both be true and imply that a and b are equal in the order and not distinguished by it, in which case the set has a partial order. Otherwise, if there is an order, all the objects have a distinct place in the order and the set has a total order)
.. [bgp-route-osci-cond] McPherson, D. and Gill, V. and Walton, D., "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", IETF RFC3345
.. [stable-flexible-ibgp] Flavel, A. and M. Roughan, "Stable and flexible iBGP", ACM SIGCOMM 2009
.. [ibgp-correctness] Griffin, T. and G. Wilfong, "On the correctness of IBGP configuration", ACM SIGCOMM 2002
projects / mirror_frr.git / blobdiff