Buongiorno everybody! (I recently went to Italy, so I am obviously fluent in Italian now).
How are you all doing?
We just passed the first official day of summer! You might remember from my previous post that I was really looking forward to all the fun summertime activities: hiking, swimming, camping, etc. Well, I have some good news/bad news on that front. Bad news: I have not done any of those things yet ☹. Good news: the reason I haven't done it yet is because I bought a house and I am moving!
So, my life has pretty much been spent getting my current house ready to sell. There is so much cleaning, repairing, and purging I need to do. I have papers and books from several lifetimes ago that I just need to get rid of. It feels good to get rid of these things.
It kinda makes me think of how it feels good to get rid of some of the middle-boxes you may have in your network. With the right SD-WAN router, you can save money and time by having less devices on your network that you need to learn how to use, configure, maintain, and troubleshoot. Doing spring cleaning of your life and network can be a beneficial activity.
For this week's FF, I want to discuss one of the features within the Session Smart Router intended to do just that: the Session Load Balancer.
I wrote about this feature a long long time ago. It's such a blast from the past to see that post and the old SSR screenshots. Truthfully, I forgot I even wrote about it until one of my friends pointed it out and asked me to do an update. So here I am. (I was so formal in those older posts…)
The first thing I want to point out about the Session Load Balancer feature is the name: "Session Load Balancer." The intent of the feature is to perform load balancing based on active sessions – it has nothing to do with bandwidth. If you want to do some more complicated routing based on bandwidth, then you will want to perform Traffic Engineering.
The primary driver behind the SSR's Session Load Balancer is it's Session Stateful behavior. (I'm sorry, that sentence also feels super formal). What I mean by that is the SSR can do Session Load Balancing because it knows everything about every packet related to a session and thus can make sure all of the packets for that session go to one destination while all of the packets of a separate, but almost identical, session go to a different destination.
Another key factor in all of this is NATTING. The way we make Session Load Balancing work is first we define a Service with an IP address/port-range/protocol/tenant that will represent the Service, not the IP address of any of the servers we are ultimately load balancing between. I like to think of this as a dummy IP address.
After we define the Service, we define a Service Policy for that Service which determines our load-balancing strategy. We have 2 options:
For both strategies, you will define your destination servers by number of active sessions or maximum session rate. With hunt, the SSR will send traffic to whichever destination has the most capacity until it has hit the limit and then move on to the next destination. For example, if there are 3 possible next-hops and 1 can handle 500 sessions, 1 can handle 300 sessions, and 1 can handle 200 sessions, then the first next-hop will be selected until it is handling close to 500 sessions, and then the second next hop will be selected. In the case of proportional, the SSR sends the traffic to each destination in proportion to how many sessions each destination can handle. For example: if we look at the same next hops as before: 1 that can handle 500 sessions, 1 that can handle 300 sessions, and 1 can handle 200 sessions, then the first next-hop will get 50% of the traffic, the second will get 30% and the last will get 20%.
So now we just need to define the actual destinations we will route to/load balance between and their capacities. The Service Route is where we put in the actual IP addresses/ports we want to send our traffic to (so not the dummy ones) and the Service Route Policy is where we define the capacities. You will want to create one of each of these for each server you want to load balance between.
Ok, to put it all together, let's say I have 3 servers I want to load balance between, proportionally:
172.16.128.1 – 500 sessions
172.16.128.2 – 300 sessions
172.16.128.3 – 200 sessions
I create 1 Service called "Load-balance" with an IP address of 128.128.128.128 (dummy IP address). I create a Service Policy for Load-balance with "proportional" set for my load-balancing strategy. On the destination router, I create 3 Service Routes for Load-balance, each one pointing to a different one of those 3 IP addresses. I then create a Service Route Policy for each one of those Service Routes where I put in the capacities for each destination.
I will tell all my end clients to send their traffic to 128.128.128.128. When that traffic hits my final router (the one doing the load balancing), they will see the 128.128.128.128 destination address and send it to 172.16.128.1, 172.16.128.2, or 172.16.128.3 depending on the current number of active sessions.
Does that make sense?
Let me know if this makes sense and if you have any questions. I also have my normal questions for you:
- Have you tried the Session Load Balancer?
- Any thoughts on how it works?
- Which middle-boxes do you want to get rid of?
- Did you do your Spring cleaning this year?
One announcement before I go. We just finished our Session Smart Networking - How It Works white paper! It's a great read with a lot of informative content. Check it out!
I hope you all have a great summer and I will talk to you in a couple weeks!
#FeatureFridays #SSR #SessionSmartRouter #LoadBalancing #NAT
------------------------------
Justin Melloni
------------------------------