In the last article of this BGP series, we discussed the NEXT_HOP attribute used in BGP UPDATE messages. We saw how the value of this attribute can vary depending on the scenario (e.g. IBGP and a destination within the same AS). In this article, we will be looking at some other common path attributes such as ORIGIN, AS_PATH, MULTI_EXIT_DISC and LOCAL_PREF.

CCNA Training – Resources (Intense)

Terminology

Before we continue, let’s look at some terminology used to describe the different path attributes:

  1. Well-known: All BGP implementations must recognize the attribute.
    1. Mandatory: The attribute must be sent in all UPDATE messages that contain an NLRI.
    2. Discretionary: The attribute may or may not be sent in an UPDATE message.
  2. Optional: BGP implementations may or may not recognize the attribute
    1. Transitive: If the BGP speaker does not recognize the attribute, it should accept it and also pass it along to other BGP peers.
    2. Non-transitive: If the BGP speaker does not recognize the attribute, it can quietly ignore the attribute and not pass it along to other BGP peers.

Note that all well-known attributes (mandatory or discretionary) are transitive.

ORIGIN attribute

The ORIGIN attribute is a well-known mandatory attribute that defines the origin of the routing information. There are three possible values that this attribute can have: IGP, EGP and Incomplete. Routes that are advertised into BGP using the network command have an origin of IGP; routes learned via the EGP protocol have an origin of EGP; while routes redistribute into BGP (using the redistribute command) have an origin of Incomplete because the routing information could have come from anywhere.

Let’s see an example of this using the network scenario below:

On R1, the 1.1.1.1/32 network will be advertised into BGP using the network command therefore it will have an ORIGIN of IGP. However, the 3.3.3.3/32 from EIGRP will be redistributed in BGP using the redistribute command on R2 therefore it will have an ORIGIN of Incomplete.

This ORIGIN attribute is used in BGP path selection as follows: IGP has a higher preference than EGP which has a higher preference than Incomplete.

AS_PATH attribute

The AS_PATH attribute is a well-known mandatory attribute used to describe the ASes through which the NLRI contained in the UPDATE message has passed. This attribute will vary depending on where the routing information originated and to whom (IBGP or EBGP) it will be sent. Let’s consider these different options.

Scenario #1: Locally originated route advertised to an IBGP peer

In general, whenever a BGP speaker sends an update to an IBGP peer, it does not modify the AS_PATH attribute. In the case where the routing information is locally originated, the advertising BGP speaker will include an empty AS_PATH attribute (i.e. length of 0) in the UPDATE message.

For example, in the network diagram above, when R1 sends the update for the 1.1.1.1/32 prefix to R2, the AS_PATH attribute will be empty.

Scenario #2: Locally originated route advertised to an EBGP peer

In general, when a BGP speaker sends an update to an EBGP peer, it prepends (adds to the front) its AS number to the AS_PATH attribute. In the case of locally originated routes, the AS_PATH attribute will contain only the AS number of the advertising BGP speaker.

For example, in the network diagram below, when R1 sends an update for the prefix 1.1.1.1/32 to R2, it will include its AS number (i.e. 1) in the AS_PATH attribute.

Scenario #3: BGP-learned routed advertised to an EBGP peer

As discussed, when a BGP speaker sends an update to an EBGP peer, it prepends its AS number to the AS_PATH attribute.

For example in the network diagram below, R4 sends the update for 4.4.4.4/32 with an AS_PATH of {4} to R3. When R3 sends the update for that prefix to R2, it will prepend the AS_PATH attribute with its own AS i.e. {3 4}.

Scenario #4: BGP-learned route advertised to an IBGP peer

Like we already mentioned, whenever a BGP speaker sends an update to an IBGP peer, it does not modify the AS_PATH attribute. Therefore in the above network diagram, when R2 sends an update for the 4.4.4.4/32 prefix to R1, its IBGP peer, it will not modify the AS_PATH attribute as shown below:

 

The AS_PATH attribute is also used as a loop avoidance mechanism. Whenever a BGP speaker receives an UPDATE message that contains its own AS in the AS_PATH attribute, it ignores the update.

As with the ORIGIN attribute, the AS_PATH attribute is used in the BGP best path selection process: given that all higher preferred attributes are equal, the path with the shorter AS_PATH is preferred to a longer one.

MULTI_EXIT_DISC attribute

This MULTI_EXIT_DISC (Multiple Exit Discriminator or MED for short) is an optional non-transitive attribute that a BGP speaker uses to influence its external neighbors on the entry point into its AS in the case where there are multiple entry points. The value of the MED attribute is also called a metric; therefore, (as with other concepts of metric) a lower value is better than a higher one.

Let’s take the network scenario below as an example:

In this case, R1 and R2 are both peering (EBGP) with R3 and are also advertising the network 10.0.12.0/24. The link between R2 and R3 is a better one compared to the one between R1 and R3; therefore, AS1 wants traffic to the 10.0.12.0/24 network to flow through R2 in normal working conditions. If that preferred path goes down, then the path via R1 can be used.

To achieve this, we can configure R2 to advertise a better (lower) metric for that network. In my case, R2 will advertise a metric of 50.

R1 will also advertise the same network but with a higher metric of 100.

If we check the BGP table on R3, we will see both paths there but only the best path through R2 is installed in the IP routing table.

LOCAL_PREF attribute

The LOCAL_PREF (Local Preference) attribute is a well-known discretionary attribute that a BGP speaker uses to inform its IBGP peers of its degree of preference for an advertised route. Whereas the MED attribute is used to inform external peers of a preferred entry point into an AS, the LOCAL_PREF attribute influences the exit point for a particular destination among internal peers.

For example, in the network diagram below, R1 is receiving the 192.168.34.0/24 network from R3 while R2 is receiving the same network information from R4.

The path through R1 is the preferred path for the 192.168.34.0/24 network from AS1; therefore, R1 will set the LOCAL_PREF for that destination to a higher value than the one set by R2. The default LOCAL_PREF value is 100 so R1 can set its own, to say, 200.

Before I set the LOCAL_PREF attribute on R1, notice that R2 is using R4 to reach the 192.168.34.0/24, even though it also has a route through 192.168.13.3 (R3 which is reachable via R1). This is because, all other higher priority attributes being equal, routes received via EBGP have a higher preference than those received via IBGP.

When I set the LOCAL_PREF on R1 (and I restart the BGP session), R1 sends R2 an UPDATE message with the LOCAL_PREF attribute set to 200.

On receiving this update, R2 recalculates the best path to reach the network and since the LOCAL_PREF attribute is higher up in the best path selection algorithm, R2 begins using the path via R1.

Summary

In this article, we have looked at four commonly used BGP attributes including ORIGIN, AS_PATH, MULTI_EXIT_DISC (MED) and LOCAL_PREF. Keep in mind that since MED represents a metric, then a lower value is better than a higher value. Also, the LOCAL_PREF signifies degree of preference; therefore, a higher value is better than a lower value.

I hope you have found this article insightful and I look forward to the next article in the series.

References and further reading

  1. RFC 4271: A Border Gateway Protocol 4 (BGP-4): http://tools.ietf.org/html/rfc4271
  2. Internet Routing Architectures 2nd Edition by Sam Halabi and Danny McPheron.
  3. Routing TCP/IP, Volume II, by Jeff Doyle.