How a Packet Traverses a SteelConnect Network
This topic describes how the SteelConnect gateway processes packets as they traverse the network.
The SteelConnect gateway is configured and managed from SteelConnect Manager (SCM). The gateway provides several network services, such as routing services and firewall services, as packets cross the appliance.
Sample SteelConnect network
The topology in
Sample SteelConnect network uses these terms and definitions:
•A zone refers to a subnet that is local to the SteelConnect gateway or gateways at the site. The SteelConnect gateway can provide services to the clients such as DNS or DHCP; however, the default gateway or another device might perform these functions.
•In Branch D, D1 is a local zone that is used to reach another zone (Zone D2) that is not directly connected to the gateway at Layer 3. This route is referred to as a third-party route in SCM.
The network paths shown in
Sample SteelConnect network use these conventions and definitions:
•Gray dotted lines illustrate a generic IPsec tunnel that has been created between a SteelConnect gateway appliance and a third-party firewall. This configuration is known as a classic VPN in SCM.
•Blue dotted lines depict a RouteVPN tunnel. These VPN tunnels are automatically formed over the internet WAN between SteelConnect appliances.
•Orange dotted lines represent the VPN tunnels built over a private WAN (for example, MPLS) when that WAN is configured to use encryption. You can enable encryption in SCM when you create a WAN. This configuration is called AutoVPN in SCM.
Orange and blue lines are collectively referred to as the overlay network. This term is an abstraction of the internet and WAN in which the gateways communicate with each other. The communication for the overlay network takes place on an underlay network. The underlay is the series of network devices owned by a provider or customer making up a network infrastructure.
•Brown solid lines illustrate the connection to the MPLS network and are known as the underlay network.
SteelConnect gateway services
The SteelConnect gateway uses these services:
Routing services overview
SteelConnect gateways provide these routing services:
•Path selection - SCM uses traffic path rules to provide path selection. The path is selected by the gateway where the traffic originates and reflected by the gateway on the remote end. For example, traffic from Zone C to Zone E can be configured to prefer the internet path over the private WAN. These rules have automation built in to select the better path based on quality metrics. Latency, loss, and jitter are also used in the calculation, if configured.
•Quality of Service - The gateway ensures efficient use of bandwidth and leverages the common applications kept enhanced (CAKE) scheduling mechanism. CAKE uses an advanced fair queue mechanism based on hierarchical priority that distributes bandwidth while considering packet delays. CAKE is a connection-based system that tracks latency on each connection or traffic flow rather than bandwidth per class. CAKE is purposely built for internet-based uplinks so it is ideal for dynamic WAN throughput.
You can configure QoS in the outbound and inbound directions on the uplinks only. Branch gateways support both marking and enforcement.
The SDI-5030 does not support QoS enforcement because it is out-of-path and your QoS enforcement endpoint should be on your existing MPLS routers.
Traffic forwarding mechanism
SteelConnect gateways provide the fundamental subset of router functionality of an edge router but do not have one-to-one parity with a traditional router.
SteelConnect gateways classify different network types by maintaining separate routing tables using these criteria:
Local - The LAN subnets managed by the SteelConnect gateway. In
Sample SteelConnect network, Zones B, C, D1, E, and F are subnets considered as local for their respective appliance.
Overlay WAN - Subnets that are created as zones on SCM and advertised as reachable on the overlay network. The appliance in site B is aware of remote zones C, D1, E, and F using the overlay WAN.
Underlay WAN - Any WAN forwarding decisions that are made outside of (or “under”) the SteelConnect overlay. For underlay connectivity on the WAN, the site must participate in underlay learning with a routing protocol. (See the
SteelConnect Manager User Guide for details.) In the example in
Sample SteelConnect network, Branch C would discover LAN F via a routing protocols such as BGP or OSPF. LAN F’s subnet appears in the underlay routing table of the gateway.
Classic VPN - Creates a manual VPN tunnel using the standard IPsec IKEv1 or IKEv2 protocol. A remote gateway is not necessary. For example, the tunnel could be terminated by a firewall or router or another networking device. LAN A’s subnet would appear in the classic VPN table of Branch B’s gateway.
Statically defined routes - Typically, networks behind Layer 3 routers on the LAN side of the gateway. In SteelConnect terminology, this is called a third-party routing configuration. D2’s subnet appears as a third-party/static route in SteelConnect.
Forwarding of traffic is done in two stages:
1. A route lookup is performed across all route tables. For a given destination address, the route lookup returns all available paths with the most specific prefix match.
2. The selection of the path is based on policies. You can configure a default path preference at the site or organization level. You can configure more specific traffic path rules to take precedence over less specific rules.
Overlay paths are always preferred over underlay path when routes with equal prefix matches.
Routing example: Branch B to Branch A
In this example, a host (10.1.2.15) in Branch B wants to connect to a server (10.1.1.250) in Branch A.
Branch B to Branch A routing example
At the organization level, traffic uses this default path preference:
1. RouteVPN
2. MPLS
The SteelConnect gateway in Branch B has these entries in its routing table:
•Local: 10.1.2.0/24 directly connected
•Overlay WAN:
–10.1.3.0/24 learned from the Branch C gateway
–10.1.0.0/16 learned from the data center gateway
•Underlay WAN: Not used because the two sites do not have a common network. If the overlay fails and because we are using classless addressing, there is not a way to route traffic over the internet.
•Classic VPN: 10.1.1.0/24 learned from the IPsec tunnel to the firewall in Branch A
•Third-party zones/statically defined routes: Not used
The SteelConnect gateway in Branch B checks the routing table and chooses the most specific prefix match, which is the classic VPN connection.
Routing example: Branch C to Branch F
In this example, a host (10.1.3.20) in Branch C wants to connect to a server (10.1.18.250) in Branch F.
Branch C to Branch F routing example
At the organization level, traffic uses this default path preference:
1. RouteVPN
2. MPLS
The SteelConnect gateway in Branch C has these entries in its routing table:
•Local: 10.1.3.0/24 directly connected
•Overlay WAN:
–10.1.2.0/24 learned from the Branch B gateway
–10.1.0.0/16 learned from the data center gateway
•Underlay WAN: 10.1.16.0/16 learned from the Branch F MPLS CE router
•Classic VPN: Not used
•Third-party zones/statically defined routes: Not used
The SteelConnect gateway in Branch B checks the routing table and chooses the most specific prefix match, which is the underlay network to MPLS.
Routing example: Branch C to Branch D
In this example, a host (10.1.3.20) in Branch C wants to connect to a server (10.1.5.120) in Branch D.
Branch C to Branch D routing example
At the organization level, SteelConnect has been changed from the default and uses this path preference:
1. MPLS
2. RouteVPN
The SteelConnect gateway in Branch C has these entries in its routing table:
•Local: 10.1.3.0/24 directly connected
•Overlay WAN:
–10.1.2.0/24 learned from the Branch B gateway
–10.1.0.0/16 learned from the data center gateway
–10.1.4.0/29 and 10.1.5.0/24 learned from the Branch D gateway
•Underlay WAN:
–10.1.16.0/16 learned from MPLS CE router in Branch F
–10.1.4.0/29 and 10.1.5.0/24
•Classic VPN: Not used
•Statically defined routes: Not used
The route lookup finds two available paths for 10.1.5.120. The SteelConnect gateway in Branch D is advertising its local and third-party subnets on the overlay but it is also advertising on the underlay using BGP or OSPF. See
WAN Topologies for details.
Since Overlay paths are always preferred over the underlay path for equal prefix, the traffic will be routed on the AutoVPN tunnel between Branch C and Branch D.
If a host in Branch B wants to communicate with a server in Branch D while they are in different WANs, it is possible to establish the communication between the two.
Packet operation flow
When a packet is processed by a SteelConnect gateway, the logical order of the operation flow is from left to right as shown in
Packet operation flow. Connection tracking, highlighted in yellow, maintains the state for packets of a flow.
Packet operation flow
Packets arrive to the gateway on a WiFi, LAN, or Ethernet interface. These interfaces differ slightly in terms of how traffic is handled. LAN interfaces on some gateway hardware have a switch inside and traffic between interfaces in the same zone on a LAN interface will be switched at Layer 2, bypassing the features described.
After traffic arrives, SteelConnect classifies it based on the application and tracks this classification for all packets in a flow. The firewall is invoked and will act on packet headers or, if needed, wait until the application is identified. Following the firewall, SteelConnect might select a path for the overlay based on a traffic path rule and quality or an underlay path if their is an LPM match. After it selects the path, it performs any source NAT and the packet might be encrypted. Following the encryption process, the packet is handed over to an interface and the per-interface routing table is consulted. In the case of packets going out a WAN interface (uplink), the packet will have QoS applied, if appropriate, or will retain its downstream marking.
The following examples show additional details of how a packet is processed by the SteelConnect gateway as it traverses an SD-WAN network. Keep in mind that SteelConnect can skip some steps in the left-to-right flow. In these examples, the functions that are in use are highlighted in yellow and the functions that are skipped are highlighted in gray.
Example: traffic sent from site to site
In this topology, traffic is sent from one site to another over the WAN.
Traffic sent from site to site shows how packets are processed at the originating SteelConnect appliance (source) before the traffic is sent over the WAN to the remote gateway.
Traffic sent from site to site
•Traffic arrives on an interface, is not malformed, and passes header validation checks.
•Application ID is checked and the application catalog is used.
•Connection tracking maintains the state for packets of a flow.
•The firewall determines that traffic from the local zone to the remote zone for this application is permitted.
•Path selection can use the organizational default when a zone is a member of more than one WAN but, in this case, a traffic path rule is used to steer the application. In SCM terms, an organization is a company representing an end customer. The traffic path rule has path quality override configured and the path decision is overridden due to quality (latency, loss, and/or jitter).
•Traffic is encrypted using Encapsulating Security Payload (ESP) protocol and encapsulated in a UDP header with a destination for the remote gateway uplink IP address connecting to the WAN that has the better quality metrics.
•Routing determines the next hop out the uplink interface.
•QoS performs scheduling using CAKE to minimize delay.
•Traffic is sent out the WAN interface.
This flow also includes traffic to zones not directly connected to the gateway at Layer 3, referred to as a third-party route.
Example: traffic to the internet
In this topology, traffic is destined outbound to the internet.
Traffic outbound to the internet
•Traffic arrives on a LAN interface, is not malformed, and passes header validation checks.
•Application ID is learned from the catalog and belongs to a category that is used for determination in the rules.
•Connection tracking maintains the state for packets of a flow.
•The firewall determines that traffic from the local zone to the internet for this application is permitted.
•Path selection uses a traffic path rule to send this application directly to the internet overriding the organizational default for internet egress.
•Source IP should have Network Address Translation.
•Routing determines that the destination is to the internet.
•QoS performs scheduling using CAKE to minimize delay.
•Traffic is sent out the WAN interface (uplink).
Example: inbound traffic
This topology shows how a packet is processed by the SteelConnect gateway when it arrives from the WAN. This topology is for all traffic destined to a server in the local network on the site arriving from the internet. A common use case is an inbound connection to the web server hosted at a site.
Traffic arriving inbound from the WAN
•Traffic arrives on the WAN interface for a destination IP address of the uplink and the MAC address of the uplink. The packet passes header validation checks.
•Destination NAT is performed for traffic to reach the internal device.
•The application ID is a custom application created for any traffic to the destination that is a defined device. In SCM, any inbound traffic has to be defined to a device using a custom application unless the WAN is configured as trusted.
•Connection tracking maintains the state for packets of a flow.
•The firewall determines that traffic from the internet to a device in a local zone is permitted and that the destination IP should have NAT to the private IP address.
•Routing determines the destination to the local device.