RIB – BGP Routing Information Base
- Adj-RIBs-In – Information received from the peers and used for the decision process, before applying any attribute modification or applying route filtering.
- Local RIB – Information from the result of the processing of the RIBs-In table. After applying decision process and BGP policies. This information will be processed to create the routing table.
- Adj-RIBs-out – Information chosen by the process to be advertised to the peers.
Well-known Mandatory: They MUST appear in every UPDATE message and must be supported by all implementations.
Well-known Discretionary: Not required on the UPDATES, but they must be supported.
Optional, Transitive: Not required in the UPDATES and not required to be supported by all implementation.
Optional, Non-Transitive: Won’t be send on the UPDATES, not required to be supported by implementations.
- Multi-Exit Discriminator (MED)
- Cluster List
Optional, transitive attribute. 32 bits field divided in two sections. 16 bits are for the AS number that originates the community. The other 16 bits carry a unique id assigned by the AS.
Community attribute is used as a tag for the prefixes to apply routing policies.
Configuration example sending the community:
route-map AddCommunity permit 10 match ip address 101 set community 2990:400 access-list 101 permit ip host 10.1.1.0 host 255.255.255.0 ip bgp-community new-format router bgp 1200 network 10.1.1.0 mask 255.255.255.0 neighbor 10.10.20.1 remote-as 2990 neighbor 10.10.20.1 route-map AddCommunity out neighbor 10.10.20.1 send-community
Configuration example receiving the community
route-map CheckCommunity permit 10 match community 1 set local-preference 130 ip community-list 1 permit 2990:400 ip bgp-community new-format router bgp 2990 neighbor 10.10.20.2 remote-as 1200 neighbor 10.10.20.2 route-map CheckCommunity in
Multi-Exit Discriminator (MED)
Optional, non transitive attribute. Lower MED value is preferred over a higher value.
Used when a customer has two ISP path available, to influence from the “customer” side which path will be used for each network.
router bgp 65001 network 10.1.0.0 mask 255.255.0.0 network 10.2.0.0 mask 255.255.0.0 neighbor 192.168.1.2 remote-as 65002 neighbor 192.168.1.2 route-map setMED-R2 out neighbor 192.168.1.3 remote-as 65002 neighbor 192.168.1.3 route-map setMED-R3 out access-list 1 permit 10.1.0.0 0.0.255.255 access-list 2 permit 10.2.0.0 0.0.255.255 ! route-map setMED-R3 permit 10 match ip address 1 set metric 200 ! route-map setMED-R3 permit 20 match ip address 2 set metric 100 ! route-map setMED-R2 permit 10 match ip address 1 set metric 100 ! route-map setMED-R2 permit 20 match ip address 2 set metric 200 !
MED is only considered when the routes comes from the same AS. To force to use MED for different AS, the command bgp always-compare-med should be used
bgp deterministic-med should be used to avoid temporal dependency of MED when same prefix comes from different AS.
Best Path Selection Algorithm
- Highest WEIGHT – Cisco specific parameter. Local to the router.
- Highest LOCAL_PREF – Local to the AS
- Network / Redistribute preferred to Aggregate – Local to the router. Kind of specific network preferred to summarized.
- Shortest AS_PATH – Global
- Lowest origin type – IGP < EGP < incomplete
- Lowest MED
- Prefer eBGP before iBGP
- Path with lowest IGP metric
- Check if BGP Multipath is required
- For external paths, prefer the oldest (first in arrive)
- Coming with the router with a lower Router ID
- Minimum cluster list lenght (only on RR environments)
- Lowest neighbor address
Reference: Cisco’s BGP Best Path Selection Algorithm
iBGP requires to have a full mesh relationship between all the peers because routes received by iBGP peer are not redistributed to other iBGP peers. That means that the router receiving a route through a eBGP (or other protocol) will send the route to the iBGP neighbour, but they won’t send the route to their iBGP neighbors again.
To avoid configuring a full mesh schema, route reflectors can be used. The iBGP peer acting as a route reflector will forward the routes received by a iBGP peer to the other iBGP peers.
The configuration on the clients is the standard bgp configuration. Only the route reflector router has a specific configuration:
RR(config)#router bgp 1 RR(config-router)#neighbor 192.168.1.2 remote-as 1 RR(config-router)#neighbor 192.168.1.2 route-reflector-client RR(config-router)#neighbor 192.168.1.3 remote-as 1 RR(config-router)#neighbor 192.168.1.3 route-reflector-client
Avoiding SPF with Route Reflectors
Route Reflectors are a single point of failure, so it could be required to use more than one route reflector. But using several route reflectors in a wrong way could cause route propagation loops. When needing more than one Route reflector, route reflector cluster can be used to avoid routing loops.
RR Clusters will send their cluster ID in the BGP prefix attributes, so other members in the RR cluster won’t reflect prefixes that already includes their cluster ID.
Update BGP table methods
The following command will clear the bgp peer session to get fresh information from the neighbor. Causes an outage on the routing.
clear ip bgp
Soft Reconfiguration is a method to update the BGP table without having to clear the entire BGP table. The router will store a copy of the table (using more memory). It requires a preconfiguration to clear inbound prefixes. It doesn’t require a configuration for outbound update.
router bgp 1 neighbor x.x.x.x soft-reconfiguration inbound
clear ip bgp [*/address] soft [in/out]
Activating the soft-reconfiguration inbound for a peer allows the use of the command show ip bgp neighbor x.x.x.x received-routes
AS Path Prepend is used to assign less priority to a prefix being advertised. This allows to control the election of the best route in a network. Requires: Prefix List with the networks that we want to modify
Create a prefix-list with the networks for which the AS needs to be modified.
ip prefix-list LIST seq 10 permit 10.13.0.0/16
Create a route-map with the prefix list and the AS-path configuration
route-map ADVERTISED_ROUTES permit 10 match ip address prefix-list tcnet-nets set as-path prepend 65003 65003 65003 route-map ADVERTISED_ROUTES permit 20
Add the rout-map to the neighbor in the router bgp configuration
neighbor REMOTE_NEIGHBOR route-map ADVERTISED_ROUTES out
When advertising routes received from an AS to a third AS, BGP will wait until the route is advertised through IGP inside the AS.
RTB won’t advertise the 188.8.131.52 route until it knows that it’s reachable through RTE.
Synchronization is enabled by default.
In a scenario where all the routers in the AS run BGP, synchronization is not needed. Disabling it will provide better convergence times.
router bgp AS no synchronization
Reference: Cisco Doc
Prefix lists can be used in two different ways:
Standard prefix List
ip prefix-list LIST seq X permit w.x.y.z/len It matches exactly the specified prefix
only default route
ip prefix-list LIST permit 0.0.0.0/0
ip prefix-list LIST permit 10.50.1.0/24
Prefix list using ge and le
ip prefix-list LIST permit w.x.y.z/len [ge][le] submask
- ge – greater or equal
- le – lower or equal
Checks the len number of bits of the prefix and defines that the submask should be greater or lower than GE and LE Condition: Len < GE <= LE
any 10.x.x.x network with mask greated than 21 and lower to 29
ip prefix-list LIST permit 10.0.0.0/8 ge 21 le 29
allows any 10.50.1.x/32 to /24
ip prefix-list LIST permit 10.50.1.0/24 le 32
ip prefix-list LIST permit 0.0.0.0/0 le 32
Apply a Prefix List
Can be done directly with the prefix list or with a route map. It works the same way, but with a route map it’s possible to apply some more settings lige Local Preference, AS-Path,… Prefix List
neighbor IP prefix-list LIST in/out
route-map RMNAME permit 10 match ip address prefix-list LIST neighbor IP route-map RMNAME in/out
For inbound updates, the order preference is route-map first and then prefix-list. For outbound updated, the order preference is prefix-list and then route-map.
Confederations are used to avoid a full-mesh setup in big iBGP scenarios. Confederated iBGP is divided in sub-AS and full-mesh is only required between Sub-AS. Externally, it looks like just one AS.
router bgp SUB-AS bgp confederation identifier REAL-AS bgp confederation peers OTHER-SUB-AS neighbor IP1 remote-as SUB-AS neighbor IP2 remote-as OTHER-SUB-AS
Keep-alive and Hold-Down. BGP peers send keep-alive to the other peer every Keep-alive timer seconds. BGP table will be kept until the Hold-Down timer expires. Each keep-alive received will reset the hold-down timer.
Default values are a keep-alive of 60 seconds and a hold-down of 180 seconds (3x Keep-alive).
This values can be modified with the command
R1(config-router)# neighbor 184.108.40.206 timers 20 60
The values are negotiated between the peers when the session is initiated and the lower values will be choosen.
R1(config-router)# neighbor 220.127.116.11 timers 20 60 40
A minimum hold-time timer can be set for a peer, so BGP session won’t be initiated if the other peer tries to set the hold-time lower than this value. This is set to avoid too aggressive timers that could cause flapping. That will cause the BGP peer to not establish.