Log in to ask questions, share your expertise, or stay connected to content you value. Don’t have a login? Learn how to become a member.
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:
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):
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!
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