Domain-Based Traffic Routing: AsterNOS-VPP’s GeoSite/GeoIP Technologies

As 100G bandwidth and cloud-native applications become ubiquitous, traditional routing policies based on the IP 5-tuple are increasingly falling short when handling SaaS (e.g., Zoom, Office 365) and CDN-distributed traffic. AsterNOS-VPP, a SONiC-based routing system, addresses this by integrating GeoSite and GeoIP technologies. By leveraging the SNI and Hostname fields in packet headers for traffic identification, it provides a higher-dimension matching mechanism for ACLs and PBR (Policy-Based Routing). Utilizing the Marvell OCTEON 10 platform, this feature set is deployed across Asterfusion’s ET2500, ET3608, and ET3616 switches, providing edge networks with a high-performance, flexible routing management solution.

What are GeoSite/GeoIP Technologies?

AsterNOS-VPP (SONiC-based routing operating system) introduces GeoSite (Domain-based classification) and GeoIP (IP-based classification) capabilities. This technology identifies traffic by parsing specific fields in the packet header – like SNI (Server Name Indication) or Host, providing more flexible matching mechanisms for ACLs (Access Control Lists) and PBR (Policy-Based Routing) beyond simple IP addresses.

 The Bottlenecks: Limitations of Traditional Solutions

Why do we need to move beyond standard IP routing or traditional DPI? Existing solutions face significant bottlenecks in modern network environments.

Limitation A: Why IP Alone Cannot Meet Scheduling Demands

In traditional network architectures, routers forward packets based on the destination address. However, modern internet services extensively employ CDN technologies, leading to:

• Frequent changes in service IP addresses (IP Dynamism): The resolved IP of a domain changes based on location/load, making static IP lists difficult to maintain.
• IP Multiplexing: A single CDN IP hosts multiple services. Blocking or allowing a specific IP might inadvertently affect other legitimate services or fail to pass the target traffic.

Limitation B: The Pain Points of Traditional DPI (Deep Packet Inspection)

For a long time, DPI was the only alternative. However, in the era of 100G encrypted networks, DPI creates new problems:

• Performance Bottleneck: DPI must “reassemble” data streams and use complex regex engines. This consumes massive CPU resources. As concurrent connections increase, device throughput drops, and latency increases.

• Encryption Blindness: With TLS 1.3, traffic is fully encrypted. DPI payload signatures become unreadable. DPI often requires “Man-in-the-Middle” decryption, which raises privacy concerns and is hard to implement.
• Operational Black Box: DPI relies on proprietary signature databases. Users cannot view the rules, and updates are often lagging.

Why We Need GeoSite/GeoIP?

To solve these problems without the heavy cost of DPI, AsterNOS-VPP shifts the routing paradigm from “Addresses” (IPs and Ports) to “Identity” (Application) and “Origin” (Location).

How it solves the problem: Instead of inspecting the full encrypted payload (DPI) or relying on unstable IPs, AsterNOS-VPP focuses on visible plaintext information that must be retained within the protocol design—specifically, the handshake information used to establish connections.

AsterNOS-VPP introduces GeoSite (Domain-based classification) and GeoIP (IP-based classification) capabilities. Built upon VPP’s high-performance data forwarding architecture, this feature identifies traffic by parsing specific fields in the packet header, providing more flexible matching mechanisms for ACLs (Access Control Lists) and PBR (Policy-Based Routing).

• Lightweight State Model: It parses necessary header fields to complete a match only during the connection establishment phase and caches the result (Session Offload).
• Encryption Compatibility: By leveraging SNI (Server Name Indication), it identifies traffic even in TLS 1.3 environments without decryption.
• Open Standards: Unlike DPI’s “black box,” it is compatible with community-standard .dat rule file formats, making rules transparent and controllable.

How does it Work?

This technology focuses on parsing packet header fields to extract domain information. Here is the detailed mechanism:

Domain Extraction Logic

AsterNOS-VPP supports extracting domain names from the handshake or header information of various protocols:

HTTPS/TLS: During the TLS handshake, it extracts the server_name value from the SNI in the Client Hello packet.

HTTP/1.1: Parses the HTTP request header to retrieve the Host field.

DNS: When functioning as a DNS proxy, it extracts the domain from the Query name field.

SOCKS5: Parses the SOCKS5 header. When ATYP is 0x03, the subsequent address is retrieved as the target domain.

Matching Algorithms and Data Structures

Once extracted, the system uses efficient data structures to ensure speed:

• Trie Tree (For Domain Suffixes): Supports RootDomain matching, accelerating lookups via the Trie tree structure.
• Patricia Trie (For IPs): Manages IP mask rules, supporting Longest Prefix Match (LPM). Even if a single IP hits multiple rules, the system returns the accurate result based on priority.

In traditional networking, policies are built around “Addresses” (IPs and Ports). AsterNOS shifts this paradigm to “Identity” (Application) and “Origin” (Location).

How AsterNOS-VPP Supports It?

Built upon VPP’s (Vector Packet Processing) high-performance architecture, AsterNOS implements this via a specific plugin and graph node structure.

The Plugin Architecture

AsterNOS developed the geosite_plugin.so plugin, which operates as the geosite_input_node within the VPP graph. This allows the feature to integrate seamlessly into the forwarding plane.

The Processing Flow

When a packet enters the VPP ip4/6-input node, the process follows these steps:

1. Domain Extraction: The packet enters the geosite_input node. The domain name is extracted based on the protocol type.
2. Session Lookup: The system queries the existing session table. If a match exists, it is reused.
3. Rule Matching: Prioritizes Domain matching over IP matching.
4. Action Execution (Enforce): Bind the policy to the interface to execute actions.

What Are the AsterNOS GeoSite Benefits?

By adopting this architecture, we achieve a balance of performance, visibility, and control.

Technical Comparison Summary

Comparison Dimension	Traditional DPI	AsterNOS GeoSite
Inspection Depth	L7 Payload (Application Layer)	L4-L7 Header (Packet Header/Handshake)
Performance Impact	High. Burden on CPU due to reassembly.	Minimal. Maintains Wire-speed forwarding.
Encrypted Traffic	Poor. Powerless against TLS 1.3.	Excellent. Compatible based on SNI/DNS.
Rule Transparency	Black Box. Unmodifiable.	White Box. Fully user-customizable.

Real-World Benefits (Use Cases)

• Application-Aware Routing (Performance)
  • Benefit: Put critical services in the “Fast Lane”.
  • Example: Route Zoom/Office 365 to a dedicated line and YouTube to a cost-effective line purely based on domain names, ignoring dynamic IPs.

• Security Compliance (Control)
  • Benefit: Precise Geo-Fencing and Content Filtering.Example: Block access to media sites or specific countries (e.g., US) directly at the forwarding plane without consuming downstream resources.

• Precision QoS (Optimization)
  • Benefit: Taming Bandwidth Hogs in Encrypted Traffic.Example: Distinguish between YouTube and Zoom (both on Port 443) and rate-limit only the streaming traffic.

Conclusion

AsterNOS-VPP offers a solution that is both fast and accurate. It rejects the approach of bloating gateways with heavy DPI features, choosing instead a high-performance, encryption-ready, and open technical path.

Want to try it yourself? Download the → AsterNOS-VPP VM Image ← today to deploy it in your own lab environment. Pair it with our companion document, → GeoSite/GeoIP-VPP Case ←, to follow detailed configuration steps and experience the power of intelligent scheduling firsthand.

Applicable Hardware Models