AWS for Industries

Understanding Virtual Network Interfaces on AWS Snowball Edge

Virtual Network Interfaces (VNI) on Snowball Edge (SBE) are used for connecting your EC2 instances to your local area network (LAN). One can think of a VNI as a 1:1 entry in a NAT table (Network Address Translation). The VNI is associated to an instance (and its corresponding private IP address).

Let’s take an example below. The SBE is connected via RJ45 and has a static IP address of 192.168.26.200/24. There are two EC2 instances, each assigned a private IP address from the SBE’s internal DHCP server. The private IP will be assigned from the 34.223.14.128/25 subnet and have a gateway address of 34.223.14.129 (this is the IP address of the gateway within the SBE’s IP stack). There is a VNI entry for each EC2 instance. Instance A has a VNI with IP 192.168.26.220 that translates to the internal IP 34.223.14.194. Instance B has a VNI with IP address 192.168.26.230 that translates to the internal IP 34.223.14.195. From the LAN’s perspective, traffic sent to 192.168.26.220 will be sent to EC2 instance A. Likewise, traffic sent to 192.168.26.230 will be sent to EC2 instance B.

Some things to note:

  • VNIs support both static and DHCP address assignment.
  • VNIs can be configured via OpsHub or command line.
  • Only one VNI can be attached to an EC2 instance at one time.
  • VNIs can be created and attached to EC2 instances during the launch of the EC2 instances.
  • If creating static VNIs, avoid duplicate IP addresses on your network. Use DHCP reservations on your DHCP server as appropriate for your environment.
  • VNIs can be created and later attached to EC2 instances.
  • If an EC2 instance is terminated, its attached VNI will not be delete.
  • You can change the VNI association to an EC2 instance. The previously attached VNI will have no attachment and will be available to attach to another instance.
  • Each VNI also has a corresponding MAC address, which will exist on the same L2 domain as the physical interface.
  • The MAC address of the VNI remains with the VNI. This allows you to modify the IP address of the VNI without affecting the MAC address.
  • Traffic passing through a VNI can be protected by security groups. The default security group allows all traffic.
  • VNIs are supported on the RJ45, SFP+, and QSFP interfaces. The VNIs are associated to the physical interface at time of creation.
  • You can detach a VNI from an instance using the AWS cli (aws ec2 disassociate-address).
  • VNIs do not support multicast (use Direct Network Interfaces for this capability).

The Snowball Edge was designed for disconnected operations. This may involve moving the SBE from location to location, from network to network. When there are network changes, there are certain behaviors that can be observed. This chart describes the various scenarios that may be encountered.

Case DHCP1 Network change?2 Existing VNI New VNI
Static DHCP Static DHCP
1 No no Remain the same Remain the same Will inherit GW of physical interface Will timeout and show error since no DHCP available
2 yes no Remain the same Remain the same Will inherit GW of physical interface Will receive an IP address from the DHCP server
3 No yes* IP address remains the same. GW is GW of physical int at time of boot. Will become static VNI with address of 0.0.0.0. GW is GW of physical int at time of boot. VNI detaches from EC2** Will inherit GW of physical interface Will timeout and show error since no DHCP available
4 yes yes* IP address remains the same. GW is GW of physical int at time of boot. Will receive an IP address from the DHCP server. GW is GW of physical int at time of boot. VNI detaches from EC2 Will inherit GW of physical interface Will receive an IP address from the DHCP server

1Is the SBE server connected to a network with a DHCP server at the time of boot?

2Has the SBE moved to a new network? The IP address of the physical interface has changed since the last time the SBE was powered off.

*The SBE should be rebooted if there are existing VNIs at the time the subnet change (the IP address and gateway of the SBE physical interface has changed). This will update the GW of the existing VNIs.

**VNIs with 0.0.0.0 addresses can be update via CLI using the snowballedge update-virtual-network-interface command. If a VNI with a 0.0.0.0 is deleted (without being updated to a valid IP address), it will “lock” a DHCP VNI slot. To clear this “lock”, the SBE should be rebooted. If the SBE cannot be rebooted, an alternative method is to create a new static VNI to take up that slot. As long as a DHCP VNI slot is “locked”, new DHCP VNIs cannot be created.

The following examples with screenshots help explain the various scenarios.

  1. The SBE is configured with a static IP address, 192.168.26.90. There is a DHCP server available and allocates an address of 192.168.26.175 to a VNI.

There is a DHCP VNI with the address of 192.168.26.175:

The DHCP VNI is associated with Test-instance1:
  1. The SBE is now configured to obtain a DHCP address. It successfully obtains 192.168.26.144 from the DHCP server. Since there is no subnet change, the existing VNIs are not affected.

The DHCP VNI remains the same. The static VNIs also remain the same.

The VNIs remain associated to their instances:

The MAC address also remains unchanged

Note the private IP address of Test-instance1 is 34.223.14.194:
  1. Now the subnet is changed from 192.168.26.0/24 to 192.168.25.0/24. The SBE receives a different DHCP address. It successfully obtains 192.168.25.101 from the DHCP server.

The DHCP VNI obtains a new IP address. The static VNI remains the same.

The new DHCP VNI keeps the old mac address. The static VNI changed its gateway to the gateway of the SBE (This is expected behavior as the user is not able to specify the gateway for static VNIs).

The static VNI remains associated to its instance, but the new VNI is not associated to an instance. The Test-instance1 no longer has a VNI associated with it.

The PrivateIPAddress of Test-instance1 remains the same.

Since the new DHCP VNI is not attached to the instance, we can use OpsHub to reattach it.
  1. The SBE is moved from subnet 192.168.26.0/24 to subnet 192.168.44.0/24 which has no DHCP server. A static IP address of 192.168.44.20 has been assigned to the SBE after the bootup process completed.

When there is no DHCP server available, the previous DHCP VNI becomes a static VNI with an IP address of 0.0.0.0. The gateway is set to the GW of the physical interface at the time the SBE boots (which is the last GW value before it was rebooted).

The MAC address remains the same. Notice that the Default Gateway of the VNIs remains the same (since there was no IP address/default gateway when the SBE booted up).

The instance is no longer attached to the VNI:

The 0.0.0.0 VNI can be updated using the Snowballedge update-virtual-network-interface command. The MAC address remains the same. The Default Gateway remains the previous gateway (the default gateway when the VNI was created or SBE was rebooted. Since this VNI was previously created, the default gateway stays the previous value).

After reboot, the gateway changes to the newly assigned gateway.

Mark Nguyen

Mark Nguyen

Mr. Nguyen is a passionate 25+ year Tech veteran with a proven track record of customer success. Combined with vision and experience, he builds pragmatic solutions that are scalable, resilient, secure, and operationally manageable. Mr. Nguyen currently supports the US DoD as a Senior Solutions Architect at AWS.