When iBGP Full Mesh Is Actually Unnecessary

It is widely believed that all BGP routers within an Autonomous System (AS) must be connected in a full iBGP mesh, or, when this becomes impractical, that route reflectors or confederations must be used. However, a full mesh is not always necessary, and in some scenarios it may even be undesirable.

In this article, I will explain why the belief that iBGP full mesh is mandatory has become so widespread, and clarify when it is actually necessary to interconnect all BGP routers within an AS - and when it is better not to do so.

The origin of the problem

Much of the confusion around the supposed requirement for a full iBGP mesh stems from the wording of early, now obsolete, versions of the BGP standard. In the first version of the protocol (RFC 1105), it was stated:

“…in order to maintain consistent routing information, these gateways MUST have direct BGP sessions with each other (the BGP sessions should form a complete graph).”

And further:

“If the BGP UPDATE was received over the INTERNAL link, it is not propagated over any other INTERNAL link. This restriction is due to the fact that all BGP gateways within a single AS form a completely connected graph.”

It is reasonable to assume that the authors had transit providers in mind, which, at that time (June 1989), were essentially the only networks using BGP.

Subsequent versions of the protocol retained similar wording:

• In RFC 1163 and RFC 1267, the first statement was removed, but the second remained largely unchanged.
• In RFC 1654 and RFC 1771, the wording evolved, but the idea of a full mesh requirement remained:

“When a BGP speaker receives a new route from a BGP speaker in a neighbouring autonomous system, it shall advertise that route to all other BGP speakers in its autonomous system by means of an UPDATE message.”

All these RFCs have since been replaced by the current standard, RFC 4271, where any explicit reference to a full mesh requirement has been removed. The relevant statement now reads:

“When a BGP speaker receives an UPDATE message from an internal peer, it SHALL NOT re-distribute that routing information to other internal peers (unless acting as a route reflector).”

Unfortunately, the RFCs defining alternatives to full mesh — route reflection (RFC 4456) and confederations (RFC 5065) — still contain wording that can be interpreted as implying such a requirement.

For example, RFC 4456 states:

“Typically, all BGP speakers within a single AS must be fully meshed…”

While this wording reflects common practice rather than a strict requirement, later passages may still reinforce the perception that a full mesh is necessary. This is particularly evident in RFC 5065, which includes statements such as:

“As originally defined, BGP requires that all BGP speakers within a single AS must be fully meshed.”

“[BGP-4] requires BGP speakers in the same autonomous system to establish a full mesh of TCP connections among all speakers for the purpose of exchanging exterior routing information.”

These statements, although historically accurate, may contribute to the persistent misconception that full mesh is a protocol requirement rather than a design choice.

When iBGP full mesh (or its alternatives) is required

In most ASes, multiple border routers maintain eBGP sessions with external peers. The AS must then determine which border router should be used to reach each external destination. While there are multiple ways to achieve this, iBGP is the most common solution.

However, using iBGP introduces the risk of routing loops within the AS, since BGP’s loop detection mechanism (based on AS_PATH) only works between autonomous systems, not within them.

For this reason, BGP prohibits re-advertising routes learned via iBGP to other iBGP peers. As a consequence, a full mesh is required if all BGP routers are expected to have full visibility of external routes.

But this reasoning relies on a key assumption - i.e., that all BGP routers in the AS must know all external routes. This assumption is valid for transit providers, but not necessarily for stub ASes or even for small local ISPs.

When iBGP full mesh is not required

Multihomed stub AS

Consider a multihomed stub AS with two border routers (BR1 and BR2), each connected to a different upstream ISP (figure 1). Internally, the AS consists of three campus networks, each with a campus core router (IR1, IR2, IR3).

The figure shows two routers connected by a solid line when there is an iBGP session between them. As can be seen, in STUB there is no full iBGP mesh between all the BGP routers; there is no iBGP session between BR1 and BR2, nor between IRs.

Are those sessions necessary?

In a stub AS, which does not provide transit between its upstream providers, traffic entering through one border router must always be forwarded towards internal routers, never towards other border routers. Note that, in the event of an upstream failure, internal routers will stop sending traffic to the affected border router (since they will remove BGP routes imported from that router) and will send all outbound traffic to other border routers. This makes it unnecessary for the border routers to be aware of alternative BGP paths provided by other border routers.

Similarly, outbound traffic flows from internal routers to border routers, never to another internal router.

Therefore, concerning to iBGP:

• Internal routers in the figure (IRs) must know all external routes imported by both border routers (BRs). But they have nothing to learn from other IRs, as internal traffic will be routed via IGP (Internal Gateway Protocol, for example, OSPF)
• Border routers only need to know internal destinations, not routes learned by other border routers

On the other hand, establishing an iBGP session between BR1 and BR2 provides no operational benefit, but increases the risk of accidentally re-advertising external routes, effectively turning the AS into a transit provider. Adding iBGP sessions between IRs is a neutral option when an IGP is not used.

This example shows that in multihomed stub ASes, a full mesh is neither necessary nor desirable.

Small local ISP

A similar situation can arise in a small ISP. This is illustrated in Figure 2, which shows an ISP with:

• Two upstream connections (Up1, Up2)
• Three Points of Presence (PoPs) serving downstream customers
• One peering router (P) connected to an IXP

Such an ISP:

• Should not provide transit between upstream providers
• Should not provide transit between peers and upstream providers (in either direction)
• Should only provide transit to its downstream customers

In this case:

• PoP routers must have full visibility of:
  • routes from upstream (via Up1/Up2)
  • routes from peering (via P)
  • routes from other PoPs
• Upstream routers (Up1/Up2) and the peering router (P):
  • only need to know customer routes (via PoPs)
  • do not need visibility of each other’s external routes

Therefore:

• PoPs maintain iBGP sessions with all other BGP routers
• Up1, Up2, and P maintain iBGP sessions with PoPs only, but not among themselves

This design is simpler than a full mesh and reduces operational risk, particularly the risk of unintended transit between upstreams or peers.

As in the previous case, failure of an upstream or peering link does not require alternative path knowledge at the affected border router, since PoPs will stop forwarding traffic towards it.

It is worth noting that adopting a design based on route reflectors can further simplify the topology, even for relatively small ISPs. For example, in the scenario shown in Figure 2, using a route reflector with iBGP sessions to all other routers in the AS would require only six iBGP sessions, compared to the twelve required even in a non-full-mesh design. On the other hand, configuring those 6 sessions will be more complex and riskier than setting up 12 sessions without a reflector.

Conclusions / takeaways

• iBGP full mesh is not a protocol requirement, but a route visibility requirement.
• It is only necessary among routers that must have full visibility of all external routes.
• Designing an AS with explicit role separation and controlled route visibility can eliminate the need for a full iBGP mesh, while preserving correct routing behaviour and reducing operational risk.
• When full mesh is not required, deploying it unnecessarily violates the KISS principle (RFC 1958) and increases operational complexity.
• Multihomed stub ASes are a clear example where full mesh is not needed.
• Small local ISPs often fall into the same category.
• Some RFCs would benefit from clarification to avoid perpetuating this misconception.

References

[RFC1105] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1105, June 1989, <https://www.rfc-editor.org/info/rfc1105>.

[RFC1163] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1163, June 1990, <https://www.rfc-editor.org/info/rfc1163>.

[RFC1267] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol 3 (BGP-3)", RFC 1267, October 1991, <https://www.rfc-editor.org/info/rfc1267>.

[RFC1654] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1654, March 1995, <https://www.rfc-editor.org/info/rfc1654>.

[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995, <https://www.rfc-editor.org/info/rfc1771>.

[RFC1958] B. Carpenter, Ed. "Architectural Principles of the Internet", RFC 1958, June 1996, <https://www.rfc-editor.org/info/rfc1958>.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.

[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,<https://www.rfc-editor.org/info/rfc4456>.

[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, DOI 10.17487/RFC5065, August 2007, <https://www.rfc-editor.org/info/rfc5065>.