--- title: Establish an IBGP Session « BGP Labs | daily.dev description: A hands-on lab exercise walking through how to establish an IBGP session between two WAN edge routers (R1 and R2) in the same autonomous system. Covers why... canonical: https://daily.dev/posts/establish-an-ibgp-session-bgp-labs-r5tkotlhs twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Establish an IBGP Session « BGP Labs | daily.dev og:description: A hands-on lab exercise walking through how to establish an IBGP session between two WAN edge routers (R1 and R2) in the same autonomous system. Covers why... og:url: https://daily.dev/posts/establish-an-ibgp-session-bgp-labs-r5tkotlhs og:image: https://api.daily.dev/og/posts/R5TkOTLHS.png og:image:alt: Establish an IBGP Session « BGP Labs 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. # Establish an IBGP Session « BGP Labs **[ipSpace.net Blog](https://daily.dev/sources/ipspace)** · 11 min read · 0 upvotes · 0 comments ## Summary A hands-on lab exercise walking through how to establish an IBGP session between two WAN edge routers (R1 and R2) in the same autonomous system. Covers why IBGP is needed when two routers connect to different upstream ISPs, how to configure the session using loopback interfaces with `neighbor update-source`, and how to fix the BGP next-hop problem using `neighbor next-hop-self` so IBGP-learned prefixes are considered valid and selected as best routes. Includes Arista EOS command output and automated validation via netlab. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why do I need IBGP between my two WAN edge routers if they already run EBGP with upstream ISPs? Without IBGP, each WAN edge router only sees BGP routes received from its own upstream ISP — it has no visibility into routes learned by the other router. IBGP lets both routers exchange those external prefixes internally, enabling traffic to use the optimal uplink for each destination rather than being limited to a single ISP path. _Engineers designing dual-homed WAN setups track BGP architecture decisions like this on daily.dev._ ### Why does my IBGP session fail to establish when I configure the neighbor using loopback addresses? BGP uses TCP, and without explicit configuration the source IP defaults to the outgoing interface address. When the TCP SYN arrives at the remote router, its source IP doesn't match the configured neighbor address, so the session is rejected. Fix this by adding `neighbor

update-source Loopback0` (or equivalent) on both routers so the TCP session originates from the loopback. _Networking engineers troubleshooting BGP session issues find relevant lab walkthroughs on daily.dev._ ### Why are IBGP-learned prefixes marked as invalid even after the IBGP session comes up? BGP does not change the next-hop of EBGP routes when re-advertising them over IBGP. The receiving router sees a next-hop IP belonging to the external subnet of the advertising router's ISP link — a subnet it has no route to — so the prefix is marked invalid. Configuring `neighbor next-hop-self` on the IBGP session makes the advertising router substitute its own loopback as the next-hop, which is reachable via IGP. _Keeping up with BGP gotchas like next-hop handling is easier when daily.dev surfaces the right lab content for your stack._ ## Similar posts on daily.dev - [BGP-Free Core with SR-MPLS « ipSpace.net blog](https://daily.dev/posts/bgp-free-core-with-sr-mpls-ipspace-net-blog-h7kronzy3) · ipSpace.net Blog · 0 upvotes · 0 comments --- Tags: [#bgp](https://daily.dev/tags/bgp) [View this post on daily.dev](https://daily.dev/posts/establish-an-ibgp-session-bgp-labs-r5tkotlhs) ```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":"Establish an IBGP Session « BGP Labs","url":"https://daily.dev/posts/establish-an-ibgp-session-bgp-labs-r5tkotlhs","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/establish-an-ibgp-session-bgp-labs-r5tkotlhs"},"datePublished":"2026-08-11T08:55:58.114Z","dateModified":"2026-08-11T09:23:56.519Z","description":"A hands-on lab exercise walking through how to establish an IBGP session between two WAN edge routers (R1 and R2) in the same autonomous system. Covers why...","image":"https://media.daily.dev/image/upload/s--2-1xRawN--/f_auto/v1722860399/public/Placeholder%2011","thumbnailUrl":"https://media.daily.dev/image/upload/s--2-1xRawN--/f_auto/v1722860399/public/Placeholder%2011","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/establish-an-ibgp-session-bgp-labs-r5tkotlhs","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"bgp","timeRequired":"PT11M"} {"@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":"Establish an IBGP Session « BGP Labs"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/establish-an-ibgp-session-bgp-labs-r5tkotlhs#faq","mainEntity":[{"@type":"Question","name":"Why do I need IBGP between my two WAN edge routers if they already run EBGP with upstream ISPs?","acceptedAnswer":{"@type":"Answer","text":"Without IBGP, each WAN edge router only sees BGP routes received from its own upstream ISP — it has no visibility into routes learned by the other router. IBGP lets both routers exchange those external prefixes internally, enabling traffic to use the optimal uplink for each destination rather than being limited to a single ISP path. Engineers designing dual-homed WAN setups track BGP architecture decisions like this on daily.dev."}},{"@type":"Question","name":"Why does my IBGP session fail to establish when I configure the neighbor using loopback addresses?","acceptedAnswer":{"@type":"Answer","text":"BGP uses TCP, and without explicit configuration the source IP defaults to the outgoing interface address. When the TCP SYN arrives at the remote router, its source IP doesn't match the configured neighbor address, so the session is rejected. Fix this by adding `neighbor

update-source Loopback0` (or equivalent) on both routers so the TCP session originates from the loopback. Networking engineers troubleshooting BGP session issues find relevant lab walkthroughs on daily.dev."}},{"@type":"Question","name":"Why are IBGP-learned prefixes marked as invalid even after the IBGP session comes up?","acceptedAnswer":{"@type":"Answer","text":"BGP does not change the next-hop of EBGP routes when re-advertising them over IBGP. The receiving router sees a next-hop IP belonging to the external subnet of the advertising router's ISP link — a subnet it has no route to — so the prefix is marked invalid. Configuring `neighbor next-hop-self` on the IBGP session makes the advertising router substitute its own loopback as the next-hop, which is reachable via IGP. Keeping up with BGP gotchas like next-hop handling is easier when daily.dev surfaces the right lab content for your stack."}}]} ```