Archous partnered with Big Network engineers to build our uCPE product, leveraging Big Network’s EdgeOS to deliver a robust remote network management platform with high-performance Layer 2 Ethernet pseudowires. The Ethernet Pseudowire solution extends Ethernet connectivity across IP networks, including the public Internet where remote spokes can call home through NAT without requiring a public IP address or inbound port forwarding. We explained more about this in our previous articles: Extending you Broadband Network Over any Internet Connection (With HA!) and Introducing Archous uCPE.
In this article we cover low-level details on the uCPEs to provide perspective to our customers on Ethernet Pseudowires such as protocol transparency, UDP forwarding performance, TCP application throughput, and WAN recovery.
Test Environment
The lab connected two uCPE appliances through a 10G WAN path via MikroTik CCR2116 routers which had Layer 3 hardware offload enabled, and a 10G backbone link to form a standard 1500-byte IP underlay.
For benchmarking, we used iperf3 on two Debian Linux VMs and the MikroTik RFC Testing tool developed by Sam Holub, with two custom-built MikroTik CHR VMs. The Debian Linux and CHR VMs remained well below 50% reported CPU utilization throughout testing.
We consolidated observations from iperf3 and the MikroTik tool, favored the lower results, and intentionally rounded down to provide conservative planning figures.
The reported UDP throughput uses a less-than-0.01% packet-loss criterion. These are low-loss measurements that are typically seen on RFC2544 tests.
Validated Traffic and Passed Protocols
We validated that the following traffic types, protocols, and encapsulations pass through the Ethernet pseudowire:
| Category | Validated traffic |
|---|---|
| Ethernet packet delivery | Unicast, multicast, and broadcast |
| L2 discovery / control protocols | VRRP, VTP, CDP, LLDP, MNDP, MAC-TELNET, and STP |
| Encapsulation | 802.1Q and 802.1ad (QinQ), MPLS |
| Network protocols | IPv4 and IPv6 |
| Tunnel protocols | IPsec, GRE, and IP-in-IP (IPIP) |
Note: Ethernet Pseudowires can only use an IPv4 underlay to form the transport tunnel connection.
For all throughput tests, we tested with 20 parallel streams and at 60 seconds of duration.
UDP forwarding performance
The following rates were achieved in each direction while both directions were tested simultaneously, through a single tunnel.
| Test size/profile | uCPE Small (each way simultaneously) | uCPE Medium/Large (each way simultaneously) |
|---|---|---|
| 64 bytes | 150 Mbps | 285 Mbps |
| 512 bytes | 450 Mbps | 855 Mbps |
| 1518 bytes | 600 Mbps | 1,140 Mbps |
| 2000 bytes | 550 Mbps | 1,045 Mbps |
| IMIX | 500 Mbps | 950 Mbps |
Note: Measured results, conservatively rounded down, with less than 0.01% packet loss. Actual throughput is much higher when packet loss is accepted above 0.01%.
For example, the Small uCPE’s 1518-byte result means it carried 600 Mbps in one direction while simultaneously carrying 600 Mbps in the other.
No UDP test results yielded any out of order packets.
Across the rounded results, the Medium/Large size uCPE delivered approximately 90% higher per-tunnel throughput.
During testing we also performed unidirectional UDP spot checks, throughput reached approximately the sum of the two simultaneous bidirectional rates:
| Platform | Bidirectional result at 1518 bytes | Unidirectional spot-check result |
|---|---|---|
| uCPE Small | 600 Mbps each way | Approximately 1.20 Gbps |
| uCPE Medium / Large | 1.14 Gbps each way | Approximately 2.28 Gbps |
TCP forwarding performance
We also tested TCP using iperf. Unlike the UDP tests, these tests did not apply an explicit packet-loss acceptance threshold.
TCP detects missing data, retransmits it, and adjusts its sending rate in response to network conditions. These tests therefore measure achieved TCP throughput while allowing TCP to manage loss, rather than identifying a forwarding rate below a loss threshold.
The different acceptance criteria and multi-stream workload help explain why the TCP results exceeded our conservatively rounded UDP figures.
| TCP test | VEP1485 | VEP4600 |
|---|---|---|
| Simultaneous receive | 750 Mbps | 1.5 Gbps |
| Simultaneous transmit | 750 Mbps | 1.5 Gbps |
| Simultaneous total—RX + TX | 1.5 Gbps | 3 Gbps |
| Single direction | 1.5 Gbps | 3 Gbps |
Tunnel Scale
The Archous Small uCPE has the capability to forward up to 5 Gbps of sustained aggregate throughput. On the Medium/Large uCPE, that capability increases to 10 Gbps.
Reaching those levels involves distributing multiple tunnels across CPU cores and combining their forwarding capacity. Big Network EdgeOS handles that distribution, drawing on the engineering work undertaken by Archous and Big Network in developing the product.
Final Observations
Quick Start / Datasheets
Datasheets and quick start guides for the uCPEs can be found below:
Archous_uCPE_Small_Quick_Start.pdf
Archous_uCPE_Medium_Large_Quick_Start.pdf
WAN failover and failback
We measured recovery from physical-link, DHCP, ARP, and routing failures.
| Failure scenario | Failover | Failback |
|---|---|---|
| Physical link | 12 seconds | 30 seconds |
| DHCP | 16 seconds | 12 seconds |
| ARP | 9 seconds | 12 seconds |
| Routing | 9 seconds | 6 seconds |
Failover ranged from 9 to 16 seconds, while failback ranged from 6 to 30 seconds.
Maximum MTU
4870 bytes is the maximum supported MTU that can be passed through an Ethernet Pseudowire. This result is measured with an underlay configured at 1500 bytes.
A True Disruptor
Archous uCPE is a highly flexible platform designed to deliver high performance at a competitive price compared with similar solutions. Powered by VMware, it extends beyond networking to host services such as virtual routers, VPNs, DNS, and other infrastructure tools in one tightly integrated solution. Archous backs the platform with 24/7 on-call support, giving customers access to technical assistance when issues arise, with monitoring and ongoing management provided through the selected managed-service plan.