Getting Started
Cisco Secure DDoS Edge Protection is composed of two components:
- Detector -- DDoS detection function implemented on a Docker container in the IOS XR NCS 540 router. The detector performs DDoS attack analysis based on the traffic flow information received from the router. IOS-XR platform samples GTP traffic and send Netflows records to this docker container. This information is passed through a slew of detection algorithms to generate alert indications when a DDoS attack is identified. Once an attack is detected, the mitigation can be implemented on the router ingress port either automatically or manually depending on the customer’s preference.
Deployment of the detectors is controlled and managed by the controller.
Note :
For more information on deploying containers on NCS 540 routers, refer to Application Hosting Configuration Guide for Cisco NCS 540 Series Routers.
- Controller -- A central interface management function for admin users to manage a fleet of detectors. The controller includes a GUI dashboard that presents information for real-time attacks for detector visibility, forensics, and threat intelligence analysis. With the controller, you can
- Manage a detector fleet
- Create and add new detectors
- Configure and edit detector profiles and security settings
- Check the health of a specific detector
- Display information about real-time attack forensics and threat intelligence analysis
- Mitigate DDoS attacks on the network
The images below provide examples of attacks indication presented by the controller:
System Requirements
The following are minimum requirements for installing and running Cisco Secure DDoS Edge Protection.
Router: HW model NCS540, Minimum version 7.x.x
Controller:
- Minimum VM resource: 4 vCPU, 8 GB mem, 50G or more storage
- Maximum Detectors per Controller: 50,000
- Management Protocol: SSH, HTTP, HTTPS, REST API
- Controller to/from Detector communication Protocol: gRPC
- High Availability: Yes, using Kubernetes clustering technology
Detector on router:
- Minimum resource: 2 vCPU, 1 GB mem, 1GB storage
- Management Protocols: SSH and NETCONF over SSH
- Flow Protocols: Protocol Buffers (Protobuf) or NetflowV9 support for third party applications
- Flows Per Second support with 2 vCPU: 80,000
Note:
To support a high number of detectors, additional memory and CPU cores will be required above the minimum required resources for Controller. For example, to support 1000 detectors, the recommended resources are 8 CPU cores and 16G memory. Although there are no specific versions of CPU or memory specified, the performance and response of the Controller application will be reflective of the quality and performance of these components.
Detector Scalability
The scalability of the detector is based on the number of flows ingested, not on the bandwidth consumed by the router.
A single detector can ingest tens of thousands of flows per second (FPS) without impacting the data or management plane of the router.
Cell site routers may see thousands or even tens of thousands of FPS from User Equipment (UE) associated to a cell site location.
Flows forwarded to the detector are based on a configurable sampling rate.
The sampling ratio used is dependent on the volume of traffic and flows on a device to provide good visibility without losing attack accuracy.
The lower the ratio, the more flows will be forwarded to the detector and thereby increase the total number of FPS received by the detector.
In cell site routers where flows are in the tens of thousands these ratios can be anywhere from 10 to 1 in a low UE environment to 1000 to 1 in a UE dense scenario.
The table below provides guidance on the scalability and performance of the Edge Protection Detector based on number of flows received.
It also shows the increase in the detector’s CPU utilization as the number of flows per second increase.
Solution Architecture
The following is an illustration of the detector integrated within an Cisco NCS 540 router. The Cisco NCS 540 will route GTP traffic, when placed between the radio cell and core elements. The detection and mitigation will be made by the detector agent.
Glossary of Terms:
| Term | Description |
|---|---|
| Controller | GUI and main control dashboard (OVA image) |
| Detector | DDoS and security detection function (Docker container) |
| Router | Cisco IOS XR router, e.g. Cisco NCS 540 |
| gRPC | Google RPC communication function – part of the controller |
| GTP | GPRS Tunneling protocol |
| TEID | Tunneling Endpoint Identifier |
Features and Customer Benefits
- Stop attacks at the ingress of the network
- No additional hardware required
- No change to the architectures
- No need to over-provision network to account for attack traffic
- No backhauling of malicious traffic
- Minimize customer outages and optimizes the end user experience
- No facilities requirements such as power, rack space, cooling
- Allows SPs to meet 5G low-latency requirements
Licensing
The Edge Protection detector is licensed for cell site router based on number of routers.
The detector is licensed for peering edge based on aggregate bandwidth.
The controller is the central licensing manager for the Cisco Secure DDoS Edge Protection.
Head over to the Learning Lab now for a step-by-step tutorial on using Cisco Secure DDoS Edge Protection.
Get your hands dirty next - Head to the DevNet Sandbox - Cisco Secure DDoS Edge Protection.
For more information about supported platforms, contact your Cisco sales representative
or email : secure-ddos-edge-protection@external.cisco.com