In our previous blog, we explored eBGP — its configuration and key operational rules. Now, let’s take it a step further as we dive into iBGP.
iBGP, or Internal Border Gateway Protocol, is another flavor of BGP where both the local and remote routers belong to the same Autonomous System (AS).
In this blog, we’ll break down what iBGP is, how to configure it step by step, and the fundamental rules every network engineer should be aware of.
What Is iBGP?
Internal Border Gateway Protocol (iBGP) is a type of BGP session established between routers within the same autonomous system (AS). Unlike External BGP (eBGP), which connects routers across different ASes (such as between different organizations or ISPs), iBGP coordinates route advertisements and policies internally, ensuring all routers in the AS maintain a consistent view of the network’s available paths.
Key attributes of iBGP:
- Facilitates sharing of BGP-learned routes across all routers in the same AS.
- Enhances route policy control, redundancy, and scalability within enterprise or service provider networks.
- Helps routers build uniform routing tables to make optimized forwarding decisions.
Why Do We Need iBGP?
While Interior Gateway Protocols (IGPs) like OSPF or EIGRP manage internal routing, they fall short when it comes to propagating external route information (those learned from eBGP) throughout a large AS, especially when handling thousands of internet prefixes. iBGP bridges this gap by allowing BGP routes from other ASes to be distributed internally, making it indispensable for ISPs and large enterprises that connect to multiple external networks
Key benefits:
- Prevents suboptimal routing by ensuring all routers have complete BGP visibility.
- Enables granular traffic engineering and policy enforcement inside the AS.
- Essential for networks acting as internet transit providers or connecting to multiple upstream ISPs.
Basic Rules of iBGP
iBGP has its own set of operational rules, distinct from eBGP and IGPs:
- Full Mesh Requirement: All iBGP speakers (routers) must form a full mesh, i.e., each iBGP router must establish a session with every other iBGP router in the AS. This ensures all routers learn about all routes and prevents routing information black holes.
- Split Horizon Rule: Routes learned from one iBGP peer are not advertised to another iBGP peer by default (called the iBGP split horizon rule). This prevents routing loops since iBGP does not modify the AS path attribute.
- No Direct Connection Requirement: iBGP routers don’t need to be directly connected. They can communicate as long as there’s IP reachability between them. By default TTL value is 255.
- Next-Hop Handling: The next-hop attribute is not changed by default in iBGP. This can lead to routing issues if the next-hop IP is not reachable by all routers; solutions include using the next-hop-self command or deploying IGPs for reachability.
- Scaling with Route Reflectors: In large networks, maintaining a full mesh becomes impractical. Route Reflectors or Confederations are used to reduce the session overhead.
How to Configure iBGP: Step-by-Step
Here’s a generalized step-by-step guide, using Cisco-like syntax for clarity. The process is similar across major platforms
To understand iBGP configuration we use the below topology please have a look –
Lab Topology Overview
- R1 – AS100
- Interface g1/0 – 12.1.1.1/24
- R2 – AS200
- Interface g1/0 – 12.1.1.2/24 (eBGP with R1)
- Interface g2/0 – 23.1.1.2/24 (iBGP with R3)
- R3 – AS200
- Interface g2/0 – 23.1.1.3/24
Goal:
To clearly highlight the difference between eBGP and iBGP configurations, I’ve included both scenarios in this lesson.
- Establish eBGP between R1 and R2.
- Establish iBGP between R2 and R3 (same AS).
Step-by-Step Configuration –
Step 1: Basic IP Configuration
| R1 | R2 | R3 |
| conf t interface g1/0 ip address 12.1.1.1 255.255.255.0 no shutdown | conf t interface g1/0 ip address 12.1.1.2 255.255.255.0 no shutdown exit interface g2/0 ip address 23.1.1.2 255.255.255.0 no shutdown | conf t interface g2/0 ip address 23.1.1.3 255.255.255.0 no shutdown |
Step 2: Enable eBGP Between R1 and R2
| On R1 (AS100): | On R2 (AS200): |
| router bgp 100 neighbor 12.1.1.2 remote-as 200 network 12.1.1.0 mask 255.255.255.0 | router bgp 200 neighbor 12.1.1.1 remote-as 100 network 12.1.1.0 mask 255.255.255.0 |
Step 3: Enable iBGP Between R2 and R3
Since R2 and R3 are in the same AS (200), we configure iBGP:
| On R2: | On R3: |
| router bgp 200 neighbor 23.1.1.3 remote-as 200 network 23.1.1.0 mask 255.255.255.0 | router bgp 200 neighbor 23.1.1.2 remote-as 200 network 23.1.1.0 mask 255.255.255.0 |
Step 4 – Verification –
Once BGP was configured on all the routers, the sessions established successfully. Below is the status showing both eBGP and iBGP peering are up and running.
Where Should You Use iBGP?
iBGP is not just a theoretical concept; it’s a practical necessity in many modern networking environments. Let’s explore where iBGP plays a crucial role:
- Service Provider Environments:
Internet Service Providers (ISPs) rely on iBGP to seamlessly share routes learned from their clients and upstream peers across their internal backbone. This ensures that every edge and core router knows how to forward packets effectively. - Large Enterprise Networks:
Enterprises that are connected to more than one ISP or have multiple branch offices benefit greatly from iBGP. It allows for granular routing policies, improves fault tolerance, and ensures optimal path selection across complex topologies. - Data Centers & Cloud Architectures:
In highly distributed environments such as data centers or cloud platforms, iBGP helps distribute external routes between edge devices and internal routers. This is vital in multi-homed setups where consistent connectivity and failover routing are required.
iBGP Troubleshooting Tips
Encountering issues with iBGP configuration or stability? Here are some quick pointers to help you debug:
- IGP Reachability:
Ensure that all BGP routers can reach each other’s loopback interfaces. This is especially important when loopbacks are used as BGP identifiers. - Check Port 179:
BGP sessions use TCP port 179. Confirm that no firewall or ACL is silently blocking BGP communication between peers. - Split Horizon in iBGP:
Remember, iBGP doesn’t advertise routes from one iBGP peer to another. If you’re not using a full mesh of iBGP sessions, consider deploying Route Reflectors to overcome this limitation.
Summary –
iBGP is a foundational tool for maintaining route consistency and enforcing intelligent routing decisions within a single Autonomous System. It empowers network architects to implement policies with precision, enhance fault tolerance, and scale the network without chaos.
Whether you’re managing a global ISP backbone or a hybrid enterprise cloud, mastering iBGP will give you the confidence to build smarter and troubleshoot faster. And now that you know when and where to use it — you’re one step closer to BGP mastery.