Configuring Radware cBOS for Traffic Optimization in MPLS Networks
MPLS remains a dependable foundation for connecting branches, data centers, and private cloud environments. Its predictable forwarding and provider-managed quality of service make it attractive for business-critical applications, but bandwidth costs, competing traffic classes, and cloud-bound workloads can still create congestion.
Radware cBOS can help administrators coordinate traffic policies, application priorities, and path decisions across an MPLS environment. The goal is not simply to send packets through the fastest link. A successful design identifies important applications, preserves their service levels, and uses available WAN capacity without creating asymmetric or difficult-to-troubleshoot flows.
The exact interface and feature names depend on the cBOS release, deployment model, and licensed modules. Before making changes, record the current topology, routing behavior, QoS markings, and provider service definitions. That baseline makes it easier to distinguish an optimization problem from an underlying MPLS or application fault.
Map The MPLS Environment Before Making Changes
Begin with a logical inventory of hubs, branches, data centers, Internet exits, and cloud on-ramps. Document every circuit’s committed information rate, burst allowance, latency, jitter, packet-loss target, and supported traffic classes. Include backup paths, because a policy that works on the primary circuit may fail when traffic moves to a lower-bandwidth link.
Next, identify the routing boundaries. Note whether cBOS is positioned between LAN and WAN routers, integrated with virtual routing and forwarding instances, or deployed alongside a Radware application delivery platform. Record the VLANs, subnets, VRFs, next hops, and tunnel endpoints that cBOS must recognize.
Capture several days of utilization data if possible. Interface saturation alone does not prove that optimization is required. Application response time, retransmissions, queue drops, and provider QoS counters reveal whether the problem is congestion, inefficient traffic selection, or a service-class mismatch.
Define Application Policies And Traffic Classes
Create policy groups based on business behavior rather than port numbers alone. Voice and video require low delay and jitter, while ERP, database replication, and interactive virtual desktop traffic may need reliable delivery with controlled latency. Software updates, backups, and general web browsing are usually better candidates for lower priority or scheduled transfer windows.
Use application signatures, destination networks, service ports, identity information, and DSCP values together where practical. A port-only rule can misclassify encrypted or tunneled traffic, while a DSCP-only rule can trust markings that were altered by an access switch or remote device.
A typical policy model gives real-time collaboration strict priority within a bounded percentage of the link, assigns transactional applications a guaranteed class, and places bulk transfers in a weighted or scavenger class. Avoid unlimited priority queues. If a high-priority class can consume the entire MPLS circuit, every other application becomes vulnerable during a busy period.
Configure cBOS Traffic Steering
In cBOS, establish the available paths and associate each with measurable performance requirements. Depending on the deployment, these may include primary MPLS, secondary MPLS, broadband, LTE, or an encrypted overlay. Define the preferred path for each application group and specify what should happen when latency, loss, or jitter exceeds the acceptable threshold.
Health monitoring must test more than link availability. An interface can remain operational while the provider is dropping packets or routing traffic through a congested segment. Use active probes and application-aware measurements where supported. Probe destinations should represent real service locations, such as a data center gateway or cloud application endpoint, rather than relying only on the local provider router.
Set conservative failback behavior. Rapid movement between paths can cause session disruption, route churn, and packet reordering. Hysteresis, hold timers, and recovery thresholds allow a link to stabilize before cBOS returns traffic to it.
| Traffic category | Preferred treatment | Useful measurement | Common fallback |
|---|---|---|---|
| Voice and interactive video | Low-latency queue with strict admission control | Jitter, delay, loss | Alternate low-latency path |
| ERP and transactional systems | Guaranteed bandwidth and stable routing | Response time, loss | Secondary MPLS circuit |
| Replication and backups | Rate-limited, lower-priority transfer | Throughput, queue depth | Scheduled window |
| Web and general user traffic | Weighted fair sharing | Utilization, latency | Internet or secondary path |
| Guest and non-business traffic | Scavenger class or local breakout | Volume and policy hits | Block or restrict |
Preserve QoS Markings Across The WAN
MPLS providers commonly map customer DSCP values to a small set of EXP or service-provider classes. Confirm the provider’s classification map before changing markings in cBOS. A local value such as EF or AF31 has no benefit if the carrier rewrites it into a best-effort queue.
Classify traffic at the trusted edge, then police or remark traffic entering each service class. Shaping should generally occur slightly below the provider’s committed rate so that the customer device controls the queue instead of allowing the carrier-facing interface to drop packets unpredictably.
Check both directions. A branch may mark outbound packets correctly while return traffic arrives with different values or traverses another device before reaching cBOS. Preserve DSCP through tunnels only when the encapsulation and provider policy support it, and verify the outer and inner headers during testing.
Tune Optimization Without Breaking Applications
Traffic optimization can include compression, deduplication, caching, connection management, or protocol acceleration, depending on the cBOS capabilities enabled in the environment. Apply these functions selectively. Encrypted traffic, already-compressed media, and modern application protocols may gain little from additional processing while consuming CPU and introducing latency.
Create exceptions for sensitive or incompatible flows. Database replication, storage protocols, and applications that already perform their own compression can behave poorly when an intermediary changes segmentation or connection characteristics. Test large file transfers, interactive sessions, API calls, and long-lived connections separately.
Pay close attention to MTU and fragmentation. MPLS labels, GRE or IPsec encapsulation, and optimization tunnels can reduce the effective payload size. Confirm path MTU discovery, MSS adjustment, and firewall allowances before enabling encapsulation across every site.
Validate Failover And Operational Behavior
Use a controlled rollout beginning with one branch and a limited application set. Compare baseline and post-change values for throughput, latency, jitter, packet loss, retransmissions, queue drops, CPU, memory, and policy-hit counts. A successful configuration should improve application behavior without simply moving congestion to another interface.
Test failure conditions deliberately. Disconnect the primary path, introduce controlled loss where possible, and verify that cBOS selects the intended alternate route. Confirm that existing sessions behave as expected, new sessions use the correct path, and return traffic remains symmetric through firewalls and stateful inspection devices.
Monitoring should expose policy decisions as well as link status. Export events and performance metrics to the organization’s logging or observability platform. Useful alerts include repeated path changes, rising loss on a preferred circuit, QoS queue exhaustion, tunnel failure, and a sudden increase in unclassified traffic.
Practical Deployment Recommendations
- Back up the cBOS configuration and export the existing policy set before each change window.
- Align application classes, DSCP values, and MPLS provider queues in a single documented matrix.
- Shape customer-facing traffic below the carrier’s committed rate to prevent uncontrolled provider-side drops.
- Use application-aware probes and stability timers instead of failover based only on interface state.
- Review policy hits, queue utilization, and path changes after rollout, then adjust thresholds gradually.
A well-tuned cBOS deployment gives administrators control over how business traffic uses MPLS, secondary circuits, and hybrid paths. Start with clear service objectives, validate provider QoS behavior, and introduce optimization features only after routing and classification are predictable. Apply the configuration to a pilot site, measure real application performance, and then extend the design across the network with documented rollback steps.