SD-WAN

HAAAAAPPPPPYYYYYYY FRIDAY EVERYONE!!!

I cannot believe Summer is almost here! I feel like it was just Winter and I was complaining about the cold and then all of a sudden BAM! Here comes Summer! (Yes, I do realize that I used the same introduction on the Feature Friday: Secure Edge Connectors post and this one. This was unintentional but I am keeping it now 🤪).

But you know what, I like Spring/Summer. Where I am, this is the time of year when the flowers start to bloom, I can go for a hike or a swim, I can start gardening. So many fun things I can do and since it is still Spring, I have several fun months to look forward to. I've already done a couple small hikes this Spring. I went over near the UMass Amherst campus, a Juniper customer btw, to do a small hike up Mt. Holyoke. I have a friend currently going there, so we got some food from the dining hall. Yum! I also did some small hikes at the Assabet River National Wildlife Refuge and the Sachuest Point National Wildlife Refuge. I saw a ton of wildlife including woodpeckers, beavers, and I could hear a band of coyotes (they were yipping and howling, not playing music). 

I love nature! As I mentioned before, I am really looking forward to Summer and all the other hikes I will be doing. I plan to hit up some of the 4000 Footers in NH (on our side of the US, mountains come pretty small). On that note, when I do go on hikes, I do like to plan my routes and have backup routes for when I get lost, or a path gets blocked. I bet you can see where I am going here… It's kinda like having…a…FAILOVER strategy!!! (That's right, it took me a while, but I did find a cheesy segue). 

When I think of SD-WAN, the number one feature that comes to mind for me is "session resiliency" or the ability to keep my active sessions alive even when I have a network issue. For example, if I am on a VoIP call and the there is an outage with one of my SPs, I'm able to keep the call up just by routing my packets through another SP. This can obviously be done on the Session Smart Router (otherwise I wouldn't be writing about it). 

However, there are a few things that differentiate the way the SSR does it as compared to our competitors.

First off, the failovers that happen with the SSR are done in less than a second. A main factor in this is our tunnel-free protocol, Secure Vector Routing or SVR. (You can read all about SVR here: Feature Friday: SVR Part 1 and Feature Friday: SVR Part 2). Most SD-WAN solutions out there use tunnels like IPSEC and GRE to protect your data. This is fine for protecting your information, but it has some downsides as well. One of those downsides is that it takes time to establish your tunneled connections. So, if you have a failover, you either need to wait the few seconds for the new tunnel to get set up, or you have to have your backup tunnel up at all times. This can be costly if you use a metered connection, such as an LTE backup. Also, you are limited to the number of tunnels you can have established at one time. Since SVR is treated like regular IP packets, that limitation does not exist.


Another advantage for the SSR is how we measure the quality of the path. As mentioned in the Inline Flow Performance Monitoring Feature Friday, we measure the quality of our links in 2 ways: in-line or out-of-band. The out-of-band method is going on all the time and is done by sending and receiving BFD messages. This lets us know how the path is doing without caring about the type of traffic we send on the path. However, we all know that networks treat traffic like voice and video differently than they treat data. So, with our in-line performance monitoring, we use the live traffic to tell you about the quality of the path. 

The SSR will then take the information it gets from both methods of path measurements to determine if it should failover a session or not. You can set the thresholds it will use to do this too! If you are managing your network with a Conductor, you will find those thresholds at the Service Policy. For SSRs managed by the Mist Cloud, it's at the Application. Just select "Custom" as your Traffic Type and input your Maximum Latency, Maximum Jitter, and Maximum Loss. Once those are set, when the session exceeds one of those limits, it will failover over to one of the backup paths you have set. You can choose for this failover to be revertible or not.

Speaking of backup paths, check out this Service Route Redundancy and Vectors Video to see all the different options you can use for backups.

Furthermore, this is all done application by application (or Service by Service for the traditional folks). So, I can go out there and set one set of criteria for my Voice Traffic, one for my Data traffic, and a third for any Netflix traffic. The number of possibilities are endless.

Subsecond Failover has so many things to talk about and I feel I have barely scratched the surface. Please ask your questions below and I will be very happy to elaborate. Here are some other things I would like to hear from you:

• Do you do failover on all of your traffic or just for some applications?
• How many backup paths do you have?
• What type of paths are you failing over between?
• What are your favorite Spring/Summer activities? Any recommendations on good hikes you have taken?
  
  

BTW, we are back in Vegas at The Cosmopolitan (my favorite hotel in Vegas, so far) for AI in Action on June 7^th and 8^th! Our free two-day event is designed to provide you with the insights you need to take your network to the next level, including a full day technical bootcamp on Thursday. Plus, join your peers for an afternoon of entertainment and networking opportunities with Juniper leadership. Click here to see the agenda and register. Hopefully we will see you there!

On that note, I hope you enjoy the rest of your Spring and I will talk to you in a couple of weeks! See ya!

#FeatureFridays #Failover #SVR #SessionResiliency