SONiC (Software for Open Networking in the Cloud), with its open, modular architecture and standardized interfaces, has become a key software foundation for building open networking platforms. As open networking expands beyond traditional data center switching into routing scenarios such as Internet edge, service provider edge, broadband access, and regional aggregation, the challenge is evolving from simply whether a platform can perform routing and forwarding to whether it can support millions of routes and efficiently deliver those routes into the data plane.

AsterNOS-VPP integrates the SONiC control and management framework with the high-performance VPP (Vector Packet Processing) software data plane:

• Control and management plane: SONiC provides network operations, routing protocol control, and unified configuration management.
• Data plane: VPP provides high-performance vector packet forwarding.
• Adaptation layer: A VPP-oriented SAI (Switch Abstraction Interface) adapter, libsaivpp.so, translates standard SAI operations from SONiC into data-plane operations that can be executed by VPP.

Building on this architecture, AsterNOS-VPP introduces end-to-end optimizations across control-plane processing, route download, and data-plane installation for large-scale routing environments. These optimizations enable millions of IPv4 and IPv6 routes not only to be efficiently learned by the control plane but also to traverse the complete SONiC + VPP software path efficiently and ultimately be installed in the VPP FIB (Forwarding Information Base).

This white paper is intended for network architects in service provider, cloud networking, and large enterprise environments, as well as presales engineers, solution architects, and network engineers responsible for evaluating Internet edge, peering, broadband edge, regional networking, white-box routing, and virtual routing platforms.

Readers are expected to have a working knowledge of IPv4/IPv6 routing, BGP, RIB/FIB concepts, and the basic SONiC architecture.

Route scale is not an isolated, static metric. As network architectures become flatter and service boundaries continue to expand, a single edge router may need to accommodate large volumes of routes from the public Internet, multiple upstream service providers, customer networks, access users, cloud resources, and internal enterprise networks. Large-scale IPv6 deployment, high-density peering relationships, and the growing use of granular host routes are further driving rapid growth in routing-table size.

• Internet edge: Devices may need to receive full Internet routing tables from multiple upstream ISPs (Internet Service Providers), as well as routes from IXPs (Internet Exchange Points) and private peering sessions, while also maintaining internal infrastructure and customer routes.
• Broadband and service provider edge: As subscriber scale increases, the system may need to generate and maintain large numbers of subscriber prefixes and host routes.
• Cloud and regional aggregation: Prefixes from geographically distributed data centers, multiple VPCs (Virtual Private Clouds), and multiple service domains may converge on core or regional aggregation nodes.

Once route scale reaches the million-route level, the key challenge is no longer limited to whether the control plane can learn and retain the required routes. The more important question is whether those routes can be delivered quickly and reliably into the underlying hardware or software data plane.

Accordingly, platform capability needs to be evaluated across two dimensions:

• Route capacity: The maximum number of route entries that the platform can stably accommodate.
• Route download performance: The end-to-end efficiency of moving large numbers of routes from control-plane processing into the data plane, measured by the number of route entries successfully downloaded per unit of time.

AsterNOS-VPP is optimized to ensure that large-scale routing information can be reliably maintained in the VPP FIB, while providing clearly defined route-capacity and route-download performance metrics for deployment planning.

AsterNOS-VPP is built on a unified SONiC + VPP software architecture and provides routing capabilities for both virtual machine (VM) deployments and ET-series white-box hardware platforms.

The values shown above are not cumulative across different route types. Each figure represents the supported capacity for a single address family and a single route type. In production networks that combine IPv4 and IPv6, host and prefix routes, or large numbers of BGP paths, overall capacity should be planned according to the actual route mix.

When evaluating large-scale routing performance, it is important to distinguish route capacity from route download performance.

In this white paper, route download performance refers to the end-to-end processing efficiency from the point at which routes are injected in bulk, through control-plane processing, state propagation, and data-plane installation, until the routes are installed in the VPP FIB and become available for forwarding.

This metric is distinct from BGP session establishment time, BGP UPDATE reception rate, or routing convergence time.

To compare processing capabilities across software versions and different VPP core allocations, this white paper uses the average route download rate (routes/s) as the primary performance metric.

For production release download, please go to: AsterNOS-VPP_V6.1_R0104P02 – 2026 Major Update

Route download rate is not a fixed value. Actual end-to-end performance may vary depending on factors such as the IPv4/IPv6 route mix, the types and number of iBGP/eBGP neighbors, routing policies, and overall control-plane processing complexity. V1.4P03T01 is currently an internal test build.

ET-series platforms allocate 2 cores to VPP by default. In current testing, increasing the number of cores allocated to VPP from 2 to 4 further improves million-scale route download performance. Increasing the allocation beyond 4 cores has not shown a significant additional performance gain.

The presence of a BGP route in the control plane does not necessarily mean that it is already available for packet forwarding. In AsterNOS-VPP, a dynamic route must traverse the complete software processing path before it is ultimately installed in the VPP data plane.

• Protocol Processing and Route Management (FRR): FRRouting (FRR) handles dynamic routing protocol interactions. Using BGP as an example, the bgpd process receives routes from BGP neighbors and performs best-path selection. The selected routes are then passed to zebra, which provides unified route management.
• State Propagation (FPM): zebra uses the Forwarding Plane Manager (FPM) interface to pass selected routes into the SONiC route-processing pipeline.
• Object Orchestration and Translation (SWSS / RouteOrch): Within SWSS (Switch State Service), fpmsyncd receives route events and passes them to RouteOrch inside orchagent for object orchestration. RouteOrch then describes the required data-plane operations through the standard SAI interface.
• Adaptation and Execution (syncd / libsaivpp.so): The syncd process receives and processes SAI operations and invokes the VPP-specific adaptation layer, libsaivpp.so.
• Data-Plane FIB Installation (VPP FIB): libsaivpp.so translates standard SAI operations into data-plane operations that can be executed by VPP and installs the corresponding entries into the VPP IPv4/IPv6 FIB, completing the path from control-plane routing information to an operational forwarding entry in the data plane.

As route scale grows from tens or hundreds of thousands of entries to several million, system limitations are no longer determined simply by whether an individual component can support that many routes. The more important question is whether the entire route download path can continuously and efficiently process such a large number of objects.

The performance bottleneck does not necessarily remain at the same point as route scale changes. Message-processing, state-synchronization, or interface-call overhead that may be negligible at several hundred thousand routes can become a major limiting factor at multi-million-route scale. Once one stage is optimized, the bottleneck may shift to a downstream component. Million-scale route performance is therefore fundamentally a system-level issue across the entire software path rather than a problem that can be solved by tuning a single parameter or component.

In AsterNOS-VPP, after a dynamic route is learned and selected by FRR, it must pass through multiple software components—including FPM, SWSS, SAI, syncd, and libsaivpp.so—before it is ultimately installed in the VPP FIB. A single message transfer, Redis operation, or SAI call may contribute only a small amount of overhead for an individual route. However, when the same operation is repeated one million or even four million times, these small fixed costs are amplified by scale.

AsterNOS-VPP therefore optimizes the entire route download path. The goal is not to identify a single “fastest” parameter for every deployment, but to address three key challenges within the constraints of the SONiC + VPP architecture, route scale, and available system resources: per-route processing overhead, state synchronization, and intermediate object accumulation.

Bottleneck:

In a traditional per-route processing model, each route may independently trigger message transfer, object serialization, database operations, and interface calls. The associated fixed overhead grows linearly with the number of routes, significantly increasing the overall route download time at million-route scale.

Optimization:

• Front-end batching: AsterNOS-VPP optimizes the FRR FPM Dataplane processing mechanism by introducing Batch processing, allowing multiple routes to be grouped and passed into the SONiC processing path together. This reduces high-frequency event-processing overhead.
• Back-end batching: The VPP data-plane adaptation layer, libsaivpp.so, supports SAI Bulk operations, allowing multiple VPP FIB entries to be processed in batches and amortizing the system overhead of individual calls.

Bottleneck:

Redis is a core component used by SONiC for state sharing and decoupling between software modules. During route processing, Redis serves three major logical roles: propagating desired route state, transferring data-plane objects, and reporting execution status. At million-route scale, frequent synchronous writes and state validation can accumulate into substantial processing overhead.

Optimization:

• While preserving SONiC’s existing state-management model, AsterNOS-VPP optimizes the Lua scripts and Redis Pipeline processing associated with PST, CST, PT, and CT. These correspond to Producer State Table, Consumer State Table, Producer Table, and Consumer Table, respectively, and participate in state production and consumption between SONiC components.
• Redundant Redis SET operations are removed from the critical RouteOrch processing path.
• syncd status write-back is changed to non-blocking asynchronous processing.
• ZMQ (ZeroMQ) is used to optimize northbound message delivery and reduce synchronous waiting on the critical processing path.

Bottleneck:

Batch processing reduces the overhead of per-route operations, but this introduces another question: can route download performance continue to improve simply by increasing the Batch or Bulk size?

Not necessarily. Larger batches can reduce the number of interface calls, but they also require the system to hold more pending route objects in memory. Without limits on batch caching, processing millions of routes can result in a large accumulation of intermediate objects and a rapid increase in peak memory usage.

Optimization:

• AsterNOS-VPP limits the number of objects that can be cached by the RouteOrch Bulker in orchagent, preventing excessive accumulation of intermediate objects during continuous million-scale route download and controlling peak memory usage during batch processing.
• This enables continuous million-scale route download to the VPP data plane at a stable and controlled batch rate, improving batch-processing throughput while keeping peak memory usage under control.

Internet edge deployments typically connect to multiple upstream service providers, IXPs, private peering links, and internal core networks.

As the number of upstream connections grows, IPv6 deployment expands, and customer and internal service prefixes continue to increase, the system must process more BGP paths and may also need to maintain a larger forwarding table. AsterNOS-VPP supports up to 8M routes for a single address family and route type, providing additional FIB capacity for Internet routes, peering prefixes, customer networks, and internal service routes.

In broadband and service provider edge networks, large route tables do not necessarily originate from the Internet routing table. They may also be driven by large subscriber populations and access networks.

PPPoE (Point-to-Point Protocol over Ethernet), IPoE (IP over Ethernet), subscriber address pools, and other access services can generate large numbers of IPv4 /32 and IPv6 /128 host routes. As the subscriber base continues to grow, the number of host routes that a single edge device must maintain can increase significantly.

AsterNOS-VPP provides million-scale host-route capacity to support these broadband access and service provider environments. In production planning, route capacity should be evaluated together with the number of active PPPoE/IPoE sessions, ARP/ND entries, and CGNAT scale.

In multi-branch connectivity, multi-VPC connectivity, and hybrid-cloud aggregation environments, network prefixes from distributed branches and data center regions ultimately converge on aggregation routers for centralized routing and exchange.

In these scenarios, million-scale route capacity enables an open software routing platform to retain sufficient FIB headroom as the network expands, reducing the pressure to replace the platform prematurely due to routing-table growth.

Building on SONiC’s existing modular routing architecture, AsterNOS-VPP applies system-level optimizations across control-plane processing, state propagation, batch route download, and data-plane installation for million-scale routing scenarios.

By optimizing FRR FPM batch processing, SONiC state interactions, and SAI Bulk adaptation, AsterNOS-VPP improves the efficiency of large-scale route delivery from the control plane into the VPP FIB while preserving SONiC’s open architecture and state-management framework. These optimizations provide clearly defined route-capacity tiers together with measurable route download performance.

For Internet edge, broadband and service provider edge, and cloud and regional aggregation deployments, AsterNOS-VPP provides a large-scale software routing solution for white-box and virtualized platforms based on the SONiC + VPP architecture.