Cisco Cisco Catalyst 6500 Cisco 7600 Router Anomaly Guard Module 디자인 가이드

 

 

© 2005 Cisco Systems, Inc. All rights reserved. 

Important notices, privacy statements, and trademarks of Cisco Systems, Inc. can be found on cisco.com. 

Page 9 of 12 

 
 

Given that each zone can contain multiple destination IP addresses (each representing a server) that are either host destinations (/32 mask) or 

subnetted destinations, multiple customers can be configured onto one zone. The most significant configuration constraint is that active zones 

cannot have duplicate IP address space. Therefore, one can potentially configure DDoS detection (Traffic Anomaly Detector) and mitigation 

(Anomaly Guard) for thousands of customers on each individual module. Apart from the active zone limit, total module bandwidth capacity, as 

described above, is the other factor to consider when designing a hosting provider managed service deployment. 

Internet service providers (ISPs) can deploy DDoS protection for their subscribers as a managed service offering to complement their Internet 

connectivity services. In an ISP-managed DDoS service, Anomaly Guard modules will always be deployed in the service provider network. 

Traffic Anomaly Detector modules can be deployed on the subscriber premises or within the service provider network, depending on the type 

of attack detection system being used. 

Centralized or Distributed Attack Mitigation 

There are two options for deploying Anomaly Guard Modules—centralized or distributed deployment. 

The centralized model is optimal for ubiquitous DDoS managed service deployments, where all subscribers and the service provider’s peering 

ingress points are being protected by Anomaly Guard Modules. The distributed model is easier to deploy for service providers that are introducing 

the managed service to a subset of customers over a staggered introduction process. 

Centralized Model 

In the centralized deployment model, Anomaly Guard clusters are installed in a single central location on the service provider backbone network or 

in multiple regional locations (Figure 5). These Anomaly Guard “scrubbing centers” are engaged to clean traffic from any source to any destination 

on the service provider backbone. The destinations are addresses (representing servers or network infrastructure that are potential attack targets) 

of ubscribers who have signed up for the DDoS protection service. 

Attack detection in the centralized deployment model can be accomplished using a different detection mechanism than the Traffic Anomaly 

Detector odule. Given the broad mitigation coverage afforded by a centralized model (attacks destined for any subscriber destination throughout 

the ervice provider network will be directed to a central location for cleaning), a broadly based attack detection mechanism would be best provided 

by a NetFlow-based system, such as Arbor Networks’ Peakflow SP product. 

In a centralized deployment, Anomaly Guard modules can be dedicated for individual subscribers, shared among all subscribers, or a combination 

of edicated and shared. However, the centralized model is well suited for a ubiquitous managed service deployment, where all subscribers share 

the entral Anomaly Guard cluster. 

A variation of a single centralized cluster is the deployment of multiple regional clusters that would more efficiently process anomalous traffic in 

a arge backbone network. 

Design recommendations for the centralized model include: 

•

 

Sufficient backbone network capacity (bandwidth) exists to transport the anomalous traffic (good and bad traffic destined for a target that 

requires cleaning) from ingress points to the Anomaly Guard cluster. 

•

 

Scalable traffic injection methods are configured for forwarding the cleaned (legitimate) traffic from the Anomaly Guard cluster to the 

intended destinations (using MPLS-VRF rather than GRE tunnel’s more efficient router operation, for example).