Functional testing of Stingray BNG using an Ixia traffic generator

June 23, 2026
BNG/BRAS
Functional testing of Stingray BNG using an Ixia traffic generator
In BNG-related projects, not only performance but also predictable system behavior under different conditions is critical. Before moving on to load testing, it is important to verify that the device correctly implements both basic and advanced functions in accordance with RFC requirements. This article explains how functional testing of a BNG was organized using a test environment built according to the requirements of a nationwide telecom operator.

The customer’s technical specification included more than 380 functional requirements, covering subscriber termination, routing, QoS, NAT, high-availability mechanisms, monitoring, and Control Plane protection.

The primary objective of the testing was to verify the operation of a wide range of network functions within a single platform and a unified architecture. To achieve this, test scenarios were developed to closely replicate real-world deployment conditions in a service provider network.

Test Platform

The test environment was built using an Ixia XGS traffic generator.

Ixia XGS is a modular network testing platform designed for L2–L7 validation. It supports 10G, 40G, and 100G interfaces and allows the creation of high-density test environments.

The platform architecture is based on a high-speed internal switching fabric, enabling the processing of large traffic volumes and resource sharing between modules. Modules can be replaced without interrupting ongoing tests, simplifying maintenance and operation.

IxNetwork, IxLoad, and IxExplorer software suites were used for configuration and control. These tools allow engineers to define traffic patterns, protocol configurations, and testing parameters. The traffic generator was used to establish subscriber sessions and emulate typical network conditions during BNG testing.

One of the key goals of the project was to verify that the entire set of functions could operate simultaneously within a single platform, without distributing roles across multiple specialized solutions.

ixia test platform

Testbed Configuration

Testing was performed on a server equipped with 128 CPU cores.

Server Specifications:

AMD EPYC 9754 (128 cores)
2U Heatsink
12 × 32 GB DDR5 RDIMM 5600 MHz
2 × 960 GB SATA SSD (front slots, PM893)
2 × Dual-port 100GbE QSFP28 PCIe 4.0 adapters
1 × 1 TB NVMe SSD (990 PRO)
2 × 1Gb RJ45 onboard interfaces
Dedicated 1Gb RJ45 management interface
2 × 1300W AC power supplies
Rack Mount Kit
Standard 8x5xNBD+5 warranty, 3 years

Two testbed configurations were used.

The first configuration utilized 100G interfaces: 2 × 100G ingress and 2 × 100G egress. This setup was used to validate high-throughput traffic scenarios and BNG operation with 100G links.

dpdk_device=10:pci:41:00.0
dpdk_device=11:pci:41:00.1
dpdk_device=20:pci:01:00.0
dpdk_device=21:pci:01:00.1
in_dev=10:20
out_dev=11:21
lag {
name=IN
device=10
device=20
lacp=2
system_id=6c:b3:11:79:81:5e
priority=32768
short_timeout=on
balance_algo=0
}
lag {
name=OUT
device=11
device=21
lacp=2
system_id=6c:b3:11:79:81:5f
priority=32768
short_timeout=on
balance_algo=0
}
dpdk_engine=6
dpdk_rss=10
num_threads=98
dpdk_tx_queue_size=8160
rx_dispatcher=2
support_service_18=1
syslog_level=7
scale_factor=10
mem_slices_ip=32
dpdk_mempool_size=8000000
mem_tracking_flow=130000000
mem_tracking_ip=100000000
mem_ipv6_tracking_flow=40000000
mem_ipv6_tracking_ip=30000000
mem_ssl_parsers=18000000
mem_http_parsers=512000
mem_ip_billdata_recs=500000
mem_preset=1
cloud=0
ctrl_port=29000
ctrl_dev=lo
federal_black_list=0
black_list_redirect=
netflow=12
enable_acct=1
enable_auth=1
auth_servers=127.0.0.1%lo:29002
bras_enable=1
bras_arp_ip=10.1.0.62
bras_arp_mac=6c:b3:11:79:81:5d
bras_ip_filtering=0x0001
bras_terminate_l2=1
bras_dhcp_mode=2
bras_dhcp_ratelimit=17
bras_dhcp_disconnect=0x000B
bras_dhcp_ratelimit_ban=5
bras_dhcp_timeout=17
bras_vlan_terminate=3
bras_qinq_type=0x8100
bras_arp_proxy=0x003
bras_subs_id=qinq+mac,vlan+mac,mac
bras_ip4db_bucket_count=1048576
ipv6=1
bras_ipv6=1
bras_dhcp6_mode=1
bras_ipv6_address=2A0F:1900:2000::31
bras_icmp6_send_rtradv=1
bras_icmp6_min_rtradv_interval=60
bras_icmp6_max_rtradv_interval=80
bras_pppoe_enable=1
bras_pppoe_session=150000
bras_ppp_auth_list=1,2,3
bras_pppoe_restore_on_startup=0
bras_ppp_idle_timeout=30
bras_ppp_restart_timeout=3
bras_ppp_ping_timeout=5
bras_ppp_max_failure=3
netflow_dev=lo
netflow_timeout=10
netflow_full_collector_type=1
netflow_full_collector=127.0.0.1:1500
netflow_passive_timeout=20
netflow_active_timeout=60
ipfix_mtu_limit=1400
ipfix_dev=bond0
ipfix_udp_collectors=10.169.29.173:1602
router=1
router_netns=router
router_kernel_table=101
router_subs_announce=0x100007
router_default_vrf=vrf-grt
bras_vrf_isolation=1
router_max_ip4_route_count=5000000
router_max_ip6_route_count=800000

router_device {
vrf=vrf-grt
device=11
tap=bng
peer=rib
subnet=224.0.0.5/32
subnet=224.0.0.6/32
subnet=10.1.0.1/32
subnet=10.2.0.1/32
subnet=10.3.0.1/32
subnet=10.4.0.1/32
subnet6=2a0f:1900:2000::30/128
subnet6=2a0f:1900:2002::30/128
subnet6=fe80::2898:7ff:fe59:880e/128
subnet6=ff02::5/128
subnet6=ff02::6/128
}

router_vrf {
id=vrf-grt
netns=router
kernel_table=100
neighbor_cache=shared
}

The second configuration utilized 16 × 10G interfaces and 2 × 100G egress interfaces. This setup is intended for BNG deployments where LAN and WAN sides use different interface types.

dpdk_device=10:pci:0000:41:00.0
dpdk_device=20:pci:0000:01:00.0
dpdk_device=30:pci:0000:c2:00.0
dpdk_device=31:pci:0000:c2:00.1
dpdk_device=32:pci:0000:c2:00.2
dpdk_device=33:pci:0000:c2:00.3
dpdk_device=34:pci:0000:c2:00.4
dpdk_device=35:pci:0000:c2:00.5
dpdk_device=36:pci:0000:c2:00.6
dpdk_device=37:pci:0000:c2:00.7
dpdk_device=40:pci:0000:02:00.0
dpdk_device=41:pci:0000:02:00.1
dpdk_device=42:pci:0000:02:00.2
dpdk_device=43:pci:0000:02:00.3
dpdk_device=50:pci:0000:89:00.0
dpdk_device=51:pci:0000:89:00.1
dpdk_device=52:pci:0000:89:00.2
dpdk_device=53:pci:0000:89:00.3
in_dev=30:31:32:33:34:35:36:37:40:41:42:43:50:51:52:53
out_dev=10:10:10:10:10:10:10:10:10:20:20:20:20:20:20:20:20
lag {
name=IN
device=30
device=31
device=32
device=33
device=34
device=35
device=36
device=37
device=40
device=41
device=42
device=43
device=50
device=51
device=52
device=53
lacp=2
system_id=6c:b3:11:79:81:5e
priority=32768
short_timeout=on
balance_algo=0
}
lag {
name=OUT
device=10
device=20
lacp=2
system_id=6c:b3:11:79:81:5f
priority=32768
short_timeout=on
balance_algo=0
}
dpdk_engine=7
dpdk_dispatch=30,31;mempool=main10G
dpdk_dispatch=32,33;mempool=main10G
dpdk_dispatch=34,35;mempool=main10G
dpdk_dispatch=36,37;mempool=main10G
dpdk_dispatch=40,41;mempool=main10G
dpdk_dispatch=42,43;mempool=main10G
dpdk_dispatch=50,51;mempool=main10G
dpdk_dispatch=52,53;mempool=main10G
dpdk_dispatch=10,20;rss=16;mempool=main100G
dpdk_mempool=name=main10G;size=1600000
dpdk_mempool=name=main100G;size=8000000

num_threads=98
dpdk_tx_queue_size=8160
rx_dispatcher=2
support_service_18=1
syslog_level=7
scale_factor=10
mem_slices_ip=32
mem_tracking_flow=130000000
mem_tracking_ip=100000000
mem_ipv6_tracking_flow=40000000
mem_ipv6_tracking_ip=30000000
mem_ssl_parsers=18000000
mem_http_parsers=512000
mem_ip_billdata_recs=500000
mem_preset=1
cloud=0
ctrl_port=29000
ctrl_dev=lo
federal_black_list=0
black_list_redirect=
netflow=12
enable_acct=1
enable_auth=1
auth_servers=127.0.0.1%lo:29002
bras_enable=1
bras_arp_ip=10.1.0.62
bras_arp_mac=6c:b3:11:79:81:5d
bras_ip_filtering=0x0001
bras_terminate_l2=1
bras_dhcp_mode=2
bras_dhcp_ratelimit=17
bras_dhcp_disconnect=0x000B
bras_dhcp_ratelimit_ban=5
bras_dhcp_timeout=17
bras_vlan_terminate=3
bras_qinq_type=0x8100
bras_arp_proxy=0x003
bras_subs_id=qinq+mac,vlan+mac,mac
bras_ip4db_bucket_count=1048576
ipv6=1
bras_ipv6=1
bras_dhcp6_mode=1
bras_ipv6_address=2A0F:1900:2000::31
bras_icmp6_send_rtradv=1
bras_icmp6_min_rtradv_interval=60
bras_icmp6_max_rtradv_interval=80
bras_pppoe_enable=1
bras_pppoe_session=150000
bras_ppp_auth_list=1,2,3
bras_pppoe_restore_on_startup=0
bras_ppp_idle_timeout=30
bras_ppp_restart_timeout=3
bras_ppp_ping_timeout=5
bras_ppp_max_failure=3
netflow_dev=lo
netflow_timeout=10
netflow_full_collector_type=1
netflow_full_collector=127.0.0.1:1500
netflow_passive_timeout=20
netflow_active_timeout=60
ipfix_mtu_limit=1400
ipfix_dev=bond0
ipfix_udp_collectors=10.169.29.173:1602
router=1
router_netns=router
router_kernel_table=101
router_subs_announce=0x100007
router_default_vrf=vrf-grt
bras_vrf_isolation=1
router_max_ip4_route_count=5000000
router_max_ip6_route_count=800000

router_device {
vrf=vrf-grt
device=10
tap=bng
peer=rib
subnet=224.0.0.5/32
subnet=224.0.0.6/32
subnet=10.1.0.1/32
subnet=10.2.0.1/32
subnet=10.3.0.1/32
subnet=10.4.0.1/32
subnet6=2a0f:1900:2000::30/128
subnet6=2a0f:1900:2002::30/128
subnet6=fe80::2898:7ff:fe59:880e/128
subnet6=ff02::5/128
subnet6=ff02::6/128
}

router_vrf {
id=vrf-grt
netns=router
kernel_table=100
neighbor_cache=shared
}

The test environment used dual-stack scenarios with simultaneous IPv4 and IPv6 support, VRF isolation, DHCPv4/v6, PPPoE, QinQ, and dynamic routing using BGP and OSPF.

Special attention was paid to large routing table scenarios, including:

  • up to 5 million IPv4 routes;
  • up to 800,000 IPv6 routes;
  • BGP and OSPF support;
  • full-view BGP routing table scenarios.

Test Scenarios

The test scenarios were derived directly from the customer’s technical requirements and cover the key functions used by a BNG in a production network.

The first stage focuses on subscriber session termination, including PPPoE and IPoE in multiple deployment models: individual VLANs, VLAN ranges, and QinQ, including scenarios with session admission restrictions.

For IPoE, large-scale scenarios were also validated, including up to 128,000 subscriber sessions in the current configuration.

ixia scenarios

The next stage focuses on session management. Tests verify timeout handling, RADIUS attribute application, dynamic session control via CoA, and assignment of services and access policies.

cli ppoe-sessions-1

cli ppoe-sessions-2

IP addressing functionality is then validated, including DHCP, DHCPv6, local address pools, and dual-stack scenarios.

Multi-pool addressing and multi-service deployments using a local DHCP server were also tested. The functionality was successfully verified across different configuration variants.

IP-addressing-1

IP-addressing-2

The next area of validation is routing, including route tables, route scaling, route updates, and basic protocol operation for OSPF and BGP.

Additional tests covered large routing tables and large-scale BGP configurations.

routing_1

routing_2

Traffic management mechanisms are also tested, including rate limiting, QoS profiles, and traffic marking.

traffic managing

Additional validation covers network foundation and resiliency functions, including Layer 2 mechanisms, link aggregation, ECMP, Control Plane protection, malformed traffic handling, NAT, and filtering functions.

As part of ECMP validation, groups containing up to 32 next hops were successfully tested, demonstrating proper traffic distribution and lossless failover behavior.

Network Foundation and Resilience Functions_1

Network Foundation and Resilience Functions_2

The final validation block focuses on operational tools, including management access, monitoring, and statistics collection, with specific scenarios covering SNMPv3 and encrypted communication.

Inspection of maintenance tools

Correct jumbo frame operation was also successfully verified.

jumbo frames-1

Particular attention was given to scalability. During testing, configurations with large subscriber counts, extensive routing tables, and high connection density were validated.

scalability

Results

As part of the project, a test environment was prepared and validated to reproduce operational scenarios typical for a nationwide service provider network.

This testing approach provides not merely a collection of isolated checks, but a comprehensive understanding of how the system behaves under real operational conditions. For large-scale projects, this means that the solution undergoes a complete validation cycle before deployment, and its behavior in critical scenarios is known in advance. A unified set of test cases and a consistent validation methodology are used throughout the process.

The same test scenarios used for large deployments are also applied to smaller projects. As a result, operators of any size receive a solution that has undergone the same level of verification.

In the next article, we will move on to performance testing and review real throughput metrics. We will also demonstrate how the BNG behaves under load when tested with a traffic generator and present the results achieved across different deployment scenarios.