I was sitting down, having my cup of coffee, scrolling through Reddit, when I looked at the calendar and I saw something. I saw the date. And no, it is not my birthday. Nor is it a holiday. It's better than that. It's…
We've got a great one for you with this week's Feature Friday: BGP Over SVR.
This was part of the reason we did the 2-parter on Secure Vector Routing (SVR). Now I don't have to go into a ton of detail on SVR, but in case you didn't see those Feature Fridays and are too excited about this one to go back and read those (I get it!), then here is a quick Summary.
Summary/TL;DR on SVR
Secure Vector Routing is a protocol that is used when 2 Session Smart Routers (SSRs) are sending traffic to each other. SVR uses a metadata exchange during the session set up to allow for encryption and authentication without the need of additional headers, like you might see with tunneled protocols. In other words, you get all the same protections you would get from tunneled protocols, but without using as much bandwidth.
BGP Over SVR
You probably know that your Session Smart Routers can also share routes with non-SSRs through traditional routing protocols like BGP and OSPF. This capability is great for integrating with your existing routers and transitioning while you have some sites that are SSR managed and some that are still using their previous routers. Here's some info on configuring BGP on your SSR. And while this topic is not about OSPF, here's instructions on configuring OSPF.
BGP and OSPF are both considered dynamic routing protocols. This means that if a route change needs to happen, one router can tell other routers about that change and the change is made. Static routing protocols need to be manually configured in every router to take effect, a very slow and tedious task.
Before BGP Over SVR was created, if you wanted to use SVR when sending traffic, you would have to use Peer Service Routes on your SSR. This was the only way the SSR knew it was sending traffic to another SSR and thus knew the other SSR would understand SVR.
Service Routes are almost like static routes on steroids. You say, if I see traffic that matches this Service (remember, Services are defined by tenant, destination address, destination port, and transport protocol) then I will send the traffic to another SSR (Peer/Next Peer) or a gateway/host (Service Agent). With the Next Peer option, you can set up some backup routes, but it's not a truly dynamic routing method.
BGP gives us the dynamic routing ability, but it is not secure. There are extensions to the RFC that can make BGP more secure, but those usually include tunneling protocols and thus we lose our bandwidth savings.
So how do we get the dynamic routing of BGP with the security and bandwidth savings of SVR? Well, you already know the answer (I've been told I'm very bad at secrets). It's BGP Over SVR.
BGP Over SVR is simply allowing SSRs to send route information to each other using BGP but having that all protected by Secure Vector Routing.
IMO, there are 2 big advantages to BGP over SVR:
- The BGP is protected and sent via SVR - Not only does this mean our BGP is now secure, it also means we don't need to open any more ports in our NAT devices to allow BGP and SVR. We can keep our NAT devices how they are to enable the SVR (either opening port 1280 or using Peer-Connectivity: outbound-only).
- Any traffic we forward to routes we learned from other SSRs using BGP Over SVR will be sent as SVR traffic – We no longer have to use Peer Service Routes to send SVR traffic. Basically, the SSR knows that it learned the routes from one of its SSR Peers and thus knows to send traffic to that Peer via SVR.
This feature is so cool, that we use it in most of our deployments.
So how do we configure BGP over SVR?
Well, it's pretty simple (you'll find all the settings we are going to configure under the Routing Instance which is under the Router in the Data Model):
- We configure a Routing Interface. The Routing Interface is like a loopback interface. It's an IP address (it does not need to be routable) that when the SSR receives traffic headed to that IP address, it knows to forward that traffic to the Routing Engine.
- We then configure a BGP Instance with the router-id matching the Routing Interface.
- Lastly, we configure our BGP Neighbors with their Routing Interfaces as their addresses. Make sure to also set next-hop-self to true and add 1 to your multihop ttl.
Once you do that, the Conductor sees that the 2 SSRs are BGP peering using their Routing Interfaces and auto-generates a bunch of config to make it work (tenants, services, service-routes, etc.).
For more information, check out our documentation on BGP Over SVR.
And as with every FF, I want to hear from you now. Tell us what you think!
- Have you heard of BGP Over SVR before this Feature Friday?
- Are you using BGP Over SVR and how is it going for you?
- Do you have a topology that you would like to share with us that shows how you are using your BGP Over SVR?
- What other protocols would you like to see encapsulated in SVR?
Feel free to reach out if you have any questions. Looking forward to our next Feature Friday!
#FeatureFridays #SSR #SessionSmartRouter #BGP #BGPoverSVR #BGPPeering #OSPF #ServiceRoutes