5/26/2017 BGP Path Attributes – netcerts.

net

netcerts.net
Routing & Switching

 Contact

Home » BGP » BGP Path Attributes Categories

▼ BGP (5)

BGP Path Attributes » BGP Decision Process

» BGP Path Attributes
» BGP Protocol Overview
» IBGP Basics
Path Attributes as the name suggests are the characteristics of an
» Route Reflectors and
advertised BGP Route. BGP routing policy is set and communicated
Confederations
using the path attributes.
► IP Multicast (1)
► IPv6 (2)
Path Attributes fall into one of the two categories
► Layer-2 Switching (5)
1. Well-known Path Attributes
► Layer-7 Applications (1)
2. Optional Path Attributes
► MPLS (4)
► Network Services (2)
Well-known: Meaning these attributes must be recognized by all ► QoS (9)
the BGP implementations.

Well- Known BGP Path Attributes fall into two sub-categories Recent Posts
known as
Exploring HTTP and PKI
1. Mandatory (Called as Well-known Mandatory)
Configuring Cisco router as a
2. Discretionary (Called as Well-Known Discretionary)
DHCP client
QoS Congestion Avoidance
Mandatory: This means the attribute must be always included and
CBWFQ and LLQ
carried in all BGP update messages to peers. The BGP
Custom Queuing and Priority
implementation has to recognize the attribute, accept it and also
Queuing
advertise it to its peers.

Discretionary: Meaning these are recognized by the BGP Archives

implementation but may or may not be sent in a specific Update
Select Month
message. Its up to the discretion of BGP Implementation to send
or not to send these attributes in the update messages to the peers.

http://netcerts.net/bgp­path­attributes­and­the­decision­process/ 1/18
5/26/2017 BGP Path Attributes – netcerts.net

Optional: Meaning these attributes may or may not be supported by

the BGP implementations.

Optional BGP Path attributes also fall into two sub-categories

1. Transitive (Called as Optional Transitive)
2. Non-transitive (Called as Optional Non-transitive)

Transitive: 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. Meaning if any optional attribute is
not recognized by a BGP implementation, then BGP looks to check
if the transitive flag is set. If the transitive flag is set then BGP
implementation should accept the attribute and advertise it to its
other BGP Peers.

Non-transitive: If the BGP process does not recognize the attribute

then it can ignore the update and not advertise the path to its
peers. If the transitive  flag is not set then BGP implementation
can quietly ignore the attribute, it does not have to accept and
advertise this attribute to its other peers.

To Summarize the BGP Path Attribute Categories

1. Well-known Mandatory: Recognized and Included in all BGP

Update messages.
2. Well-known Discretionary: Recognized and May or May not
include in BGP Update messages
3. Optional Transitive: Even if Not Supported it Still need to accept
and Send in Update Message.
4. Optional Non-transitive: Can be ignored and not advertise to
peers.

LIST OF BGP PATH ATTRIBUTES

Attribute Name Category / Class

ORIGIN Well-Known Mandatory

AS_PATH Well-Known Mandatory

NEXT_HOP Well-Known Mandatory

LOCAL_PREF Well-Known Discretionary

ATOMIC_AGGREGATE Well-Known Discretionary

http://netcerts.net/bgp­path­attributes­and­the­decision­process/ 2/18
5/26/2017 BGP Path Attributes – netcerts.net

AGGREGATOR Optional Transitive

COMMUNITY Optional Transitive

MULTI_EXIT_DISC (MED) Optional Non-Transitive

ORIGINATOR_ID Optional Non-Transitive

CLUSTER LIST Optional Non-Transitive

MULTIPROTOCOL Reachable NLRI Optional Non-Transitive

MULTIPROTOCOL Unreachable NLRI Optional Non-Transitive

Python Tutorial: Python Network Programming – Build 7 Apps

ORIGIN ATTRIBUTE:
As the name suggests the ORIGIN attribute specifies the origin of
the routing update. This is a Well-known Mandatory BGP Attribute
and hence has to be recognized and sent to peers by all BGP
implementations. The Origin attribute can contain one of these
three values
1. IGP
2. EGP
3. Incomplete

If BGP has multiple routes then ORIGIN is one of the factor in

determining the preferred route. IGP is the highest preferred
ORIGIN value followed by EGP and Incomplete ORIGIN Attribute
is the lowest preferred ORIGIN value of the three.

IGP: It means that the NLRI was learnt from an internal routing
protocol of the originating AS.
EGP: This ORIGIN code specifies that the NLRI was learnt from
EGP.
Incomplete: Usually misunderstood, this value means that the
NLRI was learnt from some other means, it does not mean that the
route is faulty, it only specifies that the information to determine
the ORIGIN is not complete. All redistributed routes into BGP
have an Incomplete ORIGIN attribute, since the origin of these
routes cannot be determined.

http://netcerts.net/bgp­path­attributes­and­the­decision­process/ 3/18
5/26/2017 BGP Path Attributes – netcerts.net

AS_PATH ATTRIBUTE:

AS_Path describes the inter-AS path taken to reach a destination.

It gives a list of AS Numbers traversed when reaching to a
destination. Every BGP speaker when advertising a route to a peer
will include its own AS number in the NLRI. The subsequent BGP
speakers who advertise this route will add their own AS number to
the AS_Path, the subsequent AS numbers get prepended to the list.
The end result is the AS_Path attribute is able to describe all the
autonomous systems it has traversed, beginning with the most
recent AS and ending with the originating AS.

AS_Path is a well-known attribute, so if a BGP speaker advertises

the route to a destination then it has to include its AS number in
the advertisement if its originating the NLRI or if its advertising a
received NLRI to other peers then it has to prepend its AS number
to the existing list of autonomous systems in the AS_path attribute.

For an example below:

Lets assume AS-100 is advertising 1.1.1.0/22 to AS-200 Since AS-

100 is originating the NLRI the advertisement will be [ 1.1.1.0/22
100]
AS-200 will receive this NLRI and advertise it to its peers AS-300
and AS-400, the NLRI  advertisement will look like  [ 1.1.1.0/22

http://netcerts.net/bgp­path­attributes­and­the­decision­process/ 4/18
5/26/2017 BGP Path Attributes – netcerts.net

200,100] – specifying that to reach the network 1.1.1.0/22 you have

a path where you can to traverse AS-200 then AS-100.

The subsequent autonomous systems AS-300, AS-400 and others

do the same. In the end AS-600 receives two routes to reach the
network 1.1.1.0/22. To reach any host in network 1.1.1.0/22 it can
either reach through AS-500 or from AS-400, since BGP is a path
vector protocol by default AS-600 will choose the path from AS-
400 since its shorter (less number of Autonomous Systems to
traverse). Also note by default EBGP will not load balance across
the two paths and will select only one best path, but it can be
configured to load balance.

Also, BGP Speaker will add its AS number to the AS_Path only
when an Update message is being sent to the neighbor which
means only when BGP is advertising the route to the peer it will
prepend its AS number to the AS_Path attribute.

AS_Path Prepend to Prefer one route over another:

In BGP the outgoing route advertisements directly influence the

incoming traffic. In the example lets assume the link between AS-
200 and AS-400 is a T1 and AS-200 does not want to prefer this
route. Since the outgoing advertisements directly influence the

http://netcerts.net/bgp­path­attributes­and­the­decision­process/ 5/18
5/26/2017 BGP Path Attributes – netcerts.net

incoming traffic in BGP, and AS-200 wants to prefer AS-300

assuming this is a high speed Gig link, AS-200 will prepend its AS
number is the advertisements to AS-400 so that it makes it less
preferable, the new BGP path ratio is reflected in the example
diagram . AS-600 will now prefer the path from AS-500 and will
follow the path 500-300-200-100 to reach 1.1.1.0/22 since this
one becomes the shorter path.

AS_Path prepending is one of the way to influence how the BGP

advertisements and the incoming traffic is handled.

AS_Path Attribute also makes sure that there is no routing loop, if

an NLRI advertisement is received from a BGP peer and the
receiving AS sees its own AS number in the AS_Path list of the
destination route which is received, then the receiving BGP speaker
knows that there is a loop and will not accept the advertisement.

AS_Path can be shown by issuing the command “sh ip bgp” on a

cisco router.

NEXT_HOP ATTRIBUTE:

NEXT_HOP Attribute specifies the next hop IP address to reach the

destination advertised in the NLRI.  NEXT_HOP is a well-known
mandatory attribute and it has some set of rules to be followed for
different BGP scenarios.

1. If the BGP Peers are in different Autonomous Systems then the

NEXT_HOP IP address that will be sent in the update message will
be the IP address of the advertising router.

2. If the BGP peers are in the same AS (IBGP Peers), and the
destination network being advertised in the update message is also
in the same AS, then the NEXT_HOP IP address that will be sent in
the update message will be the IP address of the advertising
router.

3. If the BGP peers are in the same AS (IBGP Peers), and the
destination network being advertised in the update message is in
an external AS, then the NEXT_HOP IP address that will be sent in
the update message will be the IP address of the external peer
router which sent the advertisement to this AS.

http://netcerts.net/bgp­path­attributes­and­the­decision­process/ 6/18
5/26/2017 BGP Path Attributes – netcerts.net

Below are some examples for each of these scenarios.

NEXT_HOP BGP UPDATE Between Different Autonomous Systems:

In this
example,
the EBGP
update is
pretty
straight
forward.
As the
rule
states If
the BGP
Peers are
in
different
Autonomo
us
Systems
then the
NEXT_HO
P IP
address
that will be sent in the update message will be the IP address of
the advertising router.

NEXT_HOP will always be advertised by the router which is sending

an update to the BGP peer on how to reach a particular network.

The router in AS-200 sends in its update that network 2.2.2.0/24 is

reachable via its IP address of 192.168.100.2

The router in AS-100 when needs to reach the network 2.2.2.0/24,

it will always use the next hop ip address of 192.168.100.2 which is
advertised by the router in AS-100 as a NEXT_HOP Attribute to
reach this network.

Since NEXT_HOP is a well-known Mandatory Attribute, the router

in AS-100 will have to accept and honor this value.

http://netcerts.net/bgp­path­attributes­and­the­decision­process/ 7/18
5/26/2017 BGP Path Attributes – netcerts.net

In this scenario where there are two routers in different AS and

have formed the EBGP relationship, the NEXT_HOP attribute is
pretty simple and straight forward.

The command “show ip bgp neighbor 192.168.100.1 advertised-

routes” when executed on the router in AS-200 will show the
network prefix it is advertising and the NEXT_HOP it is advertising.
Both these values will be network: 2.2.2.0/24 and the NEXT_HOP
as 192.168.100.2

NEXT_HOP BGP UPDATE Within Peers in Same Autonomous

System:

NEXT
_HOP
addre
ss for
the
BGP
peers
in the
same
Auto
nomo
us Systems  is the address of the advertising router which in this
case is RTR-A. Both RTR-A and RTR-C are IBGP Peers, When
RTR-A sends an update message indicating the reachabilty
information for network 10.10.10.0/24, it puts its own IP address in
the NEXT_HOP. For RTR-C to reach the network 10.10.10.0/24, it
will have the NEXT_HOP IP address of RTR-A and not RTR-B to
which it is directly connected.

Also, this applies to the routers on the same shared IP segment,

the NEXT_HOP will always be the IP address of the advertising
router.

NEXT_HOP BGP UPDATE For Different AS:

In this scenario, the router is AS-100 is advertising the network

172.16.30.0/24 and specifies the next hop ip address of its own as
172.16.10.1, the router in AS-200 receives this update and has the
next hop to reach this network as the IP address of the router

http://netcerts.net/bgp­path­attributes­and­the­decision­process/ 8/18
5/26/2017 BGP Path Attributes – netcerts.net

which advertised the network which is the router in AS-100.

Within AS-200 now RTR-A advertises this network to its IBGP

peers and advertises the NEXT_HOP as the IP address of the router
in AS-100.

RTR-C which is the IBGP peer of RTR-A, now knows to reach the
network 172.16.30.0/24 it has to use the next hop ip address of
172.16.10.1 (which is the ip address on router in AS-100).

This could cause an issue because RTR-C does not know how to
reach the address 172.16.10.1 and the packets for the destination
in 172.16.20.0/24 are dropped.  The route 172.16.30.0/24 is
installed in BGP table but it is not installed in the IGP as the next
hop IP address specified is not reachable and is considered as an
invalid address. This issue can be resolved in one of the three ways.
1. Use static routes to link external addresses to internal routers,
not a very feasible solution to use.
2. Run IGP is passive mode on the external interfaces.
3. BGP implementation gives a more practical solution called as
“Next_Hop_Self” this when configured on the local RTR-A it will
cause RTR-A to set its own IP address in the NEXT_HOP attribute. 
The internal peers RTR-B and RTR-C will now have a NEXT_HOP IP
address of 192.168.10.1 to reach the network 172.16.30.0/24 in

http://netcerts.net/bgp­path­attributes­and­the­decision­process/ 9/18
5/26/2017 BGP Path Attributes – netcerts.net

AS-100. Since the internal routers already have the RTR-A’s

address in IGP they know how to reach the external network
through RTR-A.

Local Preference (LOCAL_PREF):

LOCAL_PREF is only used in updates sent to the IBGP Peers. This is

a well-known discretionary attribute and as the name suggests it is
used locally within an AS to update the internal BGP peers. It is
not passed on to the BGP peers in other autonomous systems.

LOCAL_PREF specifies the BGP Speaker’s degree of preference for

an advertised route.
The higher the value of Local Preference attribute the more
preferred the route is.
Remember: For Local Preference : Higher Value = More Preference

Note that the Local Preference will only affect the traffic leaving
the AS.

For an example on how LOCAL_PREF influences BGP routing, take

a look at the diagram below.

In this example, the customer is peering with two ISPs to get the
internet routing table, assuming that the connection to ISP-1 is a
Gig connection and the connection to ISP-2 is only a T1, the
customer wants to use ISP-1 and keep ISP-2 as a backup in case
the link to ISP-1 fails.

From the diagram, RTR-A is connected to ISP-1 and it advertises

the routes received from ISP-1 with a local preference of 200 to
other internal BGP peers.

RTR-B is connected to ISP-2 and is advertising the routes received

from ISP-2 with a local preference value of 100 (which is the
default value of LOCAL_PREF).

Assuming that both the ISPs are advertising the same destination

http://netcerts.net/bgp­path­attributes­and­the­decision­process/ 10/18
5/26/2017 BGP Path Attributes – netcerts.net

routes then RTR-C, the internal BGP Peer receives the routes from
both RTR-A and RTR-B and will select RTR-A because the
LOCAL_PREF value is higher on the routes advertised by RTR-A.

Also note that RTR-B will also prefer the routes advertised by ISP-
1 connected to RTR-A. that is all internal routers within the
customer AS in the diagram will now prefer Routes received from
ISP-1.

LOCAL_PREF affects the traffic leaving the AS, the traffic leaving
the Customer-AS in this example will prefer the routes from ISP1
to reach the destination networks. If there are any destination
routes that ISP2 is advertising which are not being advertised on
ISP1 for some reason, then traffic destined for those routes which
are missing in ISP1’s advertisements will leave from RTR-B to
ISP2 in order to reach those destinations network prefixes.

ATOMIC_AGGREGATE and AGGREGATOR:

ATOMIC_AGGREGATOR path attribute does  route aggregation on

the routes that are non identical but point to the same destination.
In effect if summarizes the routes when advertising them to the
BGP peer.

When a router receives routes for the same destination, it makes

the best path decision by selecting the more specific path. When

http://netcerts.net/bgp­path­attributes­and­the­decision­process/ 11/18
5/26/2017 BGP Path Attributes – netcerts.net

aggregation is performed the BGP Speaker starts advertising the

less specific routes to its peers but the path detail information is
lost in this process. Anytime a BGP speaker does this aggregation
by summarizing more specific routes into a less specific route it has
to inform its down stream BGP peers that aggregation has been
done, this is done by attaching the ATOMIC_AGGREGATE attribute
to the update message.

When the downstream BGP speakers receive the route with

ATOMIC_AGGREGATE attribute set, then they cannot advertise
the more specific routes for this aggregated route, and they will
have to keep the ATOMIC_AGGREGATE attribute attached when
advertising this route to their BGP peers.

In some instances not all routes in a  network can be aggregated,

and in others  all of them can be aggregated but still there might be
an need to advertise both aggregate-address and the more-specific
routes. In both the cases the router can advertise both the more
specific routes as well as the aggregate address. Aggregation is
done by the command “aggregate-address <network-prefix>
<mask> and individual network statements” if the same command
is used with the keyword “summary-only” then only the aggregate
address is advertised and not the more-specific prefixes.

ATOMIC_AGGREGATE is a well-known discretionary attribute and

informs its down stream routers that a loss of path information has

http://netcerts.net/bgp­path­attributes­and­the­decision­process/ 12/18
5/26/2017 BGP Path Attributes – netcerts.net

occurred.

AGGREGATOR:

when the ATOMIC_AGGREGATE attribute is set, the BGP speaker

has an option of attaching the AGGREGATOR attribute.
AGGREGATOR i optional transitive attribute and gives information
on where the aggregation was performed by including the AS
number and the IP address of the router that originated the
aggregate route. Cisco uses the Router ID as the the address of
AGGREGATOR.

AS_SET:

When aggregation is done on the BGP route, the AS_Path

information is lost. One of the purposes why AS_Path is used is to
avoid any loops, and if the BGP speaker does not see its own AS
number in the AS_Path, it will accept the route and can create a
potential loop in the routing.

AS_SET is used to avoid this, AS_SET gives an unordered list of AS

numbers when aggregation is done.

When a BGP speaker does aggregation for an NLRI leant from

other autonomous systems, it can include all the AS numbers in the
AS_Path as AS_SET,  including AS_SET will still give a list of AS
numbers, though unordered it will still let the BGP speaker know if
its own AS number was there somewhere in the path and it can
reject the NLRI if its own AS number was seen for this NLRI
advertisement.

MULTI_EXIT_DISC ATTRIBUTE: (MED)

MED is an optional non-transitive attribute and it is used to

influence how the incoming traffic comes into an AS.

MED allows the AS  to inform its immediate neighbor AS of its

preferred entry points. MED is also called as metric and the lowest
value of MED is the most preferred one.
Note that MED Is not passed beyond the receiving AS. It is only
used to influence traffic between two directly connected
autonomous systems. Also MEDS are never compared when the
routes to the same destination are received from two or more

http://netcerts.net/bgp­path­attributes­and­the­decision­process/ 13/18
5/26/2017 BGP Path Attributes – netcerts.net

d
if
f
e
r
e
n
t
A
S
.
M
E
D
o
n
l
y
a
p
p
lies to the routes advertised by a single AS.

In this example, AS-100 advertises the route from two different

entry points with the MED value of 50 0n one router and a value of
100 on another. The Preferred entry point will be the router which
is advertising the routes with the MED value of 50, since this is the
lower value. Also notice that AS-200 will not advertise the AS-100
MED values to AS-300 in its outgoing route advertisements, since
MED is an optional non-transitive attribute.

Also in this example the MED attribute will only take affect if AS-
200’s BGP implementation recognizes the MED attribute, or else
setting these MED attribute values on the routes for a preferred
entry point into AS will not have any affect.

Note: By default MED values are not compared for routes to the
same destination received from tw0 or more different autonomous
systems. There is however a way for enabling this by using the
command “bgp-always-comapre-med”. when this command is
used, MED values on the received routes for same destination from
different autonomous systems are compared. If this command is
configured then it needs to be configured on every BGP router in
the AS.

http://netcerts.net/bgp­path­attributes­and­the­decision­process/ 14/18
5/26/2017 BGP Path Attributes – netcerts.net

COMMUNITY ATTRIBUTE:

COMMUNITY attribute allows to share a common policy across

multiple BGP peers who can be identified to be in a same group.

This is an optional transitive attribute so it needs to be passed on to

other BGP peers. This attribute simplifies the policy enforcement
by grouping a set of BGP peers with common properties to share a
common set of policy.

An AS can set a COMMUNITY attribute for some of its BGP peer

routes, and set the LOCAL_PREF and MED attributes based on the
COMMUNITY rather than setting these values individually for each
of these Peers. This helps in simplifying the process of policy
enforcement.

Community attribute is always represented in Hex Format and is a

set of 4 Octets.
As per RFC 1997 the first 2 octets are AS-number and the last two
octets are an administratively defined identifier , resulting in the
format of  AA:NN
The default Cisco format is the reverse of this as NN:AA, but this
can be changed by the command “ip bgp-community new-format”

Community values in these ranges are reserved

0 – 65535 [Hex: 0x00000000-0x0000FFFF] and
4294901760 – 4294967295 [Hex: 0xFFFF0000-0xFFFFFFFF]
some of the well-known communities fall into these reserved
ranges, as below.

1. INTERNET: The internet community is the default community, it

has no value. All routes by default to belong to this community and
all of the routes in this category are advertised freely.

2. NO_EXPORT: Routes received carrying this value cannot be

advertised to EBGP Peers.  That is these routes must not be
advertised outside the AS. The value is  0xFFFFFF01. If there is a
confederation defined and this value is received then the routes
cannot be advertised outside the confederation.

3. NO_ADVERTISE: Routes received carrying this value cannot be

advertised at all, that is they cannot be advertised to IBGP or
EBGP peers. The value is 0xFFFFFF02.

http://netcerts.net/bgp­path­attributes­and­the­decision­process/ 15/18
5/26/2017 BGP Path Attributes – netcerts.net

4. LOCAL_AS: Routes received carrying this value cannot be

advertised to EBGP peers and peers in other AS within a
confederation. The value is 0xFFFFFF03. As per RFC 1997 this
attribute is called as NO_EXPORT_SUBCONFD.

Apart from these well-known community attributes, private

community attributes can also be defined for certain uses, but
these private community attributes will only be significant to the
AS that has defined it in context to its BGP peers.

A route can carry more than one community attribute, and the BGP
peer that receives such a route with multiple community attributes 
can act based on one, some or all of the community attributes. A
router can also add or modify the community attributes before
passing them to other BGP peers.

Administrative Weight: (Cisco Only Parameter)

This is a Cisco Specific attribute that is applied to a route within a

router. it is not communicated to other routers. The value of admin
weight ranges between 0 to 65.535 and the route with higher value
is more preferred.
By default all routes leant from a BGP peer have a value of 0 and
all routes generated by the local router have a value of 32,768.

In this example, the router RTR-C prefers route  1.1.1.0/24  from

RTR-B in AS-200, because the admin weight assigned is higher on
the route received from RTR-B. Administrative weight is the first
parameter which Cisco routers use for deciding the best BGP route
when multiple routes to the same destination are available.

http://netcerts.net/bgp­path­attributes­and­the­decision­process/ 16/18
5/26/2017 BGP Path Attributes – netcerts.net

Incoming search terms for the article:

bgp attributes (588)

bgp attributes list (324)
bgp path attributes (199)
bgp path attributes list (127)
Define various BGP path attributes (86)
List of BGP attributes (47)
bgp attribute (46)
bgp aggregator attribute (27)
bgp influence incoming traffic (17)
as path attribute in bgp (17)
bgp transitive vs non-transitive (15)
path attributes in bgp (15)
bgp attribute list (13)
bgp transitive and non transitive (2)
bgp attributes explained (2)

 May 21, 2010  Amit Rai  BGP  4 Comments

 BGP Protocol Overview

BGP Decision Process 

4 Thoughts On “BGP Path Attributes”

Pingback: Non-Transitive or Transitive? - BGP Path Attributes -

Geeky Nick

Pingback: List The Attributes Of Isp | cable - internet providers in

Pingback: List The Attributes Of Isp | join - rate your internet

http://netcerts.net/bgp­path­attributes­and­the­decision­process/ 17/18
5/26/2017 BGP Path Attributes – netcerts.net

Pingback: What Are Bgp Transitive Attributes – GoogleTeach

Leave A Reply

You must be logged in to post a comment.

netcerts.net Copyright © 2017 | Theme: Magazine Style Powered by WordPress

http://netcerts.net/bgp­path­attributes­and­the­decision­process/ 18/18