On this page
Key points
- Assign a specific jobTunnel termination, route control and packet forwarding need different evidence and resources.
- Size the complete pathA virtual port label does not measure what the guest, host and physical link can sustain.
- Test a real serviceA second BGP session is useful only when the selected routes and application path recover as intended.
Decide what the VM will do before choosing its size
A router VM can terminate an approved GRE handoff, maintain BGP sessions or route traffic between networks. Write down which of those jobs is required. Route control and packet forwarding are related but different: a VM that exchanges routes without carrying application traffic should not be sized like an inline gateway.
Draw the actual path through public ingress, tunnel termination, application networks, return routing and management access. Identify the organization responsible for each boundary. Include IPv4 and IPv6 separately where used. This small record makes it possible to distinguish a guest configuration issue from a host, provider or remote-endpoint issue.
An existing dedicated server may already perform some of these functions. Adding a VM should solve a defined problem such as isolating the routing role or preparing another approved handoff. Moving the same dependencies into two processes does not by itself create independent redundancy.
Make route policy part of the delivery specification
For each BGP neighbor, agree on local and remote ASNs, address family, source and peer addresses, permitted announcements and expected received routes. A default route, a restricted set of routes and a full Internet table create different requirements. Do not assume a service includes a full table because it supports BGP.
List what the session may import and export, its prefix limits and the intended response when those limits are reached. Keep a record of ownership and authorization for advertised prefixes. Operational BGP security includes route policy as well as protection of the session; the BGP operations guidance in RFC 7454 is a useful review reference.
After a session is established, inspect accepted routes and the routes installed for the relevant destinations. Check the next hop and the forwarding path from the application side. The session state alone does not prove that a default route was received, that your prefixes were accepted or that return traffic can reach the application.
Measure the virtualized forwarding path
The interface speed displayed inside a guest is not a sustained throughput commitment. Record the allocated CPU, memory, guest driver, virtual NIC model and queue configuration, then identify the host resources that are actually available to the service. Host contention and the physical uplink remain part of the path.
Measure both traffic volume and packet rate in the direction that matters. A stream of large packets and a large number of small packets can use similar bandwidth while requiring very different numbers of forwarding operations. NAT, filtering, tunnel processing and additional service functions must be included if they will be enabled in production.
Inspect drops and utilization at both guest and host boundaries when those measurements are available. A low average CPU value can hide pressure on a particular queue or core. Linux networking documentation describes RSS, RPS and related mechanisms; those mechanisms require deployment-specific review rather than a universal queue-count recipe.
Treat encapsulation and MTU as separate acceptance items
Record the delivered outer endpoint, inner addressing, encapsulation and MTU for each tunnel. A basic GRE header over IPv4 consumes 24 bytes before optional fields or other encapsulation. That arithmetic does not establish the real path MTU. Primary and backup tunnels can have different transport constraints.
Check representative application exchanges with larger payloads as well as short connectivity probes. A small ping or an established BGP session is insufficient evidence for every TCP and UDP service. Review the intended return path and path-MTU behavior with the network team; changing TCP MSS does not solve every oversized UDP exchange.
Define which failure the backup is supposed to survive
A second VM on the same host can survive a guest-specific problem while still sharing power, hypervisor, physical NIC and upstream dependencies. Record those shared components before describing a service as redundant. Two established sessions do not prove that two independent data paths exist.
Agree on primary and backup route selection for both traffic directions. The important questions are which event removes or deprioritizes the primary route, whether an alternative route is eligible, and what happens when the primary returns. Review persistent static routes as well as BGP; an unrelated static route may continue selecting a failed path.
Use an authorized maintenance test with a known-working application reference and a rollback owner. Compare the route selected, traffic counters and application result during the specific failure being tested. Record recovery time and any effect on existing sessions. Do not extrapolate a guest restart test into survival of a host or upstream outage.
Accept the deployment against observable results
Before the VM carries an important production dependency, agree on a short acceptance record. Keep performance tests in an isolated environment where overload cannot spill onto customers. RFC 6815 explains why RFC 2544 capacity tests are inappropriate on production networks.
| Check | Evidence to retain | Boundary of the result |
|---|---|---|
| Routing | Expected imports, exports, installed routes and next hops | Established BGP is only the session state |
| Application path | A completed exchange through the intended ingress and return path | One application does not validate every protocol |
| MTU | Delivered settings and representative larger exchanges on each path | A byte calculation is not a path measurement |
| Forwarding | Bidirectional counters, packet sizes, active features and observed loss | Virtual port speed is not measured forwarding capacity |
| Recovery | Selected routes, user impact, recovery time and restoration behavior | Only the tested failure and dependencies are covered |
Questions before ordering a Router VM
Does a Router VM replace upstream DDoS protection?
Not by itself. It can perform a routing or delivery role, but traffic still has to reach it through a usable network path. Separate upstream capacity, filtering, virtual resources and service scope when evaluating a design.
Does support for BGP mean a full table is included?
No. Confirm address families, received routes, prefix limits and the actual service conditions. Routing-table memory and update work must be sized for the agreed policy.
What information helps qualify the deployment?
Describe the intended routing role, ASN and authorized prefixes where applicable, tunnel delivery, expected traffic in Gbit/s and packets/s, active network functions and recovery requirements. Keep credentials and private keys out of the request.
