Stream of Knowledge: Day 15

Day 15 — Locally Originated BGP Paths: The Best-Path Step Hidden Behind Weight

at September 12, 2026

Learning objective

Explain the Cisco best-path preference for a locally originated path, distinguish that decision step from the commonly observed Weight 32768 on local routes, and diagnose an accidental local origin that creates a blackhole.

Locally Originated BGP Paths: The Best-Path Step Hidden Behind Weight

1. Opening — “local wins” is more nuanced than it looks

Cisco's best-path documentation includes a step that prefers a path originated by BGP on the local router. Engineers often learn this as a simple rule: “local routes win.”

But Cisco also commonly assigns Weight 32768 to locally originated routes, while ordinary received paths have Weight 0. Because Weight is evaluated earlier, many labs never actually reach the explicit “locally originated” comparison step—the local route has already won on Weight.

Day 15 removes that ambiguity.

We deliberately equalize Weight so we can see why local origination is a distinct selection concept. Then we turn the same behavior into a troubleshooting scenario: an accidental network statement backed by a Null0 route causes the router to prefer a local path when the engineering intent was to use an external route.

2. What Cisco means by locally originated

Cisco best-path guidance identifies paths sourced by local BGP configuration such as network or redistribution as locally originated. Cisco also documents nuance around locally generated aggregates.

The key design point is not that local origination is “more truthful.” It simply reflects the local router's policy assertion that it originates the NLRI into BGP.

That assertion can be correct—or dangerously wrong.

A network statement does not verify business ownership, reachability of an application, or whether advertising the prefix is safe. It requires the configured route condition to be satisfied in the local routing table, as covered on Day 10.

3. Why Weight can hide this step

A typical local BGP route on Cisco appears with Weight 32768. A received route normally starts at Weight 0.

Therefore a table may look like this conceptually:

Local path      Weight 32768
Received path   Weight     0

The local path wins at the Weight step, before the algorithm reaches the separate local-origination comparison.

To isolate the next step, our lab assigns Weight 32768 to the received path too. LOCAL_PREF remains equal. Now the router must continue to the local-origination comparison.

This is a teaching technique, not a recommended production policy.

4. Scenario — Quarry Accidental Origin

Illustrative lab — not a real incident.

Topology

Service / upstream R1               Edge R2
      AS65010                       AS65020
203.0.113.0/24 ---- eBGP ---- 192.0.2.2
                                  |
                           local static Null0
                           203.0.113.0/24
                                  +
                           BGP network statement

R2 receives 203.0.113.0/24 from R1. R2 also has a local static route to Null0 and a matching BGP network statement.

For the experiment, the received route is assigned Weight 32768 so Weight ties.

Objective

Prove both BGP paths exist.
Equalize Weight.
Observe that the locally originated path remains preferred.
Treat the local origin as an injected fault.
Remove the unintended local origination and verify the eBGP path becomes usable.

5. Prerequisites

Two IOS XE-capable nodes.
Direct eBGP.
203.0.113.0/24 originated by R1 for the lab.
Console access to R2.
Understanding that Null0 provides control-plane reachability for origination but discards packets sent to it.

6. Baseline configuration

R1 — AS65010

hostname R1
interface GigabitEthernet0/0
 ip address 192.0.2.1 255.255.255.252
 no shutdown
!
ip route 203.0.113.0 255.255.255.0 Null0
!
router bgp 65010
 bgp router-id 10.10.10.1
 neighbor 192.0.2.2 remote-as 65020
 address-family ipv4 unicast
  network 203.0.113.0 mask 255.255.255.0
  neighbor 192.0.2.2 activate
 exit-address-family

R2 — AS65020

hostname R2
interface GigabitEthernet0/0
 ip address 192.0.2.2 255.255.255.252
 no shutdown
!
ip route 203.0.113.0 255.255.255.0 Null0
!
route-map EQUALIZE-WEIGHT permit 10
 set weight 32768
!
router bgp 65020
 bgp router-id 10.20.20.2
 neighbor 192.0.2.1 remote-as 65010
 address-family ipv4 unicast
  network 203.0.113.0 mask 255.255.255.0
  neighbor 192.0.2.1 activate
  neighbor 192.0.2.1 route-map EQUALIZE-WEIGHT in
 exit-address-family

This configuration is intentionally unsafe for the prefix: it creates an alternate local origin to Null0.

7. Verification before modification

On R2:

show ip bgp 203.0.113.0
show ip route 203.0.113.0
show route-map EQUALIZE-WEIGHT
show running-config | section router bgp

Evidence to capture:

one path is locally originated;
one path is learned from 192.0.2.1;
both are assigned equal Weight for this controlled experiment;
LOCAL_PREF does not create a difference;
the local path remains preferred.

Do not fabricate exact output flags. Record them from the selected IOS XE image if the lab is executed.

8. Why the locally originated path matters operationally

A local origin is a policy statement: “this router/AS can originate this NLRI.”

If that statement is backed only by a discard route and no valid forwarding path to the real service, traffic can be attracted and discarded.

This is why Day 10 treated route origination as an export boundary rather than a mere syntax exercise.

Best-path selection magnifies the risk: once a local origin exists, it can outrank an otherwise healthy external path.

9. Fault injection

Illustrative lab — not a real incident.

Lab name

Quarry Accidental Origin

Fault

The network 203.0.113.0 mask 255.255.255.0 statement and supporting Null0 route are present on R2 even though R2 is not supposed to originate the service prefix.

Symptoms

eBGP to R1 is Established;
R2 receives a valid external path;
R2 still selects the local path;
forwarding toward the prefix follows the local RIB entry to Null0 and fails.

Misdiagnosis to avoid

“BGP is ignoring the provider route.”

BGP is not ignoring it. It is selecting another eligible path according to policy and implementation rules.

10. Troubleshooting sequence

Confirm the service prefix.
Verify R1 advertises the prefix.
Verify R2 receives the eBGP path.
Inspect all BGP paths, not only the best path.
Check Weight and LOCAL_PREF.
Identify the locally originated path and its source.
Inspect network, redistribution and aggregate configuration.
Inspect the RIB entry satisfying the local origin.
Determine whether the local route represents real service reachability or only Null0.
Remove the smallest incorrect origin source and verify selection again.

11. Controlled correction

If R2 should not originate the prefix:

configure terminal
router bgp 65020
 address-family ipv4 unicast
  no network 203.0.113.0 mask 255.255.255.0
 exit-address-family
no ip route 203.0.113.0 255.255.255.0 Null0
end

If the static route is required for another valid purpose, do not remove it blindly; remove only the BGP origination statement or redesign the route source.

Expected result

The local BGP path disappears. The received eBGP path remains and can become best if it is otherwise eligible.

12. Root cause and correction

Root cause

R2 was configured to originate the same prefix that it was supposed to learn externally. The local origin was supported by a discard route, creating a blackhole.

Correction

Remove the unintended BGP origin and, where appropriate, the discard route that existed only to satisfy it.

Why it works

Once the local path no longer exists, the received path can proceed through best-path selection without competing against a local origin.

13. Post-fix verification

show ip bgp 203.0.113.0
show ip route 203.0.113.0
show ip bgp neighbors 192.0.2.1 routes

Confirm:

only the intended external path remains;
next hop is reachable;
the route is installed according to normal RIB rules;
no local advertisement of the prefix remains unless explicitly intended.

14. Rollback

Only rollback if R2 is genuinely supposed to originate the service prefix:

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

Before restoring, verify that the discard route is an intentional aggregate/origination safety mechanism rather than the original cause of service loss.

15. Production lessons

Selection lesson

Do not assume the observed “local wins” behavior is only the explicit local-origination step; default Cisco Weight often decides first.

Origination lesson

A BGP origin is a policy assertion, not proof that the application exists.

Troubleshooting lesson

When a received route looks healthy but is not selected, inspect all local route-generation mechanisms before manipulating external attributes.

Change-management lesson

network, redistribution and aggregate changes can affect path selection as well as advertisement scope.

Safety lesson

Null0 routes are useful in controlled aggregation/origination designs but become dangerous when they outlive the policy that justified them.

15A. Local `network`, redistribution and aggregate nuance

Cisco's best-path documentation distinguishes among forms of local origination. Routes generated by network or redistribution are locally sourced, while aggregate routes have their own local-generation behavior. Cisco support guidance further notes that local paths sourced by network or redistribution can be preferred over a locally generated aggregate when the comparison reaches that local-path logic.

This matters when a router has multiple local representations of the same destination or overlapping aggregate/specific policy. The correct troubleshooting question is not only “is the route local?” but also “how was this local BGP path created?”

Useful evidence includes:

show running-config | section router bgp
show ip bgp <prefix>
show ip route <prefix>
show route-map

Then trace the path source to one of these mechanisms:

exact network origination;
redistribution;
aggregate generation;
policy-driven conditional origination.

Later posts will treat aggregation and conditional advertisement at greater scale. For this day, the lesson is that local generation is not a single undifferentiated state.

15B. Why accidental local origination is a change-control problem

An accidental local origin can survive long after the engineer who created it has forgotten why the supporting static route exists. That is especially common with Null0 routes used to satisfy aggregate or advertisement requirements.

A production change review should therefore pair every local BGP origin with:

an owner;
a business reason;
the exact route that satisfies origination;
the expected forwarding behavior;
a monitoring signal for loss of the real service behind the prefix;
a rollback condition.

The route should never be treated as self-justifying merely because BGP accepts it.

16. Knowledge check

Q1

Why did the lab set the received route's Weight to 32768?

Answer: To tie the normal local-route Weight and expose the separate locally originated best-path comparison instead of letting Weight decide first.

Q2

Does a network statement prove that hosts inside the prefix are reachable?

Answer: No. It originates the NLRI when the required local routing condition is satisfied; it does not validate application reachability or prefix ownership.

Q3

What is the smallest correction if the static route is still needed but BGP must not originate the prefix?

Answer: Remove the BGP network statement while preserving the static route if that static route has a separate valid purpose.

17. Sources

RFC 4271 — *A Border Gateway Protocol 4 (BGP-4)* — Decision Process framework.
Cisco — *IP Routing Configuration Guide, Cisco IOS XE 17.18.x: Configuring BGP* — Cisco best-path ordering and local-path preference.
Cisco — *Select BGP Best-path Algorithm* — locally originated path behavior and Cisco selection details.
Cisco — *Connecting to a Service Provider Using External BGP, IOS XE 17.x* — local route examples showing Weight 32768 and path display fields.

Accessed: 2026-08-11.