Day 7 — Inside a BGP UPDATE: Withdrawn Routes, Path Attributes and IPv4 NLRI
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:
- Is the BGP session healthy?
- 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:
- receive and validate the BGP UPDATE;
- interpret the NLRI and attributes;
- apply inbound policy;
- retain eligible path information according to implementation behavior;
- run best-path selection;
- attempt installation into the routing table;
- resolve the next hop;
- 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 |
Topology
203.0.113.0/24
|
R1
AS 65010
192.0.2.1/30
|
| eBGP
|
192.0.2.2/30
R2
AS 65020Success 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-familyR2 — 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-familyThe 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 summaryR2
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 summaryWhat the evidence must prove
show ip bgp summaryproves the peer is Established and shows prefix/accounting information relevant to the platform.show ip bgp 203.0.113.0proves whether the NLRI is present in the local BGP table.show ip route 203.0.113.0checks 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
endExpected 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
- Confirm the exact missing prefix:
203.0.113.0/24. - Confirm R2's BGP session with R1 is still Established.
- Check whether R2 has any BGP path for the prefix.
- Check whether R1 still has the prefix locally.
- Check whether R1's BGP table still contains a locally originated path.
- Check R1's advertised routes toward R2.
- Inspect recent configuration changes around the BGP address family.
- If packet capture is available, locate the UPDATE in the incident window.
- Determine whether the event was a route withdrawal or a session reset.
- 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
endWhy 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-routesOn R2:
show ip bgp 203.0.113.0
show ip route 203.0.113.0
show ip bgp summaryIf 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.0If unexpected route changes occur, preserve:
show ip bgpevidence;- 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
- RFC 4271 — *A Border Gateway Protocol 4 (BGP-4)* — UPDATE message format, NLRI and path-attribute behavior.
- RFC 7606 — *Revised Error Handling for BGP UPDATE Messages* — modern handling considerations for malformed UPDATE information.
- Cisco — *IP Routing Configuration Guide, Cisco IOS XE 17.x: Configuring a Basic BGP Network* — BGP network origination and neighbor/address-family workflow.
- Cisco — *Cisco IOS IP Routing: BGP Command Reference* —
show ip bgpand related BGP verification commands.
Accessed: 2026-08-11.
