Skip to content
Log in Sign up My account

1.11.b Next Hop, AS Numbers and Route Exchange

Blueprint 1.11: Troubleshoot BGP (Interior and External)

This page covers the rest of 1.11.b, neighbor relationship and authentication:

  • next-hop
  • 4-byte AS
  • private AS
  • route refresh
  • synchronization
  • operation (how routes enter BGP, are advertised and reach the routing table)

Session states, timers, authentication, multihop and peer groups are on Sessions, States and Address Families.

BGP operation: from the BGP table to the routing table

A session being Established says nothing about whether a prefix is usable. A prefix passes through four gates, and each one has its own failure symptom.

graph LR
  A["Received or originated<br/>Adj-RIB-In"] --> B["Inbound policy"]
  B --> C["BGP table<br/>valid paths"]
  C --> D["Best path<br/>marked with >"]
  D --> E["Routing table<br/>unless better AD"]
  D --> F["Outbound policy<br/>and advertising rules"]
  F --> G["Sent to peers"]
Gate Fails when What you see
Into the BGP table Inbound filter denies it, or the AS path contains the local AS (loop prevention) Prefix absent from show ip bgp; received-routes shows it if soft reconfiguration is on
Valid and best Next hop unreachable, or (with synchronization on) not in the IGP Prefix present, no >; show ip bgp <prefix> says inaccessible or not synchronized
Into the routing table A route with lower administrative distance exists r (RIB-failure) code on the prefix
Advertised to a peer iBGP split horizon, outbound filter, or the prefix is not best show ip bgp neighbors <ip> advertised-routes does not list it

How routes enter BGP on the originating router:

Method Origin code Requirement
network 192.0.2.0 mask 255.255.255.0 i (IGP) Exact prefix and mask must be in the routing table
redistribute ospf 1 (or static, connected) ? (incomplete) Route present in the source protocol; OSPF redistribution into BGP takes only internal routes unless you add match external
aggregate-address 192.0.2.0 255.255.254.0 i At least one more-specific prefix in the BGP table

Administrative distances for BGP routes: eBGP 20, iBGP 200, locally originated (network, aggregate) 200. That high iBGP distance is why an IGP or static route to the same prefix normally wins.

Advertising rules: a router advertises only its best path for each prefix. Routes learned from an iBGP peer are not advertised to other iBGP peers (iBGP split horizon, which is why you need a full mesh or a route reflector). A router discards any update whose AS_PATH already contains its own AS number (eBGP loop prevention). neighbor x allowas-in relaxes that check, for a customer whose sites share one AS number across a provider.

The NEXT_HOP attribute

NEXT_HOP is well-known mandatory: every update carries one, and a path whose next hop cannot be resolved in the routing table is never a candidate for best path.

Situation Next hop sent
Router advertises to an eBGP peer Its own update-source address (the interface it peers from)
Router advertises a route it learned from eBGP to an iBGP peer Unchanged: the eBGP neighbor's address
Router advertises a route it learned from iBGP to an eBGP peer Its own address
Route reflector reflects a route Unchanged
Router advertises a locally originated route Its own update-source address (shows as 0.0.0.0 in its own table)
eBGP peer and the real next hop share the same subnet The third-party next hop on that subnet, not the advertiser (avoids an extra hop) 
graph LR
  R4["R4 ISP-A<br/>10.2.4.2"] -- "eBGP, NH 10.2.4.2" --> R2["R2"]
  R2 -- "iBGP, NH 10.2.4.2 unchanged<br/>or 10.255.255.2 with next-hop-self" --> R1["R1 RR"]
  R1 -- "reflected, NH unchanged" --> R3["R3"]

The iBGP rule creates the most common BGP fault in an enterprise. If the eBGP link subnet is not in the IGP, every internal router has the prefix in its BGP table with an unreachable next hop.

R1# show ip bgp 198.51.100.0
BGP routing table entry for 198.51.100.0/24, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  Refresh Epoch 1
  65001
    10.2.4.2 (inaccessible) from 10.255.255.2 (10.255.255.2)
      Origin IGP, metric 0, localpref 100, valid, internal

Two fixes, and an exam question may forbid one of them:

router bgp 65010
 address-family ipv4
  neighbor 10.255.255.1 next-hop-self

The edge router rewrites the next hop to its own update-source (its loopback) on everything it sends to that iBGP peer. Internal routers resolve the loopback through the IGP.

router ospf 1
 passive-interface GigabitEthernet0/1
interface GigabitEthernet0/1
 ip ospf 1 area 0

The eBGP link becomes reachable inside the AS without forming an OSPF adjacency with the ISP.

When the next hop resolves, show ip bgp <prefix> shows the IGP metric to it in brackets, for example 10.255.255.2 (metric 2) from 10.255.255.1 (10.255.255.1), and show ip route shows a recursive route through the loopback.

Exam trap

next-hop-self goes on the edge router toward its iBGP peers. Configuring it on the route reflector does nothing for reflected iBGP routes, because IOS only applies plain next-hop-self to eBGP-learned paths. (IOS XE has next-hop-self all for reflected routes, but that is a design choice, not the usual fix.) Configuring it on the eBGP session toward the ISP changes nothing either: eBGP already sets the next hop to self.

4-byte AS numbers

The original AS number was 16 bits (0 to 65535). RFC 6793 extended it to 32 bits. Routers advertise the "four-octet AS" capability in the OPEN. When a 4-byte speaker talks to an old 2-byte speaker, it puts the reserved number AS 23456 (AS_TRANS) in the 2-byte fields and carries the real path in the optional transitive AS4_PATH attribute, which the old router passes on unchanged.

Format Example How to convert
asplain 65546 Decimal value of the 32-bit number
asdot 1.10 High 16 bits, dot, low 16 bits: 65546 = 1 x 65536 + 10

Formats are display only. Two neighbors do not need to agree on the format; they both carry the same 32-bit number on the wire. On IOS, bgp asnotation dot switches display and regular expression matching to asdot. That matters for AS-path filters: in asdot, 1.10 contains a dot, which a regular expression treats as "any character" unless you escape it as 1\.10.

R3# show ip bgp neighbors 10.3.5.2 | include Four-octets
    Four-octets ASN Capability: advertised and received

Private AS numbers

Range Size
64512 to 65534 2-byte private
4200000000 to 4294967294 4-byte private (RFC 6996)
65535 and 4294967295 Reserved, not private
23456 AS_TRANS, not private

Enterprises with a single upstream, or customers of an MPLS provider, often use private AS numbers. Those numbers must not leak into the Internet table, so the provider (or the customer edge) strips them with remove-private-as on the session toward the eBGP peer, in the outbound direction.

Command Behaviour
neighbor x remove-private-as Removes private AS numbers only if the AS path contains nothing but private AS numbers. If public and private are mixed, nothing is removed.
neighbor x remove-private-as all Removes every private AS number, even in a mixed path
neighbor x remove-private-as all replace-as Replaces each private AS number with the local AS, keeping the path length (useful when the path length is used for policy)

Exam trap

remove-private-as acts on updates sent to that eBGP neighbor, and only on eBGP sessions. It does nothing on iBGP sessions and nothing to routes received. If the exhibit shows the command and the private AS still leaks, check whether the path also contains a public AS: the plain form leaves mixed paths alone.

Route refresh and soft reconfiguration

Inbound and outbound policies only touch updates as they are sent or received. When you change a filter or a route-map, routes already exchanged are not re-evaluated until you reset the session. A hard reset (clear ip bgp 10.2.4.2) tears down TCP and drops traffic; a soft reset reapplies policy without dropping the session.

Command What it does Requirement
clear ip bgp 10.2.4.2 Hard reset None. Disruptive.
clear ip bgp 10.2.4.2 soft out Resends all updates to the neighbor through the current outbound policy None
clear ip bgp 10.2.4.2 soft in Asks the neighbor for a full resend (ROUTE-REFRESH message) and applies the current inbound policy Route refresh capability on both sides (all modern IOS)
clear ip bgp 10.2.4.2 soft in with soft reconfiguration Re-runs inbound policy over the locally stored, unfiltered copy neighbor 10.2.4.2 soft-reconfiguration inbound
clear ip bgp * soft Soft reset in both directions for every neighbor

soft-reconfiguration inbound costs memory (a second copy of everything the neighbor sends), but it is the only way to see what a neighbor sent before your inbound policy touched it:

Command Shows
show ip bgp neighbors x received-routes Everything received, before inbound policy. Needs soft-reconfiguration inbound.
show ip bgp neighbors x routes What was accepted after inbound policy
show ip bgp neighbors x advertised-routes What this router is sending to the neighbor 
R2# show ip bgp neighbors 10.2.4.2 received-routes
% Inbound soft reconfiguration not enabled on 10.2.4.2

The capability shows in show ip bgp neighbors as Route refresh: advertised and received(new).

Synchronization

The synchronization rule dates from transit networks where not every router ran BGP: a router must not use or advertise to an eBGP peer a route learned from iBGP until the same prefix is also known through the IGP. Otherwise the AS would attract traffic that its non-BGP core routers would drop.

  • Synchronization is off by default since IOS 12.2(8)T, and you meet it mostly in exam questions. Some newer IOS XE releases no longer accept the command.
  • With it on, an iBGP-learned prefix that is not in the IGP is shown as not synchronized, is not marked best, is not installed and is not advertised to eBGP peers.
  • If the IGP is OSPF and the prefix is redistributed into OSPF, the OSPF router ID of the advertising router must also match its BGP router ID for the route to count as synchronized.
  • In a network where every transit router runs BGP (full mesh or route reflectors), synchronization is unnecessary. Turn it off with no synchronization.
R3# show ip bgp 192.0.2.0
BGP routing table entry for 192.0.2.0/24, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    10.255.255.1 (metric 2) from 10.255.255.1 (10.255.255.1)
      Origin IGP, metric 0, localpref 100, valid, internal, not synchronized

Exam trap

"Not synchronized" and "inaccessible" both leave a prefix without a >, but the fixes are different. Inaccessible is about the next hop (fix with next-hop-self or the IGP). Not synchronized is about the prefix itself being absent from the IGP (fix with no synchronization). Read the line under the path carefully.

Lab: tickets 5 and 6

Topology: the module topology with the baseline from the Sessions lab. Start each ticket from the saved baseline.

  1. Before you inject anything, record the baseline evidence:

    R1# show ip bgp 198.51.100.0 | include from
    10.255.255.2 (metric 2) from 10.255.255.2 (10.255.255.2)
R1# show ip route 198.51.100.0
Routing entry for 198.51.100.0/24
  Known via "bgp 65010", distance 200, metric 0
  ...
  * 10.255.255.2, from 10.255.255.2, ... ago
      Route metric is 0, traffic share count is 1

  2. On R2, turn on neighbor 10.2.4.2 soft-reconfiguration inbound, run clear ip bgp 10.2.4.2 soft in, then compare received-routes with routes. They match now; they will differ on the Policies page.

  3. On R3, confirm the capabilities negotiated with ISP-B: show ip bgp neighbors 10.3.5.2 | include Four-octets|Route refresh. Both lines should read advertised and received.
  4. Inject ticket 5, troubleshoot, fix. Restore. Inject ticket 6, troubleshoot, fix.
Fault injection, ticket 5 

! R2
router bgp 65010
 address-family ipv4
  no neighbor 10.255.255.1 next-hop-self
Then clear ip bgp 10.255.255.1 soft out on R2.

Fault injection, ticket 6 

! R3
router bgp 65010
 address-family ipv4
  synchronization
Then clear ip bgp * on R3.

Tickets

Ticket 5: "Nobody inside the company can reach ISP-A's customer network 198.51.100.0/24, and traffic to 203.0.113.0/24 now leaves through ISP-B. Do not add the ISP links to OSPF." Ticket 6: "ISP-B reports that our 192.0.2.0/24 prefix disappeared from their table. All BGP sessions on R3 are up."

Ticket 5: root cause and fix

On R1, show ip bgp shows 198.51.100.0/24 with no > and 203.0.113.0/24 with only the R3 path as best. show ip bgp 198.51.100.0 shows 10.2.4.2 (inaccessible) from 10.255.255.2. R2 no longer rewrites the next hop, and 10.2.4.0/30 is not in OSPF. Because R1 has no best path for 198.51.100.0/24, it reflects nothing to R3 either. For 203.0.113.0/24, the R2 path is invalid, so the R3 path wins and all traffic leaves through ISP-B.

Fix on R2 (the restriction rules out the OSPF fix):

router bgp 65010
 address-family ipv4
  neighbor 10.255.255.1 next-hop-self

Then clear ip bgp 10.255.255.1 soft out, and confirm on R1 that the next hop is 10.255.255.2 with (metric 2) and a >.

Ticket 6: root cause and fix

On R5, show ip bgp 192.0.2.0 returns nothing. On R3, show ip bgp neighbors 10.3.5.2 advertised-routes does not list 192.0.2.0/24, and show ip bgp 192.0.2.0 shows valid, internal, not synchronized with no best path. 192.0.2.0/24 is a BGP-only prefix and is not in OSPF, so with synchronization on, R3 will neither use it nor send it to an eBGP peer. show run | section router bgp shows the synchronization line under the IPv4 address family.

Fix on R3: no synchronization under the IPv4 address family, then clear ip bgp * soft. Do not redistribute BGP into OSPF to satisfy the rule; that would be the wrong design answer.

Quick check

R2 learns 203.0.113.0/24 from an eBGP peer at 10.2.4.2. Without next-hop-self, what next hop does R1 (an iBGP peer) see, and what next hop does R3 see after R1 reflects it?

10.2.4.2 in both cases. iBGP does not change the next hop, and a route reflector does not change it either.

Write AS 131072 in asdot notation.

131072 = 2 x 65536 + 0, so asdot 2.0.

You change an inbound route-map toward a neighbor that supports route refresh. Which command applies it without dropping the session?

clear ip bgp <neighbor> soft in. The router sends a ROUTE-REFRESH and the neighbor resends its updates, which pass through the new policy.

References

  • RFC 4271 (BGP-4, NEXT_HOP and synchronization background), RFC 6793 (four-octet AS numbers), RFC 5396 (textual representation of AS numbers), RFC 6996 (private AS range for 4-byte AS), RFC 2918 (route refresh), at rfc-editor.org
  • IP Routing: BGP Configuration Guide, Cisco IOS XE: chapters on BGP 4-byte ASN support and removing private AS numbers (search on cisco.com)
  • "BGP Next Hop Self" and "Understanding BGP soft reconfiguration", Cisco documentation (search on cisco.com)
  • Cisco Live On-Demand Library: search "BGP troubleshooting"