GENEVE - Generic Network Virtualization Encapsulation
GENEVE (Generic Network Virtualization Encapsulation) is a network virtualization protocol designed to overcome the limitations of VXLAN, NVGRE, and STT. GENEVE supports network virtualization scenarios, particularly for building tunnels between virtual switches.
Introduction to GENEVE
What Is GENEVE?
GENEVE is a modern encapsulation protocol that:
- Uses arbitrary IP networks as the underlay
- Supports Clos network architectures
- Provides flexibility through an extensible header
- Was developed by the IETF NVO3 Working Group
Key Features
Header architecture:
- Version - protocol version
- Option Length - length of the optional fields
- VNI (Virtual Network Identifier) - virtual network identifier
- Protocol Type - type of the encapsulated protocol
- Variable Length Options - extensible options
Advantages over VXLAN:
- More flexible header format
- Metadata support
- Better extensibility
- Compatibility with various transport protocols
When to Use GENEVE?
Recommended for:
- Cloud overlay networks
- Network virtualization in the datacenter
- Multi-tenant environments
- SDN/NFV solutions
- Kubernetes CNI (for example, OVN-Kubernetes)
Cloud use cases:
- Yandex Cloud: Overlay networking for container platforms
- VK Cloud: Multi-tenant isolation
- Private Cloud: Network virtualization infrastructure
GENEVE Configuration
Basic Setup
configure
# Create a GENEVE interface
set interfaces geneve gnv0 remote 203.0.113.10
set interfaces geneve gnv0 vni 100
set interfaces geneve gnv0 address 10.10.0.1/24
commit
saveConfiguration Parameters
VNI (Virtual Network Identifier)
# The VNI identifies the virtual network (0-16777215)
set interfaces geneve gnv0 vni 100VNI range: 0 - 16777215 (24-bit)
Remote Address
# IP address of the remote tunnel endpoint
set interfaces geneve gnv0 remote 203.0.113.10
# IPv6 is supported
set interfaces geneve gnv0 remote 2001:db8::10Source Address (optional)
# If not specified, it is selected automatically based on the routing table
set interfaces geneve gnv0 source-address 203.0.113.1UDP Port
# UDP destination port (default 6081)
set interfaces geneve gnv0 port 6081
# Use a custom port
set interfaces geneve gnv0 port 8472Default GENEVE port: 6081 (IANA assigned)
IP Configuration
# IPv4 address
set interfaces geneve gnv0 address 10.10.0.1/24
# IPv6 address
set interfaces geneve gnv0 address 2001:db8:1::1/64
# Multiple IP addresses
set interfaces geneve gnv0 address 10.10.0.1/24
set interfaces geneve gnv0 address 10.10.1.1/24MTU Settings
# Set the MTU (account for encapsulation overhead)
set interfaces geneve gnv0 mtu 1450
# GENEVE overhead:
# - IPv4: 50 bytes (20 IP + 8 UDP + 8 GENEVE + 14 Ethernet)
# - IPv6: 70 bytes (40 IP + 8 UDP + 8 GENEVE + 14 Ethernet)MTU recommendations:
- Underlay MTU 1500: GENEVE MTU = 1450
- Underlay MTU 9000 (Jumbo): GENEVE MTU = 8950
MAC Address
# Set a custom MAC address
set interfaces geneve gnv0 mac '00:50:56:00:00:01'Description
# Add an interface description
set interfaces geneve gnv0 description 'GENEVE to DC-EAST'Practical Scenarios
Scenario 1: Point-to-Point GENEVE Tunnel
Topology:
[VyOS-R1] ===== GENEVE Tunnel ===== [VyOS-R2]
10.0.1.1/24 10.0.2.1/24
| |
Overlay: 172.16.0.0/30VyOS-R1 configuration:
configure
# WAN interface
set interfaces ethernet eth0 address 10.0.1.1/24
# GENEVE tunnel
set interfaces geneve gnv0 remote 10.0.2.1
set interfaces geneve gnv0 vni 1000
set interfaces geneve gnv0 address 172.16.0.1/30
set interfaces geneve gnv0 mtu 1450
set interfaces geneve gnv0 description 'Tunnel to R2'
# Static route through the tunnel
set protocols static route 192.168.2.0/24 next-hop 172.16.0.2
commit
saveVyOS-R2 configuration:
configure
# WAN interface
set interfaces ethernet eth0 address 10.0.2.1/24
# GENEVE tunnel
set interfaces geneve gnv0 remote 10.0.1.1
set interfaces geneve gnv0 vni 1000
set interfaces geneve gnv0 address 172.16.0.2/30
set interfaces geneve gnv0 mtu 1450
set interfaces geneve gnv0 description 'Tunnel to R1'
# Static route through the tunnel
set protocols static route 192.168.1.0/24 next-hop 172.16.0.1
commit
saveVerification:
# Check the interface
show interfaces geneve
# Ping through the tunnel
ping 172.16.0.2 source-address 172.16.0.1
# Check routing
show ip routeScenario 2: Multi-Tenant Network Virtualization
Goal: Isolate the traffic of multiple tenants using separate VNIs
Topology:
Tenant A (VNI 100): 10.100.0.0/16
Tenant B (VNI 200): 10.200.0.0/16
Tenant C (VNI 300): 10.300.0.0/16Configuration:
configure
# Tenant A
set interfaces geneve gnv100 remote 203.0.113.10
set interfaces geneve gnv100 vni 100
set interfaces geneve gnv100 address 10.100.0.1/16
set interfaces geneve gnv100 description 'Tenant-A Network'
# Tenant B
set interfaces geneve gnv200 remote 203.0.113.10
set interfaces geneve gnv200 vni 200
set interfaces geneve gnv200 address 10.200.0.1/16
set interfaces geneve gnv200 description 'Tenant-B Network'
# Tenant C
set interfaces geneve gnv300 remote 203.0.113.10
set interfaces geneve gnv300 vni 300
set interfaces geneve gnv300 address 10.300.0.1/16
set interfaces geneve gnv300 description 'Tenant-C Network'
# Firewall for isolation
set firewall group network-group TENANT-A network 10.100.0.0/16
set firewall group network-group TENANT-B network 10.200.0.0/16
set firewall group network-group TENANT-C network 10.300.0.0/16
set firewall name TENANT-ISOLATION default-action drop
set firewall name TENANT-ISOLATION rule 10 action accept
set firewall name TENANT-ISOLATION rule 10 state established enable
set firewall name TENANT-ISOLATION rule 10 state related enable
commit
saveScenario 3: GENEVE in Yandex Cloud
Goal: Overlay network between VMs in Yandex Cloud
Yandex Cloud specifics:
- Support for custom protocols between VMs
- A security group allowing UDP 6081 is required
- MTU in Yandex Cloud: 1500 (use GENEVE MTU 1450)
Configuration:
configure
# Define cloud metadata to obtain the IP
set system option performance throughput
# GENEVE tunnel between cloud VMs
set interfaces geneve gnv0 remote 10.128.0.20
set interfaces geneve gnv0 vni 1000
set interfaces geneve gnv0 address 172.16.100.1/24
set interfaces geneve gnv0 mtu 1450
set interfaces geneve gnv0 description 'Yandex Cloud Overlay'
# Source address - the VM internal IP
set interfaces geneve gnv0 source-address 10.128.0.10
commit
saveYandex Cloud Security Group:
# Through the Yandex Cloud Console or CLI
yc vpc security-group-rule create \
--security-group-id <sg-id> \
--direction ingress \
--protocol udp \
--port 6081 \
--cidr-blocks 10.128.0.0/24 \
--description "GENEVE tunnel"Scenario 4: GENEVE with Dynamic Routing
Goal: OSPF over a GENEVE tunnel
configure
# GENEVE tunnel
set interfaces geneve gnv0 remote 203.0.113.10
set interfaces geneve gnv0 vni 1000
set interfaces geneve gnv0 address 172.16.0.1/30
set interfaces geneve gnv0 mtu 1450
# OSPF over GENEVE
set protocols ospf area 0 network 172.16.0.0/30
set protocols ospf area 0 network 192.168.1.0/24
# Interface parameters for OSPF
set protocols ospf interface gnv0 hello-interval 10
set protocols ospf interface gnv0 dead-interval 40
set protocols ospf interface gnv0 priority 100
commit
saveOSPF verification:
show ip ospf neighbor
show ip ospf routeBridge Integration
GENEVE interfaces can be added to a bridge for L2 connectivity:
configure
# Create a bridge
set interfaces bridge br0 address 192.168.100.1/24
# Add GENEVE to the bridge
set interfaces bridge br0 member interface gnv0
# Add a local interface to the bridge
set interfaces bridge br0 member interface eth1
commit
saveUse case: L2 extension over a GENEVE tunnel
Monitoring and Debugging
Status Checks
# General information
show interfaces geneve
# Detailed statistics
show interfaces geneve gnv0
# Configuration only
show interfaces geneve gnv0 briefExample output:
gnv0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450
inet 172.16.0.1/30
RX: bytes packets errors dropped
1048576 1024 0 0
TX: bytes packets errors dropped
2097152 2048 0 0Packet Capture
# Capture traffic on the GENEVE interface
monitor traffic interface gnv0
# Filter by protocol
monitor traffic interface gnv0 filter "icmp"
# Save to a file
monitor traffic interface gnv0 save /tmp/geneve-capture.pcapDebugging
# Check the encapsulated traffic on the underlay
monitor traffic interface eth0 filter "udp port 6081"
# Check kernel messages
show log kernel | match geneveTroubleshooting
Issue: The GENEVE Tunnel Does Not Come Up
Diagnostics:
# 1. Check IP connectivity to the remote endpoint
ping 203.0.113.10
# 2. Verify that UDP 6081 is not blocked
sudo tcpdump -i eth0 udp port 6081
# 3. Check routing to the remote endpoint
show ip route 203.0.113.10
# 4. Check the firewall
show firewallCommon causes:
- The firewall blocks UDP 6081
- No IP connectivity to the remote endpoint
- Incorrect source-address
- MTU problems
Issue: Packet Loss Through the Tunnel
Diagnostics:
# Check the MTU path
ping 172.16.0.2 size 1450 do-not-fragment
# Check for fragmentation
show interfaces geneve gnv0
# Look at TX/RX errorsSolution:
# Reduce the MTU
set interfaces geneve gnv0 mtu 1400
commit
# Or enable TCP MSS clamping
set interfaces geneve gnv0 ip adjust-mss 1360
commitIssue: Low Performance
Causes:
- High encapsulation overhead
- CPU limitations during encap/decap
- Underlay network latency
Optimization:
# Enable offloading if the NIC supports it
set interfaces ethernet eth0 offload gso
set interfaces ethernet eth0 offload gro
set interfaces ethernet eth0 offload tso
# Increase the MTU on the underlay (if possible)
set interfaces ethernet eth0 mtu 9000
set interfaces geneve gnv0 mtu 8950
commitGENEVE vs VXLAN Comparison
| Characteristic | GENEVE | VXLAN |
|---|---|---|
| Default UDP Port | 6081 | 4789 |
| Header Size | Variable (min 8 bytes) | Fixed 8 bytes |
| VNI Bits | 24-bit | 24-bit |
| Extensibility | Yes (TLV options) | Limited |
| Multicast Support | Optional | Yes |
| Metadata Support | Yes | No |
| OAM Support | Built-in | External |
| IETF Standard | Draft | RFC 7348 |
| Adoption | Growing (OVN, NSX) | Wide (most vendors) |
When to choose GENEVE:
- Extensibility is needed (metadata, OAM)
- SDN environment (OpenStack, Kubernetes)
- Passing context between devices is required
When to choose VXLAN:
- Broad compatibility is required
- Hardware offload is critical
- An existing VXLAN infrastructure is in place
Best Practices
1. VNI Planning
# Use a logical VNI allocation scheme
# Example:
# 1000-1999: Production networks
# 2000-2999: Development networks
# 3000-3999: Test networks
# 4000-4999: Management networks
set interfaces geneve gnv-prod remote 10.0.1.1 vni 1000
set interfaces geneve gnv-dev remote 10.0.1.1 vni 2000
set interfaces geneve gnv-test remote 10.0.1.1 vni 30002. MTU Configuration
# Always account for overhead
# Formula: GENEVE MTU = Underlay MTU - 50 (IPv4) or -70 (IPv6)
# For underlay MTU 1500
set interfaces geneve gnv0 mtu 1450
# For Jumbo frames (MTU 9000)
set interfaces geneve gnv0 mtu 89503. Monitoring
# Set up SNMP for monitoring
set service snmp community public authorization ro
set service snmp community public network 192.168.1.0/24
# Or use syslog for logging
set system syslog host 192.168.1.100 facility all level info4. Security
# Restrict access with a firewall
set firewall name GENEVE-IN default-action drop
set firewall name GENEVE-IN rule 10 action accept
set firewall name GENEVE-IN rule 10 protocol udp
set firewall name GENEVE-IN rule 10 destination port 6081
set firewall name GENEVE-IN rule 10 source group network-group GENEVE-PEERS
set interfaces ethernet eth0 firewall in name GENEVE-IN5. Documentation
# Always document the purpose of each tunnel
set interfaces geneve gnv0 description 'GENEVE to DC-EAST VNI:1000 Prod'
set interfaces geneve gnv1 description 'GENEVE to DC-WEST VNI:1001 Prod'Conclusion
GENEVE is a modern, extensible protocol for network virtualization that:
Advantages:
- Flexibility through an extensible header
- Metadata support for SDN
- Compatibility with various transports
- IETF standardization
Use cases:
- Cloud overlay networks
- Multi-tenant environments
- Kubernetes/OpenStack networking
- Datacenter fabric virtualization
Best suited for:
- New SDN/NFV deployments
- Environments that require metadata
- Multi-vendor integration through an open standard
GENEVE is an excellent choice for modern network virtualization, especially in the context of the Yandex Cloud and VK Cloud platforms, where flexible isolation and overlay networking are required.