There are a list of necessary elements to know when forging a BGP configuration.
When forging a BGP configuration, the local AS number, and the remote AS number, as well as the remote IP address have to be known in order to establish peering.
An AS is an administrative set of routers, depending on an administrative authority. There are public or assigned ASes, and private ASes. An ASes is identified by a number called ASN.
The public ASNs are any registered ASN values that are not private. These ASNs are assigned by a RIR. The private ASNs are made up of 2 ranges that can be used for local administration. These numbers are 64512 through 65535, and 4200000000 through 4294967294.
BGP has been extended to exchange routing information not only for IPv4
routing tables, also other routing information like IPv6, or for other purpose:
flowspec, or L3VPN or L2VPN.
The address-family command allows us to identify the network protocol. It is
made up of a pair of arguments
AFI, SAFI. For instance, by default,
IPv4, unicast is enabled and stands for the routing information of IPv4.
Here below is an example on how to configure a sample BGP configuration with both IPv4 and IPv6 address-family set:
vrf main routing bgp router-id 10.125.0.1 as 65501 neighbor 10.125.0.3 remote-as 65502 address-family ipv6 .. .. commit
The same configuration can be made using this NETCONF XML configuration:
vrouter running config# show config xml absolute vrf main routing bgp <config xmlns="urn:6wind:vrouter"> <vrf> <name>main</name> <routing xmlns="urn:6wind:vrouter/routing"> <bgp xmlns="urn:6wind:vrouter/bgp"> <router-id>10.125.0.1</router-id> <as>65501</as> <neighbor> <neighbor-address>10.125.0.3</neighbor-address> <address-family> <ipv6-unicast> </ipv6-unicast> </address-family> <remote-as>65502</remote-as> </neighbor> </bgp> </routing> </vrf> </config>
Configuring various address-family means that there are subtle differences between each address-family, that permit benefiting from each specificity.
IPv6, unicast address-family provides 2 IPv6 next-hops :
the local one and the global one.
IPv4, vpn is the L3VPN combination for MPLS tunnels. While the
routing information exchanged deals with inner IPv4 information, the
MPLS VPN SAFI implies that the overlay will be based with MPLS. The
nexthop information will stand for underlay tunnel end point information.
Here, the nexthop may be either IPv4 or IPv6, independently of the inner
IPv4 prefix. The nexthop will also contain the MPLS label identifier.
You can also disable BGP, either by suppressing the configuration:
vrf main del routing bgp ..
Alternatively, if you don’t want to lose the configuration, and disabling BGP configuration, you can use following command:
vrf main routing bgp enabled false
This method can be used if the user wants to force peering with remote BGP speakers.
Consecutively changing the state of BGP will force the peering.
Here, below illustration indicates how the session for
10.125.0.3 is flushed.
flush bgp vrf main ipv4 unicast neighbor 10.125.0.3
Note that this command can also selectively flush different parts of the routing
tables, like ADJ-RIB-IN by issuing the
soft in prefix at the end of the command.
An other possibility is to disable the whole BGP instance.
vrf main routing bgp enabled false commit routing bgp enabled true commit
The above diagram depicts 3 devices, each one has a BGP instance that peers with each other. The 3 devices configuration is like below:
routing bgp router-id 10.1.1.1 as 65500 neighbor 10.1.1.2 remote-as 65510 neighbor 10.1.1.3 remote-as 65520 address-family ipv4-unicast redistribute connected .. .. interface physical eth1_0 ipv4 address 192.168.1.0/24 .. .. physical eth0_0 ipv4 address 10.1.1.1/28 .. ..
routing bgp router-id 10.1.1.2 as 65510 neighbor 10.1.1.1 remote-as 65500 neighbor 10.1.1.3 remote-as 65520 address-family ipv4-unicast redistribute connected .. .. interface physical eth1_0 ipv4 address 192.168.2.0/24 .. .. physical eth0_0 ipv4 address 10.1.1.2/28 .. ..
routing bgp router-id 10.1.1.3 as 65520 neighbor 10.1.1.1 remote-as 65500 neighbor 10.1.1.2 remote-as 65510 address-family ipv4-unicast redistribute connected .. .. interface physical eth1_0 ipv4 address 192.168.3.0/24 .. .. physical eth0_0 ipv4 address 10.1.1.3/28 .. ..
After having executed the three configurations, the status of the BGP connections can be obtained. The peerings between the devices can be visualised with the following command:
rt1> show bgp summary IPv4 Unicast Summary: BGP router identifier 10.1.1.1, local AS number 65500 vrf-id 0 BGP table version 5 RIB entries 9, using 1368 bytes of memory Peers 2, using 41 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/P fxRcd 10.1.1.2 4 65510 17 17 0 0 0 00:09:08 4 10.1.1.3 4 65520 17 17 0 0 0 00:09:11 4 Total number of neighbors 2
The output of the state column must be blank in case the BGP connection is established, otherwise it reflects the state of the BGP connection. The different BGP session states are studied later in the section. Following command gives detailed BGP information about a given neighbor:
rt1> show bgp neighbor 10.1.1.2 BGP neighbor is 10.1.1.2, remote AS 65510, local AS 65500, external link Hostname: rt1 BGP version 4, remote router ID 10.1.1.2 BGP state = Established, up for 00:14:00 Last read 00:01:00, Last write 00:01:00 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 Route refresh: advertised and received(old & new) Address Family IPv4 Unicast: advertised and received Hostname Capability: advertised (name: rt1,domain name: n/a) received (name: rt2,domain name: n/a) Graceful Restart Capabilty: advertised and received Remote Restart timer is 120 seconds Address families by peer: none Graceful restart informations: End-of-RIB send: IPv4 Unicast End-of-RIB received: IPv4 Unicast Message statistics: Inq depth is 0 Outq depth is 0 Sent Rcvd Opens 1 1 Notifications: 0 0 Updates: 6 6 Keepalives: 14 14 Route Refresh: 0 0 Capability: 0 0 Total: 21 21
It is also possible to dump the list of BGP entries that rt1 learnt from the other peers, by using following command on configuration mode:
rt1> show bgp ipv4 unicast neighbors BGP table version is 5, 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 * 10.0.2.0/24 10.1.1.2 0 0 65510 ? * 10.1.1.3 0 0 65520 ? *> 0.0.0.0 0 32768 ? * 10.1.1.0/28 10.1.1.2 0 0 65510 ? * 10.1.1.3 0 0 65520 ? *> 0.0.0.0 0 32768 ? *> 192.168.1.0 0.0.0.0 0 32768 ? * 192.168.2.0 10.1.1.2 0 65520 65510 ? *> 10.1.1.2 0 0 65510 ? * 192.168.3.0 10.1.1.3 0 65510 65520 ? *> 10.1.1.3 0 0 65520 ? Displayed 5 routes and 11 total paths
Scaling BGP deployments may be useful, when one deploys multiple instances of BGP. Instead of configuring each peer one by one, it is possible to configure peer groups.
A peer group is defined by a name, and is being applied the same configuration as the one applied to a single peer IP, except for the IP addressing of that peer.
You can use following configuration to create a peer group named
routing bgp listen neighbor-range 10.135.0.0/24 neighbor-group group .. as 65502 neighbor-group group address-family ipv6-unicast .. .. remote-as 65501 update-source 10.135.0.2 .. neighbor 10.145.0.2 neighbor-group group .. ..
By default, the peer group will create as many peering connection as it receives incoming BGP connections that match its settings. It is however possible to limit the number of accepted incoming connections by establishing a range of potential IP addresses. Conversely, it is also possible to define some peers with outgoing peering, with the inherited configuration coming from the peer-group.
Route reflector is used in iBGP networks, where the number of BGP peers becomes too
important. Instead of using a full mesh peering, a 1-N peering topology is used.
A single ( or two, in case backup is needed) BGP instance acts as route reflector
server, and receives/replies BGP updates from/to route reflector clients accordingly.
This permits scaling some setups. Creating a route reflector server consists in defining
an IBGP peering session, either via peer-group or by defining directly a peer. The
route-reflector-client must be set to true.
as 65501 neighbor-group group address-family ipv4-unicast route-reflector-client true .. .. remote-as 65501 neighbor 126.96.36.199 address-family ipv4-unicast route-reflector-client true .. .. remote-as 65501 ..
There is no need to add extra-configuration to the iBGP clients.
BGP multipath permits to create ECMP routes, so that traffic can be load-shared on all the
available routing entries. By default, BGP know how to handle up to 8 ECMP route entries.
It is possible to reduce per the number of maximum-paths per address-family, and for both iBGP
or eBGP sessions.
Here is a configuration example, on how to disable multipath for
IPv4, unicast BGP:
router-id 10.125.0.1 address-family ipv4-unicast maximum-path ebgp 1 ibgp 1 .. .. .. as 65501
The multipath is criteria are strict by default. That means that even if as-path attribute that goes along with the prefixes differs, then the load-sharing will fail. There are some mitigations methods that permit relax the load sharing. For instance, the as-path attribute list can be completely ignored with following command, thus permitting to do load sharing across paths that do not share at all same path-list.
bestpath as-path ignore true .. ..
It is also possible to find an intermediary point, by taking into account only prefixes that share different path list, but same as-path list count.
bestpath as-path multipath-relax as-set .. ..
BGP supports advertisements of multiple paths. This is an extra identifier that is encoded in the NLRI of the packet. It contains a separate identifier. For instance, it permits to transmit 2 ECMP entries that will be differentiated by that identifier. To enable encoding of the prefix with the add-path option, use the following configuration command:
neighbor 10.125.0.3 remote-as 65502 address-family ipv4-unicast addpath tx-all-paths true .. .. .. ..