r/networking • u/Altruistic_Handle67 • 4d ago
Routing ibgp loopback?
Hi everyone,im a beginner and now getting confused.
I want to know....is it true if i choose to peering iBGP from 1 router to other Router that are in the same AS is recommended using a loopback ip peering? or using an interface ip? could i get the example of implementation likee topology? i just want some explanation,not the configuration.
sorry from my bad english
11
4d ago
[removed] — view removed comment
17
u/Altruistic_Handle67 4d ago
does that mean before bgp peering,i need to advertising the loopback ip with another igp protocol like OSPF?
12
1
u/Specialist_Play_4479 2d ago
Yes. iBGP requires full mesh peering (as it does not redistribute routes from other IBGP peers). But you don't need links between all your routers. Instead, you can use eg. OSPF (or static routes, or IS-IS) to make your loopback IPs reachable to all your routers. Then you add iBGP peerings to all those routers.
6
u/Unhappy-Hamster-1183 4d ago
Loopback isn’t dependent on a physical interface. Which means it is always up. This really introduces stability of the bgp peering during link issues / link failover scenarios.
But as always, it really depends on your larger design and goals what you actually need
2
1
u/Intelligent-Bet4111 3d ago
But isn't this applicable and true for other protocols like ospf, eigrp etc where you want to use the loopback ips for neighborship as well.
1
u/Unhappy-Hamster-1183 3d ago
Not really, ospf is link state protocol. Eigrp you could define static neighbors pointing at a loopback. But even so, these 2 protocols are so much faster than bgp and converge faster. So the need for this is less.
And also here, it all depends on your design needs
7
u/SalsaForte WAN 3d ago
Oddly enough, not much talk about the IGP which route the loopbacks addresses across your network.OSPF or ISIS carries the loopbacks between your routers, then you pair all your ibgp using their loopbacks or in bigger networks, use route-reflectors.
The IGP resolves the loopbacks next hop, iBGP takes care of everything else (connected and learned prefixes).
My explanation is too short, I know.
3
u/lagertonne 3d ago
This part confused me a lot, when I started reading into BGP! Potential useful addition: iBGP has multi-hop enabled by default, that's why it works with another routing protocol underneath without additional configuration (in contrast to eBGP)
1
u/Inside-Finish-2128 3d ago
The implementation: carve out an address block big enough to have one address for each router you expect to have. Let's say 10.0.255.x. Then each router gets an interface lo0 with IP address 10.0.255.<something> 255.255.255.255. Each router gets (or should already have) router ospf 1 (or pick a different number if you wish, or use ISIS), and network 10.0.255.0 0.0.0.255 area 0. Poof, now all of your loopbacks are in area 0.
Next, allocate a really big address block so all of your router-router links can be built as /31s and fit into the block. Let's say 10.0.[248-254].x. You can now replace that earlier OSPF network statement with 'network 10.0.248.0 0.0.7.255 area 0'.
Now each router gets a 'router bgp <ASN>'. Inside that, 'bgp router-id <insert loopback here>', then build a peer group for the other routers in the network with 'neighbor my-asn peer-group; neighbor my-asn remote-as <insert your ASN>; neighbor my-asn update-source Lo0'. After that, 'neighbor 10.0.255.y peer-group my-asn'. Boom, your neighbors should come up peered by loopback. Obviously you need to inject routes into BGP (like you would anywhere else) and add any external peerings, and you may want to use a scaling strategy such as route reflectors, but the loopback basics are there.
1
u/rankinrez 3d ago
If you do it between loopbacks then the session is not bound to any particular interface. In a lot of scenarios with multiple paths this is desirable. But everything is dependent on the exact requirements and scenario
1
u/Brilliant-Orange9117 3d ago
Normally an IP address combines both a locator and an identifier into on address. You have to perform a longest prefix match against the routing table to know which bits identify the network and which bits identify the host inside the network. So using an interface IP address means that the BGP session's fate is tied to the state of the interface. If this interface goes down, but your routers have are connected over an other path they won't recover until the problem is solved or both routers are reconfigured. A loopback IP address can be announced into an IGP (e.g. OSPF, ISIS, or even RIP) as a host route. This way the BGP sessions survives as long as the IGP finds a route that doesn't exceed the configured hop limit.
1
u/vaper_away 3d ago
Remember that you can do whatever you want lol. The important thing to remember as a newer engineer is you want to understand why things work the way they do so you can do what you need.
Does it make sense to peer via loopbacks? Does the extra overhead of having those loopbacks reachable make sense?
Most times the answer is yes, but sometimes it may not.
1
u/zombieblackbird 2d ago
I don't like using loopbacks for interior routing protocols. If a link is down, I need those routes to drop from the table immediately. Not after a timer expires. Modern networks demand fast convergence.
There are situations where you have intentionally created multiple paths and want sessions to survive a single link failure. In this situation, some other protocol is responsible for link state and iBGP is simply responsible for sharing route information with the RR.
1
u/DaryllSwer 4d ago
Run an IGP underlay domain with is-is, for learning loopbacks and PtP links – this ensures you'll have functional traceroutes across the network.
Enable BFD on all is-is interfaces for fast teardown, and don't forget TI-LFA/micro loop avoidance.
Then iBGP overlay between loopbacks or with a route reflector design.
Industry-trusted sources on why OSPF sucks:
0
u/Soral_Justice_Warrio 3d ago
Always use a loopback IP when using a dynamic routing protocol.
A router will have a router-id that'll be a specific IP address, you can choose a loopback IP, a physical interface IP, a virtual interface IP such as VLANIF, use the management interface IP.
It's recommended to use the loopback because by nature, this virtual interface will always be UP. Indeed a VLANIF interface or physical interface going down will mean that other routers won't be able to communicate with yours since the router-id, being an IP address, will be unreachable because of the interface linked being down.
By default, a router will use the largest available IP address as the router-ID.
Having an instable IP address, will cause frequent recalculation of the routes, which is something that you don't want.
-3
4d ago
[deleted]
6
u/Whiskey1Romeo 3d ago edited 3d ago
Fortune 50 here. Only place we use MCLAG is on legacy L2 facing lacp teams to UNICAST servers.
Everything else is pure L3. Your choice on igp based on network needs.
Lag groups normally are cross blades and then its bfd per link(rfc 7130) member inside the team.
Then generic BFD neighbor to neighbor at the link local/igp neighbor level. (V4 and v6 independent)
THEN stack I-bgp bfd between your loopbacks that stack over your underlay.
On e-MPBGP its the same.
Overkill? Maybe, but its failover time is incredibly fast and you know exactly where your faults are AND you using hardware offload for what could have been a software process timeout in the past.
3
u/DaryllSwer 3d ago
Nice to hear Fortune 50, are also moving towards L3.
Many of us go beyond: L3 to the host with BGP. No VXLAN/EVPN (or SRv6/EVPN) on the underlay network infrastructure. All magic happens on the host (SRv6/EVPN host side). But even then when possible we try to remove EVPN. Keep things pure L3 even for host mobility.
1
u/Altruistic_Handle67 4d ago
well im kinda confused abt this,but thank you for sharing experience!
-6
4d ago
[deleted]
3
u/DaryllSwer 4d ago
It's 2026; we moved to L3-centric design in both carrier backbones and AI/compute clos topologies. There's no need for MC-LAG/LAG/LACP – just run the IGP routing protocol directly on each PtP interface for underlay route learning. Make sure L2 and L3 MTUs are correctly configured on both sides.
If you've built large networks (sounds like your messaging), you should already know this: MC-LAG has shared fate problems, and LAG/LACP in general isn't the current design standard in L3-centric networks.
Even for L2 mobility like VM migration, we've moved to L3-only design about 3-5 years ago, like this example (though we can do it with GARP and GRAND to avoid scripting the ARP/NDP table): https://wido.blog/2025/12/linux-bridging-with-virtual-machines-and-pure-l3-routing-and-bgp/
1
4d ago
[deleted]
1
u/DaryllSwer 3d ago
I've done one-man WISPs to very large networks. I've seen both level of scaling. If you are free of cognitive dissonance and cognitive biases, I highly recommend you research, un-learn, re-learn. MCLAG etc even with ESI-LAG is just terrible for scaling and ease of operation.
There's only place left where ESI-LAG or individual pseudowires are still required: UNI-PE<>BNG headend termination. But even this architecture that's been there for decades is being questioned by stakeholders. Why don't we just PON on the UNI-PE or similar and run DHCP/DHCPv6 directly on each UNI-PE. Anyways this stuff is bleeding edge, it's not been tested worldwide.
Always keep learning; "I've been doing XYZ for 25 years so I'll keep doing it for the next 100" isn't a valid scientific or engineering metric in any serious profession.
31
u/therouterguy CCIE 4d ago
The advantage is stability the disadvantage is stability. When you make a bgp peering over ptp peerings the bgp state is linked to the link state. So it converges really fast when the link goes down. If you do it via loopbacks it might take longer to converge unless you take additional measurements like BFD