Based in Gipuzkoa, Basque Country
Articles
Likes on articles
José Mª Rivadeneyra is a Senior Lecturer in Computer Science, at EHU (Euskal Herriko Unibertsitatea), in the Basque Country. He has a large experience teaching Computer Networks. His research focuses on computer networks, multicast traffic, and project engineering.
• 9 min read
A common misconception is that iBGP requires a full mesh or alternatives such as route reflectors. In reality, full mesh is not a protocol requirement, but a design choice that may be unnecessary and even undesirable in stub ASes and small ISPs.
Showing 1 article(s)
“Agreed on the KISS principle and I'd also argue "POLA" here - the principle of least astonishment. The larger the network, the more important it is to have uniformity. If there are bgp speakers on ibgp network which fall outside the RR / full-mesh config, this creates an architectural exception that needs to be understood and handled in a different way to everything else. This isn't to say that there couldn't be good reasons for doing this, just that a modest improvement in localised convergence performance may not always be worth the increase in architectural complexity. All decisions have a cost.”
Thanks for this perspective, I really like the POLA framing — that’s a very useful way to think about it. I fully agree that uniformity and predictability become increasingly important as networks grow, and that introducing exceptions to a full-mesh or RR-based design can make operations and troubleshooting more complex. My intention with the article was not to argue against full-mesh as a practical design choice, but rather to highlight that it is not a protocol requirement in all cases, particularly in well-bounded stub AS scenarios. In that sense, I see it as a trade-off: in smaller or tightly-scoped networks, relaxing full-mesh may simplify the design locally, while in larger environments the consistency benefits you describe likely outweigh that. I very much agree that these decisions always come with a cost, and that operational simplicity is often the dominant factor in practice. (Apologies for the delayed response as I’ve been offline for the Easter break)
“Thanks for this article: the historical walk through the RFC wording is really interesting and I enjoyed reading it. I'd like to share a slightly different perspective on some of the points raised. On the risk of accidental transit: in my experience, this is something you solve with route-maps and filters on eBGP, not by removing iBGP sessions. Removing sessions to prevent misconfigurations feels a bit like removing roads to prevent accidents. On failure scenarios: I keep thinking about what happens during convergence. If BR1 loses its upstream and has no iBGP session with BR2, it just has to sit there and wait for the IRs to converge. With that session in place, BR1 would immediately know that BR2 has an alternative path. That seems worth having. On KISS: I'd actually argue it the other way around. A full mesh of 5 or 6 routers is uniform and predictable. A partial mesh means you need to keep track of who sees what, which in my experience makes troubleshooting harder, not easier. "Everyone talks to everyone" is a pretty simple rule to follow. I also think that tools like next-hop-self, BGP communities, and well-designed route policies are what make full mesh safe and manageable in practice, even where it's not strictly necessary. And in the real world, the boundaries between upstream, peering, and customer roles can be less clear-cut than the model assumes, so having full route visibility across all routers can really help with traffic engineering. Anyway, just my two cents; thanks again for putting this out there, it's a topic that doesn't get discussed enough.”
Thanks a lot for your thoughtful and well-articulated comment — I really appreciate the perspective. I think your point about failure scenarios is particularly relevant. You are absolutely right that having an iBGP session between BRs can improve convergence behaviour, as it provides immediate visibility of alternative paths. That is indeed a practical advantage of a full mesh that I did not explicitly cover in the article. More generally, I agree that in many real-world deployments, maintaining a full mesh can be a perfectly reasonable and even preferable design choice. My main goal with the article was more limited: to clarify that iBGP full mesh is not a strict protocol requirement, but rather a design choice driven by the need for route visibility and operational considerations. In that sense, I wanted to highlight that simpler topologies may be sufficient in specific scenarios. Thanks again for contributing to the discussion — I agree this is a topic that deserves more attention.
Showing 2 comment(s)