BGP path attributes are the fundamental mechanism by which BGP selects the best path to a destination. On the CCNA 200-301 exam (objective 3.6), you must understand the four well-known mandatory attributes (AS_PATH, NEXT_HOP, ORIGIN) and the four well-known discretionary attributes (LOCAL_PREF, ATOMIC_AGGREGATE, AGGREGATOR) as well as the optional transitive (MED, COMMUNITY) and optional non-transitive (MULTI_EXIT_DISC, CLUSTER_LIST, ORIGINATOR_ID) attributes. This knowledge is critical for designing and troubleshooting BGP-based networks, and it appears in both multiple-choice and simulation questions.
Jump to a section
Imagine you're a piece of luggage at an airport, and your goal is to reach your final destination (a specific network prefix). Each airport (BGP router) attaches a series of tags (path attributes) to your luggage tag as you travel. Some tags are mandatory: your origin airport code (ORIGIN), the list of airports you've passed through (AS_PATH), and the next airport you must go to (NEXT_HOP). These are like the well-known mandatory attributes – every piece of luggage must have them. Other tags are optional but useful: your priority level (LOCAL_PREF) tells airport staff which routing path to prefer within the same airline alliance (AS). The airline might also add a tag saying "this luggage is a priority" (MED) to influence the next airport's decision. Some tags are understood by all airports (well-known), while others are understood only by certain airlines (optional). When your luggage arrives at a transfer airport, the staff look at all the tags to decide which flight to put you on next. The staff follow a strict decision process: first, they check the highest priority tag (LOCAL_PREF), then the shortest airport list (AS_PATH), then the origin type (ORIGIN), then the lowest MED, and so on. If two bags have identical tags, the staff might use a tie-breaker like the smallest luggage ID (router ID). This is exactly how BGP uses path attributes to select the best path – each attribute influences the decision at a specific step of the BGP best path selection algorithm.
What Are BGP Path Attributes?
BGP (Border Gateway Protocol) is a path vector protocol. Unlike OSPF or EIGRP, which build a topology map based on link-state or distance-vector, BGP carries a set of attributes with each route. These attributes describe the path to a destination network. BGP routers use these attributes to implement routing policies and to select the single best path among multiple paths to the same prefix.
Attributes fall into four categories: - Well-known mandatory: Must be present in all BGP updates. They are AS_PATH, NEXT_HOP, and ORIGIN. - Well-known discretionary: Recognized by all BGP routers, but not required in every update. They are LOCAL_PREF, ATOMIC_AGGREGATE, and AGGREGATOR. - Optional transitive: May not be recognized by all BGP implementations, but if unrecognized, the attribute is still passed along (transitive). Examples: COMMUNITY and the extended community set. - Optional non-transitive: If not recognized, the attribute is not passed to peers. Example: MULTI_EXIT_DISC (MED).
Why Path Attributes Matter
In a typical enterprise or service provider network, BGP is used to connect to the internet or to multiple ISPs. Without attributes, BGP would have no way to prefer one path over another – it would simply accept all routes and possibly install the first one learned. Attributes allow network engineers to influence inbound and outbound traffic flows. For example, you can set LOCAL_PREF to prefer a specific ISP for outbound traffic, or set MED to influence an ISP's inbound traffic to your network.
BGP Best Path Selection Algorithm
The BGP best path selection algorithm is a sequence of comparisons. When a BGP router has two or more paths to the same prefix, it compares them attribute by attribute until one path wins. The algorithm steps are:
Prefer the path with the highest Weight (Cisco proprietary, local to router).
Prefer the path with the highest LOCAL_PREF.
Prefer the path that was originated by the local router (via network or aggregate command).
Prefer the path with the shortest AS_PATH.
Prefer the path with the lowest ORIGIN type (IGP < EGP < incomplete).
Prefer the path with the lowest MED (Multi-Exit Discriminator).
Prefer eBGP over iBGP.
Prefer the path with the lowest IGP metric to the NEXT_HOP.
If both paths are eBGP, prefer the oldest route (received earliest).
Prefer the path from the peer with the lowest Router ID.
Prefer the path from the peer with the lowest Peer IP address.
Detailed Look at Key Attributes
#### AS_PATH
AS_PATH is a sequence of AS numbers that a route has traversed. It is used for loop prevention and path selection (shorter path preferred). The AS_PATH can be of type AS_SEQUENCE (ordered list) or AS_SET (unordered, used in aggregation). On Cisco IOS, you can manipulate AS_PATH using set as-path prepend in route maps.
#### NEXT_HOP
NEXT_HOP is the IP address of the next-hop router that should be used to reach the destination. For eBGP, the next hop is typically the IP address of the peer router. For iBGP, the next hop is the same as the eBGP next hop (by default). This attribute is crucial because BGP installs routes into the routing table only if the next hop is reachable (via an IGP or static route).
#### ORIGIN
ORIGIN indicates how BGP learned about the route. It can be:
- IGP (value 0): Route originated via the network command.
- EGP (value 1): Route learned from EGP (obsolete).
- Incomplete (value 2): Route learned via redistribution.
Cisco prefers IGP over EGP over incomplete.
#### LOCAL_PREF
LOCAL_PREF is a well-known discretionary attribute. It is used to influence outbound traffic from an AS. It is advertised to iBGP peers but not to eBGP peers (unless explicitly configured). Higher LOCAL_PREF is preferred. Default value is 100 on Cisco routers.
#### MED (Multi-Exit Discriminator)
MED is an optional non-transitive attribute. It is used to influence inbound traffic to an AS when multiple entry points exist. Lower MED is preferred. MED is typically exchanged between eBGP peers and is not propagated beyond the adjacent AS. Default MED is 0 on Cisco.
Verification Commands
Use show ip bgp to view the BGP table with attributes:
R1# show ip bgp
BGP table version is 4, local router ID is 192.168.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 192.168.2.2 0 100 0 65001 i
* 10.1.1.0/24 192.168.3.2 0 100 0 65002 65001 iUse show ip bgp prefix for detailed attributes:
R1# show ip bgp 10.1.1.0/24
BGP routing table entry for 10.1.1.0/24, version 4
Paths: (2 available, best #1, table default)
Advertised to update-groups:
1
Refresh Epoch 1
65001
192.168.2.2 from 192.168.2.2 (192.168.2.2)
Origin IGP, metric 0, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
65002 65001
192.168.3.2 from 192.168.3.2 (192.168.3.2)
Origin IGP, metric 0, localpref 100, valid, external
rx pathid: 0, tx pathid: 0Interaction with IGP
BGP relies on an IGP (or static routes) for next-hop reachability. If the NEXT_HOP is not reachable via the routing table, BGP will not install the route. This is why iBGP often requires an IGP (OSPF/EIGRP) to propagate next-hop information.
Examine BGP table for a prefix
Use `show ip bgp 10.1.1.0/24` to see all paths for a specific prefix. This command displays the attributes for each path, including AS_PATH, NEXT_HOP, MED (metric), LOCAL_PREF (locprf), Weight, and Origin. Note the asterisk (*) next to the best path. The output shows two paths: one via 192.168.2.2 with AS_PATH 65001 and one via 192.168.3.2 with AS_PATH 65002 65001. The first path is chosen as best because it has a shorter AS_PATH.
Check LOCAL_PREF configuration
LOCAL_PREF is set using a route map under BGP or via the `bgp default local-preference` command. To verify, use `show ip bgp` and look at the LocPrf column. Default is 100. If you set it higher, that path is preferred. For example, if you configure `set local-preference 200` for routes from a specific peer, those routes will have LocPrf 200 and be preferred over others with lower values.
Verify MED (metric) values
MED is shown as the Metric column in `show ip bgp`. Lower MED is better. MED is typically set on routes advertised to an eBGP peer to influence inbound traffic. Use `show ip bgp prefix` to see the metric value. For example, if you see metric 50 vs metric 100, the path with metric 50 is preferred (all else equal). Note that MED is compared only if the paths come from the same neighboring AS (by default).
Trace AS_PATH prepending
AS_PATH prepending is a common technique to make a path less preferred by artificially lengthening the AS_PATH. To verify, look at the Path column in `show ip bgp`. For example, if you see "65001 65001 65001", that means the AS 65001 has prepended itself three times. This makes the path longer and thus less preferred compared to a path with a single 65001.
Identify ORIGIN code
The ORIGIN attribute is shown as a letter in the BGP table: 'i' for IGP (network command), 'e' for EGP, '?' for incomplete (redistribution). Use `show ip bgp` and look at the last column. For example, if you see "65001 i", the origin is IGP. If you see "65001 ?", the route was redistributed. BGP prefers i over e over ?.
Determine best path using algorithm
Manually apply the BGP best path selection algorithm. List all paths for a prefix. Compare step by step: highest Weight, then highest LOCAL_PREF, then locally originated, then shortest AS_PATH, then lowest ORIGIN, then lowest MED, then eBGP over iBGP, then lowest IGP metric to next hop, then oldest route, then lowest Router ID, then lowest peer IP. Use `show ip bgp` output to gather the values. For example, if two paths have same LOCAL_PREF and AS_PATH length, compare ORIGIN: 'i' beats '?'.
Enterprise Multi-Homing Scenarios
In a typical enterprise with two ISP connections, BGP path attributes are essential for traffic engineering. For example, a company might have a primary ISP (AS 65001) and a backup ISP (AS 65002). To ensure that outbound traffic prefers the primary link, the network engineer sets a higher LOCAL_PREF (e.g., 200) on routes learned from the primary ISP via a route map. All internal BGP routers learn this LOCAL_PREF and choose the primary path for outbound traffic. If the primary link fails, routes from the backup ISP (with default LOCAL_PREF 100) become the best paths.
For inbound traffic, the company might want to influence which ISP carries traffic destined to its public IPs. The engineer can set MED on routes advertised to each ISP. For example, on the router connected to ISP1, set MED 50 for the company's prefix; on the router connected to ISP2, set MED 100. ISP1 will prefer the path with MED 50 (lower), so inbound traffic from ISP1's customers will enter via the primary link. However, MED is only a suggestion; the ISP may ignore it or have its own policies.
Another common scenario is AS_PATH prepending. If a company wants to depreference a backup link for inbound traffic, it can prepend its own AS number multiple times on routes advertised out the backup link. For example, the backup router advertises the prefix with AS_PATH "65000 65000 65000" instead of "65000". ISPs see a longer AS_PATH and prefer the primary link (shorter path).
Scale and Performance Considerations
In large networks, BGP tables can contain hundreds of thousands of routes. Path attribute processing consumes CPU and memory. Cisco routers have features like BGP route refresh and soft reconfiguration to minimize disruption when policies change. Misconfiguration can cause suboptimal routing or even blackholing. For example, if LOCAL_PREF is mis-set, traffic may flow through a slower link. If MED is not properly coordinated between ASes, inbound traffic may be unbalanced.
Real-World Misconfiguration
A common mistake is forgetting to propagate LOCAL_PREF within the AS. LOCAL_PREF is exchanged only via iBGP. If an eBGP route is learned and LOCAL_PREF is set on the border router, but iBGP is not fully meshed (or route reflectors are misconfigured), internal routers may not receive the updated LOCAL_PREF, leading to inconsistent path selection. Another issue is MED comparison across different ASes. By default, MED is compared only if the paths come from the same neighboring AS. If you want MED to be compared across ASes, you need to enable bgp always-compare-med.
Exam Objective 3.6: Path Attributes
The CCNA 200-301 exam tests your ability to identify path attributes and understand their role in the BGP best path selection process. You will not be asked to configure BGP extensively, but you must know the attributes, their order of preference, and how to interpret show ip bgp output.
Most Common Wrong Answers
Confusing LOCAL_PREF and MED: Candidates often think MED is used for outbound traffic (like LOCAL_PREF). Actually, LOCAL_PREF influences outbound traffic (from your AS), while MED influences inbound traffic (to your AS). On the exam, if the question is about which path your router chooses to send traffic to a destination, think LOCAL_PREF. If it's about which path an external AS uses to reach your networks, think MED.
Incorrect order in the best path algorithm: A frequent trap is placing AS_PATH before LOCAL_PREF or thinking Weight is after LOCAL_PREF. Remember: Weight (Cisco) > LOCAL_PREF > locally originated > AS_PATH > ORIGIN > MED > eBGP over iBGP > IGP metric > oldest > Router ID > peer IP.
Believing MED is transitive: MED is optional non-transitive. It is not passed to third-party ASes. If you see a question where MED is set on a route from AS 100 to AS 200, and AS 200 advertises that route to AS 300, the MED is not included. Many candidates assume MED stays with the route.
Misreading AS_PATH prepending: Candidates might think prepending makes a path more preferred because it adds AS numbers. Actually, longer AS_PATH is less preferred. The router wants the shortest path.
Specific Values and Commands
Default LOCAL_PREF: 100
Default MED: 0
ORIGIN codes: i (IGP), e (EGP), ? (incomplete)
Command: show ip bgp – look for LocPrf, Metric (MED), Path (AS_PATH), and Origin.
Command: show ip bgp prefix – detailed attributes.
Decision Rule for Scenario Questions
When presented with a BGP path selection scenario, write down the attributes for each path in order of the algorithm. Compare one step at a time. If a step ties, move to the next. The first attribute that differs determines the best path. For example, if one path has LOCAL_PREF 150 and another has 100, the first wins regardless of AS_PATH length. Eliminate wrong answers that skip steps (e.g., comparing AS_PATH before LOCAL_PREF).
BGP path attributes are used for loop prevention and best path selection.
The four well-known mandatory attributes: AS_PATH, NEXT_HOP, ORIGIN.
LOCAL_PREF is well-known discretionary, default 100, used for outbound traffic engineering.
MED is optional non-transitive, default 0, used for inbound traffic engineering.
Best path selection order: Weight > LOCAL_PREF > locally originated > AS_PATH > ORIGIN > MED > eBGP > IGP metric > oldest > Router ID > peer IP.
AS_PATH prepending makes a path less preferred by increasing its length.
Use `show ip bgp` to view attributes; `show ip bgp prefix` for details.
These come up on the exam all the time. Here's how to tell them apart.
LOCAL_PREF
Well-known discretionary attribute
Used to influence outbound traffic from your AS
Higher value is preferred
Default value is 100
Exchanged only within the AS (iBGP)
MED
Optional non-transitive attribute
Used to influence inbound traffic to your AS
Lower value is preferred
Default value is 0
Exchanged between eBGP peers, not propagated beyond adjacent AS
Mistake
MED is used to influence outbound traffic from your AS.
Correct
MED influences inbound traffic to your AS. It is set on routes advertised to an eBGP peer to suggest a preferred entry point.
Candidates often confuse MED with LOCAL_PREF because both are metrics. LOCAL_PREF is for outbound, MED for inbound.
Mistake
AS_PATH prepending makes a route more preferred.
Correct
Prepending increases the AS_PATH length, making the route less preferred because BGP prefers the shortest AS_PATH.
The word 'prepend' might sound like adding value, but in BGP, longer is worse.
Mistake
MED is compared even when paths come from different neighboring ASes by default.
Correct
By default, MED is compared only if the paths originate from the same neighboring AS. To compare across ASes, you must configure 'bgp always-compare-med'.
Cisco's default behavior is to avoid MED comparison across different ASes to prevent unfair influence.
Mistake
LOCAL_PREF is sent to eBGP peers.
Correct
LOCAL_PREF is exchanged only between iBGP peers. It is not advertised to eBGP peers (unless explicitly configured via 'send-community' and 'set local-preference' in outbound route map, but that's non-standard).
LOCAL_PREF is an AS-wide policy; it should not influence other ASes.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Weight is a Cisco proprietary attribute that is local to the router and not advertised to any BGP peer. It has the highest priority in the best path selection algorithm. LOCAL_PREF is a well-known discretionary attribute that is exchanged within the AS via iBGP. Weight is used to influence path selection on a single router, while LOCAL_PREF influences all routers in the AS. On the exam, if a question mentions 'Cisco proprietary' or 'local to the router', think Weight.
AS_PATH prepending artificially increases the length of the AS_PATH by repeating the local AS number. Since BGP prefers shorter AS_PATH, the prepended path becomes less preferred. This is used to depreference a backup link for inbound traffic. For example, if you prepend your AS three times, the AS_PATH length becomes 3 instead of 1, making other paths more attractive. Exam tip: When you see multiple same AS numbers in the Path column, recognize it as prepending.
By default, MED is compared only when paths come from the same neighboring AS. If you want MED to be compared across different ASes, you must configure the 'bgp always-compare-med' command under the BGP process. Without this command, MED from different ASes is considered equal. This is a common exam trap: they might show two paths from different ASes with different MEDs, and the correct answer is that MED is not compared, so the tie goes to the next attribute.
The default LOCAL_PREF is 100. You can change it globally with 'bgp default local-preference <value>' or per route using a route map. On the exam, if no LOCAL_PREF is set, assume 100. Remember that a higher LOCAL_PREF is preferred, so setting it to 200 makes that path more preferred than the default.
In iBGP, the NEXT_HOP attribute is typically the IP address of the eBGP peer that advertised the route. It is not changed when the route is propagated via iBGP (unless the next-hop-self command is used). This means that iBGP routers must have a route to that next-hop address, usually via an IGP. If the next hop is not reachable, BGP will not install the route. Exam tip: If you see a BGP route that is not installed (no '>' in show ip bgp), check if the next hop is reachable.
Use 'show ip bgp' and look at the last column. The ORIGIN code is shown as 'i' (IGP), 'e' (EGP), or '?' (incomplete). For example, '65001 i' means the route was originated via the network command. If you see '65001 ?', it was redistributed. The ORIGIN attribute is compared in step 5 of the best path algorithm (after AS_PATH).
The tie-breakers are: prefer the oldest route (step 10), then prefer the path from the peer with the lowest Router ID (step 11), then prefer the path from the peer with the lowest peer IP address (step 12). These are rarely needed but appear in exam scenarios where all other attributes are identical. The 'oldest route' tie-breaker only applies to eBGP paths.
You've just covered BGP Path Attributes — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?