HAPPY FRIDAY EVERYONE!!!!
I can't believe we're already towards the end of September! In New England, we're entering the fall months, which means leaves changing colors, apple picking, pumpkin spice lattes and…FEATURE FRIDAYSSSSSS! (Okay, Feature Fridays are all times of the year… I think I have a problem)
Anyway, for this Feature Friday I want to discuss Ethernet Over SVR or EoSVR.
Secure Vector Routing (SVR) Recap
To recap a little, a few weeks ago we did a two-parter on Secure Vector Routing (SVR) and how it enables you to send traffic securely without the added overhead of using tunneled protocols. Pretty cool stuff. For a refresh, check out these posts: SVR Part 1 and SVR Part 2.
We then went and talked about how we can use SVR to advertise BGP routes to other Session Smart Routers (SSRs). This is what we call BGP Over SVR and gives you the ability to use a dynamic routing protocol while also getting the encryption, authentication, and reduced bandwidth that you all know and love with SVR. You can review the BGP Over SVR post here.
At the end of the BGP Over SVR post, I asked what other protocols you would like to see protected by SVR. Well, in this post, I want to discuss one of those other protocols, and this time it is a Layer 2 protocol. Ethernet!!!!
Ethernet Over SVR
Ethernet Over SVR allows you to extend your Layer 2 network across multiple sites. So, we could have 2 branches in the same L2 domain with a WAN in between them, all of this being protected by SVR.
Extending our L2 network across sites allows devices to talk to each other on the same broadcast domain even though they are in different physical locations. You also have the ability to retain your IP and MAC addresses when you move your servers to new locations. This can be very useful for license conservation.
When comparing Ethernet Over SVR to traditional MPLS networks, you also get the following benefits:
How it Works
The way Ethernet Over SVR works with the SSR is Layer 2 and IP traffic destined for your LAN arrives on the SSR and is transported over an Ethernet Over SVR bridge to the destination SSR within the customer network. The bridge is configured between no more than two routers, and the configuration is validated before committing it to the running config.
There are four types of packets that are enabled for Ethernet Over SVR:
Ethernet Over SVR in Use
I could talk about the benefits Ethernet Over SVR all day, but I'm told people like to know how it's actually being used by customers. Well, our customers and partners, CMC Networks and Redvine, have partnered to deliver EoSVR to their customers in Africa. Their goal with EoSVR was to deliver a dedicated layer 2 service between any two nodes enabling services that normal layer 3 networks can't. One of their biggest realized benefits is that EoSVR enables them to quickly upgrade core infrastructure without impacting customers. Read this article to learn more about how CMC and Redvine are using EoSVR.
If you are interested in learning more about Ethernet Over SVR, check out our documentation:
Alright, now it is time to hear from you:
I hope you all enjoy the start of fall and I cannot wait to speak to you soon! Take care!
#FeatureFridays #SVR #SSR #ethernet #L2 #vxlan #CMC #Redvine
Great write up Justin! What is the limitation that forces an EoSVR bridge to only be configured between two routers? will an EoSVR with a Point to Multi-Point configuration on the SSR road map? If so, is there a time frame?We are utilizing EoSVR for communication between our Door Access Hubs and their controller. There is a limitation with the Door Access system that we use, that requires it to have a controller for each location, and each controller has to be managed separately and there is no syncing of user accounts between the controllers. We want to manage our door access at multiple locations from a single controller, to simplify the management of users, cards, and locations. At Site A we have Device/Network Interface configured with a subnet on VLAN 30, with the Door Access Controller and some Door Access hubs for that site tagged to VLAN 30. We have an EoSVR bridge configured between Site A and Site B. At Site B we have Door Access Hubs also tagged to VLAN 30. The Door Access Hubs are now on the same L2 network as their controller and work just like they should as if they were installed at Site A. This has been configured for a few months now, and we have not experienced any issues so far!Now our next hurdle is to configure EoSVR Bridges for Site C, Site D, and Site E to connect to Site A in the same fashion. But with the current limitations of EoSVR, it looks like this is not possible yet.