View Only
last person joined: 7 days ago 

Ask questions and share experiences with SD-WAN and Session Smart Router (formerly 128T).
  • 1.  Feature Friday: Secure Vector Routing (SVR) Part Two – Packet Walkthrough

    Posted 07-15-2022 10:24
    Edited by Jodi Meier 07-11-2023 12:44

    Alright, last week I introduced SVR and discussed the benefits of SVR compared to Tunnel-based Protocols. This week I’m here to tell you how this whole operation works. This is the SVR Packet Walkthrough Feature Friday!



    Detecting a new Session

    The process starts when a client sends traffic to a server. For example, a user tries to access Outlook. If the client needs to access the server that is on the WAN, then it will need to send traffic to a router, in our case, that will be the Session Smart Router (SSR).


    When the Session Smart Router sees the first packet of the session, it does a little inspection to determine:

    1. Have we seen this session before?
    2. Is this client allowed to access the server?


    The SSR determines if it has seen the session before by looking at the 7-tuple:

    • Source Address
    • Source Port
    • Destination Address
    • Destination Port
    • Transport Protocol
    • VLAN
    • Ingress Network Interface


    The SSR does this look up to determine if it already knows the path to send the session, or if it needs to do further processing. If the SSR cannot tell if it has already seen the session, it will need to determine if the client is allowed to access the server. Here’s where Services and Tenants come in.


    Services and Tenants

    The Service represents the destination of your network traffic. The Tenant represents an Access Group on your network. 


    The SSR wants to determine which Tenant this session is coming from and it does that in one of four ways.

    1. From another SSR – through SVR. Remember, the Tenant is information that is included in the metadata. 
    2. From the network-interface – this basically means per VLAN since you can have multiple network-interfaces per device-interface (physical interface), they just get separated by VLAN.
    3. By source sub-net – this involves adding a neighborhood to your LAN interface and then saying “if traffic comes from X.X.X.X/X, then it belongs to tenant X”
    4. Global tenant – this is the tenant that is assigned when there is no tenant assigned through the other means


    Every session can only belong to one Tenant, so this is the order of precedence (if it gets a Tenant from one of the ways higher in the list, then it won’t look at the lower ones).


    Once a Tenant is assigned, the SSR will do a look up in the FIB to determine if the client can access the server. The FIB table shows:

    • Destination Address/Subnet
    • Destination Port
    • Transport Protocol
    • Tenant


      Service and Next-Hop

      If there is a successful match, the SSR will return a Service and Next-Hop. The Service will have a Service Policy, which will tell us how we want to route (i.e., path preference by vector (cost), dynamic path selection based on SLA, load-balancing, etc.) and if we want to do any Traffic Engineering (Service Class). It basically tells us how we want to treat traffic headed to that application/Service. 


      The Next-Hop tells us where we are sending the traffic. This could be to another SSR (which is when we do SVR) or to a gateway or host. 


      Ok, let’s say the FIB lookup is a successful match and we are going to send traffic to another SSR. As I mentioned a sentence ago, it’s time to do Secure Vector Routing!



      The SSR will now take the information from the FIB table, encrypt and hash it using the Security Policy you assigned to the Service, and then add that to the front of the payload. This is the metadata. The metadata is only included in the beginning of a Session (for example, TCP SYN and SYNACK). Once there is acknowledgement from the receiving SSR, then there is no more metadata added to the following packets unless there is a need (for example, a path change). 


      The original source and destination addresses and ports are then replaced with the sending and receiving network-interface addresses and a port from the range of 16385-65533. This is what we call waypoints and wayports.  You can learn more about those here. This is how the SSR performs NAT for SVR. 


      Receiving Packets

      With all of this done, the SSR is ready to send the packet to the receiving SSR. When the receiving SSR receives the packet, it will do the exact same steps. If there are more SSRs along the path, then it will send it to those as SVR, if there are not, then it will restore the original information and send the packet to its destination. At this point, you could do some additional Source and Destination NAT if you like. We’ll go over how to do that in a future post. 


      When the server responds to the client, the response will take the same path back that the request came from. At this point, the session will be added to the Session Table and metadata will only be included in the first response (just to confirm “hey, I got your metadata”).


      After that, every other message that comes out for that session will take the same path as the original request and not need to go through the same FIB lookup and metadata addition. We call this the Fast Lane. 


      Summary (TL: DR)

      So, to sum it up, Session Smart Routers use Secure Vector Routing to securely route packets without the downfalls of tunnels. How it works:

      • The Session Smart Router inspects the first packet of a session
      • If it is not familiar with the session, then it determines the source of the session (Tenant)
      • The SSR then looks at the FIB table to determine if the client has access to its destination
      • If it has access, then the SSR will return a Service and Next-Hop and apply service and security policies
      • Next, the SSR will package this information (metadata), and assign it only to the first packet in the session
      • Finally, the last receiving SSR will restore the original information and send the packet to its destination


      So yea, that’s Secure Vector Routing in a nutshell. Thanks for sticking with me, I know that was a long read! However, I want to discuss features that take SVR to the next level like BGP Over SVR and Ethernet Over SVR in future, so I figured let's all build that SVR foundation with this and the previous post.

      As usual, we have some great additional resources for you to check out:


      And we’d love to hear from you:

      • Have you notices improved performance or bandwidth cost savings with SVR?
      • Do you have other question on how SVR works?
      • I'm still waiting on those firework suggestions...

      Thanks again for reading! I am looking forward to speaking with you soon!

      #FeatureFridays #SVR #SecureVectorRouting #service #tenant #metadata #tunnels​​​​​​​​​

      Justin Melloni

    • 2.  RE: Feature Friday: Secure Vector Routing (SVR) Part Two – Packet Walkthrough

      Posted 07-22-2022 17:37
      I love learning about everything that goes on behind the scenes in the life of a packet between two SSRs!

      One help way to think of waypoints: think of a Waypoint as an area that you have to pass through. We use the waypoints as a way of anchoring every packet of every session in order to go through the Session Smart routers (we do this by NATting the original source and destination IP address to match the sending and receiving SSRs). The Waypoint address is configured under the Interface Address section of the Network Interface.

      Jenna Ramos
      Information Development Engineer II

    • 3.  RE: Feature Friday: Secure Vector Routing (SVR) Part Two – Packet Walkthrough

      Posted 07-31-2022 08:14
      Good stuff.  Thanks.

      It would be nice to have a document of what (and how much)  information applications (malware) or non-allowed applications get when SSR drops the packet.


      Hannu Rokka
      Senior Advisor (DataCom)

    • 4.  RE: Feature Friday: Secure Vector Routing (SVR) Part Two – Packet Walkthrough

      Posted 08-03-2022 08:29
      Hi @Hannu,

      Thank you so much for your feedback, I will definitely let our product management team know that we should have this documented.

      When the SSR drops a packet, if you have an explicit deny set (tenantX is denied access to serviceY), then the SSR will silently drop the packet. If there is no explicit deny set, then the SSR will send back an ICMP unreachable.

      Does help answer the question at all?

      Thank you,

      Justin Melloni

    • 5.  RE: Feature Friday: Secure Vector Routing (SVR) Part Two – Packet Walkthrough

      Posted 08-05-2022 08:20

      I think it's important to add this to the "SSR Life of Packet" flowchart. 


      It's funny you mention "if you set explicit deny", since SSR should by default is Zero Trust and only explicitly allowed traffic should go forward ;-)

      Hannu Rokka
      Senior Advisor (DataCom)