Enhance your Career in Networking With IPinBits!!!​

BGP Path attributes

As we discussed about the BGP in our BGP introduction article, we mentioned that BGP is a PATH vector protocol. What do we mean by that and how is that significant- Well, BGP is a path vector protocol because it considers different path attributes for best route selection.
BGP divides the path attributes in different categories. BGP path attributes are listed below :-
Lets Discuss all of them one by one.
1. Well Known Path attributes– These attributes are well known and are fundamentals for BGP working. These path attributes must be recognized by BGP speaking routers.
1.1 Mandatory path attributes– These attributes must be shared in BGP update from one BGP peer to other. These are mandatory as the name suggest and if these are not shared in BGP update, a Notification error will be sent by BGP and BGP peering is torn down.
Mandatory path attributes are as follows :-
1.1.1 AS-PATH – This attribute is used by BGP in two ways – in BGP path selection as well as loop prevention in EBGP implementation. AS-PATH is prepended by each BGP router before sending the route to next EBGP router.
1.1.2 NEXT HOP – Next hop as the name suggest is used for telling the next hop address. Before any BGP router sends a route to its BGP neighbor, the next address is the interface ip of the sending router. It is used in BGP path selection criteria. Please note that the next hop attribute works differently in case of EBGP and IBGP. In EBGP Next hop changes hop by hop while in IBGP NEXT hop remains same (Next hop remains same as EBGP neighbor) 
1.1.3 ORIGIN – This path attribute tells us the origin of the route. There are three possibilities for origin – IGP,EGP or INCOMPLETE. IGP(i) denotes that the route is learned from NETWORK command i.e it was manually injected into BGP using NETWORK Command. EGP denotes that the route was learned from EGP protocol (predecessor of BGP protocol). You won’t see this in todays network. Incomplete (?) denotes that BGP can not tell how the route is injected into BGP. If we redistribute IGP (OSPF/ISIS/EIGRP/RIP etc) into BGP those routes will be shown as INCOMPLETE. 
NOTE:: ORIGIN is used for BGP path selection.
1.2 Discretionary path attribute– These attributes can be and can not be shared and BGP will run just fine. So what’s the difference between Discretionary and Optional attributes then – well, Discretionary path attributes are well known and every BGP router must know how to process them while optional path attributes may not be recognized by the router based on the BGP implementation. Discretionary path attributes are as follows :-
1.2.1 LOCAL PREFERENCE – Also referred as LP, It is used for BGP path selection and also to tell IBGP neighbors how to leave their AS i.e it is used to tell the exit point of IBGP AS (Outbound Traffic). LP is shared in UPDATE message and it is only shared within IBGP peers and not EBGP peers (except confederation). Default on cisco is 100.
1.2.2 ATOMIC AGGREGATE – When BGP router aggregates several routes before advertisement to its peer, The aggregated route can be sent with aggregated AS-PATH which includes all the AS it travelled in AS-SET. But if a Network engineer wishes to remove this AS-SET (be aware this can cause loops) the ATOMIC AGGREGATE attribute should be included in the update message. Upon receiving a update message with ATOMIC ATTRIBUTE a BGP router will do following things :-
a. It will propagate the ATOMIC AGGREGATOR attribute to other BGP peers.
b. The route will not be further aggregated.
2. Optional path attributes– These path attributes are optional and BGP will work just fine without these path attributes. Optional path attributes are as follows –
2.1 Transitive path attributes– If a BGP router receives these attributes, Router must pass these path attributes to next BGP speaking router. Transitive path attributes are as follows :-
2.1.1 AGGREGATOR – This is optional attribute and transitive in nature. Aggregator is the router which aggregates the multiple routes into one. The aggregator attribute contains the AS Number and BGP identifier (Router ID of BGP) of the router which does the aggregation.
2.1.2 COMMUNITY – BGP can control routing information based on IP address prefixes or path attributes and Communities were introduced to simplify the control of routing information based on grouping of destinations. So by using communities, routing decisions can be made on the basis of group identity (TAG) also.  SO a community is the group of destinations which share some common properties.
Communities are identified by 32bit values ranging from 0x0000000 to 0x0000FFFF. However there is a 16 bit new format which is stated as ASnumber:Community (extended communities). NO EXPORT {0xFFFFFF01} – All routes received with this community value will not be advertised outside of BGP. In other words, router will not be shared with EBGP, but will be shared within IBGP. NO ADVERTISE {0xFFFFFF02} – Router received with this community will not be advertised to EBGP or IBGP. INTERNET – When using this community, routes will be shared to all. NO_EXPORT_SUBCONFED (0xFFFFFF03) – This is also known as LOCAL-AS community. When routes received with this community the routes are forwarded within Confederation IBGP only.

2.2 Non-Transitive path attributes– These path attributes can be suppressed by a BGP speaking router and router do not pass them to the next BGP speaking router. Non-Transitive path attributes are as follows :-
2.2.1 M.E.D – It is used to manipulate the incoming traffic. We can refer MED as metric of BGP. When all other attributes are equal before MED, then LOWER MED is preferred. Some points to be noted wrt MED are as follows :-
a. MED is used for incoming traffic (or outgoing routes) between AS.
b. MED received from a peer AS can be populated into the IBGP but it can never be forwarded to next peer AS.
c. MED is derived from IGP metric if the route is populated in BGP using network command.
d. If EBGP send route without MED value, then cisco IOS put MED = 0 before sending to IBGP  while no MED is sent to EBGP. 
e. MED of TWO AS is never compared unless and until BGP is configured with always compare MED option.
2.2.2 ORIGINATOR – This is used when Route Reflectors (RR) are used. It is a loop prevention mechanism when RR is used. A router will reject the route if it sees its R-ID in the Originator attribute. Originator can be :-
a. BGP speaker R-ID if NETWORK Command is used.
b. BGP Broder AS R_D if learned from eBGP.
2.2.3 CLUSTER-ID – Cluster ID is used when multiple RR are used. It works same as ORIGINATOR ID.

BONUS – Accumulated IGP Metric Attribute or AIGP metric attribute

Companies might desire to implement a network design where the network is split with multiple Interior Gateway Protocols (IGPs), each with one BGP autonomous system. This is used for scalability reasons, where the network becomes too large for one IGP. The BGP helps to scale when it carries some of the routes that otherwise would be carried by the IGP. The solution that uses AIGP is intended for networks with different BGP autonomous systems under one administrative control.

Here is an example:

The end-to-end service is Multi-Protocol Label Switching (MPLS) VPN. When there is a large number of Provider Edge (PE) routers in the network, the IGP must carry too many routes. The solution is to have BGP carry the loopback interfaces of the PE routers. The solution that is used in order to ensure that the MPLS Label Switched Path (LSP) is not interrupted end-to-end is to use the BGP IPv4 + label. This means that RFC 3107 is used between the PE routers and the border routers, which connects the different IGP domains.

The issue with this solution is that the border routers or the PE routers can no longer make a decision about the best path, based on the shortest metric end-to-end, because there is no longer one IGP that runs throughout the whole network. The solution to this issue is the new BGP attribute, called the Accumulated IGP Metric Attribute or AIGP metric attribute. This BGP non-transitive attribute carries the accumulated metric for the paths so that the BGP speakers receive knowledge of the end-to-end metric for those paths.

Related blog posts