Interchassis Asymmetric Routing Support for Zone-Based Policy Firewalls

The Interchassis Asymmetric Routing Support for Zone-Based Firewalls feature supports the forwarding of packets from a standby redundancy group to an active redundancy group for packet handling. If this feature is not enabled, the return TCP packets forwarded to the router that did not receive the initial synchronization (SYN) message are dropped because they do not belong to any known existing session. Interchassis asymmetric routing also supports active/active and active/standby load sharing redundancy.

This module provides an overview of asymmetric routing and active/active and active/standby load sharing redundancy, and describes how to configure asymmetric routing.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/​go/​cfn. An account on Cisco.com is not required.

Restrictions for Interchassis Asymmetric Routing Support for Zone-Based Policy Firewalls

The following are not supported:

  • Asymmetric routing on a Multiprotocol Label Switching (MPLS) VPN network. You cannot configure MPLS on the egress interface and VPN routing and forwarding (VRF) on the ingress interface.

  • Configuring asymmetric routing on a redundancy group (RG) interface.

  • IPv6 traffic.

Information About Interchassis Asymmetric Routing Support for Zone-Based Policy Firewalls

Asymmetric Routing Overview

Asymmetric routing occurs when packets from TCP or UDP connections flow in different directions through different routes. In asymmetric routing, packets that belong to a single TCP or UDP connection are forwarded through one interface in a redundancy group (RG), but returned through another interface in the same RG. In asymmetric routing, the packet flow remains in the same RG. When you configure asymmetric routing, packets received on the standby RG are redirected to the active RG for processing. If asymmetric routing is not configured, the packets received on the standby RG may be dropped.

Asymmetric routing determines the RG for a particular traffic flow. The state of the RG is critical in determining the handling of packets. If an RG is active, normal packet processing is performed. In case the RG is in a standby state and you have configured asymmetric routing and the asymmetric-routing always-divert enable command, packets are diverted to the active RG. Use the asymmetric-routing always-divert enable command to always divert packets received from the standby RG to the active RG.

The figure below shows an asymmetric routing scenario with a separate asymmetric-routing interlink interface to divert packets to the active RG.

Figure 1. Asymmetric Routing Scenario

The following rules apply to asymmetric routing:

  • 1:1 mapping exists between the redundancy interface identifier (RII) and the interface.

  • 1:n mapping exists between the interface and an RG. (An asymmetric routing interface can receive traffic from and send traffic to multiple RGs. For a non asymmetric-routing interface (normal LAN interface), a 1:1 mapping exists between the interface and the RG.)

  • 1:n mapping exists between an RG and applications that use it. (Multiple applications can use the same RG).

  • 1:1 mapping exists between an RG and the traffic flow. The traffic flow must map only to a single RG. If a traffic flow maps to multiple RGs, an error occurs.

  • 1:1 or 1:n mapping can exist between an RG and an asymmetric-routing interlink as long as the interlink has sufficient bandwidth to support all the RG interlink traffic.

Asymmetric routing consists of an interlink interface that handles all traffic that is to be diverted. The bandwidth of the asymmetric-routing interlink interface must be large enough to handle all expected traffic that is to be diverted. An IPv4 address must be configured on the asymmetric-routing interlink interface, and the IP address of the asymmetric routing interface must be reachable from this interface.


Note

We recommend that the asymmetric-routing interlink interface be used for interlink traffic only and not be shared with high availability control or data interfaces because the amount of traffic on the asymmetric-routing interlink interface could be quite high.

Asymmetric Routing Support in Firewalls

For intrabox asymmetric routing support, the firewall does a stateful Layer 3 and Layer 4 inspection of Internet Control Message Protocol (ICMP), TCP, and UDP packets. The firewall does a stateful inspection of TCP packets by verifying the window size and order of packets. The firewall also requires the state information from both directions of the traffic for stateful inspection. The firewall does a limited inspection of ICMP information flows. It verifies the sequence number associated with the ICMP echo request and response. The firewall does not synchronize any packet flows to the standby redundancy group (RG) until a session is established for that packet. An established session is a three-way handshake for TCP, the second packet for UDP, and informational messages for ICMP. All ICMP flows are sent to the active RG.

The firewall does a stateless verification of policies for packets that do not belong to the ICMP, TCP, and UDP protocols.

The firewall depends on bidirectional traffic to determine when a packet flow should be aged out and diverts all inspected packet flows to the active RG. Packet flows that have a pass policy and that include the same zone with no policy or a drop policy are not diverted.


Note

The firewall does not support the asymmetric-routing always-divert enable command that diverts packets received on the standby RG to the active RG. By default, the firewall forces all packet flows to be diverted to the active RG.

Active/Active Failover

In an active/active failover configuration, both devices can process network traffic. Active/active failover generates virtual MAC (VMAC) addresses for interfaces in each redundancy group (RG).

One device in an active/active failover pair is designated as the primary (active) device, and the other is designated as the secondary (standby) device. Unlike with active/standby failover, this designation does not indicate which device becomes active when both devices start simultaneously. Instead, the primary/secondary designation determines the following:

  • The device that provides the running configuration to the failover pair when they start simultaneously.

  • The device on which the failover RG appears in the active state when devices start simultaneously. Each failover RG in the configuration is configured with a primary or secondary device preference. You can configure both failover RGs to be in the active state on a single device and the standby failover RGs to be on the other device. You can also configure one failover RG to be in the active state and the other RG to be in the standby state on a single device.

Active/Active Load-Sharing Application Redundancy

The following figure shows two RGs, RG1 and RG2. The firewall is registered to both the groups. RG1 has a high priority on Router 1 and RG2 on Router 2. The firewall will process half of the sessions through RG1 on Router 1 and the other half through RG2 on Router 2. As a result, the firewall actively processes traffic on both routers.

Figure 2. Active/Active Load-Sharing Application Redundancy

In an enterprise scenario, if all WAN links on Router 1 fail, switchover happens on Router 2. For example, if there is only one WAN link per box, the failure of the WAN link on the active RG triggers a failover. In the case of a hardware or software failure such as Cisco software reload, the standby will detect active groups on the failed router either through the hello packets timeout or through Bidirectional Forwarding Detection (BFD) if BFD is configured on the control interface.

When Router 1 goes down in the scenarios described, the standby RG will assume the active role on Router 2. When the RG changes the state from standby to active, the firewall will change the state of all sessions in the new active RG and will start processing the traffic.

Active/Standby Failover

Active/standby failover enables you to use a standby device to take over the functionality of a failed device. A failed active device changes to the standby state, and the standby device changes to the active state. The device that is now in the active state takes over IP addresses and MAC addresses of the failed device and starts processing traffic. The device that is now in the standby state takes over standby IP addresses and MAC addresses. Because network devices do not see any change in the MAC-to-IP address pairing, Address Resolution Protocol (ARP) entries do not change or time out anywhere on the network.

In an active/standby scenario, the main difference between two devices in a failover pair depends on which device is active and which device is a standby, namely which IP addresses to use and which device actively passes the traffic. The active device always becomes the active device if both devices start up at the same time (and are of equal operational health). MAC addresses of the active device are always paired with active IP addresses.

Asymmetric Routing in a WAN-LAN Topology

Asymmetric routing supports only a WAN-LAN topology. In a WAN-LAN topology, devices are connected through LAN interfaces on the inside and WAN interfaces on the outside. There is no control on the routing of return traffic received through WAN links. Asymmetric routing controls the routing of return traffic received through WAN links in a WAN-LAN topology. The figure below shows a WAN-LAN topology.
Figure 3. Asymmetric Routing in a WAN-LAN Topology

Exclusive Virtual IP Addresses and Exclusive Virtual MAC Addresses

Virtual IP (VIP) addresses and virtual MAC (VMAC) addresses are used by security applications to control interfaces that receive traffic. An interface is paired with another interface, and these interfaces are associated with the same redundancy group (RG). The interface that is associated with an active RG exclusively owns the VIP and VMAC. The Address Resolution Protocol (ARP) process on the active device sends ARP replies for any ARP request for the VIP, and the Ethernet controller for the interface is programmed to receive packets destined for the VMAC. When an RG failover occurs, the ownership of the VIP and VMAC changes. The interface that is associated with the newly active RG sends a gratuitous ARP and programs the interface’s Ethernet controller to accept packets destined for the VMAC.

IPv6 Support

You can assign each redundancy group (RG) on a traffic interface for both IPv4 and IPv6 virtual IP (VIP) addresses under the same redundancy interface identifier (RII). Each RG uses a unique virtual MAC (VMAC) address per RII. For an RG, the IPv6 link-local VIP and global VIP coexist on an interface.

You can configure an IPv4 VIP, a link-local IPv6 VIP, and/or a global IPv6 VIP for each RG on a traffic interface. IPv6 link-local VIP is mainly used when configuring static or default routes, whereas IPv6 global VIP is widely used in both LAN and WAN topologies.

You must configure a physical IP address before configuring an IPv4 VIP.

Checkpoint Facility Support for Application Redundancy

Checkpointing is the process of storing the current state of a device and using that information during restart when the device fails. The checkpoint facility (CF) supports communication between peers by using the Inter-Process Communication (IPC) protocol and the IP-based Stream Control Transmission Protocol (SCTP). CF also provides an infrastructure for clients or devices to communicate with their peers in multiple domains. Devices can send checkpoint messages from the active to the standby device.

Application redundancy supports multiple domains (also called groups) that can reside within the same chassis and across chassis. Devices that are registered to multiple groups can send checkpoint messages from one group to their peer group. Application redundancy supports interchassis domain communication. Checkpointing happens from an active group to a standby group. Any combination of groups can exist across chassis. The communication across chassis is through SCTP transport over a data link interface that is dedicated to application redundancy.

Note

Domains in the same chassis cannot communicate with each other.

How to Configure Interchassis Asymmetric Routing Support for Zone-Based Policy Firewalls

Configuring a Firewall

In this task, you will do the following:

  • Configure a firewall.

  • Create a security source zone.

  • Create a security destination zone.

  • Create a security zone pair by using the configured source and destination zones.

  • Configure an interface as a zone member.

SUMMARY STEPS

    1.    enable

    2.    configure terminal

    3.    class-map type inspect match-any class-map-name

    4.    match protocol {icmp | tcp | udp}

    5.    exit

    6.    parameter-map type inspect global

    7.    redundancy

    8.    exit

    9.    policy-map type inspect policy-map-name

    10.    class type inspect class-map-name

    11.    inspect

    12.    exit

    13.    class class-default

    14.    drop

    15.    exit

    16.    exit

    17.    zone security security-zone-name

    18.    exit

    19.    zone security security-zone-name

    20.    exit

    21.    zone-pair security zone-pair-name source source-zone destination destination-zone

    22.    service-policy type inspect policy-map-name

    23.    exit

    24.    interface type number

    25.    ip address ip-address mask

    26.    encapsulation dot1q vlan-id

    27.    zone-member security security-zone-name

    28.    end

    29.    To attach a zone to another interface, repeat Steps 21 to 25.


DETAILED STEPS
     Command or ActionPurpose
    Step 1 enable


    Example:
    Device> enable
     

    Enables privileged EXEC mode.

    • Enter your password if prompted.

     
    Step 2configure terminal


    Example:
    Device# configure terminal
     

    Enters global configuration mode.

     
    Step 3class-map type inspect match-any class-map-name


    Example:
    Device(config)# class-map type inspect match-any ddos-class
     

    Creates an application-specific inspect type class map and enters QoS class-map configuration mode.

     
    Step 4match protocol {icmp | tcp | udp}


    Example:
    Device(config-cmap)# match protocol tcp
     

    Configures the match criterion for a class map based on the specified protocol.

     
    Step 5exit


    Example:
    Device(config-cmap)# exit
     

    Exits QoS class-map configuration mode and enters global configuration mode.

     
    Step 6parameter-map type inspect global


    Example:
    Device(config)# parameter-map type inspect global
     

    Defines a global inspect parameter map and enters parameter-map type inspect configuration mode.

     
    Step 7redundancy


    Example:
    Device(config-profile)# redundancy
     

    Enables firewall high availability.

     
    Step 8exit


    Example:
    Device(config-profile)# exit
     

    Exits parameter-map type inspect configuration mode and enters global configuration mode.

     
    Step 9policy-map type inspect policy-map-name


    Example:
    Device(config)# policy-map type inspect ddos-fw
     

    Creates a protocol-specific inspect type policy map and enters QoS policy-map configuration mode.

     
    Step 10class type inspect class-map-name


    Example:
    Device(config-pmap)# class type inspect ddos-class
     

    Specifies the traffic class on which an action is to be performed and enters QoS policy-map class configuration mode.

     
    Step 11inspect


    Example:
    Device(config-pmap-c)# inspect
     

    Enables stateful packet inspection.

     
    Step 12exit


    Example:
    Device(config-pmap-c)# exit
     

    Exits QoS policy-map class configuration mode and enters QoS policy-map configuration mode.

     
    Step 13class class-default


    Example:
    Device(config-pmap)# class class-default
     

    Configures the default class on which an action is to be performed and enters QoS policy-map class configuration mode.

     
    Step 14drop


    Example:
    Device(config-pmap-c)# drop
     

    Allows traffic to pass between two interfaces in the same zone.

     
    Step 15exit


    Example:
    Device(config-pmap-c)# exit
     

    Exits QoS policy-map class configuration mode and enters QoS policy-map configuration mode.

     
    Step 16exit


    Example:
    Device(config-pmap)# exit
     

    Exits QoS policy-map configuration mode and enters global configuration mode.

     
    Step 17zone security security-zone-name


    Example:
    Device(config)# zone security private
     
    Creates a security zone and enters security zone configuration mode.

    • You need two security zones to create a zone pair—a source and a destination zone.

     
    Step 18exit


    Example:
    Device(config-sec-zone)# exit
     

    Exits security zone configuration mode and enters global configuration mode.

     
    Step 19zone security security-zone-name


    Example:
    Device(config)# zone security public
     
    Creates a security zone and enters security zone configuration mode.

    • You need two security zones to create a zone pair—a source and a destination zone.

     
    Step 20exit


    Example:
    Device(config-sec-zone)# exit
     

    Exits security zone configuration mode and enters global configuration mode.

     
    Step 21zone-pair security zone-pair-name source source-zone destination destination-zone


    Example:
    Device(config)# zone-pair security private2public source private destination public
     

    Creates a zone pair and enters security zone-pair configuration mode.

     
    Step 22service-policy type inspect policy-map-name


    Example:
    Device(config-sec-zone-pair)# service-policy type inspect ddos-fw
     

    Attaches a policy map to a top-level policy map.

     
    Step 23exit


    Example:
    Device(config-sec-zone-pair)# exit
     

    Exits security zone-pair configuration mode and enters global configuration mode.

     
    Step 24interface type number


    Example:
    Device(config)# interface gigabitethernet 0/1/0.1
     

    Configures an interface and enters subinterface configuration mode.

     
    Step 25ip address ip-address mask


    Example:
    Device(config-subif)# ip address 10.1.1.1 255.255.255.0
     

    Configures an IP address for the subinterface.

     
    Step 26encapsulation dot1q vlan-id


    Example:
    Device(config-subif)# encapsulation dot1q 2
     

    Sets the encapsulation method used by the interface.

     
    Step 27zone-member security security-zone-name


    Example:
    Device(config-subif)# zone-member security private
     

    Configures the interface as a zone member.

    • For the security-zone-name argument, you must configure one of the zones that you had configured by using the zone security command.

    • When an interface is in a security zone, all traffic to and from that interface (except traffic going to the device or initiated by the device) is dropped by default. To permit traffic through an interface that is a zone member, you must make that zone part of a zone pair to which you apply a policy. If the policy permits traffic (via inspect or pass actions), traffic can flow through the interface.

     
    Step 28end


    Example:
    Device(config-subif)# end
     

    Exits subinterface configuration mode and enters privileged EXEC mode.

     
    Step 29To attach a zone to another interface, repeat Steps 21 to 25.  

    —

     

    Configuring a Redundancy Application Group and a Redundancy Group Protocol

    Redundancy groups consist of the following configuration elements:

    • The amount by which the priority will be decremented for each object.

    • Faults (objects) that decrement the priority

    • Failover priority

    • Failover threshold

    • Group instance

    • Group name

    • Initialization delay timer

    SUMMARY STEPS

      1.    enable

      2.    configure terminal

      3.    redundancy

      4.    application redundancy

      5.    group id

      6.    name group-name

      7.    priority value [failover threshold value]

      8.    preempt

      9.    track object-number decrement number

      10.    exit

      11.    protocol id

      12.    timers hellotime {seconds | msec msec} holdtime {seconds | msec msec}

      13.    authentication {text string | md5 key-string [0 | 7] key [timeout seconds] | key-chain key-chain-name}

      14.    bfd

      15.    end


    DETAILED STEPS
       Command or ActionPurpose
      Step 1 enable


      Example:
      Device> enable
       
      Enables privileged EXEC mode.

      • Enter your password if prompted

       
      Step 2 configure terminal


      Example:
      Device# configure terminal
       

      Enters global configuration mode.

       
      Step 3 redundancy


      Example:
      Device(config)# redundancy
       

      Enters redundancy configuration mode.

       
      Step 4 application redundancy


      Example:
      Device(config-red)# application redundancy
       

      Configures application redundancy and enters redundancy application configuration mode.

       
      Step 5 group id


      Example:
      Device(config-red-app)# group 1
       

      Configures a redundancy group and enters redundancy application group configuration mode.

       
      Step 6 name group-name


      Example:
      Device(config-red-app-grp)# name group1
       

      Specifies an optional alias for the protocol instance.

       
      Step 7 priority value [failover threshold value]


      Example:
      Device(config-red-app-grp)# priority 100 failover threshold 50
       

      Specifies the initial priority and failover threshold for a redundancy group.

       
      Step 8 preempt


      Example:
      Device(config-red-app-grp)# preempt
       
      Enables preemption on the redundancy group and enables the standby device to preempt the active device.

      • The standby device preempts only when its priority is higher than that of the active device.

       
      Step 9 track object-number decrement number


      Example:
      Device(config-red-app-grp)# track 50 decrement 50
       

      Specifies the priority value of a redundancy group that will be decremented if an event occurs on the tracked object.

       
      Step 10 exit


      Example:
      Device(config-red-app-grp)# exit
       

      Exits redundancy application group configuration mode and enters redundancy application configuration mode.

       
      Step 11 protocol id


      Example:
      Device(config-red-app)# protocol 1
       

      Specifies the protocol instance that will be attached to a control interface and enters redundancy application protocol configuration mode.

       
      Step 12 timers hellotime {seconds | msec msec} holdtime {seconds | msec msec}


      Example:
      Device(config-red-app-prtcl)# timers hellotime 3 holdtime 10
       
      Specifies the interval between hello messages sent and the time period before which a device is declared to be down.

      • Holdtime should be at least three times the hellotime.

       
      Step 13 authentication {text string | md5 key-string [0 | 7] key [timeout seconds] | key-chain key-chain-name}


      Example:
      Device(config-red-app-prtcl)# authentication md5 key-string 0 n1 timeout 100
       

      Specifies authentication information.

       
      Step 14 bfd


      Example:
      Device(config-red-app-prtcl)# bfd
       
      Enables the integration of the failover protocol running on the control interface with the Bidirectional Forwarding Detection (BFD) protocol to achieve failure detection in milliseconds.

      • BFD is enabled by default.

       
      Step 15 end


      Example:
      Device(config-red-app-prtcl)# end
       

      Exits redundancy application protocol configuration mode and enters privileged EXEC mode.

       

      Configuring Data, Control, and Asymmetric Routing Interfaces

      In this task, you configure the following redundancy group (RG) elements:

      • The interface that is used as the control interface.

      • The interface that is used as the data interface.

      • The interface that is used for asymmetric routing. This is an optional task. Perform this task only if you are configuring asymmetric routing for Network Address Translation (NAT).


      Note

      Asymmetric routing, data, and control must be configured on separate interfaces for zone-based firewall. However, for Network Address Translation (NAT), asymmetric routing, data, and control can be configured on the same interface.

      SUMMARY STEPS

        1.    enable

        2.    configure terminal

        3.    redundancy

        4.    application redundancy

        5.    group id

        6.    data interface-type interface-number

        7.    control interface-type interface-number protocol id

        8.    timers delay seconds [reload seconds]

        9.    asymmetric-routing interface type number

        10.    asymmetric-routing always-divert enable

        11.    end


      DETAILED STEPS
         Command or ActionPurpose
        Step 1 enable


        Example:
        Device> enable
         
        Enables privileged EXEC mode.

        • Enter your password if prompted.

         
        Step 2 configure terminal


        Example:
        Device# configure terminal
         

        Enters global configuration mode.

         
        Step 3 redundancy


        Example:
        Device(config)# redundancy
         

        Enters redundancy configuration mode.

         
        Step 4 application redundancy


        Example:
        Device(config-red)# application redundancy
         

        Configures application redundancy and enters redundancy application configuration mode.

         
        Step 5 group id


        Example:
        Device(config-red-app)# group 1
         

        Configures a redundancy group (RG) and enters redundancy application group configuration mode.

         
        Step 6 data interface-type interface-number


        Example:
        Device(config-red-app-grp)# data GigabitEthernet 0/0/1
         

        Specifies the data interface that is used by the RG.

         
        Step 7 control interface-type interface-number protocol id


        Example:
        Device(config-red-app-grp)# control GigabitEthernet 1/0/0 protocol 1
         
        Specifies the control interface that is used by the RG.

        • The control interface is also associated with an instance of the control interface protocol.

         
        Step 8 timers delay seconds [reload seconds]


        Example:
        Device(config-red-app-grp)# timers delay 100 reload 400
         

        Specifies the time required for an RG to delay role negotiations that start after a fault occurs or the system is reloaded.

         
        Step 9 asymmetric-routing interface type number


        Example:
        Device(config-red-app-grp)# asymmetric-routing interface GigabitEthernet 0/1/1
         

        Specifies the asymmetric routing interface that is used by the RG.

         
        Step 10 asymmetric-routing always-divert enable


        Example:
        Device(config-red-app-grp)# asymmetric-routing always-divert enable
         

        Always diverts packets received from the standby RG to the active RG.

         
        Step 11 end


        Example:
        Device(config-red-app-grp)# end
         

        Exits redundancy application group configuration mode and enters privileged EXEC mode.

         

        Configuring a Redundant Interface Identifier and Asymmetric Routing on an Interface


        Note
        • You must not configure a redundant interface identifier (RII) on an interface that is configured either as a data interface or as a control interface.
        • You must configure the RII and asymmetric routing on both active and standby devices.
        • You cannot enable asymmetric routing on the interface that has a virtual IP address configured.
        SUMMARY STEPS

          1.    enable

          2.    configure terminal

          3.    interface type number

          4.    redundancy rii id

          5.    redundancy group id [decrement number]

          6.    redundancy asymmetric-routing enable

          7.    end


        DETAILED STEPS
           Command or ActionPurpose
          Step 1 enable


          Example:
          Device> enable
           
          Enables privileged EXEC mode.

          • Enter your password if prompted.

           
          Step 2 configure terminal


          Example:
          Device# configure terminal
           

          Enters global configuration mode.

           
          Step 3 interface type number


          Example:
          Device(config)# interface GigabitEthernet 0/1/3
           

          Selects an interface to be associated with the redundancy group (RG) and enters interface configuration mode.

           
          Step 4 redundancy rii id


          Example:
          Device(config-if)# redundancy rii 600
           

          Configures the redundancy interface identifier (RII).

           
          Step 5 redundancy group id [decrement number]


          Example:
          Device(config-if)# redundancy group 1 decrement 20
           

          Enables the RG redundancy traffic interface configuration and specifies the amount to be decremented from the priority when the interface goes down.

          Note   

          You need not configure an RG on the traffic interface on which asymmetric routing is enabled.

           
          Step 6 redundancy asymmetric-routing enable


          Example:
          Device(config-if)# redundancy asymmetric-routing enable
           

          Establishes an asymmetric flow diversion tunnel for each RG.

           
          Step 7 end


          Example:
          Device(config-if)# end
           

          Exits interface configuration mode and enters privileged EXEC mode.

           

          Configuration Examples for Interchassis Asymmetric Routing Support for Zone-Based Policy Firewalls

          Example: Configuring a Firewall

          Router# configure terminal
Router(config)# class-map type inspect match-any ddos-class
Router(config-cmap)# match protocol tcp
Router(config-cmap-c)# exit
Router(config)# parameter-map type inspect global
Router(config-profile)# redundancy
Router(config-profile)# exit
Router(config)# policy-map type inspect ddos-fw
Router(config-pmap)# class type inspect ddos-class
Router(config-pmap-c)# inspect
Router(config-pmap-c)# exit
Router(config-pmap)# class class-default
Router(config-pmap-c)# drop
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# zone security private
Router(config-sec-zone)# exit
Router(config)# zone security public
Router(config-sec-zone)# exit
Router(config)# zone-pair security private2public source private destination public
Router((config-sec-zone-pair)# service-policy type inspect ddos-fw
Router((config-sec-zone-pair)# exit
Router(config)# interface gigabitethernet 0/1/0.1
Router(config-subif)# ip address 10.1.1.1 255.255.255.0
Router(config-subif)# encapsulation dot1q 2
Router(config-subif)# zone-member security private
Router(config-subif)# exit
Router(config)# interface gigabitethernet 1/1/0.1
Router(config-subif)# ip address 10.2.2.2 255.255.255.0
Router(config-subif)# encapsulation dot1q 2
Router(config-subif)# zone-member security public
Router(config-subif)# end

          Example: Configuring a Redundancy Application Group and a Redundancy Group Protocol

          Device# configure terminal	
Device(config)# redundancy
Device(config-red)# application redundancy
Device(config-red-app)# group 1
Device(config-red-app-grp)# name group1
Device(config-red-app-grp)# priority 100 failover threshold 50
Device(config-red-app-grp)# preempt
Device(config-red-app-grp)# track 50 decrement 50
Device(config-red-app-grp)# exit
Device(config-red-app)# protocol 1
Device(config-red-app-prtcl)# timers hellotime 3 holdtime 10
Device(config-red-app-prtcl)# authentication md5 key-string 0 n1 timeout 100
Device(config-red-app-prtcl)# bfd
Device(config-red-app-prtcl)# end

          Example: Configuring Data, Control, and Asymmetric Routing Interfaces

          Device# configure terminal
Device(config)# redundancy 
Device(config-red)# application redundancy
Device(config-red-app)# group 1
Device(config-red-app-grp)# data GigabitEthernet 0/0/1
Device(config-red-app-grp)# control GigabitEthernet 1/0/0 protocol 1
Device(config-red-app-grp)# timers delay 100 reload 400 
Device(config-red-app-grp)# asymmetric-routing interface GigabitEthernet 0/1/1 
Device(config-red-app-grp)# asymmetric-routing always-divert enable
Device(config-red-app-grp)# end

          Example: Configuring a Redundant Interface Identifier and Asymmetric Routing on an Interface

          Device# configure terminal
Device(config)# interface GigabitEthernet 0/1/3
Device(config-if)# redundancy rii 600
Device(config-if)# redundancy group 1 decrement 20
Device(config-if)# redundancy asymmetric-routing enable 
Device(config-if)# end

          Additional References

          Related Documents

          Related Topic

          Document Title

          Cisco IOS commands

          Cisco IOS Master Commands List, All Releases

          Security commands

          Technical Assistance

          Description

          Link

          The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

          http:/​/​www.cisco.com/​cisco/​web/​support/​index.html

          Feature Information for Interchassis Asymmetric Routing Support for Zone-Based Policy Firewalls

          The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

          Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/​go/​cfn. An account on Cisco.com is not required.
          Table 1 Feature Information for Interchassis Asymmetric Routing Support for Zone-Based Policy Firewalls

          Feature Name

          Releases

          Feature Information

          Interchassis Asymmetric Routing Support for Zone-Based Policy Firewalls

          15.2(3)T

          The Interchassis Asymmetric Routing Support for Zone-Based Policy Firewalls feature supports the forwarding of packets from a standby redundancy group to the active redundancy group for packet handling.

          The following commands were introduced or modified: asymmetric-routing, debug redundancy application group asymmetric-routing, redundancy asymmetric-routing enable, redundancy group (interface), redundancy rii, and show redundancy application asymmetric-routing.