BGP configuration options¶
The BGP routing protocol is very rich and offers many options. In this paragraph we will study the most used and useful BGP options.
Aggregation¶
The main goal of aggregation is to summarize the number of network prefixes that are announced into the Internet. In fact, aggregation is a requirement when the mask length is too great. Your peers or the peers of your peers will filter some of them. They may want to reduce the number of prefixes.
However, the route aggregation can introduce some network loops or some black holes when it is not set properly.
Note
A BGP router can advertise an aggregated network only if one route of the aggregate network is in the BGP table. For example if we consider four networks 192.168.0.0/24 through 192.168.3.0/24, the BGP router can advertise the aggregate network 192.168.0.0/22 only if at least one network (192.168.1.0/24 through 192.168.3.0/24) is in the BGP table.
If all the sub-networks of an aggregated network go down, this aggregated network will not be advertised.
It is recommended to check that the aggregated network is not stopped by an Access List.
BGP aggregation¶
The aggregation of the IPv4 network prefixes within the BGP tables can be done with the following command:
vsr running bgp# address-family ipv4-unicast aggregate-address
PREFIX/M [summary-only true|false] [as-set true|false]
The aggregate command originates a new prefix. However, how to summarize the different AS-PATH ? There are two solutions:
The AS-PATH is suppressed, although some network loops could be introduced.
The AS-PATH is summarized within an unordered set (AS-SET), although some black hole could be created.
No aggregation flags¶
When neither the summary-only flag nor the as-set flag are set, a route
with the aggregated PREFIX/M is originated from the BGP router. However the
sub-prefixes are still advertised.
Example
routing bgp
as 65500
address-family
ipv4-unicast
network 192.168.3.0/24
..
network 192.168.2.0/24
..
aggregate-address 192.168.0.0/22
..
..
neighbor 10.1.1.1
remote-as 65510
..
neighbor 10.1.1.6
remote-as 65530
..
After rt1 device peers with rt2, and rt2 peers with rt3, rt1 can receive following rib entries :
rt1> show bgp ipv4 unicast
BGP table version is 4, local router ID is 10.1.1.1, vrf id 0
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 192.168.0.0/22 10.1.1.2 0 65520 i
*> 192.168.0.0 10.1.1.2 0 65520 65530 i
*> 192.168.1.0 10.1.1.2 0 65520 65530 i
*> 192.168.2.0 10.1.1.2 0 0 65520 i
*> 192.168.3.0 10.1.1.2 0 0 65520 i
Displayed 4 routes and 4 total paths
rt1> show bgp ipv4 unicast prefix 192.168.0.0/22
BGP routing table entry for 192.168.0.0/22
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.1.1.2
65520, (aggregated by 65520 10.1.1.2)
10.1.1.2 from 10.1.1.2 (10.1.1.2)
Origin IGP, localpref 100, valid, external, atomic-aggregate, best
AddPath ID: RX 0, TX 6
Last update: Fri Sep 28 16:11:02 2018
Note
The aggregated prefix has the attribute atomic-aggregate, which means that the AS information is lost for the aggregate prefix (192.168.0.0/22).
Not to advertise the aggregated prefix, the flag summary-only can be set. Or a prefix-list or a distribute-list can be defined.
Moreover this aggregated prefix is received by rt3 too.
rt3> show ipv4-route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route, q - queued route, r - rejected route
B>* 192.168.0.0/22 [20/0] via 10.1.1.5, ntfp2, 00:03:34
B>* 192.168.2.0/24 [20/0] via 10.1.1.5, ntfp2, 00:03:34
B>* 192.168.3.0/24 [20/0] via 10.1.1.5, ntfp2, 00:03:34
Summary-only aggregation flag¶
When the summary-only flag is set and the as-set flag is not set, only the route with the aggregated PREFIX/M is originated from the BGP router. The sub-prefixes are not advertised. Moreover the ID of the router is set within the AS-PATH to help traffic engineering.
Example
rt2 running bgp# address-family ipv4-unicast aggregate-address 192.168.0.0/22 summary-only true
If the flag summary-only is set, the router will only advertise the aggregate
prefix. We can notice that on the router which is advertising the aggregate
prefix, the sub-prefixes have been suppressed, the remote peers will only see
the aggregate prefix.
rt2> show bgp ipv4 unicast
BGP table version is 4, local router ID is 10.1.1.1, vrf id 0
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 192.168.0.0/22 0.0.0.0 32768 i
s> 192.168.0.0 10.1.1.6 0 0 65530 i
s> 192.168.1.0 10.1.1.6 0 0 65530 i
s> 192.168.2.0 0.0.0.0 0 32768 i
s> 192.168.3.0 0.0.0.0 0 32768 i
Displayed 5 routes and 5 total paths
The sub-prefixes which have been suppressed are labeled s.
On the remote peer, only the route to 192.168.0.0/22 is received by the BGP RIB.
rt1> show bgp ipv4 unicast
BGP table version is 4, local router ID is 10.1.1.1, vrf id 0
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 192.168.0.0/22 10.1.1.2 0 65520 i
However, rt3 is still getting the aggregated route.
rt1> show bgp ipv4 unicast
BGP table version is 4, local router ID is 10.1.1.1, vrf id 0
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 192.168.0.0/22 10.1.1.5 0 65520 i
*> 192.168.0.0 0.0.0.0 0 32768 i
*> 192.168.1.0 0.0.0.0 0 32768 i
Displayed 3 routes and 3 total paths
As-set aggregation flag¶
When the summary-only flag is not set and the as-set flag is set, a route with the aggregated PREFIX/M is originated from the BGP router. Moreover the information of the previous AS-PATHs is collected into an unordered list called an AS-SET. This AS-SET, that is included within the new AS-PATH originated by the router, can help to avoid some networks loops. However the sub-prefixes are still advertised.
vsr running bgp# address-family ipv4-unicast aggregate-address 192.168.0.0/22 as-set true
The AS information appears between brackets { }. It is an unordered list of
the ASes.
In our example, if configured with as-set, rt2 can advertise an aggregate prefix because it knows at least one of its sub-networks.
Now by checking the rt2 BGP RIB we will see the as-set displayed. between brackets.
rt2> show bgp ipv4 unicast
BGP table version is 4, local router ID is 10.1.1.1, vrf id 0
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 192.168.0.0/22 0.0.0.0 32768 {65530} i
*> 192.168.0.0 10.1.1.6 0 0 65530 i
*> 192.168.1.0 10.1.1.6 0 0 65530 i
s> 192.168.2.0 0.0.0.0 0 32768 i
s> 192.168.3.0 0.0.0.0 0 32768 i
Displayed 5 routes and 5 total paths
Combined summary-only and as-set aggregation flags¶
When both the summary-only and the as-set flags are set, a route with the
aggregated PREFIX/M is originated from the BGP router. Moreover the
information of the previous AS-PATHs is collected into an unordered list called
an AS-SET. This AS-SET, that is included within the new AS-PATH originated by
the router, can help to avoid some networks loops. The sub-prefixes are no
longer advertised.
rt2 running bgp# address-family ipv4-unicast aggregate-address 192.168.0.0/22 summary-only true
as-set true
By taking following example, rt1 will receive aggregated prefix with the as-set set.
rt2> show bgp ipv4 unicast
BGP table version is 4, local router ID is 10.1.1.1, vrf id 0
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 192.168.0.0/22 10.1.1.2 0 65520 {65530} i
Confederation¶
A confederation is a set of many private ASes that are joined to be advertised as a single AS. A confederated AS is a confederation of many ASes that are joined by eBGP and that are themselves running an IGP.
The use cases are:
Join independent ASes into a single AS.
support multi-homed customers with a same ISP.
Avoid the scaling issues of the full-mesh eBGP routers.
Configure a BGP confederation:
running bgp# confederation identifier 65501Join private ASes that belong to the same confederation:
running bgp# confederation peers 65502 peers 65501
Example
Let’s configure the following confederation:
BGP confederation¶
Where the following configurations are set:
rt1
vrf main
interface physical eth0_0
ipv4 address 10.1.1.9/29
..
interface physical eth1_0
ipv4 address 172.16.255.254/30
..
routing bgp
as 65521
neighbor 10.1.1.11 remote-as 65522
neighbor 10.1.1.11 address-family ipv4-unicast route-map out route-map-name change_nexthop
neighbor 10.1.1.10 remote-as 65521
neighbor 10.1.1.10 address-family ipv4-unicast route-map out route-map-name change_nexthop
neighbor 172.16.255.253 remote-as 65500
confederation identifier 65520
confederation peers 65522
..
..
..
routing
ipv4-access-list 1
permit any
..
ipv4-prefix-list filter
seq 1 address 172.16.0.0/16 policy permit
..
route-map change_nexthop
seq 1 policy permit
seq 1 match ip address prefix-list filter
seq 1 set ip next-hop 10.1.1.9
seq 2 policy permit
seq 2 match ip address access-list 1
..
..
rt2
vrf main
interface physical eth0_0
ipv4 address 10.1.1.10/29
..
interface physical eth1_0
ipv4 address 192.168.2.1/24
..
routing bgp
as 65521
neighbor 10.1.1.9 remote-as 65521
confederation identifier 65520
address-family ipv4-unicast network 192.168.2.0/24
..
..
rt3
vrf main
interface physical eth0_0
ipv4 address 10.1.1.11/29
..
interface physical eth1_0
ipv4 address 10.1.1.1/29
..
interface loopback loop
ipv4 address 192.168.3.1/24
..
routing bgp
as 65522
neighbor 10.1.1.9 remote-as 65521
neighbor 10.1.1.2 remote-as 65520
confederation identifier 65520
confederation peers 65521
address-family ipv4-unicast network 192.168.3.0/24
..
..
rt4
vrf main
interface physical eth0_0
ipv4 address 192.168.4.1/24
..
interface physical eth1_0
ipv4 address 10.1.1.2/29
..
routing bgp
as 65522
neighbor 10.1.1.1 remote-as 65522
confederation identifier 65520
address-family ipv4-unicast network 192.168.4.0/24
..
..
rt5
However, when rt5 peers with rt1, it peers to the AS 65520 that is rt1’s BGP confederation identifier. It does not peer to the AS 65521 that is internal to the AS 65520:
vrf main
interface physical eth0_0
ipv4 address 172.16.0.1/16
..
interface physical eth1_0
ipv4 address 172.16.255.253/30
..
routing bgp
as 65000
neighbor 172.16.255.254 remote-as 65522
address-family ipv4-unicast network 172.16.0.0/16
..
..
Check this configuration on rt3 that displays the confederation path between parenthesis. The fib can also be dumped.
rt3> show bgp ipv4 unicast
BGP table version is 2, local router ID is 192.168.3.1, vrf id 0
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
172.16.0.0 10.1.1.9 0 100 0 (65521) 65500 i
*> 192.168.2.0 10.1.1.10 0 100 0 (65521) i
*> 192.168.3.0 0.0.0.0 0 32768 i
*>i192.168.4.0 10.1.1.2 0 100 0 i
Displayed 3 routes and 3 total paths
rt3> show bgp ipv4 unicast prefix 172.16.0.0/16
BGP routing table entry for 172.16.0.0/16
Paths: (1 available, no best path)
Advertised to non peer-group peers:
10.1.1.9
(65521) 65500
10.1.1.9 from 10.1.1.9 (172.16.255.254)
Origin IGP, metric 0, localpref 100, invalid, confed-external, best
AddPath ID: RX 0, TX 22
Last update: Fri Oct 12 09:34:14 2018
The FIB can also be dumped:
rt3> show ipv4-routes
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route, q - queued route, r - rejected route
C>* 10.1.1.0/29 is directly connected, eth0_0, 00:23:26
C>* 10.1.1.8/29 is directly connected, eth0_0, 00:23:26
B>* 172.16.0.0/16 [200/0] via 10.1.1.9, eth0_0, 00:18:11
B>* 192.168.2.0/24 [200/0] via 10.1.1.10, eth0_0, 00:17:17
C>* 192.168.3.0/24 is directly connected, loopback, 00:23:26
B>* 192.168.4.0/24 [200/0] via 10.1.1.2, eth1_0, 00:17:17
Note
if a route-map had not been added to rt1, 172.16.0.0/16 would not have been visible in rt3, because it has no route to 172.16.255.253. It is a feature of BGP that requires to work with an IGP to resolve the recursives routes that do not have a directly connected gateway. Moreover, it means that the eBGP sessions between the confederation sub-ASes do not change the next hop attribute.
For example, you could add RIP or OSPF v2 on rt1, rt2, rt3 and rt4 that will be the IGP of all the AS65520.
Overriding AS¶
When working with both public BGP peers and private BGP peers, it is wished to have one single BGP instance, and in the same time, having the ability to override the default AS value. This can be done by using local-as value, where it is possible to override default AS value by the one that is set as local-as value.
Following configuration illustrates what the configuration could be. real AS value (65000 here) is hiddent behind 64512. Remote peer only sees 64512 value.
vrf main
routing bgp
as 65000
neighbor 10.125.0.2 remote-as 64622
neighbor 10.125.0.2 local-as as-number 64512 no-prepend true replace-as true
..
..
..
AS-Path prepending¶
On some situations, it is also wished to modify the as-path list. For instance, on transit routers, the as-path list may be enlarged in order to influence incoming traffic. Actually, by increasing the as-path list size, BGP best path selection algorithm may pick up the routers with the shortest as-path list.
The following route-map configuration can be applied to outgoing prefixes exchanged with BGP peers. as-path prepending action will prepend as-path values to the original as-path list. The priority number configured will determine which as-path value to insert first.
For instance, below route-map will prepend {65500, 65100} in the as-path list
following the configured order 10, 20.
vrf main
routing bgp as 65500
..
routing
ipv4-prefix-list blocka
seq 10 address 10.0.0.0/8 policy permit
..
route-map bgp-export-block
seq 10
policy permit
match
ip
address
prefix-list blocka
..
..
..
set
as-path
prepend
asn 20
65100
..
asn 10
65500
..
..
..
ip
next-hop 184.106.55.69
EBGP policy requirement¶
When interoperating with eBGP peers, route propagation may become riskier if no policies are set up on those peers. RFC 8212 enforces that policy by checking that incoming and outgoing filters are applied for eBGP sessions. With this policy, no route will be either accepted ( if no incoming filter) nor announced (if no outgoing filter). Below command can be used to enforce the behavior:
vsr running bgp# ebgp-requires-policy true
Timers¶
The BGP timers are specific to the neighbors.
Set specific timers:
vsr running bgp# neighbor 10.125.0.3 timers keepalive-interval 15 hold-time 30
Tip
A good practice is to configure the same value on both sides of the TCP connection. Generally, these values should not be changed; however when the processing time of the BGP table is too long for the CPU to fire the keepalive timer, the later could be increased.
Routing Reconfiguration¶
Some configuration items may need the BGP routing tables to be refreshed. This is the case for multipath configuration. Enabling multipath needs to analyse all the routing table to see if there are ECMP entries.
BGP provides 2 mechanisms to permit this refresh:
either by issuing BGP route refresh messages to remote peers. This message asks remote peer to send back all BGP updates for a defined (AFI, SAFI) address-family.
or by enhancing software reconfiguration inbound. An inbound RIB is created for each peer, for a defined (AFI, SAFI). This is the ADJ-RIB-IN. All incoming BGP updates are stored in ADJ-RIB-IN and are kept unmodified. This permits reinjecting original BGP updates of remote peer, when needed. Enhancing software reconfiguration inbound can be configured on each address-family node.
The routing reconfiguration will be automatically triggered upon some reconfiguration elements. If software reconfiguration is not configured, then default behaviour will issue a route refresh message with remote peer.
Anytime, ADJ-RIB-IN can be flushed by using a flush command. This will force
to rebuild the ADJ-RIB-IN command by issuing update with remote peer:
flush bgp vrf main all soft in
Route refresh¶
Route refresh is an extension to BGP that is defined in RFC 2918. Using this feature, a BGP router can request a complete retransmission of the peer’s routing information without tearing down and reestablishing the BGP session, saving a route flap. It is used to facilitate routing policy changes, without storing an unmodified copy of the peer’s routes on the local router to save memory. The capability must be supported by both routers of a BGP session. When both routers in the peering session support this extension, each router will respond to requests issued from the peer without operator intervention.
Route Refresh is enabled by default.
When the command flush is used, Route Refresh messages are sent to the peers, the router receives one or more Update packets with all the routes of the Adj-RIB-Out.
Example
Let’s configure the following peering:
routing bgp
as 65000
neighbor 172.16.255.254 remote-as 65522
address-family ipv4-unicast network 172.16.0.0/16
.. .. ..
Then the peering happens. And the RIB is feeded with remote updates from remote. No need to configure the multipath feature, since it is enabled by default.
The local peer will mark as staled the local entries learnt from the remote peer, then will send a BGP refresh message to the remote peer. The remote peer will send back the BGP updates, and the local instance will refresh the RIB accoringly.
BGP graceful restart capability¶
Usually when BGP on a router restarts, all the BGP peers detect that the session went down, and then came up. This “down/up” transition results in a “routing flap” and causes BGP route re-computation, generation of BGP routing updates and flap the forwarding tables. It could spread across multiple routing domains. Such routing flaps may create transient forwarding blackholes and/or transient forwarding loops. They also consume resources on the control plane of the routers affected by the flap. As such they are detrimental to the overall network performance.
This feature proposes a mechanism for BGP that would help minimize the
negative effects on routing caused by BGP restart. The graceful restart
capabilities (code-64) will be exchanged between the BGP speakers through the
open messages. Routes advertised by the restarting speaker will become stale
in the peer speakers’ routing table. On expiry of restart time the stale
routes will be deleted if the restarting speaker does not come up. Once the
restarting speaker re-establish the BGP session within the restart time the
stale routes will be converted to normal routes. Traffic flow through the stale
routes will not be stopped while the BGP speaker is restarting.
Enable BGP graceful restart:
vsr running bgp# graceful-restart restart-time 60vsr running bgp# graceful-restart stalepath-time 120
BGP unnumbered¶
This feature permits to establish BGP connected peering using link local ipv6 addresses, without having to provision additional ip addresses. On a given interface, BGP requests to enable router advertisement service to discover neighbor ipv6 link local addresses. This permits to receive router advertisements messages from remote peer, and identify the remote ipv6 link local address to connect to with BGP.
The feature can be configured by mentioning the interface BGP should establish a peering over. Below back to back setup between 2 devices illustrates what should be done:
rt1
vrf main
interface physical eth2
port pci-b0s5
.. ..
routing bgp
as 65000
router-id 1.1.1.1
neighbor-group group
capabilities
extended-nexthop True
remote-as 65000
address-family ipv6-unicast
.. .. ..
address-family ipv4-unicast
network 10.100.0.0/24
.. .. ..
address-family ipv6-unicast
network 10:100::/64
.. .. ..
unnumbered-neighbor eth2 neighbor-group group
unnumbered-neighbor eth2 ipv6-only true
.. ..
rt2
vrf main
interface physical eth2
port pci-b0s5
.. ..
routing bgp
as 65000
router-id 1.1.1.2
neighbor-group group
capabilities
extended-nexthop True
remote-as 65000
address-family ipv6-unicast
.. .. ..
address-family ipv4-unicast
network 10.200.0.0/24
.. .. ..
address-family ipv6-unicast
network 10:200::/64
.. .. ..
unnumbered-neighbor eth2 neighbor-group group
unnumbered-neighbor eth2 ipv6-only true
.. ..
To check the peering status on the given interface, use the following command:
rt1> show bgp unnumbered-neighbor eth2
BGP neighbor on eth2: fe80::dced:2ff:fe6b:cbc6, remote AS 65000, local AS 65000, internal link
Hostname: rt2
Member of peer-group group for session parameters
BGP version 4, remote router ID 1.1.1.2, local router ID 1.1.1.1
BGP state = Established, up for 00:00:22
Last read 00:00:21, Last write 00:00:21
Hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
4 Byte AS: advertised and received
AddPath:
IPv4 Unicast: RX advertised IPv4 Unicast and received
IPv6 Unicast: RX advertised IPv6 Unicast and received
Extended nexthop: advertised and received
Address families by peer:
IPv4 Unicast
Route refresh: advertised and received(old & new)
Address Family IPv4 Unicast: advertised and received
Address Family IPv6 Unicast: advertised and received
Hostname Capability: advertised (name: dut-vm,domain name: n/a) received (name: router-vm,domain name: n/a)
Graceful Restart Capabilty: advertised and received
Remote Restart timer is 120 seconds
Address families by peer:
none
Graceful restart information:
End-of-RIB send: IPv4 Unicast, IPv6 Unicast
End-of-RIB received: IPv4 Unicast, IPv6 Unicast
Message statistics:
Inq depth is 0
Outq depth is 0
Sent Rcvd
Opens: 2 2
Notifications: 2 0
Updates: 4 4
Keepalives: 1 1
Route Refresh: 0 0
Capability: 0 0
Total: 9 7
Minimum time between advertisement runs is 0 seconds
For address family: IPv4 Unicast
group peer-group member
Update group 1, subgroup 1
Packet Queue length 0
Community attribute sent to this neighbor(all)
1 accepted prefixes
For address family: IPv6 Unicast
group peer-group member
Update group 2, subgroup 2
Packet Queue length 0
Community attribute sent to this neighbor(all)
1 accepted prefixes
Connections established 1; dropped 0
Local host: fe80::dced:2ff:fe5c:f05a, Local port: 179
Foreign host: fe80::dced:2ff:fe6b:cbc6, Foreign port: 43650
Nexthop: 1.1.1.1
Nexthop global: fe80::dced:2ff:fe5c:f05a
Nexthop local: fe80::dced:2ff:fe5c:f05a
BGP connection: shared network
BGP Connect Retry Timer in Seconds: 120
Read thread: on Write thread: on FD used: 28
The resulting BGP routes learnt from remote peer are injected into the dataplane.
rt1> show bgp ipv4
BGP table version is 2, local router ID is 1.1.1.1, vrf id 0
Default local pref 100, local AS 65000
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.100.0.0/24 0.0.0.0 0 32768 i
*>i10.200.0.0/24 eth2 0 100 0 i
rt1> show bgp ipv6
BGP table version is 2, local router ID is 1.1.1.1, vrf id 0
Default local pref 100, local AS 65000
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10:100::/64 :: 0 32768 i
*>i10:200::/64 eth2 0 100 0 i
rt1> show ipv4-routes
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route, q - queued route, r - rejected route
B>* 10.200.0.0/24 [200/0] via fe80::dced:2ff:fe6b:cbc6, eth2, 00:06:24
rt1> show ipv6-routes
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued route, r - rejected route
B>* 10:200::/64 [200/0] via fe80::dced:2ff:fe6b:cbc6, eth2, 00:07:13
Anytime, BGP unnumbered can be flushed by using a flush command.
rt1> flush bgp ipv4 main ipv4 vpn unnumbered-neighbor eth2
Note
BGP unnumbered works only when there is only one neighbor per interface. Peering with multiple neighbors on the same interface is not supported.
BGP queue size configuration¶
Input queue limitation¶
When incoming BGP messages are received by the Virtual Service Router, they are received via
a peer input queue. A large number of messages can lead to an infinite queue length,
and drastically increase the memory consumption. The problem may appear when
dealing with a lot of peers. This can lead to high messages, CPU and memory loads,
resulting in BGP spikes with out-of-memory system problems, requiring BGP to
be restarted. To avoid this situation, it is recommended to limit the BGP input
queue, let the messages be retained in the TCP socket, and allow the TCP
congestion control to kick in. The following command is proposed:
vsr running config# routing bgp queue-limit input 5000
By default, up to 10000 messages can be stored in each peer BGP input queue, and this value can be reduced, in order to avoid the messages congestion.
Output queue limitation¶
When outgoing BGP messages are sent to a BGP peer, transmission queues store
the data before sending it to the network layer. When a remote peer is slow and
unable to process a large number of messages sent by a router, TCP congestion
control kicks in, then the BGP output queue length increases; the memory
consumed also increases. In scenarii where there are a lot of peers, this may
lead to out-of-memory messages, thus forcing BGP to restart.
To avoid this situation, we limit the BGP output queue and slow down the rate at which the output queues are filled. The ADJ-RIB-OUT will continue to be fed, but not the transmit queues, until the number of messages in the queues falls below this limit. This will reduce the bottleneck with slow peers. The following command is proposed:
vsr running config# routing bgp queue-limit output 1000
By default, up to 10000 messages can be stored in the BGP output queue, and this value can be reduced, in order to avoid the messages congestion.