<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/ibgp-local-as-next-hop-requirements-ipspace-net-blog-exjysbbub" -->

---
title: iBGP Local-AS Next Hop Requirements « ipSpace.net blog
description: Using the BGP `neighbor local-as` feature to fake an iBGP session between routers in different autonomous systems creates a subtle but critical next-hop...
canonical: https://daily.dev/posts/ibgp-local-as-next-hop-requirements-ipspace-net-blog-exjysbbub
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: iBGP Local-AS Next Hop Requirements « ipSpace.net blog | daily.dev
og:description: Using the BGP `neighbor local-as` feature to fake an iBGP session between routers in different autonomous systems creates a subtle but critical next-hop...
og:url: https://daily.dev/posts/ibgp-local-as-next-hop-requirements-ipspace-net-blog-exjysbbub
og:image: https://api.daily.dev/og/posts/ExjYSbBUB.png
og:image:alt: iBGP Local-AS Next Hop Requirements « ipSpace.net blog
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# iBGP Local-AS Next Hop Requirements « ipSpace.net blog

**[ipSpace.net Blog](https://daily.dev/sources/ipspace)** · 4 min read · 0 upvotes · 0 comments

## Summary

Using the BGP `neighbor local-as` feature to fake an iBGP session between routers in different autonomous systems creates a subtle but critical next-hop reachability problem. Because standard iBGP next-hop processing rules do not change the next hop on iBGP sessions, and there is no underlying IGP to distribute the EBGP peer subnet, the receiving router cannot resolve the advertised next hop. The conclusion is that `neighbor next-hop-self` is mandatory on iBGP local-as sessions. The post demonstrates this with Arista EOS configurations and FRR BGP table output, showing that while BGP sessions establish and prefixes propagate, routes are marked invalid due to an inaccessible next hop. This is part of a series exploring caveats of the iBGP local-as feature across 18 platforms.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://blog.ipspace.net/2025/04/ibgp-local-as-details>

## Questions this post answers

### Why are BGP routes marked invalid with 'inaccessible' next hop on an iBGP local-as session?

On an iBGP session, BGP does not change the next hop by default, because the protocol assumes the EBGP peer subnet is reachable via an IGP. When using local-as to fake an iBGP session between different autonomous systems with no underlying IGP, the receiving router has no route to the original EBGP peer's IP address, so the next hop is unresolvable and the prefix is marked invalid.

_Engineers troubleshooting BGP local-as next-hop issues across platforms share findings on daily.dev._

### What must I configure on a BGP neighbor when using iBGP local-as between different autonomous systems?

You must configure `neighbor next-hop-self` on the iBGP local-as session. Without it, the next hop advertised to the remote peer remains the original EBGP peer's IP address, which is unreachable because there is no IGP distributing that subnet between the two autonomous systems. Every tested platform failed without this configuration.

_Keeping up with BGP edge cases like this across NOS platforms is easier when the right posts surface on daily.dev._

## Similar posts on daily.dev

- [Enforcing the First AS in BGP AS\_PATHs](https://daily.dev/posts/enforcing-the-first-as-in-bgp-as-paths-yx1xiadkj) · Cloudflare · 0 upvotes · 0 comments
- [The Never-Ending IPv6 Loopback Prefix Saga « ipSpace.net blog](https://daily.dev/posts/the-never-ending-ipv6-loopback-prefix-saga-ipspace-net-blog-4nlhgh10l) · ipSpace.net Blog · 0 upvotes · 0 comments

---

Tags: [#bgp](https://daily.dev/tags/bgp)

[View this post on daily.dev](https://daily.dev/posts/ibgp-local-as-next-hop-requirements-ipspace-net-blog-exjysbbub)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"iBGP Local-AS Next Hop Requirements « ipSpace.net blog","url":"https://daily.dev/posts/ibgp-local-as-next-hop-requirements-ipspace-net-blog-exjysbbub","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/ibgp-local-as-next-hop-requirements-ipspace-net-blog-exjysbbub"},"datePublished":"2026-08-11T08:52:09.632Z","dateModified":"2026-08-11T08:59:21.729Z","description":"Using the BGP `neighbor local-as` feature to fake an iBGP session between routers in different autonomous systems creates a subtle but critical next-hop...","image":"https://media.daily.dev/image/upload/s--OHB84bZF--/f_auto/v1722860399/public/Placeholder%2010","thumbnailUrl":"https://media.daily.dev/image/upload/s--OHB84bZF--/f_auto/v1722860399/public/Placeholder%2010","isAccessibleForFree":true,"articleSection":"ipSpace.net Blog","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"ipSpace.net Blog","logo":"https://media.daily.dev/image/upload/s--xS7E82MT--/f_auto,q_auto/v1786438303/logos/ipspace?_a=BAMAMicg0","url":"https://daily.dev/sources/ipspace"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/ibgp-local-as-next-hop-requirements-ipspace-net-blog-exjysbbub","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"bgp","timeRequired":"PT4M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"ipSpace.net Blog","item":"https://daily.dev/sources/ipspace"},{"@type":"ListItem","position":3,"name":"iBGP Local-AS Next Hop Requirements « ipSpace.net blog"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/ibgp-local-as-next-hop-requirements-ipspace-net-blog-exjysbbub#faq","mainEntity":[{"@type":"Question","name":"Why are BGP routes marked invalid with 'inaccessible' next hop on an iBGP local-as session?","acceptedAnswer":{"@type":"Answer","text":"On an iBGP session, BGP does not change the next hop by default, because the protocol assumes the EBGP peer subnet is reachable via an IGP. When using local-as to fake an iBGP session between different autonomous systems with no underlying IGP, the receiving router has no route to the original EBGP peer's IP address, so the next hop is unresolvable and the prefix is marked invalid. Engineers troubleshooting BGP local-as next-hop issues across platforms share findings on daily.dev."}},{"@type":"Question","name":"What must I configure on a BGP neighbor when using iBGP local-as between different autonomous systems?","acceptedAnswer":{"@type":"Answer","text":"You must configure `neighbor next-hop-self` on the iBGP local-as session. Without it, the next hop advertised to the remote peer remains the original EBGP peer's IP address, which is unreachable because there is no IGP distributing that subnet between the two autonomous systems. Every tested platform failed without this configuration. Keeping up with BGP edge cases like this across NOS platforms is easier when the right posts surface on daily.dev."}}]}
```

