BGP

By | 28/03/2014

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.

Reference:

http://www.networkers-online.com/blog/2010/03/bgp-routing-information-base-rib/

Attributes

Well-known Mandatory: They MUST appear in every UPDATE message and must be supported by all implementations.

  • AS-Path
  • Origin
  • Next-Hop

Well-known Discretionary: Not required on the UPDATES, but they must be supported.

  • Local-Pref
  • Atomic_Aggregate

Optional, Transitive: Not required in the UPDATES and not required to be supported by all implementation.

  • Aggregator
  • Community

Optional, Non-Transitive:  Won’t be send on the UPDATES, not required to be supported by implementations.

  • Multi-Exit Discriminator (MED)
  • Originator_ID
  • Cluster List

Community

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.

Configuration example:

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.

Reference: http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13759-37.html

Best Path Selection Algorithm

  1. Highest WEIGHT – Cisco specific parameter. Local to the router.
  2. Highest LOCAL_PREF – Local to the AS
  3. Network / Redistribute preferred to Aggregate – Local to the router. Kind of specific network preferred to summarized.
  4. Shortest AS_PATH – Global
  5. Lowest origin type – IGP < EGP < incomplete
  6. Lowest MED
  7. Prefer eBGP before iBGP
  8. Path with lowest IGP metric
  9. Check if BGP Multipath is required
  10. For external paths, prefer the oldest (first in arrive)
  11. Coming with the router with a lower Router ID
  12. Minimum cluster list lenght (only on RR environments)
  13. Lowest neighbor address

Reference: Cisco’s BGP Best Path Selection Algorithm

Route Reflectors

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.

routereflector

 

Configuraiton

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.

References:

Cisco QLM – Introducting Route Reflectors

Network Lessons – BGP Route Reflector

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

References:

BGP Soft Reset Reconfiguration 

Cisco BGP Soft Reset Enhancement

AS-Path Prepend

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

Configuration example

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

Synchronization

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 170.10.0.0 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

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

Examples:

only default route

ip prefix-list LIST permit 0.0.0.0/0

only 10.50.1.0/24

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

Examples:

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

any prefix

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

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.

Reference:

http://blog.ine.com/2007/12/26/how-do-prefix-lists-work/ http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/5816-bgpfaq-5816.html#one  

 

Confedereations

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

Reference:

https://networklessons.com/bgp/bgp-confederation-explained/

 

Timers

 

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 1.1.1.2 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 1.1.1.2 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.

References: http://networkgeekstuff.com/networking/cisco-bgp-timers-re-explained/

Leave a Reply