Blog

BGP for CCNP ENCOR, Part 3: Advertising Routes and Path Attributes

A BGP session that reaches Established has accomplished nothing on its own. Routes still have to be put into BGP deliberately, and every route carries a set of path attributes that describe where it came from and how much this network likes it. Those attributes are the raw material the best path algorithm consumes, which makes this post the necessary groundwork for part 4.

This is part 3 of a four-part BGP series for CCNP ENCOR 350-401 v1.2. Part 1 covered fundamentals and eBGP versus iBGP, part 2 covered neighbor relationships and the finite state machine, and part 4 covers the best path selection algorithm.

Getting Routes Into BGP

BGP never advertises anything by accident. There are four ways to originate a prefix, and they differ in ways that matter.

1. The network Statement

This is the most misunderstood command in BGP, because it does not mean what the identically named OSPF and EIGRP commands mean.

router bgp 65001
 address-family ipv4 unicast
  network 10.1.1.0 mask 255.255.255.0
OSPF / EIGRP network BGP network
Meaning Enable the protocol on matching interfaces Advertise this exact prefix if it is already in the RIB
Argument A wildcard-matched range One specific prefix
Mask Wildcard, inexact match allowed Must match the routing table exactly
If no match Protocol simply not enabled there Nothing is advertised, silently

Two rules follow, and between them they account for most “BGP is up but advertising nothing” cases:

  • The prefix must already exist in the routing table, from any source — connected, static, or an IGP. BGP advertises what the router already knows; it does not create reachability.
  • The mask must match exactly. network 10.1.0.0 mask 255.255.0.0 advertises nothing if the RIB holds only 10.1.1.0/24. Omitting mask entirely makes IOS assume the classful mask, which is almost never what was intended.

A common production pattern is to pair the network statement with a static route to Null0, guaranteeing the prefix is always in the RIB and therefore always advertised, even if the specific subnets behind it go away:

ip route 203.0.113.0 255.255.255.0 Null0
!
router bgp 65001
 address-family ipv4 unicast
  network 203.0.113.0 mask 255.255.255.0

Routes originated this way carry an ORIGIN of IGP, shown as i at the end of the path.

2. Redistribution

router bgp 65001
 address-family ipv4 unicast
  redistribute ospf 1 route-map OSPF-TO-BGP

Redistribution pulls in everything the source protocol knows, which is exactly why it is dangerous: redistributing an IGP into BGP without a filter can leak the entire internal topology to a provider. Always attach a route-map.

Redistributed routes carry an ORIGIN of incomplete, shown as ?. That is not cosmetic — origin is step 5 of the best path algorithm, and ? loses to i, so a redistributed route can lose to an otherwise identical route originated with a network statement.

3. Aggregation

router bgp 65001
 address-family ipv4 unicast
  aggregate-address 10.1.0.0 255.255.0.0 summary-only
Keyword Effect
(none) Advertise the summary and all component routes
summary-only Advertise the summary and suppress the components
as-set Build an AS_SET from the components’ paths, preserving loop prevention
suppress-map Suppress only selected components

At least one component route must already be in the BGP table, or the aggregate is never generated. Without as-set, the summary is advertised with an empty AS_PATH beyond the local AS and is flagged ATOMIC_AGGREGATE, meaning path information was lost — which in turn means the aggregating router could accept a route back that it originated.

4. Default Origination

router bgp 65001
 address-family ipv4 unicast
  neighbor 192.0.2.2 default-originate

Sends 0.0.0.0/0 to that one neighbor. Unlike OSPF’s equivalent, this does not require a default route to exist locally unless a route-map condition is attached. The alternative, network 0.0.0.0, does require one in the RIB.

The NEXT_HOP Attribute

NEXT_HOP deserves its own section because its rules are the source of the single most common iBGP failure.

Situation What happens to NEXT_HOP
Advertised to an eBGP peer Rewritten to the advertising router’s interface address
Advertised to an iBGP peer Left unchanged
Both peers on the same multi-access segment Preserved as the original third-party address, to avoid a needless extra hop
Default iBGP behaviourR3AS 65002R1AS 65001R2AS 65001eBGPiBGP192.0.2.0/30203.0.113.0/24next-hop 192.0.2.2R1 sees:next-hop 192.0.2.2R2 sees:✗ inaccessible — valid but never bestWith next-hop-self on R1R3AS 65002R1AS 65001R2AS 65001eBGPiBGP192.0.2.0/30203.0.113.0/24next-hop 192.0.2.2R1 sees:next-hop 1.1.1.1R2 sees:✓ reachable — installed in the RIBiBGP leaves NEXT_HOP unchanged, so R2 is told to use an address on the provider link that its IGP never advertises.
Figure 1 — The iBGP next-hop problem. next-hop-self rewrites the next hop to the advertising router, which internal routing can actually reach.

The iBGP rule creates the problem. R1 learns 203.0.113.0/24 from an external peer at 192.0.2.2 and passes it to R2 over iBGP with the next hop still set to 192.0.2.2 — an address on the provider’s link that R2 has no route to. The result is distinctive:

R2# show bgp ipv4 unicast
     Network          Next Hop            Metric LocPrf Weight Path
 *   203.0.113.0/24   192.0.2.2                0    100      0 65002 i

Note what is missing: there is a * but no >. The path is valid but is not the best path, because the next hop is unreachable, so it never enters the routing table. show bgp ipv4 unicast 203.0.113.0/24 states it plainly:

  65002
    192.0.2.2 (inaccessible) from 1.1.1.1 (1.1.1.1)
      Origin IGP, localpref 100, valid, internal

There are three fixes, and only one is correct in most designs:

Fix Assessment
neighbor x.x.x.x next-hop-self The standard answer. R1 rewrites the next hop to its own address as it advertises internally.
Advertise the external link into the IGP Works, but injects provider addressing into your IGP. Avoid.
A route-map setting ip next-hop Valid but heavy-handed for this purpose. 
router bgp 65001
 address-family ipv4 unicast
  neighbor 2.2.2.2 next-hop-self

Apply it on the router with the external session, on every iBGP neighbor it feeds. It affects only advertisements sent after it is applied, so a soft clear is needed: clear bgp ipv4 unicast * soft out.

Path Attribute Categories

Every BGP attribute falls into one of four categories, defined by two questions: must every implementation understand it, and should a router pass it on if it does not?

Must every implementation understand it?Passed on ifnot understood?YES — well-knownNO — optionalWell-known mandatoryORIGIN · AS_PATH · NEXT_HOPin every UPDATEOptional transitiveAGGREGATOR · COMMUNITYpassed on, flagged partialWell-known discretionaryLOCAL_PREF · ATOMIC_AGGREGATEsupported, may be absentOptional non-transitiveMED · ORIGINATOR_ID · CLUSTER_LISTsilently droppedThe distinction that matters: a transitive attribute survives a router that does not understand it — a non-transitive one does not.That is exactly why MED never travels beyond the neighbouring AS.
Figure 2 — The four path attribute categories, defined by whether support is required and whether an unsupported attribute is forwarded.
Category Rule Members
Well-known mandatory Every implementation must support it; must be in every UPDATE ORIGIN, AS_PATH, NEXT_HOP
Well-known discretionary Must be supported, but need not be present LOCAL_PREF, ATOMIC_AGGREGATE
Optional transitive May be unsupported; passed on regardless, flagged partial AGGREGATOR, COMMUNITY
Optional non-transitive May be unsupported; silently dropped if not understood MED, ORIGINATOR_ID, CLUSTER_LIST

The exam-relevant detail is the difference between the two optional categories. A transitive attribute survives a router that does not understand it; a non-transitive one does not. This is precisely why MED does not propagate beyond the neighbouring AS.

The Attributes That Decide Paths

Six attributes account for nearly all path selection. Their scope — how far each one travels — matters as much as their value.

AS 65001 (you)AS 65002AS 65003 and beyondR1R2WEIGHTthis router onlyLOCAL_PREFthe local AS onlyMEDone neighbouring ASAS_PATHeverywhere, globallyChoosing an attribute whose scope does not reach the decision point is the most common BGP policy error.Setting LOCAL_PREF outbound toward an eBGP peer does nothing at all.
Figure 3 — How far each attribute travels. Scope decides which lever can influence a given routing decision.

WEIGHT — Cisco-proprietary, one router only

Higher is better Default 0 for learned routes, 32768 for locally originated
Scope Never advertised. Local to the router it is configured on.
Decision order Step 1 — beats everything else 
! Per-neighbor: everything from this peer gets weight 200
router bgp 65001
 address-family ipv4 unicast
  neighbor 192.0.2.2 weight 200

! Selective, via route-map
route-map SET-WEIGHT permit 10
 match ip address prefix-list IMPORTANT
 set weight 500
route-map SET-WEIGHT permit 20

Weight is not a real BGP attribute — it is a Cisco implementation detail that exists only in the local router’s memory. That makes it the right tool for influencing one router’s outbound choice, and the wrong tool for anything requiring consistency across an AS.

LOCAL_PREF — consistent across the AS

Higher is better Default 100
Scope Sent to iBGP peers only; never crosses an eBGP boundary
Decision order Step 2

LOCAL_PREF is the primary tool for controlling how your own AS sends traffic outbound. Because it propagates to every internal router, the whole AS agrees on the exit point:

route-map PREFER-ISP-A permit 10
 set local-preference 200
!
router bgp 65001
 address-family ipv4 unicast
  neighbor 192.0.2.2 route-map PREFER-ISP-A in

Applied inbound from the provider, this makes every router in AS 65001 prefer that provider for those prefixes. Setting it outbound toward an eBGP peer is pointless — the attribute is stripped at the boundary.

AS_PATH — global reach, shortest wins

Shorter is better Counts AS numbers, not routers or links
Scope Global. Travels with the route everywhere.
Decision order Step 4

Because it is the only widely honoured attribute that crosses AS boundaries, AS_PATH prepending is the standard lever for influencing inbound traffic when multihomed:

route-map PREPEND-OUT permit 10
 set as-path prepend 65001 65001 65001
!
router bgp 65001
 address-family ipv4 unicast
  neighbor 192.0.2.2 route-map PREPEND-OUT out

Two caveats worth stating. Prepending is a hint, not a guarantee: any AS in the path may override it with LOCAL_PREF, which is evaluated two steps earlier. And AS_SET counts as a single entry regardless of how many AS numbers it contains.

The four path segment types are worth recognizing: AS_SEQUENCE (ordered, the normal case), AS_SET (unordered, from aggregation, shown in braces), and the confederation variants AS_CONFED_SEQUENCE and AS_CONFED_SET, shown in parentheses.

ORIGIN — how the route entered BGP

Code Meaning Source Preference
i IGP network statement Best
e EGP Legacy EGP; effectively extinct Middle
? Incomplete Redistribution Worst

The ordering IGP < EGP < Incomplete is step 5 of the algorithm. It rarely decides anything in practice, but it is a favourite exam question precisely because it explains why a redistributed route can lose to one that was originated with a network statement.

MED — a suggestion to the neighbouring AS

Lower is better Default 0; appears in the Metric column
Scope Sent to the neighbouring AS, but not passed on beyond it
Decision order Step 6
Compared Only between paths from the same neighbouring AS, by default

MED is how you ask a neighbouring AS to prefer one of your entry points over another when you have two links to the same provider:

route-map SET-MED permit 10
 set metric 50
!
router bgp 65001
 address-family ipv4 unicast
  neighbor 192.0.2.2 route-map SET-MED out

Three things make MED unreliable in practice, and all three are examinable. It is lower-is-better, inverted relative to weight and local-pref. It is only compared between paths from the same AS unless bgp always-compare-med is configured. And the neighbouring AS is under no obligation to honour it at all — most providers reset it on ingress.

COMMUNITY — a tag, not a preference

A community is a 32-bit tag attached to a route, conventionally written ASN:value. It changes nothing by itself; its value is that it lets one AS signal intent to another, which the receiving AS acts on with its own policy.

Well-known community Effect
no-export Do not advertise beyond the receiving AS
no-advertise Do not advertise to any peer at all
local-AS Do not advertise outside the local confederation sub-AS
internet Advertise freely (the default) 
route-map TAG-ROUTES permit 10
 set community 65001:100 no-export
!
router bgp 65001
 address-family ipv4 unicast
  neighbor 192.0.2.2 route-map TAG-ROUTES out
  neighbor 192.0.2.2 send-community

send-community is required — IOS does not transmit communities by default, and forgetting it is why a correctly written community policy appears to do nothing.

Setting Attributes with Route-Maps

Every attribute manipulation goes through a route-map, and two rules govern them:

  • Sequences are evaluated in order, first match wins.
  • There is an implicit deny at the end. In a BGP context, deny means the route is filtered out entirely — so a route-map that sets an attribute on some routes will silently discard all the others unless a permissive final sequence exists.
ip prefix-list CUSTOMER-ROUTES seq 5 permit 203.0.113.0/24
!
route-map SET-ATTRIBUTES permit 10
 match ip address prefix-list CUSTOMER-ROUTES
 set local-preference 200
 set community 65001:100
!
route-map SET-ATTRIBUTES permit 20      <-- permit everything else unchanged
!
router bgp 65001
 address-family ipv4 unicast
  neighbor 192.0.2.2 route-map SET-ATTRIBUTES in
  neighbor 192.0.2.2 send-community

The empty permit 20 is the single most commonly forgotten line in BGP policy, and omitting it turns an attribute-setting policy into an accidental filter that drops everything not matched.

Which Attribute for Which Job

Goal Attribute Direction Why
Influence outbound traffic, one router WEIGHT in Local only; highest precedence
Influence outbound traffic, whole AS LOCAL_PREF in Propagates to all iBGP peers
Influence inbound traffic, different providers AS_PATH prepend out Only lever that travels globally
Influence inbound traffic, same provider MED out Compared between paths from one AS
Signal intent to another AS COMMUNITY out Provider acts on its own policy

The pattern is worth internalizing: inbound policy controls outbound traffic, and outbound policy controls inbound traffic. You set attributes on routes coming in to decide where you send packets; you modify routes going out to influence where others send packets to you.

Verification

R1# show bgp ipv4 unicast 203.0.113.0/24
BGP routing table entry for 203.0.113.0/24, version 7
Paths: (2 available, best #1, table default)
  Advertised to update-groups: 2
  Refresh Epoch 1
  65002 65010
    192.0.2.2 from 192.0.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 200, valid, external, best
      Community: 65001:100
  Refresh Epoch 1
  65003 65020 65010
    198.51.100.2 from 198.51.100.2 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, external

This is the most useful single command in BGP. It lists every path, states which is best, and prints each path’s attributes so the decision can be reconstructed by hand. Here path 1 wins at step 2 on LOCAL_PREF 200 versus 100 — the algorithm never reaches AS_PATH.

show bgp ipv4 unicast                                  ! the whole table
show bgp ipv4 unicast neighbors 192.0.2.2 advertised-routes
show bgp ipv4 unicast neighbors 192.0.2.2 received-routes   ! needs soft-reconfiguration
show bgp ipv4 unicast community 65001:100
show bgp ipv4 unicast filter-list 1                    ! matching an AS-path ACL
show bgp ipv4 unicast regexp _65010$                   ! originated by AS 65010
show ip bgp summary

Worked Examples

Example 1 — Why the network Statement Advertises Nothing

R1# show run | section bgp
 network 172.16.0.0 mask 255.255.0.0

R1# show ip route 172.16.0.0
     172.16.0.0/24 is subnetted, 3 subnets
C       172.16.1.0 is directly connected, GigabitEthernet0/1
C       172.16.2.0 is directly connected, GigabitEthernet0/2
C       172.16.3.0 is directly connected, GigabitEthernet0/3

R1# show bgp ipv4 unicast
(no 172.16.0.0 entry)

There is no 172.16.0.0/16 route in the RIB — only three /24s — so the exact-match requirement fails. Two valid fixes:

! Option A — advertise what actually exists
network 172.16.1.0 mask 255.255.255.0
network 172.16.2.0 mask 255.255.255.0
network 172.16.3.0 mask 255.255.255.0

! Option B — create the summary, then advertise it
ip route 172.16.0.0 255.255.0.0 Null0
network 172.16.0.0 mask 255.255.0.0

Example 2 — Tracing the Next-Hop Failure

R2# show bgp ipv4 unicast
     Network          Next Hop            Metric LocPrf Weight Path
 *   203.0.113.0/24   192.0.2.2                0    100      0 65002 i

R2# show ip route 192.0.2.2
% Network not in table

The path is valid (*) but not best (no >), because BGP will not select a path whose next hop it cannot reach. On R1, which holds the external session:

router bgp 65001
 address-family ipv4 unicast
  neighbor 2.2.2.2 next-hop-self
!
R1# clear bgp ipv4 unicast * soft out

! R2 afterwards:
 *>  203.0.113.0/24   1.1.1.1                  0    100      0 65002 i

Example 3 — Attribute Scope in One Diagram’s Worth of Text

AS 65001 sets on a route received from AS 65002:

  weight 500        → visible on this router only
  local-pref 200    → visible on every router inside AS 65001
  MED 50 (outbound) → visible to AS 65002 only, not beyond
  prepend 65001 ×3  → visible to every AS in the world
  community 65001:1 → visible wherever send-community allows it

Choosing the wrong attribute for the scope is the most common BGP policy error. Setting local-pref outbound toward an eBGP peer does nothing at all, because the attribute is discarded at the AS boundary.

Lab Exercises

These run on CML, EVE-NG, GNS3, or physical gear with IOSv, CSR1000v, or Catalyst 8000v. Attempt each task before opening the answer.

Lab 1 — Origination Methods and ORIGIN Codes

Topology: R1 (AS 65001) peers with R2 (AS 65002) on 192.0.2.0/30. R1 has Lo0 = 10.1.1.1/24, Lo1 = 10.1.2.1/24, and OSPF running with 172.16.5.0/24 learned from elsewhere.

Tasks:

  1. Advertise 10.1.1.0/24 with a network statement and note its origin code on R2.
  2. Redistribute OSPF into BGP and note the origin code of 172.16.5.0/24 on R2.
  3. Attempt network 10.1.0.0 mask 255.255.0.0 and explain the result.
  4. Make that summary advertise successfully without changing the interfaces.
  5. Create an aggregate for 10.1.0.0/16 with summary-only and describe what R2 sees.
Show answer 
! Task 1
router bgp 65001
 address-family ipv4 unicast
  network 10.1.1.0 mask 255.255.255.0

R2# show bgp ipv4 unicast
 *>  10.1.1.0/24      192.0.2.1    0   0  65001 i      <-- origin i (IGP)

! Task 2
router bgp 65001
 address-family ipv4 unicast
  redistribute ospf 1

R2# show bgp ipv4 unicast
 *>  172.16.5.0/24    192.0.2.1    0   0  65001 ?      <-- origin ? (incomplete)

Task 3: Nothing is advertised. No 10.1.0.0/16 route exists in R1’s routing table — only the two /24s — and the network statement requires an exact match.

! Task 4
ip route 10.1.0.0 255.255.0.0 Null0

R2# show bgp ipv4 unicast
 *>  10.1.0.0/16      192.0.2.1    0   0  65001 i

! Task 5
router bgp 65001
 address-family ipv4 unicast
  aggregate-address 10.1.0.0 255.255.0.0 summary-only

Task 5: R2 sees only 10.1.0.0/16; the component /24s are suppressed. On R1 they remain in the table marked with s for suppressed. Dropping summary-only would advertise the aggregate and all components together.

Lab 2 — The iBGP Next-Hop Problem

Topology: R1 and R2 are iBGP peers in AS 65001 on loopbacks 1.1.1.1 and 2.2.2.2, with OSPF providing internal reachability. R1 also has an eBGP session to R3 (AS 65002) on 192.0.2.0/30, from which it learns 203.0.113.0/24.

Tasks:

  1. Confirm R1 has 203.0.113.0/24 as its best path.
  2. Confirm R2 receives it, and determine whether it is usable.
  3. Identify the exact reason from the BGP table output.
  4. Fix it with the standard command and verify.
  5. Describe a second way to fix it and explain why it is inferior.
Show answer 
! Task 1 — R1
R1# show bgp ipv4 unicast 203.0.113.0/24
  65002
    192.0.2.2 from 192.0.2.2 (3.3.3.3)
      Origin IGP, localpref 100, valid, external, best

! Tasks 2 and 3 — R2
R2# show bgp ipv4 unicast
 *   203.0.113.0/24   192.0.2.2   0   100   0 65002 i     <-- valid, NOT best

R2# show bgp ipv4 unicast 203.0.113.0/24
    192.0.2.2 (inaccessible) from 1.1.1.1 (1.1.1.1)

Task 3: (inaccessible) is the diagnostic. iBGP did not change the next hop, so R2 was told to use 192.0.2.2 — an address on the external link that OSPF does not advertise. BGP refuses to select a path with an unreachable next hop, so it is valid but never best and never enters the RIB.

! Task 4 — on R1
router bgp 65001
 address-family ipv4 unicast
  neighbor 2.2.2.2 next-hop-self
R1# clear bgp ipv4 unicast * soft out

! R2 now:
 *>  203.0.113.0/24   1.1.1.1     0   100   0 65002 i

Task 5: Advertising 192.0.2.0/30 into OSPF would also work, because R2 would then have a route to the next hop. It is inferior because it injects the provider’s link addressing into your IGP, grows the IGP for no benefit, and has to be repeated for every external link. next-hop-self keeps provider addressing out of the internal routing domain entirely.

Lab 3 — Local Preference and Weight

Topology: R1 in AS 65001 has two eBGP sessions — to R2 (AS 65002) on 192.0.2.0/30 and to R3 (AS 65003) on 198.51.100.0/30. Both advertise 203.0.113.0/24. R1 also has an iBGP peer R4 inside AS 65001.

Tasks:

  1. Determine which path R1 selects by default and at which step of the algorithm.
  2. Use LOCAL_PREF to force the path through R3, and verify on both R1 and R4.
  3. Remove that policy and achieve the same result on R1 using WEIGHT.
  4. Check R4 again and explain the difference.
  5. State which approach is correct for an AS-wide policy and why.
Show answer 
! Task 1 — both have AS_PATH length 1, so the tie breaks later,
! typically at step 11 (lowest router-ID) or step 13 (lowest neighbor address).
R1# show bgp ipv4 unicast 203.0.113.0/24

! Task 2
route-map PREFER-R3 permit 10
 set local-preference 200
!
router bgp 65001
 address-family ipv4 unicast
  neighbor 198.51.100.2 route-map PREFER-R3 in
!
R1# clear bgp ipv4 unicast * soft in

R1# show bgp ipv4 unicast 203.0.113.0/24
    198.51.100.2 ... localpref 200, valid, external, best
R4# show bgp ipv4 unicast 203.0.113.0/24
    198.51.100.2 ... localpref 200, valid, internal, best   <-- R4 agrees
! Task 3
router bgp 65001
 address-family ipv4 unicast
  no neighbor 198.51.100.2 route-map PREFER-R3 in
  neighbor 198.51.100.2 weight 500
R1# clear bgp ipv4 unicast * soft in

Task 4: R1 now prefers R3 because weight 500 beats 0 at step 1. But R4 reverts to whatever it chose before — weight is never advertised, so R4 never learns about it. The AS is now inconsistent: R1 exits via R3 while R4 may exit via R2.

Task 5: LOCAL_PREF is correct for AS-wide policy, because it is carried to every iBGP peer and the whole AS agrees on the exit point. Weight is appropriate only when the intent is genuinely local to one router, such as a single border router with a temporary preference.

Lab 4 — AS_PATH Prepending, MED, and Communities

Topology: R1 (AS 65001) has two links to the same provider AS 65002 — a primary on 192.0.2.0/30 and a backup on 198.51.100.0/30 — and advertises 203.0.113.0/24.

Tasks:

  1. Advertise the prefix out both links and confirm the provider sees two paths.
  2. Use MED to make the provider prefer the primary link, and explain why MED is valid here.
  3. Replace MED with AS_PATH prepending on the backup and compare the two approaches.
  4. Tag the prefix with no-export on the backup link and describe the effect.
  5. Explain what breaks if send-community is omitted.
Show answer 
! Task 2 — lower MED wins
route-map MED-PRIMARY permit 10
 set metric 50
route-map MED-BACKUP permit 10
 set metric 200
!
router bgp 65001
 address-family ipv4 unicast
  neighbor 192.0.2.2    route-map MED-PRIMARY out
  neighbor 198.51.100.2 route-map MED-BACKUP  out

Task 2: MED is valid because both paths come from the same neighbouring AS. By default MED is only compared between paths from one AS, so it would do nothing if the two links went to different providers.

! Task 3
route-map PREPEND-BACKUP permit 10
 set as-path prepend 65001 65001 65001
!
router bgp 65001
 address-family ipv4 unicast
  no neighbor 198.51.100.2 route-map MED-BACKUP out
  neighbor 198.51.100.2 route-map PREPEND-BACKUP out

Task 3: Prepending works with different providers and travels globally, but it is evaluated at step 4 — after LOCAL_PREF at step 2 — so any AS that sets a local preference overrides it. MED is evaluated later still (step 6) but is often ignored or reset by providers. Prepending is the more dependable lever in practice; MED is the more precise one when both links go to one provider that honours it.

! Task 4
route-map BACKUP-NOEXPORT permit 10
 set as-path prepend 65001 65001 65001
 set community no-export
!
router bgp 65001
 address-family ipv4 unicast
  neighbor 198.51.100.2 route-map BACKUP-NOEXPORT out
  neighbor 198.51.100.2 send-community

Task 4: AS 65002 accepts the prefix and can use it, but will not advertise it to any other AS. The route becomes reachable only from within the provider — a genuine backup that the wider internet never sees via that link.

Task 5: Without send-community, IOS strips the community before transmitting. The route-map still appears correct in the configuration and the prepending still works, but the no-export tag never reaches the provider and the intended containment silently does not happen. This is one of the most common BGP policy bugs.

Common Mistakes and Exam Traps

  • BGP’s network statement needs an exact mask match and a route already in the RIB.
  • Redistributed routes get origin ?, which loses to i at step 5.
  • iBGP does not change the next hop — hence next-hop-self.
  • A valid path (*) with no > is usually an unreachable next hop.
  • Weight is local and never advertised; local-pref is AS-wide but never crosses eBGP.
  • MED is lower-is-better, inverted from weight and local-pref.
  • MED is only compared between paths from the same AS unless always-compare-med is set.
  • Communities need send-community or they are silently stripped.
  • Route-maps have an implicit deny — always add a trailing permissive sequence.
  • Inbound policy shapes outbound traffic and vice versa.
  • aggregate-address needs a component route in the BGP table to generate anything.

Check Your Understanding

Ten questions on the material in Part 3. Each answer is explained as you go, so a wrong answer is worth as much as a right one.

1. 

What two conditions must be met for a BGP network statement to advertise a prefix?

2. 

Which ORIGIN code is assigned to routes that entered BGP through redistribution?

3. 

What happens to the NEXT_HOP attribute when a route is advertised to an iBGP peer?

4. 

Which command is the standard fix for an unreachable iBGP next hop?

5. 

Into which attribute category does MED fall, and what is the consequence?

6. 

What is the scope of the WEIGHT attribute?

7. 

Which attribute is the correct tool for making an ENTIRE autonomous system prefer one exit point?

8. 

For the MED attribute, which value is preferred?

9. 

A route-map correctly sets a community, but the neighbouring AS never receives it. What is missing?

10. 

A route-map sets local preference on matched routes. What happens to routes that do not match?

1 out of 1

Summary

Routes enter BGP through the network statement (exact mask, must already be in the RIB, origin i), redistribution (origin ?, always filter it), aggregation, or default origination. Each carries path attributes divided into well-known mandatory, well-known discretionary, optional transitive, and optional non-transitive — the last of which is why MED never travels beyond the neighbouring AS.

Scope is what makes an attribute the right or wrong tool. Weight never leaves the router, local-pref never leaves the AS, MED reaches exactly one AS, and AS_PATH goes everywhere. Set attributes inbound to control where your traffic exits, and outbound to influence where other people’s traffic enters.

The final post puts all of this to work: the complete best path selection algorithm, step by step, with a worked tie-break at every level.

Tags: , , ,

Leave a Reply