Cloud Router: Custom Learned Routes
“...what if I do not control the BGP peer on the other side?”
Yesterday, Google Cloud announced a very interesting feature for Cloud Router: Custom Learned Routes (CLR). This feature is helping companies to control outgoing traffic in case they do not control BGP peer “on the other side”.?
In a regular situation, where we do control both sides of a BGP session, we can configure the BGP protocol to exchange prefixes we like. What if we have a situation where Cloud Interconnect or HAVPN is established between an entity which is outside of our control? This “external entity” has policies which do not allow them to send to our BGP router some of their IP prefixes which we need in order to contact them. Yes, I know it’s odd but trust me, I’ve come across many odd cases in my life.
Our solution may be a static routing in a VPC where we point out that some prefix (for the sake of clarity let’s assume 192.168.100.0/24) is reachable via Cloud Interconnect or HAVPN. Looks simple but there are some limitations in GCP. For instance, for static routing in VPC we cannot leverage Coud Interconnect or HAVPN endpoint as a destination.
There’s another drawback with static routing: it’s static. Which means, it does not reflect the change of state of path. It’s always on. Even if the path is unreachable (VPN down, endpoint down) routing stays on. Dynamic routing on the other hand is reflecting state changes in a path.
This is where Custom Learned Routes come into play. It’s a kind of a routing hybrid. Which means that it’s a manual entry - but behaves like sourced from BGP. Hence we cannot call it “static” and this is why I used “manual entry” term. Let’s look into it a bit deeper.
Lab setup
In order to present CLR, we’ll use the following HAVPN setup which is available in terraform;
Setup is relatively simple. We have two projects which emulate on-prem and cloud environments:
In prj-onprem we a vpc-onprem with two subnets in two different regions:
In prj-cloud we have a vpc-cloud with two subnets, both in europe-west1 region:
In each VPC we have configured HAVPN and a single cloud router in order to support BGP sessions. Someone may ask: why are you using a single router for HA VPN? The answer is simple: Cloud router in this case is redundant (two software tasks on a backend). If you’re interested in reading more, here’s documentation link
HAVPN gateways and cloud routers are sitting in a different region: europe-central2 in order to make routing a bit more interesting. We remember that VPC in GCP is a global entity and with a proper configuration we have full connectivity across VPC.
User story
On the on-premise side there’s a new service we need to access. This new service is sitting in the 192.168.100.0/24 subnet. To make things complicated, an IT engineer from the on-prem, who knows BGP is on vacation. We could use static routes on a cloud router - but knowing the limitations we won’t get far. This is where CLR (Customer Learnd Routes) are coming handy.
领英推荐
Solution
All we need is to configure CLR. We go to the cloud router, EDIT given BGP session, go to “Advertised routes, custom learned routes” and add “Custom learned routes entry”: 192.168.100.0/24 with relevant metric (200 in my case)
I did the same for another BGP peer with one difference: metric 300
Here’s how it looks on a diagram:
We have two BGP peers in on a cloud router in prj-cloud project with configured two CLR’s:
Let’s have a look at the routing table from europe-central2 perspective, where we can see two routing entries pointing towards BGP peers - hence they look like they will be coming from BGP.
Looks like we addressed the routing problem with “hybrid routing”: manual entry which behaves like a BGP injected prefix. The benefit is that, once peer goes down - routing entry vanishes like we’d expect from a dynamic routing protocol.
If someone is interested in looking deeper, you may want to check how routing looks in europe-west1. You can see in there prefix 192.168.100.0/24 but with different metric: 422 and 522. Why? Because there's an inter-region metric of 222 between europe-central2 and europe-west1.