Day 7 — Inside a BGP UPDATE: Withdrawn Routes, Path Attributes and IPv4 NLRI

at

Learning objective

Decode the logical sections of a base IPv4-unicast BGP UPDATE, explain how IPv4 NLRI represents prefixes, and distinguish route advertisements or withdrawals from BGP session failures.


Inside a BGP UPDATE:


1. Opening — the session can be healthy while the route is gone

A green BGP neighbor status does not mean the forwarding information you care about is still present.

BGP separates session health from routing information. Once two speakers reach Established, they can exchange UPDATE messages for hours or months without re-establishing the TCP session. One UPDATE might advertise a new prefix. Another might replace attributes for a previously known prefix. A later UPDATE might withdraw that prefix while the peer remains Established.

This is why mature troubleshooting starts with two separate questions:

  1. Is the BGP session healthy?
  2. What happened to the specific NLRI?

Day 6 introduced UPDATE as the message that carries reachability. Day 7 opens that message and follows a single documentation prefix through advertisement, withdrawal and verification.

2. What RFC 4271 puts inside a base IPv4-unicast UPDATE

For the original IPv4-unicast BGP-4 encoding, RFC 4271 defines an UPDATE message containing three logical information areas after the common BGP header:

  • Withdrawn Routes
  • Path Attributes
  • Network Layer Reachability Information (NLRI)

Length fields identify the boundaries between these variable-length portions.

The important mental model is:

> Withdrawn prefixes say what is no longer reachable; path attributes describe the path properties associated with newly advertised/re-advertised NLRI; NLRI identifies the destination prefixes being announced.

Modern multiprotocol BGP extends this model using attributes such as MP_REACH_NLRI and MP_UNREACH_NLRI. Those mechanisms are addressed on Day 8 and again in the MP-BGP module. Do not assume every modern address family encodes reachability in the final base-NLRI field.

3. NLRI is reachability, not a complete route by itself

NLRI means Network Layer Reachability Information.

In base IPv4 unicast, an NLRI entry identifies an IPv4 prefix by carrying a prefix length followed by enough prefix bits to identify the network. For example, a /24 needs 24 significant prefix bits. Conceptually, 203.0.113.0/24 can therefore be represented by a length of 24 and the three significant address octets 203.0.113.

But the prefix alone is not the complete BGP path.

A usable BGP path also depends on attributes such as:

  • ORIGIN;
  • AS_PATH;
  • NEXT_HOP;
  • LOCAL_PREF where applicable;
  • MED where applicable;
  • communities and other extensions.

This separation explains why the same destination prefix can exist as multiple candidate BGP paths with different attributes.

4. One UPDATE can carry more than one prefix

BGP can encode multiple NLRI entries in an UPDATE when those routes share the same attribute set.

Operationally, this matters because a single packet capture frame may contain several routes. When troubleshooting, do not stop after seeing the expected AS_PATH or NEXT_HOP. Confirm that the actual target prefix appears in the NLRI or withdrawn section you are inspecting.

Likewise, a high UPDATE-message counter does not mean every UPDATE is relevant to the failing service. Scope packet analysis to:

  • the affected peer;
  • the affected address family;
  • the affected prefix or prefix range;
  • the incident time window.

5. Explicit withdrawal versus implicit replacement

A route can cease being usable in more than one way.

Explicit withdrawal

The sender identifies a previously advertised prefix as withdrawn. The receiver removes the path learned from that peer, subject to local processing and any alternate paths.

Re-advertisement with changed attributes

The sender can advertise the same NLRI with a changed attribute set. From the operator's perspective the route may still exist, but its preference or forwarding consequence can change.

This is why an incident statement such as “BGP withdrew the route” should be based on evidence. If the prefix still appears from the same peer with different attributes, the problem is not an explicit withdrawal.

6. UPDATE processing is policy-sensitive

Receiving an UPDATE on the wire does not guarantee that the route becomes a usable best path.

A simplified receive pipeline is:

  1. receive and validate the BGP UPDATE;
  2. interpret the NLRI and attributes;
  3. apply inbound policy;
  4. retain eligible path information according to implementation behavior;
  5. run best-path selection;
  6. attempt installation into the routing table;
  7. resolve the next hop;
  8. program forwarding where appropriate.

Therefore a packet capture proving that an UPDATE arrived answers only one part of the investigation.

A route might be:

  • received but rejected by policy;
  • accepted but not best;
  • best in BGP but not installed in the RIB;
  • installed in the RIB but unusable because forwarding resolution fails elsewhere.

Future troubleshooting posts will separate each stage.

7. Error handling: malformed UPDATE does not always mean “reset everything”

RFC 7606 revised BGP UPDATE error handling because resetting an entire BGP session for some malformed route information can create unnecessary collateral impact.

Depending on the exact error, modern handling can include strategies such as treating affected NLRI as withdrawn or discarding a problematic attribute rather than always terminating the session.

Two cautions are essential:

  • RFC 7606 does not mean every malformed UPDATE is harmless.
  • Actual behavior depends on the error category and implementation support.

For production troubleshooting, preserve the original logs/capture and identify the precise error rather than relying on a generic “malformed UPDATE” label.

8. Scenario — Cedar Edge route withdrawal

Illustrative lab — not a real incident.

Objective

AS 65010 originates 203.0.113.0/24 toward AS 65020. The lab first proves successful advertisement. We then remove only the BGP origination statement. The BGP session must remain Established while the prefix is withdrawn.


Inside a BGP UPDATE: Withdrawn Routes, Path Attributes and IPv4 NLRI
Inside a BGP UPDATE: Withdrawn Routes, Path Attributes and IPv4 NLRI


Topology

203.0.113.0/24
     |
    R1
 AS 65010
192.0.2.1/30
     |
     | eBGP
     |
192.0.2.2/30
    R2
 AS 65020

Success criteria

Before modification:

  • BGP is Established.
  • R1 originates 203.0.113.0/24.
  • R2 has a valid path for the prefix.

After modification:

  • the BGP session remains Established;
  • R2 no longer has the path from R1;
  • packet capture, if used, shows route withdrawal behavior rather than a TCP/session reset.

9. Prerequisites

  • Cisco IOS XE 17.18.x documentation baseline.
  • Two IOS XE-capable lab nodes.
  • One Ethernet interface per router for the eBGP link.
  • Optional loopback or Null0-backed static prefix for local origination.
  • Packet capture on the inter-router link if the virtual environment permits it.
  • Independent console/management access before fault injection.

The exact virtual image should be validated before claiming observed output.

10. Baseline configuration

R1 — AS 65010

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 — AS 65020

hostname R2
!
interface GigabitEthernet0/0
 ip address 192.0.2.2 255.255.255.252
 no shutdown
!
router bgp 65020
 bgp router-id 10.20.20.2
 neighbor 192.0.2.1 remote-as 65010
 address-family ipv4 unicast
  neighbor 192.0.2.1 activate
 exit-address-family

The static route on R1 exists only to make the documentation prefix present in the local routing table so the BGP network statement can originate it. Traffic to that prefix is intentionally discarded by Null0 in this control-plane-focused lab.

11. Verification before modification

R1

show ip route 203.0.113.0
show ip bgp 203.0.113.0
show ip bgp neighbors 192.0.2.2 advertised-routes
show ip bgp summary

R2

show ip bgp 203.0.113.0
show ip route 203.0.113.0
show ip bgp neighbors 192.0.2.1
show ip bgp summary

What the evidence must prove

  • show ip bgp summary proves the peer is Established and shows prefix/accounting information relevant to the platform.
  • show ip bgp 203.0.113.0 proves whether the NLRI is present in the local BGP table.
  • show ip route 203.0.113.0 checks RIB installation separately from BGP-table presence.
  • advertised-routes output helps prove what R1 is sending, subject to platform/output support.

Do not substitute session state for prefix verification.

12. Controlled modification — withdraw one prefix without dropping the peer

On R1:

configure terminal
router bgp 65010
 address-family ipv4 unicast
  no network 203.0.113.0 mask 255.255.255.0
 end

Expected control-plane result

R1 stops originating the prefix through this BGP network statement. R2 should remove the path learned from R1 after processing the withdrawal.

Expected session result

The eBGP session remains Established.

Expected packet evidence

If captured, the route change should appear in UPDATE processing rather than as a TCP teardown followed by OPEN/KEEPALIVE session establishment.

13. Fault injection

Illustrative lab — not a real incident.

Lab name

Cedar Edge — Missing NLRI

Fault

Remove the BGP network 203.0.113.0 mask 255.255.255.0 statement from R1 while leaving the static route and neighbor configuration intact.

Initial symptom

A monitoring system reports that 203.0.113.0/24 has disappeared from R2, while the BGP peer dashboard still shows green.

Expected BGP state

Established.

Expected route-table change

The prefix learned from R1 disappears from R2's BGP table and, assuming no alternate route exists, from its RIB.

14. Step-by-step troubleshooting

  1. Confirm the exact missing prefix: 203.0.113.0/24.
  2. Confirm R2's BGP session with R1 is still Established.
  3. Check whether R2 has any BGP path for the prefix.
  4. Check whether R1 still has the prefix locally.
  5. Check whether R1's BGP table still contains a locally originated path.
  6. Check R1's advertised routes toward R2.
  7. Inspect recent configuration changes around the BGP address family.
  8. If packet capture is available, locate the UPDATE in the incident window.
  9. Determine whether the event was a route withdrawal or a session reset.
  10. Restore only the proven missing origination configuration.

This method prevents a common operational mistake: clearing a healthy BGP session when the fault is a route-origination change.

15. Root cause and correction

Proven root cause

The local route still exists on R1, but BGP is no longer instructed to originate it with the network statement.

Corrected configuration

configure terminal
router bgp 65010
 address-family ipv4 unicast
  network 203.0.113.0 mask 255.255.255.0
 end

Why it works

The exact prefix is already present in R1's local routing table. Restoring the BGP network statement makes the prefix eligible for local BGP origination again, subject to the documented Cisco behavior and any applicable policy.

16. Post-fix verification

On R1:

show ip route 203.0.113.0
show ip bgp 203.0.113.0
show ip bgp neighbors 192.0.2.2 advertised-routes

On R2:

show ip bgp 203.0.113.0
show ip route 203.0.113.0
show ip bgp summary

If traffic testing is added, use a dedicated reachable test endpoint rather than interpreting the Null0-backed control-plane prefix as an end-to-end service.

17. Rollback

If the controlled withdrawal must be reversed, restore:

router bgp 65010
 address-family ipv4 unicast
  network 203.0.113.0 mask 255.255.255.0

If unexpected route changes occur, preserve:

  • show ip bgp evidence;
  • neighbor details;
  • routing table state;
  • logs;
  • capture files;
  • the running configuration before and after the change.

18. Production lessons

Protocol lesson

An Established BGP session and a valid prefix are different objects. UPDATE messages change routing information without requiring session re-establishment.

Troubleshooting lesson

Always scope incidents by peer and prefix. “BGP is up” is not a route-level health check.

Packet-analysis lesson

Confirm whether the target prefix is advertised, withdrawn or absent from the relevant UPDATE. Do not infer route behavior from TCP packets alone.

Change-management lesson

A single network-statement removal can cause route loss with no obvious neighbor-state alarm. Route/prefix monitoring is therefore essential.

Security lesson

Unexpected withdrawals can be operational mistakes, policy effects or upstream events. Preserve evidence before assuming malicious activity.

19. Knowledge check

Q1

R2 reports its BGP peer as Established, but 203.0.113.0/24 disappears. Does that prove a session outage?

Answer: No. The prefix can be explicitly withdrawn or otherwise become unavailable while the session remains Established.

Q2

What does NLRI identify in the base IPv4-unicast UPDATE model?

Answer: Network-layer reachability, specifically the destination prefix information being advertised.

Q3

Why should show ip route and show ip bgp both be checked?

Answer: The BGP table shows BGP path information and best-path processing, while the routing table confirms whether a route is installed in the RIB. Presence in one does not automatically prove the other stage.

20. Sources

  1. RFC 4271 — *A Border Gateway Protocol 4 (BGP-4)* — UPDATE message format, NLRI and path-attribute behavior.
  2. RFC 7606 — *Revised Error Handling for BGP UPDATE Messages* — modern handling considerations for malformed UPDATE information.
  3. Cisco — *IP Routing Configuration Guide, Cisco IOS XE 17.x: Configuring a Basic BGP Network* — BGP network origination and neighbor/address-family workflow.
  4. Cisco — *Cisco IOS IP Routing: BGP Command Reference* — show ip bgp and related BGP verification commands.

Accessed: 2026-08-11.

Labels:

Featured Post

Day 41 — BGP Confederations: Sub-AS Design, External View and Migration

1. Opening Confederations are another way to scale BGP inside a large administrative domain. They divide the domain into member autonomous systems while presenting a single confederation identifier to external peers. They are powerful, but their operational model is more complex than simply 'using private ASNs inside.' The engineering goal is not to memorize another BGP command. It is to understand what information each speaker is allowed to propagate, what path information can be hidden, and what failure domain is created by the chosen control-plane architecture . 2. Concept and standards behavior RFC 5065 defines AS_CONFED_SEQUENCE and AS_CONFED_SET and how member-AS relationships are represented. Confederation external sessions have eBGP-like properties inside the confederation, while the confederation is presented externally as one AS. Modern guidance must also account for the fact that RFC 9774 prohibits new origination of AS_SET/AS_CONFED_SET in ordinary aggregation c...