LUNAROPS · OPERATIONAL UPLINK 100% UPTIME 1,247d POSTS 893 JEFF.MOON@LUNAROPS.DEV UTC --:--:--

Proxmox SDN: Software Defined Networking

17 min read Networking Deep Dives
proxmoxsdnnetworkingvxlanevpnbgpovsinfrastructure
Contents

Proxmox SDN: Software Defined Networking

Traditional Proxmox networking uses Linux bridges configured per-node. This works for small setups, but as clusters grow you hit real limitations: network config must be manually replicated across nodes, VLANs require physical switch configuration, and there’s no built-in way to create isolated tenant networks that span nodes without pre-provisioning them on every host.

Proxmox SDN (introduced as stable in PVE 8.1) solves this with a cluster-wide networking abstraction. You define networks once in the datacenter-level configuration and Proxmox propagates them to all nodes automatically. More importantly, it supports VXLAN and EVPN overlay networks that let you create virtual L2 segments spanning the entire cluster without touching your physical switches.

This post covers the full SDN stack: the zone and VNet model, simple VLAN zones, VXLAN overlays, EVPN with BGP for proper multi-site routing, and practical configurations for multi-tenant isolation.

Core Concepts

Proxmox SDN introduces three abstractions stacked on top of each other:

Zone: defines a networking technology and its scope. A zone represents how networks are implemented — plain Linux bridge, VLAN-aware bridge, VXLAN overlay, or EVPN overlay. Each zone maps to one network implementation type.

VNet: a virtual network within a zone. Think of it as a virtual switch or a network segment. VMs attach to VNets the same way they attach to regular bridges.

Subnet: optional L3 configuration on a VNet — CIDR, gateway, DHCP settings. Proxmox can optionally run IPAM (IP Address Management) to track allocations.

The relationship: one Zone contains many VNets. Each VNet is one network segment. VMs connect to VNets.

Datacenter SDN
├── Zone: vlan-zone (Simple/VLAN)
│   ├── VNet: production (VLAN 100)
│   ├── VNet: staging (VLAN 200)
│   └── VNet: management (VLAN 10)
├── Zone: overlay-zone (VXLAN)
│   ├── VNet: tenant-a (VNI 10100)
│   └── VNet: tenant-b (VNI 10200)
└── Zone: evpn-zone (EVPN)
    ├── VNet: corp-net (VNI 20100)
    └── VNet: dmz (VNI 20200)

Prerequisites and Installation

Installing SDN Dependencies

1
2
3
4
5
6
7
8
9

# On each Proxmox node
apt update
apt install libpve-network-perl ifupdown2

# For EVPN/BGP
apt install frr frr-pythontools

# Verify SDN is available in the web UI
# Datacenter → SDN (should appear in the menu)

Network Requirements

SDN works best with:

  • A dedicated VLAN trunk port per node for VLAN-based zones
  • Routed underlay connectivity between nodes for VXLAN/EVPN (all nodes must be able to reach each other’s VTEP IP)
  • For EVPN: BGP peering between nodes (or to external route reflectors)

Zone Types

Simple Zone

The simplest zone type: just creates a Linux bridge per VNet, no VLAN or overlay. Useful for creating named network segments that are automatically replicated across nodes.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# Create via CLI
pvesh create /cluster/sdn/zones \
  --zone simple-zone \
  --type simple

# Create a VNet in this zone
pvesh create /cluster/sdn/vnets \
  --vnet isolated-net \
  --zone simple-zone \
  --alias "Isolated lab network"

# Apply the config to all nodes
pvesh set /cluster/sdn

After applying, every node will have a Linux bridge named isolated-net. VMs attach to it like any other bridge. Traffic between VMs on the same node flows through the local bridge; traffic between nodes requires routed connectivity or a physical switch trunk.

Simple zones are primarily useful for documentation and config-management purposes — the real power comes with VLAN and overlay zones.

VLAN Zone

Maps each VNet to a VLAN tag on a VLAN-aware trunk interface. This is the straightforward replacement for manually configured VLAN bridges.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

# Create VLAN zone on trunk interface vmbr0
pvesh create /cluster/sdn/zones \
  --zone vlan-zone \
  --type vlan \
  --bridge vmbr0

# Create VNets (each gets a VLAN tag)
pvesh create /cluster/sdn/vnets \
  --vnet prod-net \
  --zone vlan-zone \
  --tag 100 \
  --alias "Production network"

pvesh create /cluster/sdn/vnets \
  --vnet staging-net \
  --zone vlan-zone \
  --tag 200 \
  --alias "Staging network"

pvesh create /cluster/sdn/vnets \
  --vnet mgmt-net \
  --zone vlan-zone \
  --tag 10 \
  --alias "Management network"

# Apply
pvesh set /cluster/sdn

Your physical switch port connected to vmbr0 must be a VLAN trunk carrying VLANs 10, 100, 200. Traffic is tagged at the bridge and carried over the physical infrastructure to other nodes.

Adding Subnets and DHCP

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# Add a subnet to a VNet with DHCP
pvesh create /cluster/sdn/vnets/prod-net/subnets \
  --subnet 10.100.0.0/24 \
  --gateway 10.100.0.1 \
  --snat 0 \
  --dhcp-range start-address=10.100.0.100,end-address=10.100.0.200

# Proxmox runs dnsmasq for DHCP when subnets are configured
# Enable DHCP on the zone
pvesh set /cluster/sdn/zones/vlan-zone \
  --ipam pve  # use Proxmox built-in IPAM

pvesh set /cluster/sdn

With DHCP configured, VMs on the VNet receive addresses automatically. Proxmox tracks allocations in its IPAM database.

VXLAN Zones: Overlay Networking

VXLAN (Virtual Extensible LAN) encapsulates L2 Ethernet frames inside UDP packets, creating virtual L2 segments that span routed IP networks. In Proxmox SDN, a VXLAN zone creates VTEP (VXLAN Tunnel Endpoint) interfaces on each node and bridges them to VNet interfaces.

When to use VXLAN over VLAN:

  • You need more than 4094 network segments (VXLAN supports ~16 million VNIs)
  • Your physical switches don’t support VLAN trunking to hypervisor hosts
  • You want network segments that span multiple sites connected by IP routing
  • You’re building a multi-tenant environment with arbitrary tenant isolation

VXLAN limitations (without EVPN):

  • Uses multicast or flooding for BUM (Broadcast, Unknown unicast, Multicast) traffic — requires multicast in the underlay, or falls back to unicast flooding to all peers
  • No L3 routing between VNets — requires an external router or a VM acting as gateway
  • MAC learning is per-VTEP, which can cause issues at scale
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# Create VXLAN zone
# peers: list of node IPs that form the VXLAN mesh
pvesh create /cluster/sdn/zones \
  --zone vxlan-zone \
  --type vxlan \
  --peers "10.0.1.1,10.0.1.2,10.0.1.3"

# Create VNets (each gets a VNI)
pvesh create /cluster/sdn/vnets \
  --vnet tenant-a \
  --zone vxlan-zone \
  --tag 10100   # VNI 10100

pvesh create /cluster/sdn/vnets \
  --vnet tenant-b \
  --zone vxlan-zone \
  --tag 10200   # VNI 10200

pvesh set /cluster/sdn

After applying, each node has:

  • A VXLAN interface vxlan10100 listening on UDP port 4789
  • A bridge tenant-a connected to the VXLAN interface
  • VMs on tenant-a can communicate across nodes via VXLAN encapsulation

Verifying VXLAN Operation

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Check VXLAN interfaces
ip -d link show type vxlan

# Check the bridge and FDB (Forwarding Database)
bridge fdb show dev vxlan10100

# Capture VXLAN traffic on the underlay
tcpdump -i eth1 -n udp port 4789

# Test connectivity between VMs on different nodes
# From a VM on pve1, ping a VM on pve2 — should work transparently

EVPN Zones: BGP-Controlled Overlays

EVPN (Ethernet VPN, RFC 7432) is the control plane for VXLAN that replaces multicast/flooding with BGP-distributed MAC/IP information. When a VM on node A wants to reach a VM on node B, instead of flooding frames to all VTEPs, the local VTEP looks up the destination MAC in its BGP EVPN table and sends the VXLAN packet directly to the correct remote VTEP.

EVPN advantages over plain VXLAN:

  • No multicast requirement in the underlay — works over any IP network
  • Scales to thousands of VNets without flooding overhead
  • Supports L3 routing between VNets via Symmetric IRB (Integrated Routing and Bridging)
  • MAC mobility: when a VM migrates, BGP distributes the MAC update immediately
  • ARP suppression: VTEPs answer ARP requests locally, eliminating broadcast storms

EVPN requires FRR (Free Range Routing) running on each Proxmox node for BGP.

EVPN Architecture Options

Route reflector topology (recommended for 4+ nodes):

          ┌─────────────────────┐
          │  Route Reflector    │  (can be a dedicated VM or dedicated node)
          │  (FRR, no VTEPs)    │
          └──────┬──────┬───────┘
                 │      │
        ┌────────┘      └────────┐
        │                        │
   ┌────▼────┐              ┌────▼────┐
   │  pve1   │──────────────│  pve2   │
   │  VTEP   │              │  VTEP   │
   └────┬────┘              └────┬────┘
        │                        │
   ┌────▼────┐
   │  pve3   │
   │  VTEP   │
   └─────────┘

Full mesh topology (for 3 nodes, simpler):

  • Every node has BGP sessions to every other node
  • No route reflector needed
  • Doesn’t scale beyond ~5 nodes

Configuring EVPN in Proxmox SDN

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

# Create EVPN zone
pvesh create /cluster/sdn/zones \
  --zone evpn-zone \
  --type evpn \
  --controller evpn-controller \
  --vrf-vxlan 4000 \
  --exitnodes "pve1,pve2"  # nodes that provide L3 egress routing

# Create the BGP controller
pvesh create /cluster/sdn/controllers \
  --controller evpn-controller \
  --type evpn \
  --asn 65000 \
  --peers "10.0.1.1,10.0.1.2,10.0.1.3"

# Create VNets
pvesh create /cluster/sdn/vnets \
  --vnet corp-net \
  --zone evpn-zone \
  --tag 20100   # VNI

pvesh create /cluster/sdn/vnets \
  --vnet dmz \
  --zone evpn-zone \
  --tag 20200

# Add subnets with gateways for L3 routing
pvesh create /cluster/sdn/vnets/corp-net/subnets \
  --subnet 10.200.0.0/24 \
  --gateway 10.200.0.1 \
  --snat 0

pvesh create /cluster/sdn/vnets/dmz/subnets \
  --subnet 10.201.0.0/24 \
  --gateway 10.201.0.1 \
  --snat 0

pvesh set /cluster/sdn

FRR BGP Configuration

Proxmox SDN generates the FRR configuration automatically when you apply SDN config. The generated config (at /etc/frr/frr.conf) looks like:

frr version 9.1
frr defaults traditional
hostname pve1
log syslog informational
no ipv6 forwarding

router bgp 65000
 bgp router-id 10.0.1.1
 no bgp default ipv4-unicast
 no bgp ebgp-requires-policy

 neighbor 10.0.1.2 remote-as 65000
 neighbor 10.0.1.2 update-source 10.0.1.1
 neighbor 10.0.1.3 remote-as 65000
 neighbor 10.0.1.3 update-source 10.0.1.1

 address-family l2vpn evpn
  neighbor 10.0.1.2 activate
  neighbor 10.0.1.2 next-hop-self
  neighbor 10.0.1.3 activate
  neighbor 10.0.1.3 next-hop-self
  advertise-all-vni
 exit-address-family

ip nht resolve-via-default

Verify BGP sessions are up:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# Check BGP session status
vtysh -c "show bgp summary"

# View EVPN routes
vtysh -c "show bgp l2vpn evpn"
vtysh -c "show bgp l2vpn evpn route type 2"  # MAC/IP routes
vtysh -c "show bgp l2vpn evpn route type 3"  # Inclusive multicast (IMET)

# Check VNI table
vtysh -c "show evpn vni"

# Check MAC table
vtysh -c "show evpn mac vni 20100"

# Check ARP/ND suppression table
vtysh -c "show evpn arp-cache vni 20100"

L3 Routing Between VNets (Symmetric IRB)

With EVPN and L3VNI (a dedicated VNI for routing), traffic between VNets is routed at the ingress VTEP rather than needing a dedicated router VM:

1
2
3
4
5
6
7
8

# The vrf-vxlan setting in the zone creates an L3VNI
# In our example: --vrf-vxlan 4000 creates VNI 4000 for the L3 domain

# Traffic from corp-net (10.200.0.0/24) to dmz (10.201.0.0/24):
# 1. VM sends packet to its default gateway (10.200.0.1 — anycast on all VTEPs)
# 2. Local VTEP routes to dmz VNI, encapsulates with L3VNI 4000
# 3. Remote VTEP decapsulates and delivers to destination VM
# No traffic leaves the VXLAN overlay — purely distributed routing

Exit Nodes: Reaching the Physical Network

EVPN VMs by default can only reach other VMs in the EVPN domain. To reach the internet or on-premises networks, configure exit nodes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# Exit nodes are Proxmox nodes that route EVPN traffic to the physical network
# Set in the zone config: --exitnodes "pve1,pve2"

# On exit nodes, Proxmox configures:
# 1. A VRF (Virtual Routing and Forwarding) table for each zone
# 2. Route leaking from the EVPN VRF to the default routing table
# 3. NAT (if --snat is configured on subnets)

# Verify routing on an exit node
ip vrf exec vrf_evpn-zone ip route show

# Check NAT rules
iptables -t nat -L POSTROUTING -n

Multi-Tenant Isolation Patterns

Pattern 1: VLAN Zones per Tenant

Simple and auditable. Each tenant gets its own VLAN zone and VLAN range:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Tenant A: VLANs 100-199
pvesh create /cluster/sdn/zones --zone tenant-a --type vlan --bridge vmbr0
pvesh create /cluster/sdn/vnets --vnet ta-web --zone tenant-a --tag 100
pvesh create /cluster/sdn/vnets --vnet ta-db --zone tenant-a --tag 110

# Tenant B: VLANs 200-299
pvesh create /cluster/sdn/zones --zone tenant-b --type vlan --bridge vmbr0
pvesh create /cluster/sdn/vnets --vnet tb-web --zone tenant-b --tag 200
pvesh create /cluster/sdn/vnets --vnet tb-db --zone tenant-b --tag 210

pvesh set /cluster/sdn

Limitation: physical switches must carry all VLANs on trunk ports. Doesn’t scale beyond ~100 tenants cleanly.

Pattern 2: EVPN with Per-Tenant VNIs

More scalable. Each tenant gets VNets in a shared EVPN zone but different VNIs (effectively different broadcast domains):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# All tenants share the EVPN zone
pvesh create /cluster/sdn/zones \
  --zone shared-evpn \
  --type evpn \
  --controller evpn-ctrl \
  --vrf-vxlan 4000

# Tenant A gets VNIs in range 10100-10199
pvesh create /cluster/sdn/vnets --vnet ta-net1 --zone shared-evpn --tag 10100
pvesh create /cluster/sdn/vnets --vnet ta-net2 --zone shared-evpn --tag 10101

# Tenant B gets VNIs in range 10200-10299
pvesh create /cluster/sdn/vnets --vnet tb-net1 --zone shared-evpn --tag 10200
pvesh create /cluster/sdn/vnets --vnet tb-net2 --zone shared-evpn --tag 10201

pvesh set /cluster/sdn

VMs on ta-net1 and tb-net1 cannot communicate — they’re in completely separate broadcast domains. Neither can reach the other without an explicit routing policy.

Pattern 3: EVPN Zones per Tenant (Full Isolation)

Strongest isolation model. Each tenant has its own EVPN zone with its own VRF and L3VNI:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# Tenant A: own VRF and L3VNI
pvesh create /cluster/sdn/zones \
  --zone evpn-tenant-a \
  --type evpn \
  --controller evpn-ctrl \
  --vrf-vxlan 14000  # unique L3VNI per tenant

# Tenant B: own VRF and L3VNI
pvesh create /cluster/sdn/zones \
  --zone evpn-tenant-b \
  --type evpn \
  --controller evpn-ctrl \
  --vrf-vxlan 24000

pvesh set /cluster/sdn

With separate VRFs, even if tenants use overlapping IP ranges (10.0.0.0/24 for both), there’s no conflict — they’re in isolated routing tables.

Firewalling SDN Networks

Proxmox’s built-in firewall integrates with SDN. You can apply firewall rules at the VNet level (applied to all VMs on that VNet) or at the VM NIC level.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Enable firewall on a VNet (applied to all VM interfaces on this VNet)
# In /etc/pve/sdn/vnets/prod-net.cfg:
# firewall: 1

# Proxmox firewall rule format for SDN VNets
# /etc/pve/firewall/cluster.fw

[RULES]
# Allow inter-VNet traffic only from specific sources
IN ACCEPT -source 10.100.0.0/24 -dest 10.200.0.0/24 -p tcp -dport 5432 -comment "allow app to DB"
IN DROP -source 10.100.0.0/24 -dest 10.200.0.0/24 -comment "block other app-to-DB"

For more complex microsegmentation, use the per-VM firewall configuration in conjunction with SDN:

# /etc/pve/firewall/100.fw (VM 100)
[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT

[RULES]
IN ACCEPT -p tcp -dport 80 -comment "allow HTTP"
IN ACCEPT -p tcp -dport 443 -comment "allow HTTPS"
IN ACCEPT -source 10.100.0.0/24 -p tcp -dport 22 -comment "allow SSH from management"

Troubleshooting SDN

SDN Config Not Applying

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Check for pending changes
pvesh get /cluster/sdn

# Manually apply config on a specific node
pvesh set /cluster/sdn --node pve1

# Check the SDN service
systemctl status pve-sdn

# View application logs
journalctl -u pve-sdn -f

VXLAN Connectivity Issues

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# Verify VXLAN interface exists
ip -d link show type vxlan

# Check VTEP is listening on UDP 4789
ss -ulnp | grep 4789

# Verify underlay connectivity between nodes
ping -c3 10.0.1.2  # must succeed

# Check firewall isn't blocking UDP 4789
iptables -L INPUT -n | grep 4789

# Allow VXLAN if blocked
iptables -I INPUT -p udp --dport 4789 -j ACCEPT

BGP/EVPN Not Working

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# Check FRR is running
systemctl status frr

# Check BGP sessions
vtysh -c "show bgp summary"
# Look for: "Established" state and non-zero PfxRcd (prefixes received)

# Check if FRR config was generated correctly
cat /etc/frr/frr.conf

# Restart FRR if needed (doesn't affect running VMs)
systemctl restart frr

# Debug BGP session establishment
vtysh
  debug bgp neighbor-events
  debug bgp updates

# Check system log for FRR events
journalctl -u frr -f

VM Can’t Reach Gateway

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# Verify the VNet bridge exists on the node
brctl show | grep corp-net

# Check VRF routing table (for EVPN zones)
ip vrf exec vrf_evpn-zone ip route show

# Verify the anycast gateway MAC is present on the bridge
ip link show corp-net
bridge fdb show dev corp-net | grep "00:00:00:00:00" # anycast MAC

# Ping the gateway from inside the VM
# If gateway doesn't respond, check subnet config in SDN
pvesh get /cluster/sdn/vnets/corp-net/subnets

Operational Notes

Applying SDN Changes

SDN config changes are staged until you explicitly apply them. This is a safety feature — misconfigured SDN applied to all nodes simultaneously could disconnect all VMs:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# Stage changes (safe — doesn't affect running infrastructure)
pvesh create /cluster/sdn/vnets --vnet new-net --zone evpn-zone --tag 30100

# Review what will change
pvesh get /cluster/sdn

# Apply to all nodes at once
pvesh set /cluster/sdn

# Apply to a single node first (test before rolling out)
pvesh set /cluster/sdn --node pve1
# Verify, then apply to remaining nodes
pvesh set /cluster/sdn

Performance Considerations

VXLAN encapsulation adds overhead:

  • CPU: software VXLAN offload uses CPU cycles. With hardware offload (modern NICs support VXLAN TX/RX offload), overhead is minimal.
  • MTU: VXLAN adds 50 bytes of overhead. If your underlay MTU is 1500, effective VM MTU is 1450. Set the underlay MTU to 1600 or use jumbo frames (9000) to avoid fragmentation.
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Set underlay interface MTU on each node
ip link set eth1 mtu 1600

# Or permanently in /etc/network/interfaces:
iface eth1 inet static
    ...
    mtu 1600

# Verify VM NIC MTU matches (should auto-negotiate lower)
# Inside a VM:
ip link show eth0
# MTU should reflect the reduced MTU after VXLAN overhead

BGP Route Reflector for Large Clusters

For clusters beyond 5 nodes, a full-mesh BGP topology becomes unwieldy (each node needs sessions to every other node). Set up a route reflector:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

# Dedicate a small VM as route reflector (2 vCPU, 1 GB RAM is enough)
# Install FRR on the VM
apt install frr frr-pythontools

# /etc/frr/frr.conf on route reflector:
router bgp 65000
 bgp router-id 10.0.1.100
 no bgp default ipv4-unicast

 # All Proxmox nodes as route reflector clients
 neighbor VTEPS peer-group
 neighbor VTEPS remote-as 65000
 neighbor VTEPS update-source lo
 neighbor VTEPS route-reflector-client

 neighbor 10.0.1.1 peer-group VTEPS
 neighbor 10.0.1.2 peer-group VTEPS
 neighbor 10.0.1.3 peer-group VTEPS
 neighbor 10.0.1.4 peer-group VTEPS
 neighbor 10.0.1.5 peer-group VTEPS

 address-family l2vpn evpn
  neighbor VTEPS activate
  neighbor VTEPS route-reflector-client
 exit-address-family

# Update Proxmox SDN controller to point to route reflector
pvesh set /cluster/sdn/controllers/evpn-ctrl \
  --peers "10.0.1.100"  # only peer with RR, not full mesh
pvesh set /cluster/sdn

SDN vs Traditional Proxmox Networking

Aspect Traditional (/etc/network/interfaces) Proxmox SDN
Config management Manual per-node Cluster-wide, single point of change
VLAN support Manual bridge per VLAN or VLAN-aware bridge Declarative, auto-provisioned
Overlay networks Not supported natively VXLAN and EVPN built-in
Multi-tenancy Manual firewall rules Zone/VNet isolation with EVPN VRFs
L3 routing External router VM or physical router Distributed routing with Symmetric IRB
Troubleshooting Simple, well-understood More complex, requires BGP knowledge
Stability Mature Newer, improving rapidly (stable in PVE 8.1+)

For homelabs and simple clusters, traditional networking is fine. For multi-tenant environments, clusters spanning multiple sites, or any environment requiring more than ~20 isolated network segments, SDN becomes the right tool.

The learning investment is real — VXLAN and EVPN concepts take time to internalize. But once the mental model clicks, Proxmox SDN gives you the kind of network flexibility that previously required expensive SDN appliances or dedicated networking hardware.

Comments