]> Euskal Herriko Unibertsitatea (University of the Basque Country)

Ibaetako Campusa 20018 Donostia - Gipuzkoa - Basque Country jm.rivadeneyra@ehu.eus

Routing rtgwg (Routing Area Working Group) ibgp full-mesh stub-as A common misconception within the Internet community is that internal BGP (iBGP) strictly requires a full mesh or alternatives such as Route Reflectors. In reality, a full mesh is an architectural design choice driven by route visibility needs, rather than a protocol mandate. This document analyzes the historical origins of this misunderstanding and clarifies the specific scenarios—multihomed stub Autonomous Systems (ASes)— where an iBGP full mesh is unnecessary and operationally undesirable.

Introduction 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. This document explains 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.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Origin of the Confusion Much of the confusion surrounding the supposed requirement for a full iBGP mesh stems from the wording in early, now obsolete, versions of the BGP specification. In the first version of the protocol (), 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 focused on transit providers, which, at that time (June 1989), were essentially the only networks deploying BGP. Subsequent versions of the protocol retained similar wording:

• In and , the first statement was removed, but the second remained largely unchanged.
• In and , 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 neighboring autonomous system, it shall advertise that route to all other BGP speakers in its autonomous system by means of an UPDATE message.”

All these historical documents have since been obsoleted by the current standard, , from which any explicit mandate for a full mesh has been removed. The relevant rule 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 () and confederations () — still contain legacy wording that can be interpreted as implying such a requirement. For example, states:

• "Typically, all BGP speakers within a single AS must be fully meshed..."

While this wording reflects common operational practice rather than a protocol constraint, subsequent passages reinforce the perception that a full mesh is mandatory. This is particularly evident in , 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 regarding early design assumptions, perpetuate the misconception that a full mesh is a protocol requirement rather than a network 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 multiple mechanisms exist 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 attribute) only works between autonomous systems, not within them. That's why, to prevent loops within the AS, BGP prohibits re-advertising routes learned via iBGP to other internal peers. Consequently, a full-mesh will be required between all BGP routers in the AS. But this operational reasoning relies on a key assumption:

• Every BGP router in the AS is expected to have full visibility of all external routes.

While this assumption is valid for transit providers, it does not necessarily apply to stub ASes or edge ISPs. Therefore, it can be concluded that maintaining an iBGP full-mesh is a requirement only for transit ASes.

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 an internal core router (IR1, IR2, IR3).

Figure 1: AS stub multihomed without an iBGP full mesh BR2 ISP1 STUB Ebgp Ebgp ISP2 BR1 IR2 IR1 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 iBGP sessions necessary? In a stub AS that does not provide transit between its upstream providers, inbound traffic entering through one border router must always be forwarded toward internal core routers, never toward the other border router. In the event of an upstream link failure, internal core routers will withdraw the BGP paths associated with the affected BR and shift outbound traffic toward the remaining operational BR. This mechanism renders it unnecessary for border routers to be aware of alternative external BGP paths held by other internal border routers. Similarly, outbound traffic flows strictly from internal core routers to border routers, never between internal core routers. Consequently, regarding iBGP topology:

• Border routers only need to learn internal destinations to export towards ISPs. They do not require visibility into external routes learned by other border routers since transit traffic is prohibited. Thus, an iBGP session between BR1 and BR2 is unnecessary.
• Internal core routers (IRs) must learn external routes imported by both border routers (BRs). However, they have no operational need to exchange routes with each other; hence, iBGP sessions between IRs are unnecessary.

Furthermore, establishing an iBGP session between BR1 and BR2 noticeably increases the operational risk of accidentally re-advertising external routes, which could inadvertently turn the stub AS into an unintended transit provider. This example shows that in multihomed stub ASes, an iBGP full mesh is not strictly necessary and can be operationally detrimental.

Edge ISP A similar situation can arise in an edge ISP. This is illustrated in Figure 2, which depicts an ISP featuring:

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

Figure 2: Edge ISP without an iBGP full mesh T1 ISP Ebgp Ebgp T2 Up1 Up2 PoP2 PoP1 PoP3 P IXP n x Ebgp ]]>

Such an ISP must conform to the following transit rules:

1. It MUST NOT provide transit between upstream providers.
2. It MUST NOT provide transit between peers and upstream providers (in either direction).
3. It MUST only provide transit to its downstream customers.

Under these constraints, the routing requirements dictate that:

• PoP routers must maintain full visibility of routes from upstreams (via Up1/Up2), peering points (via P), and other PoPs.
• Upstream routers (Up1/Up2) and the peering router (P) only need to learn customer routes via the PoPs, and external routes via eBGP. They do not require visibility into each other's external routes.

Therefore, the optimized iBGP architecture establishes that:

• PoP routers maintain iBGP sessions with all other BGP routers in the AS.
• Up1, Up2, and P maintain iBGP sessions exclusively with the PoP routers, but not among themselves.

This design (see Figure 2) is simpler than a full mesh and reduces operational risk, particularly the risk of unintended transit between upstreams or peers. As in the stub AS case, the failure of an upstream or peering link does not require alternative path visibility at the affected border router, because the PoP routers will autonomously stop forwarding traffic toward it once the failure triggers a route withdrawal. Note that adopting a design based on Route Reflectors (RRs) can further simplify the iBGP topology, even for relatively small edge ISPs. For example, in the scenario shown in Figure 2, utilizing a central route reflector with iBGP sessions to all other routers in the AS would require only six iBGP sessions. This contrasts with the twelve sessions required by the partial-mesh design and the twenty-one sessions demanded by a traditional full mesh. Furthermore, with an adequate community-based configuration, the same isolation between router groups achieved by removing unnecessary iBGP sessions can be replicated within a route-reflector architecture.

Operational Considerations

Applicability of iBGP partial-mesh design While deploying an iBGP partial mesh is technically feasible in any AS that does not require full route visibility across all internal BGP speakers (i.e., non-transit ASes), its implementation is only recommended for stub ASes. For edge ISPs, although the partial-mesh option is viable and superior to a full mesh, utilizing route reflectors generally remains the best approach. The use of an iBGP partial mesh in stub ASes is not a novel technique, but it has rarely been documented (for example, see the case described in Figure 5.21 in . Currently, the dominant view in available documentation is that it is unacceptable to have multiple BGP routers in the same AS that are not connected via iBGP, even though it is common practice in stub ASes to forgo iBGP sessions between border routers for security and simplicity reasons.

Convergence Behaviour In designs where border routers (BRs) do not maintain iBGP sessions between them, internal core routers (IRs) act as the focal points for route visibility and path selection. In such a design, in the event of an upstream failure affecting a specific BR, a transient time lag occurs between the detection of the link failure by the BR and the moment the IRs cease forwarding outbound traffic to that BR. In a traditional full-mesh or RR topology, traffic arriving at the affected BR during this window is dynamically rerouted to alternative BRs via internal iBGP paths. This convergence behavior could be considered an operational advantage of full-mesh or RR architectures over a partial mesh. However:

• If a default backup route (as a floating static route) is configured on the affected BR, the behavior aligns with a full-mesh/RR topology; the BR immediately redirects outbound traffic toward the alternate BR upon losing its upstream link.
• In any case, the time lag between link failure detection at the BR and route convergence at the IRs is minimal —on the order of milliseconds— rendering it insignificant in most enterprise and edge scenarios. This is because the BR will immediately send route withdraws to the IRs via iBGP, since the MRAI (Minimum Route Advertisement Interval) for iBGP is 0 seconds by default across modern routing platforms.

Risk of Misconfiguration A main argument in favour of avoiding unnecessary iBGP sessions is the reduction of potential misconfiguration scenarios (e.g. unintended transit). However, topological simplification should be viewed as a complementary defense-in-depth measure, and not as a complete substitute for rigorous routing policy design enforced by well-defined prefix filters and export rules.

Conclusions

• iBGP full mesh is not a protocol requirement, but a design choice driven by the need for route visibility and operational considerations.
• iBGP full mesh is only strictly necessary among routers that must have full visibility of all external routes. This is, in transit ASes.
• In multihomed stub ASes, deploying an iBGP full mesh violates the KISS principle () and introduces unnecessary operational risk.
• In edge ISPs, an iBGP partial mesh offers a more robust deployment model than a full mesh, though route reflection remains the best practice.
• The legacy assumption of a mandatory full-mesh design found in several foundational RFCs dates back to an era when transit providers constituted the vast majority of BGP deployments. Given the modern internet landscape, where multihoming and BGP utilization are standard requirements for enterprises, clarifying some RFCs would benefit the community, preventing the perpetuation of this architectural misconception about iBGP full-mesh requirement.

IANA Considerations This memo includes no request to IANA.

Security Considerations This document does not modify the underlying security properties of any existing Internet protocol. However, adherence to the Simplicity Principle () directly enhances the stability and security of network architectures. Minimizing unnecessary iBGP sessions explicitly reduces the internal configuration surface, thereby mitigating risks associated with human error, such as accidental transit provisioning.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This RFC outlines a specific approach for the exchange of network reachability information between Autonomous Systems. Updated by RFCs 1163 and 1164. [STANDARDS-TRACK] This RFC, together with its companion RFC-1164, "Application of the Border Gateway Protocol in the Internet", specify an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK] This memo, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK] This document defines an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK] This document, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK] The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan. While this process of evolution is one of the main reasons for the technology's success, it nevertheless seems useful to record a snapshot of the current principles of the Internet architecture. This is intended for general guidance and general interest, and is in no way intended to be a formal or invariant reference model. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for TCP/IP internets. Typically, all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that Autonomous System (AS). This represents a serious scaling problem that has been well documented with several alternatives proposed. This document describes the use and design of a method known as "route reflection" to alleviate the need for "full mesh" Internal BGP (IBGP). This document obsoletes RFC 2796 and RFC 1966. [STANDARDS-TRACK] The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/Internet Protocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals. This document describes an extension to BGP that may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system. This document obsoletes RFC 3065. [STANDARDS-TRACK]

Acknowledgements This document uses extracts from templates written by , and .