--- title: BGP Route Reflectors in the Forwarding Path «... description: A deep dive into hierarchical BGP route reflectors placed in the forwarding path, following the physical topology. The post explores how making every... canonical: https://daily.dev/posts/bgp-route-reflectors-in-the-forwarding-path-ipspace-net-blog-l0kngeka0 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: BGP Route Reflectors in the Forwarding Path « ipSpace.net blog | daily.dev og:description: A deep dive into hierarchical BGP route reflectors placed in the forwarding path, following the physical topology. The post explores how making every... og:url: https://daily.dev/posts/bgp-route-reflectors-in-the-forwarding-path-ipspace-net-blog-l0kngeka0 og:image: https://api.daily.dev/og/posts/L0knGEKa0.png og:image:alt: BGP Route Reflectors in the Forwarding Path « 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. # BGP Route Reflectors in the Forwarding Path « ipSpace.net blog **[ipSpace.net Blog](https://daily.dev/sources/ipspace)** · 5 min read · 0 upvotes · 0 comments ## Summary A deep dive into hierarchical BGP route reflectors placed in the forwarding path, following the physical topology. The post explores how making every intermediate router a route reflector creates a more resilient design where BGP sessions share fate with the data plane. It also addresses when changing BGP next hops on reflected routes is acceptable, compares centralized RR designs to SDN controllers, and revisits the original intent of route reflectors per RFC 1966 — scalability, not fate-sharing. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is the original design intent of BGP route reflectors according to RFC 1966? BGP route reflectors were designed as a more scalable replacement for the IBGP full mesh requirement, not as a mechanism to implement shared fate between the control and data planes. RFC 1966's Introduction section confirms this. The idea of aligning RR placement with physical topology for fate-sharing is a later engineering consideration, not the original motivation. _Network engineers debating RR placement strategies find the relevant RFCs and design discussions on daily.dev._ ### When is it acceptable to change the BGP next hop on reflected routes? Changing the BGP next hop on reflected routes is acceptable when IBGP sessions follow the physical topology and the route reflector sits in the actual data forwarding path. In that case the RR shares fate with user data packets, making next-hop changes meaningful. This goes against the SHOULD NOT in RFC 4456 section 10, but is technically valid in topology-aligned designs. _Engineers navigating BGP next-hop behavior and RFC compliance track these nuances on daily.dev._ ### Does hierarchical BGP route reflector design actually work in practice? Hierarchical BGP route reflectors work reliably in practice and are common in large networks. In this design every router acts as a route reflector and all its IBGP neighbors are its clients, forming a hierarchy that mirrors the physical topology. The design is most useful when intermediate routers need to know edge-advertised prefixes; it is wasteful for MPLS/VPN or EVPN where intermediate nodes do not need full prefix visibility. _Practitioners building large-scale BGP topologies follow real-world design discussions like this on daily.dev._ ## Similar posts on daily.dev - [BGP-Free Network Core with SRv6 « ipSpace.net blog](https://daily.dev/posts/bgp-free-network-core-with-srv6-ipspace-net-blog-9bbn88wub) · ipSpace.net Blog · 0 upvotes · 0 comments --- Tags: [#bgp](https://daily.dev/tags/bgp), [#networking](https://daily.dev/tags/networking) [View this post on daily.dev](https://daily.dev/posts/bgp-route-reflectors-in-the-forwarding-path-ipspace-net-blog-l0kngeka0) ```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":"BGP Route Reflectors in the Forwarding Path « ipSpace.net blog","url":"https://daily.dev/posts/bgp-route-reflectors-in-the-forwarding-path-ipspace-net-blog-l0kngeka0","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/bgp-route-reflectors-in-the-forwarding-path-ipspace-net-blog-l0kngeka0"},"datePublished":"2026-08-11T08:54:38.846Z","dateModified":"2026-10-15T02:22:23.900Z","description":"A deep dive into hierarchical BGP route reflectors placed in the forwarding path, following the physical topology. The post explores how making every...","image":"https://media.daily.dev/image/upload/s--HRgLpUt6--/f_auto/v1722860399/public/Placeholder%2003","thumbnailUrl":"https://media.daily.dev/image/upload/s--HRgLpUt6--/f_auto/v1722860399/public/Placeholder%2003","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/bgp-route-reflectors-in-the-forwarding-path-ipspace-net-blog-l0kngeka0","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"bgp,networking","timeRequired":"PT5M"} {"@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":"BGP Route Reflectors in the Forwarding Path « ipSpace.net blog"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/bgp-route-reflectors-in-the-forwarding-path-ipspace-net-blog-l0kngeka0#faq","mainEntity":[{"@type":"Question","name":"What is the original design intent of BGP route reflectors according to RFC 1966?","acceptedAnswer":{"@type":"Answer","text":"BGP route reflectors were designed as a more scalable replacement for the IBGP full mesh requirement, not as a mechanism to implement shared fate between the control and data planes. RFC 1966's Introduction section confirms this. The idea of aligning RR placement with physical topology for fate-sharing is a later engineering consideration, not the original motivation. Network engineers debating RR placement strategies find the relevant RFCs and design discussions on daily.dev."}},{"@type":"Question","name":"When is it acceptable to change the BGP next hop on reflected routes?","acceptedAnswer":{"@type":"Answer","text":"Changing the BGP next hop on reflected routes is acceptable when IBGP sessions follow the physical topology and the route reflector sits in the actual data forwarding path. In that case the RR shares fate with user data packets, making next-hop changes meaningful. This goes against the SHOULD NOT in RFC 4456 section 10, but is technically valid in topology-aligned designs. Engineers navigating BGP next-hop behavior and RFC compliance track these nuances on daily.dev."}},{"@type":"Question","name":"Does hierarchical BGP route reflector design actually work in practice?","acceptedAnswer":{"@type":"Answer","text":"Hierarchical BGP route reflectors work reliably in practice and are common in large networks. In this design every router acts as a route reflector and all its IBGP neighbors are its clients, forming a hierarchy that mirrors the physical topology. The design is most useful when intermediate routers need to know edge-advertised prefixes; it is wasteful for MPLS/VPN or EVPN where intermediate nodes do not need full prefix visibility. Practitioners building large-scale BGP topologies follow real-world design discussions like this on daily.dev."}}]} ```