BGP (Border Gateway Protocol) is an open source, dynamic Exterior Gateway protocol designed to exchange routing and reachability information among various Autonomous Systems on the IP Networks and the Internet. It is a path-vector protocol type and uses the Composite metric (based on 11 factors usually) as its metric value. It is an EGP (Exterior Gateway Protocol) used for routing the internet. BGP has 4 (Open, Update, Keepalive, Notification) no. of packets and has an Admin Distance of 20 (eBGP), 200 (iBGP). Its neighbor type is Statically (manually) configured and has 6 no. of neighbor states. BGP uses TCP connection on port 179 to establish a neighboring relationship and has a supported Standard of IETF RFC4271 (BGv4 – 2006). BGP also supports MD5 authentication for protocol exchanges.
Types of Dynamic Routing Protocols (IGP vs EGP)
Below are the two types of Dynamic Routing Protocols:
- IGP (Interior Gateway Protocol): It’s a routing protocol used for routing within one AS
- EGP (Exterior Gateway Protocol): A routing protocol that is used for routing between different Autonomous Systems (ASs)
Types of BGP (Border Gateway Protocol)
There are two types of BGP: eBGP and iBGP
BGP Autonomous System Numbers
An Autonomous System (AS) is a group of one or more IP prefixes (lists of IP addresses accessible on a network) run by one or more network operators that maintain a single, clearly-defined routing policy
Practice Lab 1 of BGP Configuration
You can practice BGP Configuration Lab 1 through our labs in Cisco packet tracer:
BGP (Border Gateway Protocol) PATH ATTRIBUTES
There are four BGP Path Attributes:
- Well-known Mandatory: It is recognized and included in all BGP Update messages
- Well-known Discretionary: Recognized and may or may not include in BGP Update messages
- Optional Transitive: Even if it’s not supported it still needs to accept and send in an update message
- Optional Non-transitive: Can be ignored and not advertised to peers
- WELL-KNOWN: These attributes must be recognized by all the BGP implementations
Well-known BGP Attributes fall into two sub-categories:
- Mandatory: The attributes must be always included and carried in all BGP update messages to peers. The BGP implementation has to recognize the attribute, accept it, and also advertise it to its peers
- Discretionary: The attributes are recognized by the BGP implementation but may or may not be sent in a specific Update message. It is up to the discretion of BGP Implementation to send or not to send these attributes in the update messages to the peers
- OPTIONAL: These attributes may or may not be supported by the BGP implementations
Optional BGP Path attributes also fall into two subcategories
- Transitive: The BGP process has to accept the path in which it is included and should pass it on to other peers even if these attributes are not supported
- Non-Transitive: If the BGP process does not recognize the attribute then it can ignore the update and would not advertise the path to its peers
There are about 11 BGP Path Attributes, which are WEIGHT, LOCAL-PREF, AGGREGATE, AS_PATH, ORIGIN, MED, NEIGHBOR Type, IGP Metric, Route AGE, ROUTER ID, and NEIGHBOR IP. The following table describes the BGP Path Attributes with their categories:
BGP (Border Gateway Protocol) LOCAL-PREF
LOCAL-PREF is used to select the exit path for an AS (Autonomous System). The path with the highest Local Preference is always preferred and the default value of Local Preference is always preferred. BGP LOCAL-PREF is sent to all internal BGP routers in your AS and is not exchanged between eBGP routers. It is a well-known and discretionary BGP attribute and it can be used to influence route selection within the local Autonomous System while MED is used between different AS. It is always local for an AS (Autonomous System) and used to influence your own AS (Autonomous System) on how to get or exit another AS (Autonomous System). MED is to influence other AS that how to enter into your AS (Autonomous System)
BGP LOCAL-PREF – EXAMPLE 1
In the example below, you will see that R3 is chosen as an exit point for AS200 after decreasing the Local Preference of R2 to 50:
BGP LOCAL-PREF – EXAMPLE 2
The scenario below is also a BGP LOCAL-PREF example:
BGP’s use in MPLS (MP – iBGP)
The following is an example of BGP’s use in MPLS:
P = Provider Router
PE = Provider Edge Router
CE = Customer Edge Router
LER = Label Edge Router
LSR = Label Switch Router
LSP = Label Switched Path
BGP’s use in MPLS (MP – iBGP) – Lab
You can practice the BGP’s use in MPLS Lab:
Refer to MPLS Lecture/Lab session recording:
https://www.youtube.com/watch?v=mmTUM6wp7Ho
BGP (Border Gateway Protocol) Origin Codes & Status Codes
The tables below describe the BGP Origin and Status Codes:
#show ip bgp command
#show ip bgp summary command
#show ip bgp prefix# command (show detail of a specific prefix)
BGP Address Families
Below is the table describing BGP Address Families:
BGP Packets Format
The BGP Packets format is as shown below:
BGP Packet Types (Message Types)
There are four types of BGP packets: Open Message, Update Message, Keepalive Message, and Notification Message
BGP Neighbor States
There are six BGP Neighbor States, these include Idle, Connect, Active, OpenSent, OpenConfirm, and Established as described in the following scenario:
iBGP next-hop-self Requirement
iBGP has a built-in problem that does not change the next-hop IP address. Therefore, we need to use the command to disable automatic next-hop selection & solve the issue
Below is an example of R1 pointing to R3’s fa0/0 instead of R2’s fa0/0 (which is wrong & we need to correct that manually)
WITHOUT NEXT-HOP SELF
R2#show ip bgp
..
Network Next Hop Metric LocPrf Weight Path
*> 3.3.3.0/24 23.23.23.3 0 0 300 i
R1#show ip bgp
..
Network Next Hop Metric LocPrf Weight Path
* i3.3.3.0/24 23.23.23.3 0 100 0 300 i
iBGP (Interior Border Gateway Protocol) Full Mesh Requirement
iBGP has no declared loop prevention mechanism. Hence, it needs full mesh topology.
iBGP peers should not re-advertise iBGP-learned routes to other iBGP speakers which is why they all need to be fully meshed. If you can’t re-advertise iBGP routes, you must be directly connected to the originator of the route, hence the full mesh requirement
Methods to fulfill iBGP full mesh requirement:
- BGP Route Reflector
- BGP Confederations (divide the AS into sub-AS)
iBGP Full mesh Formula:
No. of Links Required for full mesh topology =(n (n-1))/2
For Example: For a topology with 6x Routers:
(6 (6-1))/2 = 15 iBGP Peers are required
iBGP (Interior Border Gateway Protocol) RR (Route Reflectors)
The RR (Route Reflectors) is one method employed to eliminate full mesh iBGP peers in your network. RR (Route Reflectors) lets every single iBGP speaker within a network learn about the available routes without bringing in loops. Below are two scenarios, the first is a network that has 6 iBGP routers not having a Route-Reflector and the second scenario is a network using a Route-Reflector also consisting of 6 routers where each router only has an iBGP peering with a Route-Reflector on top:
*In real networks, we usually use 2xRR as active/standby to avoid SPoF
BGP (Border Gateway Protocol) Route Filtering and BGP Route Filtering Methods
Sending and receiving BGP updates from/to neighbors is controlled by using a number of different filtering methods. Route Filtering can be used in both Inbound/Outbound directions. BGP (Border Gateway Protocol) Route Filtering Methods are Route maps, Distribute lists (with ACL/Extended ACL), Prefix lists, Filter lists, Regular Expressions, Filtering using BGP attribute, and Filtering using BGP Community attributes
