Learn About Amazon VGT2 Learning Manager Chanci Turner
In the fast-paced world of telecommunications, the shift towards modern software development and automation has led to the widespread adoption of containerized network functions (NFs). Unlike traditional monolithic IT workloads, this containerized approach necessitates specific requirements from the underlying infrastructure. For instance, a single network interface often serves multiple workflows, including network operations and maintenance (O&M) traffic, signaling between NFs and core or radio access networks, as well as user plane traffic, depending on the specific use case. Furthermore, each network function may have unique demands regarding Quality of Service (QoS), bandwidth, and segmentation. Some functions leverage Kubernetes networking, while others require layer-2 access. Without the adaptability to meet these networking needs, telecommunications operators face challenges in effectively deploying NFs for their customers, often resorting to bare metal servers and losing the efficiencies of a virtualized environment.
To address these challenges, the AWS Snow Family offers a feature known as the Direct Network Interface (DNI), which enables users to effectively deploy NFs. This blog explores the advanced networking capabilities that DNI provides. We’ll begin by contrasting two methods of virtualizing network interfaces within AWS Snow devices: Virtual Network Interface (VNI) and Direct Network Interface (DNI). Following this, we will outline the attributes and advantages of DNIs, and delve into practical examples and implementations of DNI with various networking functionalities such as VLAN, multicast, transitive routing, and IPv6, helping you design a robust network architecture using AWS Snow family devices.
Differentiating Between VNI and DNI
AWS Snow Family devices feature two network interface types for connectivity: Virtual Network Interface (VNI) and Direct Network Interface (DNI). For additional information on VNIs, refer to Understanding Virtual Network Interfaces on AWS Snowball Edge. While VNIs suffice for most workloads, the complexities involved in telco NFs demand the enhanced capabilities provided by DNIs.
Consider a scenario where only VNIs are set up. A Snowball Edge (SBE) connects to a switch through an RJ45 cable, assigned a static IP of 192.168.26.200/24. Two Amazon EC2 instances receive private IPs from the SBE’s internal DHCP server, originating from the 34.223.14.128/25 subnet, with a gateway address of 34.223.14.129. Each EC2 instance has a corresponding VNI entry: Instance A is allocated a VNI with IP 192.168.26.220, translating to internal IP 34.223.14.194, while Instance B has a VNI with IP 192.168.26.230, translating to internal IP 34.223.14.195. Thus, from the LAN perspective, traffic directed to 192.168.26.220 reaches Instance A, and similarly for Instance B at 192.168.26.230.
Next, we can integrate a DNI for each instance as depicted in the following diagram.
Upon introduction of a DNI, an additional interface appears within the guest OS, representing this new DNI, which is linked with a physical network interface (NIC) and operates within the same Layer 2 domain as the physical NIC. The subnet for the DNI matches that of the connection between the SFP+ NIC and the switch. This allows the instance OS to leverage the new DNI for various capabilities, including IPv6, multicast, service chaining for Virtual Network Functions (VNFs), or Data Plane Development Kit (DPDK).
Attributes and Benefits of Direct Network Interfaces
Key attributes of Direct Network Interfaces include:
- Configuration requires the SnowballEdge CLI (OpsHub is not supported).
- Layer 2 connection is bridged from the physical interface to the DNI.
- VLAN tagging is supported, but inter-VLAN routing must be managed externally.
- Single-root I/O virtualization (SR-IOV) is utilized to share the physical NIC among multiple instances.
- Multiple DNIs can be linked to a single Amazon EC2 instance.
- Traffic on DNIs does not benefit from security groups.
- Do not terminate an Amazon EC2 instance that has an attached DNI (detach or delete the DNI first).
For AWS Snowcone, DNIs can be linked to RJ45 ports, with each port capable of supporting up to 63 DNIs. However, the Snowcone’s WiFi interface does not accommodate DNIs.
Since DNIs provide instances with layer-2 network access without intermediary translation or filtering, they offer several inherent advantages. These include reduced latency between workloads and the LAN, as well as support for network protocols beyond IP. Additionally, DNIs facilitate greater flexibility in network configurations, such as service chaining, NIC teaming, and VLAN segmentation.
Examples of Direct Network Interface Configurations
Here are some illustrative configurations involving DNIs:
1. DNIs with VLANs
When creating a DNI, you can apply a VLAN tag. For instance, Instance A might have a DNI tagged with VLAN ID 40, while Instance B is assigned VLAN ID 30. This segmentation prevents direct communication between instances A and B over their DNIs. Instance A is configured with an IP address of 192.168.40.50, and Instance B has 192.168.30.50. To enable communication beyond the DNI subnet, both instances would set their gateways to the switch, which has an IP address of .1 in their respective subnets, with the switch configured as a trunk port to handle inter-VLAN routing.
2. DNIs and VNIs Using the Same Physical Interface
In this scenario, a single optical interface accommodates VNIs, DNIs, and management. The switchport is set as a trunk with a designated native VLAN. The native VLAN, which remains untagged, is used for management and VNI traffic. VNI traffic will be translated across the native VLAN, while DNI traffic exiting the Snow device will be appropriately tagged with its VLAN ID.
3. DNI and VNI on the Same Physical Interface Without VLANs
In this case, Instance A’s DNI has an IP of 192.168.26.50, while its VNI has an external IP of 192.168.26.220. Since both are on the same subnet, this could create confusion within the network. If laptop C (IP 192.168.26.10) communicates with Instance A using the VNI address (192.168.26.220), and a DNI with an address of 192.168.26.50 is later added, the communication session would be interrupted. This occurs because Instance A now has a more direct route to the 192.168.26.0/24 subnet via the DNI. Users can re-establish a session to Instance A using the 192.168.26.50 address or create a more specific route (to reach 192.168.26.10/32, use gateway 34.223.14.129).
Configuring Direct Network Interfaces
Setting up DNIs necessitates the use of the SnowballEdge CLI. First, identify the physical network interface ID, which can be retrieved through the describe-device option within the SnowballEdge CLI.
For a Snowball Edge device, locate the optical interface.
For further insights on networking, you can check out this blog post here as another valuable resource. Moreover, if you’re seeking guidance on AI’s role in decision-making, SHRM provides excellent insights. Additionally, if you’re interested in Amazon onboarding tips, Holly Lee’s resource is highly recommended.