Looking for a Simple Multihop EBGP Use Case
I plan to add several challenge labs using multihop EBGP sessions to the BGP labs project, including:
- Running BGP between VMs and central BGP route servers
- Using multihop EBGP session to send full Internet routing table to a customer without overloading the PE-router
- Running EBGP EVPN session between loopbacks advertised with EBGP IPv4 session (🤢)
However, I would love to start with a simple use case to help engineers unfamiliar with BGP realize when they might have to use multihop EBGP sessions. Unfortunately, I can’t find one, and the scenarios where I used multihop EBGP in the past (EBGP load balancing and using a low-end router in the EBGP path, where I was effectively using the reverse application of #2 as a customer) are mostly irrelevant.
Would you have an easy-to-understand use case that is best solved with a multihop EBGP session? Please share it in the comments. Thanks a million!
You would need it over unnumbered interfaces too
Although more a technicality than a use case...
True, if you want to run a pure IPv4 setup, but then you'd need a route for the EBGP endpoint, so it's either dynamic routing (and why would you use that with EBGP?) or static route.
Maybe I could make this somewhat reasonable with DHCP over unnumbered VLANs.
When a firewall is in the path and doesn't support BGP, or can't handle the full Internet routing table, multihop EBGP is useful. This also applies when firewall administrators prefer not to manage BGP routing technology.
This is the scenario I have used multihop for, when there was a fw or device that wasn't going to play well with bgp in the middle.
Thank you. Peering across a firewall is a clear winner ;)
Inter-AS Option-C? Although this might align with your point #1
https://learningnetwork.cisco.com/s/question/0D53i00000Ksqy9CAB/interas-option-c
mh eBGP between RR inter-AS, carrying AFI/SAFIs typical of the service-layer, like VPNv4/6 or L2
Thank you. That would definitely be a use case, but way too complex for an intro-to-BGP lab exercise. Will add it as a challenge lab if I ever decide to create MPLS/VPN labs though.
You have to connect two administrative domains with a firewall (or even with double chained diverse firewalls) separation. You want to keep the firewalls BGP free, not impacted by the configuration of the two domains. You use only static routing between the border routers through the firewalls. So the interconnect is very robust and stable. You are not allowed to use tunnels, since you want to see the traffic in the firewalls in their natural form for filtering and analysis. Multicast shall be also supported. Use multi-hop eBGP to dynamically advertise routes from the two administrative domains.
Start with a single path and then go to the next level of complexity: You have two geographically separated sites for the firewalls. Each site has a double redundancy in border routers and firewalls. So you have 4 possible paths between the two administrative domains. Now you have to configure a quick failover between those 4 paths using multi-hop BFD to detect path failures. All physical connections are 1 Gbps, so overhead is not an issue.
Next step: Configure active-active usage of the 4 paths. Load balance the traffic so that a path failure would temporarily impact only a portion of the traffic (even that we have a quick failover).
This is a real life example. I have seen it in mission critical or safety critical networks or even in service provider networks.
Thanks a million. Peering across a firewall is a clear winner (simple, easy-to-explain use case), but I will definitely add at least the basic redundancy if not the full-blown multi-site setup as challenge labs.
Within Azure vWAN you need eBGP multihop, otherwise there is no connection to your neighbour within Azure. And to reach the neighbour, you will need to add a static route towards Microsofts default gateway since there is no other underlay. Not sure if its the same contruct on other public clouds.
Thank you! I should remember the details (as I was doing Azure webinars not so long ago), but I guess I'll have to go over the slide deck again.
IIRC, it's effectively a riff on the "low-end router in the middle," this time the Azure virtual router with no externally visible control plane.
Might add this as an advanced scenario (if I figure out how to emulate the Azure environment).
We use eBGP multi-hop in 2 main use-cases, but both are similar. 1. for lab environment. We use a single switch that uplinks to the cores and has 2 connections towards a firewall (one inside in VRF A, one outside for LAB environment in VRF B). It keeps the firewall outside BGP, with only static routes and its easier for a local person with less experience to configure.
Thank you! Effectively this is a firewall-on-a-fat-stick scenario with two VRFs on the same router.
Will add it as an advanced scenario as it requires twiddling router IDs as well.
Peering with RouteViews outside of IXs
Thank you. Added as "Centralized route collection service"
Not what you asked, but if you're looking to add more BGP labs then something focused on RPKI might be cool to have. Routinator (by NLnet Labs) is the easiest way I've found to lab RPKI. It can run containerized in containerlab. Stuffing it into a Vagrant box for easier netlab support shouldn't be difficult either.
> but if you're looking to add more BGP labs
I hoped to wrap up this project after almost a year, but new ideas keep coming in. Not that I would mind ;)
> something focused on RPKI might be cool to have
Thank you, will add to the list of ideas.
> It can run containerized in containerlab.
That's great to know. Netlab can run a mix of VMs and containers (using containerlab), so the deployment seems to be a no-brainer. Can I contact you for details once I find time to work on this one?
> Can I contact you for details once I find time to work on this one?
Sure thing. I need to do some legwork anyway, maybe I can provide a draft? I'm writing with a named account so you have my e-mail.
We use multihop eBGP sessions for sending remote trigger black hole routes with one of our transit providers.
Thank you. You gave me idea for yet another BGP lab ;)
Maybe a simple scenario might be that there is link with special requirements, say, high-bandwidth or an uncommon port type. A router (not a switch) is available to handle the link, and can forward traffic, but it can't do BGP. And the router that can do BGP can't handle the link.
That's exactly what I've been doing in the 1990s, and the "uncommon port type" was an async link.
Functionally this is equivalent to peering over the firewall, so I'll probably keep that one.
Thank you!