Contents
Abstract
Introduction
Challenge – Integration with VRFs
Solution – BGP Support for IP Prefix Import from Global Table into a VRF Table
Deployment Example – Importing AGM’s RHI routes into a VRF
Conclusion
Caveats
Acknowledgments
References
Abstract
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.
Introduction
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:
- The process begins with detection of the attack, which can be performed by Cisco Anomaly Detector module (a product closely related to Cisco Anomaly Guard) or through some other method, such as Netflow-based monitoring.
- The detection device activates the attacked zone’s protection on AGM directly or the detection notifies the network operation’s staff so the AGM can be activated manually.
- After the protection is activated, traffic destined to the protected zone is diverted to the AGM. This occurs based on the injection of an RHI route into the routing table of the MSFC in the chassis where the AGM is installed. The RHI route appears as a dynamically injected static route advertising the zone’s defined IP ranges, typically divided into two sub-segments with the IP mask 1 bit longer than the original segment’s subnet mask. This modification of the subnet mask can not occur when the zone is represented by a single IP address or a set of IP addresses defined as host-routes.
- As a consequence of the zone’s activation and traffic diversion, AGM performs traffic scrubbing and filters out malicious traffic.
The following diagram depicts the remaining phases of the mitigation process:
Figure 2 - Anomaly Guard Mitigation and Cleaned Traffic Injection
- Traffic that the Guard has identified as legitimate is forwarded to the zone while the malicious traffic is filtered out.
- Other network segments that do not belong to the activated zones continue to receive their incoming traffic normally, i.e. they are not being diverted through the Guard.
Challenge – Integration with VRFs
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.
Solution – BGP Support for IP Prefix Import from Global Table into a VRF Table
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 ip prefix-list COLORADO seq 5 permit 10.131.64.0/19 ip prefix-list COLORADO seq 10 permit 172.31.2.0/30 ip prefix-list COLORADO seq 15 permit 172.31.1.1/32 ! ! in a VRF definition reference import route map named UNIMAP ip vrf green rd 200:1 import ipv4 unicast map UNIMAP route-target export 200:10 route-target import 200:10 ! ! define the route map referenced in the import ipv4 unicast command route-map UNIMAP permit 10 match ip address prefix-list COLORADO
More details about the feature are available in reference [1] at the end of this document.
Deployment Example – Importing AGM’s RHI routes into a VRF
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:
6500’s initial configuration
! Definition of VLANs forwarded (trunked) to AGM. Vlan 100 is the management VLAN. anomaly-guard module 2 port 1 allowed-vlan 100 anomaly-guard module 2 port 2 allowed-vlan 50,51 anomaly-guard module 2 port 1 native-vlan 100 ip vrf BLU rd 5:6 ! SVI for upstream connectivitity interface Vlan20 ip vrf forwarding BLUE ip address 192.168.20.1 255.255.255.0 ! ! SVI for downstream connectivity interface Vlan21 ip vrf forwarding BLUE ip address 192.168.21.1 255.255.255.0 ! ! Diversion VLAN, facing AGM, has to be in GRT interface Vlan50 ip address 192.168.50.1 255.255.255.0 ! ! SVI on the injection VLAN 51 is not used – 6500 acts as pure L2 device for that VLAN interface Vlan51 shutdown ! ! Static routes towards the zone and the internet ip route vrf internet 192.168.100.0 255.255.255.0 192.168.21.2 ip route vrf internet 0.0.0.0 0.0.0.0 192.168.20.2
AGM’s initial configuration
! Interfaces and IP addresses interface eth1 ip address 10.10.42.150 255.255.0.0 mtu 1500 no shutdown exit interface giga2 mtu 1500 proxy 192.168.51.100 proxy 192.168.51.101 no shutdown exit ! Interface giga2.50 is used for traffic diversion interface giga2.50 ip address 192.168.50.2 255.255.255.0 mtu 1500 no shutdown exit ! Interface giga2.51 is used for traffic injection (L2 forwarding to a downstream ! router) interface giga2.51 ip address 192.168.51.2 255.255.255.0 mtu 1500 no shutdown exit ! Traffic diversion configuration diversion hijacking receive-via-vlan 50 diversion injection 0.0.0.0 0.0.0.0 nexthop 192.168.51.1 zone Z GUARD_DEFAULT ip address 192.168.100.0 255.255.255.0 ...
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:
- To allow for BGP prefix import from the global table into the VRF BLUE, the MP-BGP protocol must be enabled on the chassis that hosts the AGM, if it is not already in place.
- The import map must be defined to filter the prefixes to be imported into the VRF from the GRT.
- The RHI route (static) must be redistributed into BGP protocol in the global routing table.
- The prefix import command must be configured for the VRF BLUE.
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:
Step 1. Traffic toward the zone enters the chassis in VRF BLUE.
Step 2. Protection for a zone’s IP 192.168.100.100 is activated on the AGM, causing the RHI route to be generated in the global routing table as static route and redistributed into the global instance of BGP.
Bstp-6500-1#sh anomaly-guard module 2 advertised-route
RHI routes added by slot 2
ip mask nexthop vlan weight tableid
--------------- --------------- --------------- ------ ------ -------
A 192.168.100.100 255.255.255.255 192.168.50.2 50 1 0
Bstp-6500-1#sh ip route static
192.168.100.0/32 is subnetted, 1 subnets
S 192.168.100.100 [1/0] via 192.168.50.2, Vlan50
...
Bstp-6500-1#sh ip bgp
BGP table version is 2, local router ID is 192.168.183.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 192.168.100.100/32
192.168.50.2 0 32768 ?Step 3. BGP route from the global table is imported into the VRF BLUE. On the data-plane, this causes traffic to be redirected from VRF BLUE to the interface Vlan50 belonging to the global routing table.
! Debug output showing prefix-import.
6d01h: RT: add 192.168.100.100/32 via 192.168.50.2, static metric [1/0]
6d01h: BGP: Applying map to find origin for 192.168.100.100/32
6d01h: RT(internet): add 192.168.100.100/32 via 192.168.50.2, bgp metric [20/0]
Bstp-6500-1#sh ip bgp vpnv4 all
BGP table version is 4, local router ID is 192.168.183.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 5:6 (default for vrf BLUE)
Import Map: M23, Address-Family: IPv4 Unicast, Pfx Count/Limit: 1/1000
*> 192.168.100.100/32
192.168.50.2 0 32768 ?
Bstp-6500-1#sh ip route vrf BLUE
Routing Table: BLUE
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
C 192.168.21.0/24 is directly connected, Vlan21
C 192.168.20.0/24 is directly connected, Vlan20
192.168.100.0/32 is subnetted, 1 subnets
B 192.168.100.100 [20/0] via 192.168.50.2, 00:01:27, Vlan50Step 4. Cleaned traffic is forwarded to the zone over VLAN51 toward a different router or VRF.
Step 5. The return traffic toward the Internet that is generated by AGM is passed to the 6500 on VLAN50, which is in the global routing table. Therefore, the 6500 must have a default route in its global routing table that will point to the VLAN20 interface in the VRF BLUE (route leaking).
The above situation will remain in place as long as the zone is protected on AGM. After the protection is removed, the RHI route in the global routing table will disappear, as well as the corresponding BGP routes in the global table and the VRF BLUE, and eventually traffic would continue to flow through the VRF BLUE directly to the zone and back.
Conclusion
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.
Caveats
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 [2] 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.
Acknowledgments
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.
References
[1] BGP Support for IP Prefix Import from Global Table into a VRF Table
//www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-3s/irg-xe-3s-book/bgp_support_for_ip_prefix_import_from_global_table_into___.pdf
[2] Cisco Anomaly Guard Module Documentation
//www.cisco.com/en/US/docs/interfaces_modules/services_modules/anomaly_guard/v6.1/configuration/guide/preface.html
This document is part of the Cisco Security portal. Cisco provides the official information contained on the Cisco Security portal in English only.
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 in the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document without notice at any time.