GENEVE - Generic Network Virtualization Encapsulation

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
save

Configuration Parameters

VNI (Virtual Network Identifier)

# The VNI identifies the virtual network (0-16777215)
set interfaces geneve gnv0 vni 100

VNI 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::10

Source Address (optional)

# If not specified, it is selected automatically based on the routing table
set interfaces geneve gnv0 source-address 203.0.113.1

UDP Port

# UDP destination port (default 6081)
set interfaces geneve gnv0 port 6081

# Use a custom port
set interfaces geneve gnv0 port 8472

Default 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/24

MTU 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/30

VyOS-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
save

VyOS-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
save

Verification:

# 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 route

Scenario 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/16

Configuration:

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
save

Scenario 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
save

Yandex 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
save

OSPF verification:

show ip ospf neighbor
show ip ospf route

Bridge 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
save

Use 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 brief

Example 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       0

Packet 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.pcap

Debugging

# Check the encapsulated traffic on the underlay
monitor traffic interface eth0 filter "udp port 6081"

# Check kernel messages
show log kernel | match geneve

Troubleshooting

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 firewall

Common 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 errors

Solution:

# Reduce the MTU
set interfaces geneve gnv0 mtu 1400
commit

# Or enable TCP MSS clamping
set interfaces geneve gnv0 ip adjust-mss 1360
commit

Issue: 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

commit

GENEVE vs VXLAN Comparison

CharacteristicGENEVEVXLAN
Default UDP Port60814789
Header SizeVariable (min 8 bytes)Fixed 8 bytes
VNI Bits24-bit24-bit
ExtensibilityYes (TLV options)Limited
Multicast SupportOptionalYes
Metadata SupportYesNo
OAM SupportBuilt-inExternal
IETF StandardDraftRFC 7348
AdoptionGrowing (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 3000

2. 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 8950

3. 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 info

4. 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-IN

5. 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.

Additional Resources

Reviewed by OpenNix LLC · Last updated on