Network Instance Overview

• You must have at least the SysManager role in your enterprise.
• You should be familiar with networking topics, such as IP addressing, subnetworks, gateways, NTP servers, static and connected routing, etc.

Network instance types

Local network instance

A local NI is a virtual network that provides connectivity between local app instances on the same edge node for localized communication. When you create a local NI, you need to choose a port and configure IP settings. You also have the option to designate the new instance as default for the edge node that you select. This can save you some time in the future if you have an NI that you always want assigned to any new edge app that you create. 

Switch network instance

A switch NI provides an L2 bridge between applications and a physical network, allowing applications to appear as separate devices on the network. With a switch NI, an app can obtain an IP address from the network’s DHCP server (if available), just like a physical machine would, and it can communicate with other devices on the network and be directly accessible to them as well. 

Switch instances are useful for network connectivity across edge nodes. For example, your app might need to share the same IP subnet with some hosts on another network.

This series of articles can help you organize your network instances, leveraging adapter labels for efficient port management, and implementing static and connected routes for reliable traffic 

See Manage Networks instead if you are interested in passing edge node hardware traffic to and from ZEDEDA Cloud.

Port grouping

Adapter labels

This is available for switch or local instances. When you select your device from the EDGE Node drop-down menu, if you use Adapter Labels when you onboard your edge node to ZEDEDA Cloud, you see your adapter labels available in the Port drop-down menu. Select an adapter label to use a group of ports instead of selecting a predefined label or only one port. See Network Instances: a use case for an example of using adapter labels to configure a Local Network Instance for multi-path routing with failover and port-forwarding restrictions. 

IP configuration options

Maximum transmission unit (MTU)

The largest IP packet that the NI can carry. Smaller MTU values can be used to avoid packet fragmentation when packet encapsulation is used. Larger MTU values reduce the overhead associated with packet headers, improving network efficiency, and increasing throughput by allowing more data to be transmitted in each packet (called a jumbo frame). If a NI MTU is higher than MTU configurations of any of an associated network entity's ports, the lowest MTU among all of those ports will be used instead for the NI. If the network entity's ports have the higher MTU configuration, packets incoming to the NI will be fragmented (if permitted by the IP header).

Static routes 

You can configure specific routes that get propagated to your applications. These are typically used to route application traffic destined to external networks one or more routing hops away (for example, not directly connected to the device). Unlike connected routes, which EVE generates automatically when enabled, static routes are edited manually (subnet + gateway). You can also configure subnet+port instead, and let EVE-OS use the default gateway for the port.

Another common case is if you’re using one application as a network gateway for other applications that are running on the same device. The gateway application might provide some network functions, such as firewall, IDS, network monitoring, etc. Such an application will connect on one side with the external networks using directly attached network adapters or via switch NIs, and the other side will make use of an air-gap local NI to connect with other applications running on the device. Propagated static IP routes are necessary to make the application traffic flow through the gateway app. In theory, multiple network functions can be chained together in this way using several air-gap NIs with static IP routes.

If there are multiple possible paths to reach the routed destination network, an adapter label can be used to reference multiple possible output ports and thus create a multi-path route providing redundancy and automatic failover. If you choose an adapter label when configuring the Port for your local instance, then leave your IP Gateway Address blank when configuring your static route if you want the route to be generated dynamically. You can select an adapter label to use a group of ports instead of selecting only one Output Port. 

Connected routes 

Route application traffic destined to the network segment that the physical NI port is part of. Since EVE knows the port’s subnet and the default gateway IP (from static IP config or from DHCP), it can automatically generate such a route and propagate it to the application using DHCP. You only need to decide if EVE should propagate connected routes to the network instance’s app instances. If you change the IP configuration of the network (such as subnet mask), connected routes can adapt without requiring constant reconfiguration, enhancing flexibility. However, since connected routes are automatically generated, you might have less granular control over routing behavior. 

Probing

You can use probing for multi-path routes, for example, when the Output Port is an adapter label matching multiple ports. If the Output Port is not specified or it references a particular device port, the probing configuration is not available.

If you enable probing, EVE-OS will check the reachability of the port's next hop (the gateway IP) every 15 seconds using ICMP ping. The upside of using this probe is a fairly fast fail-over when the currently used port for a given multi-path route loses connectivity. The downside is that it could generate a lot of traffic over time. You can limit the use of this probe to only ports with low cost or you can disable this probe altogether. Additionally, every 2.5 minutes, EVE-OS will run a custom probe if configured. This can be either an ICMP ping towards a given IP or hostname, or a TCP handshake against the given IP or hostname and port. EVE-OS continuously monitors these ports and uses only one at a time for applications using this NI, based on which port has stable connectivity. If the currently used port loses connection, EVE-OS automatically switches to another port. 

Next steps

This is a series of articles. You will likely follow them in this order.

1. Network Instance Overview - You are here!
2. Create a Network Instance
3. Manage a Network Instance
4. Use the ZEDEDA CLI to Manage a Network Instance