A BGP neighbor can show Established while the network behind that neighbor remains unreachable. This happens because the BGP session state confirms the control-plane connection between two peers, not end-to-end packet delivery.

The affected prefix may never enter BGP. It may be blocked by an export or import policy, have an inaccessible next hop, lose best-path selection, fail to enter the routing table, or reach the FIB while packets still fail because of a firewall, VLAN, or missing return route.

The fastest way to troubleshoot this problem is to follow the prefix through its full path:

Origin → BGP table → export policy → peer → import policy → best path → RIB → FIB → destination → return path

This order prevents network teams from changing BGP configuration when the real fault sits somewhere else.

Does an Established BGP Session Mean the Prefix Is Reachable?

No.

The BGP Established state means the peers completed session setup and can exchange BGP messages. RFC 4271 states that peers in the Established state can exchange UPDATE, KEEPALIVE, and NOTIFICATION messages. UPDATE messages carry routing information between BGP peers. 

It does not prove that a specific route:

• was originated
• was advertised
• passed routing policy
• was accepted by the peer
• has a reachable next hop
• became the best path
• entered the IP routing table
• reached the forwarding table
• can carry traffic in both directions

That distinction should be the starting point for every case where BGP is up but the prefix is unreachable.

Find Where the BGP Prefix Disappears First

Before changing configuration, identify the last stage where the route still exists.

Check	Result	Likely fault
Prefix absent from source routing table	Missing	Local route or interface
Prefix absent from local BGP table	Missing	BGP origination
Prefix not advertised to peer	Missing	Export policy
Peer never receives prefix	Missing	Address family or advertisement
Peer receives but rejects prefix	Rejected	Import policy, AS path, RPKI
Prefix exists but has no best path	Present	Next-hop or path eligibility
Best path exists, but route is absent from RIB	Present	RIB installation
Route exists in RIB but not FIB	Present	Forwarding programming
Route exists in FIB, but host is unreachable	Present	Data plane or return path

A useful rule is simple:

Start with the prefix itself, then follow it one stage at a time. Do not use BGP neighbor state as proof that the route works.

1. Verify the Prefix Exists in the Source Routing Table

A router cannot advertise a prefix through the intended BGP origination method if the required source route does not exist.

First inspect the local routing table.

A route might come from:

• a connected interface
• a static route
• OSPF
• IS-IS
• another routing protocol
• an aggregate
• a discard or Null route
• redistribution

Suppose you want to advertise:

203.0.113.0/24

Confirm that the required route exists in the correct routing table or VRF.

A common mistake is having:

203.0.113.0/25

203.0.113.128/25

while the BGP configuration expects an exact /24 route through a network statement on a platform that requires that exact route to exist.

Check the prefix and mask, not only the first few octets.

Also Check Interface State

If a connected route supplies the prefix and its interface goes down, the route may disappear from the RIB. BGP can remain Established with the upstream neighbor while the customer prefix stops being advertised.

2. Confirm the Prefix Entered the BGP Table

Finding the route in the IP routing table is only the first step.

Now verify that BGP actually originated or learned it.

Depending on the design, the route could enter BGP through:

• a network statement
• redistribution
• aggregation
• another BGP peer

If the route exists in the main routing table but not in the local BGP table, investigate the origination method before touching neighbor filters.

This separates two different problems:

Route exists locally but never entered BGP

versus:

Route entered BGP but was not sent to a peer

That distinction saves a great deal of troubleshooting time.

3. Verify the Prefix Is Actually Advertised to the Neighbor

Next, inspect the routes being advertised toward the affected peer.

Conceptually, this is the Adj-RIB-Out stage.

If the prefix appears in your local BGP table but not among routes sent to the neighbor, focus on outbound policy.

Common causes include:

• outbound prefix-list
• route-map
• route-policy
• AS-path filter
• community match
• conditional advertisement
• wrong neighbor policy
• wrong address family
• aggregation behavior
• route not selected for advertisement

A session can remain Established through all of these conditions.

The peer relationship and route policy are separate parts of BGP operation.

Check Policy Direction

One of the easiest mistakes to miss is applying the correct policy in the wrong direction.

Confirm whether the route filter is:

inbound

or:

outbound

A prefix-list intended to control received routes will cause very different results if attached to advertisements.

4. Verify the Peer Received and Accepted the Route

A route can cross the BGP session and still disappear on the receiving router.

Separate three questions:

Did the peer receive the route?

This confirms an UPDATE containing the route reached the remote BGP process.

Did the peer accept the route?

An inbound policy may reject it after reception.

Did BGP consider the path usable?

A route that passes policy may still fail path eligibility because its next hop cannot be resolved or another protocol condition rejects it.

These stages correspond conceptually to the received route information, routing policy, and BGP’s local route information.

Do not treat “received” and “installed” as synonyms.

5. Check Prefix-Lists, Route-Maps, and Routing Policy

Route filtering is one of the first places to look when only certain prefixes are missing.

Consider an expected route:

203.0.113.0/24

A filter might accidentally allow:

203.0.113.0/25

but not the /24.

Prefix-length rules can create less obvious errors.

Check:

• exact prefix
• mask length
• staart values
• le values
• route-map sequence numbers
• implicit deny behavior
• community matches
• AS-path expressions
• policy order
• correct neighbor
• correct AFI/SAFI

An apparently small mask-length mistake can remove an entire customer network while every BGP peer remains Established.

6. Verify the Correct Address Family

BGP can have an active peer relationship while the required address family is not exchanging the routes you expect.

Examples include:

• IPv4 unicast
• IPv6 unicast
• VPNv4
• VPNv6

A dual-stack peer may exchange IPv4 correctly while IPv6 routes are absent.

If IPv4 works and IPv6 does not, do not assume the entire BGP session is faulty. Check the IPv6 address family, activation, policies, and advertised prefixes separately.

The reverse applies as well.

Treat each address family as its own routing path during diagnosis.

7. Check BGP Next-Hop Reachability

Next-hop resolution is one of the most common reasons a route exists in BGP but remains unusable.

The route may look like this:

Prefix:   203.0.113.0/24

NEXT_HOP: 198.51.100.1

The receiving router then needs a route that can resolve 198.51.100.1.

If it cannot reach that address, the BGP path may be marked inaccessible.

Cisco states that paths with an inaccessible NEXT_HOP are ignored for best-path selection and recommends confirming IGP reachability to that next hop.  

The failure chain looks like this:

BGP receives prefix

        ↓

Reads NEXT_HOP

        ↓

Performs recursive lookup

        ↓

NEXT_HOP cannot be resolved

        ↓

Path cannot become usable

        ↓

No best path for forwarding

A Common iBGP Case

Suppose:

R1 —- eBGP —- ISP

 |

iBGP

 |

R2

R1 learns an external prefix and advertises it to R2 through iBGP.

The original external next hop may remain unchanged.

R2 now knows the destination prefix through BGP, but if R2 has no route to that external next hop, the destination cannot become usable.

Cisco documents this exact type of case, where an iBGP route shows an inaccessible next hop until the receiving router gains a valid route to it. 

Depending on the architecture, the fix may involve:

• IGP reachability to the next hop
• a suitable static route
• next-hop-self
• a change to the underlay routing design

Do not add next-hop-self automatically. First confirm why the next hop is unreachable.

8. Confirm BGP Selected a Best Path

A prefix appearing in BGP output does not automatically mean BGP selected it as the active path.

Check whether the route is:

• valid
• best
• rejected
• received only
• inaccessible
• suppressed
• affected by loop prevention

Potential causes include:

Inaccessible NEXT_HOP

Already covered above, but this is often the first reason a path loses eligibility.

Local ASN in AS_PATH

BGP loop prevention may reject a path containing the local AS where that appearance is not permitted.

Cisco lists an inaccessible next hop and local AS appearing in an external path among conditions that can prevent a route from becoming a valid best-path candidate. 

Policy Rejection

The route may have arrived but failed an access list, prefix filter, AS-path policy, community rule, or another routing policy.

RPKI State

A route can also be rejected by networks that apply Route Origin Validation policy.

We cover that separately below.

9. Check Whether the Best BGP Route Entered the RIB

Now move one layer down.

There are three separate databases engineers often treat as if they were one:

BGP table

    ↓

IP routing table, or RIB

    ↓

Forwarding table, or FIB

A route can exist at one layer but not the next.

BGP Route Exists, but RIB Does Not Contain It

Look for:

• inaccessible next hop
• no usable BGP best path
• another routing source
• route installation failure
• wrong VRF
• routing table policy

Another Protocol Owns the Route

A static or IGP route may already provide the destination.

Do not assume BGP must always become the installed route simply because BGP knows about the prefix.

Inspect the active routing table entry and identify which routing source currently owns it.

Check the VRF

This problem appears frequently in hosting, MPLS, cloud connectivity, and segmented enterprise networks.

The prefix can exist correctly inside:

VRF-CUSTOMER-A

while testing is performed from the default routing table.

The route is present, but not in the forwarding context being used.

10. Check the FIB and Next-Hop Adjacency

Once the route reaches the RIB, verify forwarding.

The FIB tells the router where packets should actually go.

Depending on the platform, inspect:

• forwarding entry
• resolved next hop
• outgoing interface
• adjacency
• hardware programming
• VRF
• label stack where applicable

Then check Layer 2 resolution.

For IPv4:

• ARP

For IPv6:

• Neighbor Discovery

A correct BGP route cannot deliver packets if the router cannot resolve the next-hop adjacency on the outgoing network.

This is where troubleshooting should move away from BGP configuration and toward the data plane.

11. Check RPKI, ROA, and the Origin ASN

Public prefixes may look correct on your own routers but still be unreachable from parts of the Internet because other networks reject the announcement.

RPKI Route Origin Validation checks whether an AS is authorized to originate a prefix.

A ROA records:

• the authorized origin ASN
• the covered prefix
• optionally, the most-specific permitted prefix length

RIPE NCC describes three primary route states:

• Valid
• Invalid
• Not Found

An announcement becomes Invalid when, for example, it originates from an unauthorized ASN or is more specific than the ROA permits.  

Example

Suppose the ROA permits:

Prefix:    203.0.113.0/23

Origin:    AS65001

MaxLength: /23

You then announce:

203.0.113.0/24

The origin ASN is correct, but the /24 is more specific than the ROA permits.

Networks rejecting RPKI-invalid routes may drop that advertisement.

The result can be confusing:

• BGP session is Established
• your provider receives the route
• some networks can reach you
• other networks cannot

For BYOIP deployments, verify the ROA before the production BGP announcement.

12. Check AS_PATH Loop Prevention

BGP uses AS_PATH partly to prevent routing loops.

If your own ASN appears in a received AS_PATH in a context where it is not permitted, the route may be rejected.

Possible cases include:

• accidental re-advertisement
• multi-provider designs
• private ASN handling
• migration between ASNs
• route servers
• unusual allowas-in requirements

Do not disable loop prevention simply to make a route appear.

First identify why the local ASN is present in the path.

13. Verify the Return Path

One of the most common mistakes in BGP incident response is testing only the forward route.

Traffic must work both ways.

Consider:

Client

  |

Transit A

  |

Your BGP Edge

  |

Server

The client reaches the server correctly.

The server replies through:

Server

  |

Different gateway

  |

Transit B

  |

Stateful firewall

  |

DROP

The BGP route may be correct while the connection still fails.

Check:

• server default route
• reverse route
• source address
• policy-based routing
• firewall state
• asymmetric path
• multiple upstreams
• NAT
• VRF

Test From More Than One Direction

Use:

• traceroute from external locations
• reverse traceroute where available
• looking glasses
• route collectors
• probes from several networks

If one provider reaches the prefix and another does not, the problem is probably larger than a local server firewall.

14. Check Firewall, ACL, VLAN, and Host Networking

Once BGP, RIB, and FIB look correct, stop changing BGP until the data plane has been tested.

Verify:

• server IP address
• subnet mask or prefix length
• default gateway
• VLAN assignment
• switch port
• hypervisor bridge
• virtual switch
• security group
• router ACL
• host firewall
• service bind address
• ARP or NDP
• NAT rules

A Simple Diagnostic Question

Can the gateway reach the host directly?

If the answer is no, Internet BGP is probably not the immediate problem.

Fix the local network first.

15. Check MTU When Reachability Is Partial

MTU issues do not usually make a whole BGP prefix disappear, but they can make a working route look broken.

Typical symptoms include:

• small pings succeed
• large packets fail
• TCP connects but stalls
• tunnels work inconsistently
• some applications load while others time out

Check:

• interface MTU
• tunnel overhead
• TCP MSS
• Path MTU Discovery
• ICMP filtering

Treat this as a later-stage check after routing has been proven.

BGP Established but Receiving Zero Prefixes

If the session is up but the received prefix count is zero, use a shorter workflow.

Check in this order:

1. Confirm the correct address family is active.
2. Confirm the remote router has routes to advertise.
3. Check the remote export policy.
4. Check your import policy.
5. Check maximum-prefix controls.
6. Verify the correct VRF.
7. Check route policy based on AS path or communities.
8. Check RPKI policy where public routes are involved.

Do not restart the BGP session as the first troubleshooting step.

A reset may hide useful state without correcting the configuration fault.

BGP Prefix Received but NEXT_HOP Is Inaccessible

A typical incident may look like this:

BGP neighbor: Established

 

Prefix:

203.0.113.0/24

 

Status:

Received

 

NEXT_HOP:

198.51.100.1

 

Route to NEXT_HOP:

Missing

 

Result:

No usable BGP path

The proper question is not:

Why is BGP down?

BGP is not down.

The proper question is:

Which route should resolve 198.51.100.1, and why is that route missing?

Cisco notes that when a BGP next hop is inaccessible, the route has no usable best path and may not be advertised further.  

Prefix Works From Some Networks but Not Others

Partial Internet reachability often points toward routing policy outside the local server.

Check:

• RPKI validity
• ROA maxLength
• upstream advertisements
• route propagation
• prefix length
• communities sent to transit providers
• regional advertisements
• route leaks
• stale routes
• anycast configuration

For IPv4, also review whether the prefix is being announced at a length that upstream and downstream networks are willing to propagate.

A prefix visible through one transit provider may still be filtered elsewhere.

This is why multi-provider testing matters.

Troubleshooting an Unreachable BYOIP Prefix

BYOIP adds another set of dependencies.

Use this order:

1. Confirm ownership or authorization for the IP block.
2. Verify the prefix and prefix length.
3. Confirm the intended origin ASN.
4. Check the ROA.
5. Check the ROA maximum length.
6. Review IRR route objects if the provider uses them.
7. Confirm the hosting provider imported the prefix.
8. Confirm BGP advertisement toward upstream networks.
9. Check external route visibility.
10. Check local forwarding to the server.
11. Verify the return path.
12. Test from several external ASNs.

Do not assume the announcement is globally working because the prefix appears on one local router.

Atal Networks supports IPv4 and IPv6 services, ASN-related infrastructure, BYOIP, private networking, and multihomed hosting environments. About Atal Networks These deployments benefit from checking routing authorization, origin ASN, prefix length, and server-side forwarding before a production cutover.

Quick BGP Troubleshooting Decision Tree

Use this sequence during an incident:

BGP session Established

          |

          v

Is the source prefix in the local RIB?

          |

       No +—-> Fix source route/interface

          |

         Ja

          v

Is the prefix in the local BGP table?

          |

       No +—-> Fix BGP origination

          |

         Ja

          v

Is the prefix advertised to the peer?

          |

       No +—-> Check export policy

          |

         Ja

          v

Did the peer receive the prefix?

          |

       No +—-> Check AFI/SAFI and remote side

          |

         Ja

          v

Did the peer accept it?

          |

       No +—-> Import policy / AS_PATH / RPKI

          |

         Ja

          v

Is NEXT_HOP reachable?

          |

       No +—-> Fix next-hop resolution

          |

         Ja

          v

Is there a best path?

          |

       No +—-> Check path eligibility

          |

         Ja

          v

Is it installed in the RIB?

          |

       No +—-> Check RIB/VRF/competing route

          |

         Ja

          v

Is it installed in the FIB?

          |

       No +—-> Check forwarding programming

          |

         Ja

          v

Does the return path work?

          |

       No +—-> Fix routing/firewall/asymmetry

          |

         Ja

          v

Check host, VLAN, ACL, ARP/NDP, and MTU

This flow works because each step proves one stage before moving to the next.

Useful Commands by Troubleshooting Stage

Exact syntax varies by network operating system and release.

Goal	Cisco-style example	FRR-style example	Junos concept
Peer status	show ip bgp summary	show bgp summary	show bgp summary
Inspect prefix	show ip bgp PREFIX	show bgp ipv4 unicast PREFIX	show route PREFIX extensive
Routing table	show ip route PREFIX	show ip route PREFIX	show route PREFIX
Advertised routes	Neighbor advertised-routes	Neighbor advertised-routes	Route advertising-protocol
Received routes	Neighbor received-routes	Neighbor received-routes	Route receive-protocol
IPv6 route	show bgp ipv6 unicast	show bgp ipv6 unicast	show route table inet6.0

Always verify syntax against the vendor documentation before applying configuration changes to a production router.

Monitor More Than the BGP Session State

An alert that only checks whether a neighbor is Established can miss a routing outage.

Monitor:

• BGP state
• received prefix count
• advertised prefix count
• sudden prefix changes
• next-hop reachability
• RPKI state
• route installation
• FIB state where available
• external reachability
• IPv4 and IPv6 separately

A useful alert might detect:

Neighbor state: Established

Expected prefixes: 25

Received prefixes: 0

That is already a service problem even though the session never dropped.

External probes also help because they test the result that customers care about: whether the prefix is actually reachable.

BGP Prefix Unreachable Troubleshooting Checklist

Before escalating the incident, confirm all of the following:

• BGP peer state is Established.
• Correct AFI/SAFI is active.
• Source prefix exists in the correct RIB.
• Prefix entered the BGP table.
• Prefix is advertised to the intended neighbor.
• Remote peer receives the route.
• Import policy permits it.
• Export policy permits it.
• Prefix-list length matches.
• NEXT_HOP resolves.
• Correct VRF is used.
• BGP selected a usable best path.
• Route entered the routing table.
• Route entered the forwarding table.
• RPKI state is correct.
• ROA authorizes the origin ASN.
• ROA maxLength permits the advertisement.
• AS_PATH is acceptable.
• Server gateway is correct.
• Firewall and ACL rules permit traffic.
• VLAN and interface configuration are correct.
• ARP or NDP works.
• Return routing works.
• External tests succeed from several networks.

The key is to stop asking only whether BGP is up.

Ask instead:

At which stage does this specific prefix stop working?

That question usually points directly toward the fault.

Veel gestelde vragen

Why is my BGP session Established but the prefix is unreachable?

The BGP session may be healthy while the route fails elsewhere. Check whether the prefix was originated, advertised, received, accepted, selected as best, installed in the RIB, programmed into the FIB, and reachable in both directions.

Does BGP Established mean routes are being advertised?

No. Established means the peers can exchange BGP messages. Export policy, missing origination, address-family configuration, or route eligibility can still prevent a specific route from being advertised. RFC 4271 defines Established as the state where BGP peers can exchange UPDATE and other BGP messages.  

Why is a BGP route in the BGP table but not the routing table?

Common causes include an inaccessible next hop, no usable best path, another routing source, routing policy, or the route existing in another VRF. Cisco notes that paths with an inaccessible next hop are not considered usable best-path candidates.  

What does BGP next hop inaccessible mean?

It means the router cannot resolve the route’s NEXT_HOP through its routing information. The router may know the destination prefix through BGP but still be unable to forward packets toward the next-hop router.

Can a prefix-list block a route without dropping BGP?

Yes. Prefix policies operate on route exchange. A policy can reject one prefix, many prefixes, or every route while the neighbor session remains Established.

Can RPKI make a prefix unreachable?

Yes. Networks using Route Origin Validation may reject an RPKI-invalid route. A route can become Invalid because the origin ASN is unauthorized or because the announced prefix is more specific than the ROA permits.  

Why does the route look correct but ping still fail?

The failure may sit outside BGP. Check the FIB, outgoing interface, ARP or NDP, VLAN, firewall, host configuration, default gateway, and return path.

What does next-hop-self solve?

It can change the advertised BGP next hop to an address the receiving peer can reach. This is useful in some iBGP designs, but it should only be used after confirming that next-hop preservation is actually causing the failure.

Why does a BYOIP prefix work from some networks but not others?

Check RPKI, ROA prefix length, upstream advertisements, Internet route propagation, routing policy, and the origin ASN. Partial propagation can produce working routes through some networks and missing routes through others.

Troubleshooting BGP Prefix Reachability With Atal Networks

We operate global hosting infrastructure that includes dedicated servers, bare metal servers, VPS hosting, IPv4/IPv6 services, private networking, BYOIP support, and multihomed network capabilities. About Atal Networks

For customer-owned IPv4 or IPv6 prefixes, we recommend treating BGP deployment as an end-to-end routing process. The prefix, origin ASN, ROA, routing policy, upstream advertisement, local forwarding path, and return route should all be checked before production traffic moves to the new infrastructure.

A healthy BGP session is only one checkpoint. Reliable reachability depends on every stage between prefix origination and the destination server.