This document discusses a method of integrating Cisco Anomaly Guard Module (AGM) traffic diversion functions with VRF-lite functionality on Cisco 6500 and 7600 devices. Without the techniques described in this document, AGM can only divert traffic from the global routing table of the local chassis. By utilizing the BGP protocol’s prefix import function, which is a relatively new BGP enhancement on 7600/6500 platforms, AGM is also able to divert traffic from locally defined VRFs, whether in a full MPLS deployment or within a VRF-lite deployment. In comparison with full MPLS-VPN deployments, there are fewer possibilities of deploying workaround mechanisms in simpler topologies, such as VRF-lite implementations. As such, this paper focuses on the VRF-lite scenario, although the validity of the mechanism used also covers full MPLS-VPN deployments.
Overview of Cisco Anomaly Guard Operation
Cisco Anomaly Guard Module (AGM) is a service module developed for the Cisco Catalyst 6500 and Cisco 7600 modular, chassis-based devices with the primary functional goal of mitigating DDOS attacks. The module interacts with the chassis backplane and control elements by means of an internal feature called Route-Health-Injection (RHI). RHI, as it is implemented on the AGM, enables only control-plane interaction in the global routing table. Without detailing the AGM’s functionality, the high-level process of traffic diversion and traffic scrubbing (differentiating and filtering-out malicious traffic from the legitimate traffic) is illustrated in the following figure:
Figure 1 - Anomaly Guard Attack Detection and Diversion
Briefly described, the initial phases of an attack’s mitigation occur in the following manner:
Besides the traffic diversion functionality in the global routing table described above, it is occasionally necessary to configure AGM to automatically interact with control plane elements placed outside of the global routing table, in one or more Virtual Routing and Forwarding (VRF) tables. This interaction refers primarily to a mechanism of automatically diverting traffic for the protected zones toward the AGM (also known as traffic hijacking), and to a certain degree, traffic injection. This document describes how this can be achieved in a simple VRF-lite scenario, where a 6500 device supports multiple VRF instances that actually behave as independent IP routers. Somewhat paradoxically, this kind of diversion is actually easier to design in a more complex deployment where AGM can interact with other surrounding devices that can help alleviate the issue.
In order to address the issue described above, the IOS feature, “BGP Support for IP Prefix Import from Global Table into a VRF Table” can be utilized. The feature has been present on software-based IOS platforms for years, although it was only recently added to hardware-accelerated platforms such as Cisco 6500 and 7600 devices. On these two platforms, which are relevant as hosting platforms for AGM, the feature was introduced in IOS versions 12.2(33)SXH and 12.2(33)SRA, respectively.
The “BGP Support for IP Prefix Import from Global Table into a VRF Table” feature introduces capability to import IPv4 unicast prefixes from the global routing table into a Virtual Private Network (VPN) routing/forwarding instance (VRF) table using an import route map. This feature extends the functionality of VRF import map configuration to allow IPv4 prefixes to be imported into a VRF based on a standard community. Both IPv4 unicast and multicast prefixes are supported. No Multiprotocol Label Switching (MPLS) or route target (import/export) configuration is required.
IP prefixes are defined by the match criteria for the import map through standard Cisco IOS filtering mechanisms. For example, an IP access-list, an IP prefix-list, BGP community-list or an IP as-path filter is created to define an IP prefix or IP prefix range, and then the prefix or prefixes are processed through a match clause in a route map. Prefixes that pass through the route map are imported into the specified VRF per the import map configuration.
The following is a generic configuration example for this feature:
! define an access-list or prefix-list to identify prefixes for import
More details about the feature are available in reference  at the end of this document.
A configuration example demonstrating AGM’s interaction with VRF-lite and the BGP prefix import function is provided below.
The following diagram depicts a setup where AGM is installed in a chassis into which Internet traffic is flowing through a VRF (VRF BLUE in the example below):
Figure 3 - Physical Setup
The corresponding logical setup is depicted in the following diagram:
Figure 4 - Logical Setup
VLAN 50 is used as a diversion VLAN, while VLAN 51 is used as an injection VLAN terminated on L3 on a different downstream device(s) than the AGM’s hosting MSFC.
In this setup, activating protection for the zone depicted does not influence the traffic at all; RHI route is generated and placed in the global routing table (GRT) but it does not affect the Internet traffic flowing through the VRF BLUE.
The basic configuration for the above setup is provided below:
The above configuration is straightforward – traffic is forwarded through the VRF BLUE between the Internet and the protected zone, and AGM issues an RHI route into the global table of the hosting chassis. However, as already mentioned, Internet traffic in the VRF BLUE is not affected by the RHI route generated by the AGM, which enters into the global routing table. Please note that the above configuration does not necessarily include BGP protocol; all traffic is routed statically in this example.
In order to resolve the issue of AGM not being able to divert traffic in the above scenario, the following configuration modifications are necessary:
The above points are realized through the following configuration example:
! VRF definition is now amended with the prefix import using route-map GRT2VRF ip vrf internet rd 5:6 import ipv4 unicast map GRT2VRF ! MP-BGP configuration defining redistribution of RHI routes into BGP in GRT and ! VRF-based BGP instance (address family) router bgp 65535 bgp log-neighbor-changes ! address-family ipv4 redistribute static route-map RHI2BGP no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf BLUE no synchronization exit-address-family ip bgp-community new-format ! BGP community list identifying RHI-generated routes in the BGP global table ip community-list standard RHI-INJECTED permit 777:888 ! ! ACL identifying RHI-generated static routes by matching next-hop access-list 50 permit 192.168.50.2 ! Route-map RHI2BGP identifies RHI routes (next-hop matching) ! to be distributed into BGP in GRT and marks them with a BGP community ! to facilitate prefix import into the VRF route-map RHI2BGP permit 10 match ip next-hop 50 set community 777:888 ! ! Route-map GRT2VRF identifies BGP routes in GRT to be imported into VRF BLUE ! by community matching route-map GRT2VRF permit 10 match community RHI-INJECTED ! Static route for leaking return traffic originated by AGM towards the Internet ! from the global routing table into the VRF ip route 0.0.0.0 0.0.0.0 Vlan20 192.168.20.2
No changes to the guard’s configuration are required.
With the above modifications to the initial configuration, AGM is now able to divert traffic entering the chassis through VRF BLUE. The mechanics of this process is depicted in the following diagram:
Figure 5 - Redirecting Traffic From a VRF
Logically, the following sequence of steps occurs during the diversion process:
By using the BGP prefix import from the global table into a VRF table we have managed to achieve automatic redirection of diverted traffic from a VRF toward the Anomaly Guard, which is connected to the global routing table.
This scenario, with certain modifications, can be utilized in situations where the BGP protocol would not normally be used in the chassis that hosts the AGM, as well as when BGP is already in place for other reasons. Also, it can be applied to both the VRF-lite setup (as described above) and a full MPLS-VPN deployment scenario.
The scenario described does not address the traffic injection details, such as the issue of forwarding cleaned traffic from AGM toward the protected zone. Simple forwarding back to the MSFC over the diversion VLAN is not possible, as the traffic would be looped back to the AGM, based on the RHI-generated diversion route. Therefore, some of the available workarounds must be deployed. This situation, however, is not specific to the deployment scenario described in this paper, but is rather valid for any kind of Guard deployment. Some of the possible workaround options are described in reference  below.
The BGP prefix import feature on Cisco 7600 and 6500 devices requires one of the recent releases in the 12.2SR and 12.2SX IOS trains. Older releases do not support this functionality.
Introducing BGP into the diversion process would cause a slight delay in traffic diversion (in comparison with pure RHI-based diversion). Details of BGP’s timer tuning are out of the scope of this document but can be found in the documentation sections of the BGP protocol.
Dragan Parmakovic (CISSP, CCIE R&S #9679) joined Cisco in 2001 as a member of the Project Consulting group and currently works as a Network Consulting Engineer with Cisco Advanced Services Security Practice.
 Cisco Anomaly Guard Module Documentation
This document is part of Cisco Security Intelligence Operations.
This document is provided on an "as is" basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information on the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document at any time.