About Traffic Zones
The Adaptive Security Algorithm (Stateful Inspection Overview) takes into consideration the state of a packet when deciding to permit or deny the traffic. One of the enforced parameters for the flow is that traffic enters and exits the same interface. Any traffic for an existing flow that enters a different interface is dropped by the ASA.
Traffic zones let you group multiple interfaces together so that traffic entering or exiting any interface in the zone fulfills the Adaptive Security Algorithm security checks.
In the following scenario, a connection was established between an inside host and an outside host through ISP 1 on the Outside1 interface. Due to asymmetric routing on the destination network, return traffic arrived from ISP 2 on the Outside2 interface.
Non-Zoned Problem : The ASA maintains the connection tables on a per-interface basis. When the returning traffic arrives at Outside2, it will not match the connection table and will be dropped.
Zoned Solution : The ASA maintains connection tables on a per-zone basis. If you group Outside1 and Outside2 into a zone, then when the returning traffic arrives at Outside2, it will match the per-zone connection table, and the connection will be allowed.
In the following scenario, a connection was established between an inside host and an outside host through ISP 1 on the Outside1 interface. Due to a lost or moved route between Outside1 and ISP 1, traffic needs to take a different route through ISP 2.
Non-Zoned Problem : The connection between the inside and outside host will be deleted; a new connection must be established using a new next-best route. For UDP, the new route will be used after a single packet drop, but for TCP, a new connection has to be reestablished.
Zoned Solution : The ASA detects the lost route and switches the flow to the new path through ISP 2. Traffic will be seamlessly forwarded without any packet drops.
In the following scenario, a connection was established between an inside host and an outside host through ISP 1 on the Outside1 interface. A second connection was established through an equal cost route through ISP 2 on Outside2.
Non-Zoned Problem : Load-balancing across interfaces is not possible; you can only load-balance with equal cost routes on one interface.
Zoned Solution : The ASA load-balances connections across up to eight equal cost routes on all the interfaces in the zone.
Per-Zone Connection and Routing Tables
The ASA maintains a per-zone connection table so that traffic can arrive on any of the zone interfaces. The ASA also maintains a per-zone routing table for ECMP support.
Non-Zoned ECMP Support
Without zones, you can have up to 3 equal cost static or dynamic routes per interface. For example, you can configure three default routes on the outside interface that specify different gateways:
route outside 0 0 10.1.1.2
route outside 0 0 10.1.1.3
route outside 0 0 10.1.1.4
In this case, traffic is load-balanced on the outside interface between 10.1.1.2, 10.1.1.3, and 10.1.1.4. Traffic is distributed among the specified gateways based on an algorithm that hashes the source and destination IP addresses.
ECMP is not supported across multiple interfaces, so you cannot define a route to the same destination on a different interface. The following route is disallowed when configured with any of the routes above:
route outside2 0 0 10.2.1.1
Zoned ECMP Support
With zones, you can have up to 8 equal cost static or dynamic routes across up to 8 interfaces within a zone. For example, you can configure three default routes across three interfaces in the zone:
route outside1 0 0 10.1.1.2
route outside2 0 0 10.2.1.2
route outside3 0 0 10.3.1.2
Similarly, your dynamic routing protocol can automatically configure equal cost routes. The ASA load-balances traffic across the interfaces with a more robust load balancing mechanism.
When a route is lost, the ASA seamlessly moves the flow to a different route.
How Connections Are Load-Balanced
The ASA load balances connections across equal cost routes using a hash made from the packet 6-tuple (source and destination IP address, source and destination port, protocol, and ingress interface). Unless the route is lost, a connection will stay on the chosen interface for its duration.
Packets within a connection are not load-balanced across routes; a connection uses a single route unless that route is lost.
The ASA does not consider the interface bandwidth or other parameters when load balancing. You should make sure all interfaces within the same zone have the same characteristics such as MTU, bandwidth, and so on.
The load-balancing algorithm is not user configurable.
Falling Back to a Route in Another Zone
When a route is lost on an interface, if there are no other routes available within the zone, then the ASA will use a route from a different interface/zone. If this backup route is used, then you may experience packet drops as with non-zoned routing support.
Interface-Based Security Policy
Zones allow traffic to and from any interface in the zone, but the security policy itself (access rules, NAT, and so on) is still applied per interface, not per zone. If you configure the same security policy for all interfaces within the zone, then you can successfully implement ECMP and load balancing for that traffic. For more information about required parallel interface configuration, see Prerequisites for Traffic Zones.
Supported Services for Traffic Zones
The following services are supported with zones:
- Access Rules
- Service Rules, except for QoS traffic policing.
You can also configure to- and from-the-box services listed in To- and From-the-Box Traffic, although full zoned support is not available.
Do not configure other services (such as VPN or Botnet Traffic Filter) for interfaces in a traffic zone; they may not function or scale as expected.
Note For detailed information about how to configure the security policy, see Prerequisites for Traffic Zones.
The first interface that you add to a zone determines the security level of the zone. All additional interfaces must have the same security level. To change the security level for interfaces in a zone, you must remove all but one interface, and then change the security levels, and re-add the interfaces.
Primary and Current Interface for the Flow
Each connection flow is built based on the initial ingress and egress interfaces. These interfaces are the primary interfaces.
If a new egress interface is used because of route changes or asymmetric routing, then the new interfaces are the current interfaces.
Joining or Leaving a Zone
When you assign an interface to a zone, any connections on that interface are deleted. The connections must be reestablished.
If you remove an interface from a zone, any connections that have the interface as the primary interface are deleted. The connections must be reestablished. If the interface is the current interface, the ASA moves the connections back to the primary interface. The zone route table is also refreshed.
To allow traffic to enter one interface and exit another in the same zone, enable the same-security permit intra-interface command, which allows traffic to enter and exit the same interface, as well as the same-security permit inter-interface command, which allows traffic between same-security interfaces. Otherwise, a flow cannot be routed between two interfaces in the same zone.
To- and From-the-Box Traffic
- You cannot add management-only or management-access interfaces to a zone.
- For management traffic on regular interfaces in a zone, only asymmetric routing on existing flows is supported; there is no ECMP support.
- You can configure a management service on only one zone interface, but to take advantage of asymmetric routing support, you need to configure it on all interfaces. Even when the configurations are parallel on all interfaces, ECMP is not supported.
- The ASA supports the following to- and from-the-box services in a zone:
Overlapping IP Addresses Within a Zone
For non-zoned interfaces, the ASA supports overlapping IP address networks on interfaces so long as you configure NAT properly. However, overlapping networks are not supported on interfaces in the same zone.
Prerequisites for Traffic Zones
- Configure all interface parameters including the name, IP address, and security level. Note that the security level must match for all interfaces in the zone. You should plan to group together like interfaces in terms of bandwidth and other Layer 2 properties.
- Configure the following services to match on all zone interfaces:
– Access Rules—Apply the same access rule to all zone member interfaces, or use a global access rule.
access-list ZONE1 extended permit tcp any host WEBSERVER1 eq 80
access-group ZONE1 in interface outside1
access-group ZONE1 in interface outside2
access-group ZONE1 in interface outside3
– NAT—Configure the same NAT policy on all member interfaces of the zone or use a global NAT rule (in other words, use “any” to represent the zone interfaces in the NAT rule).
Interface PAT is not supported.
object network WEBSERVER1
host 10.9.9.9 255.255.255.255
nat (inside,any) static 184.108.40.206
Note When you use interface-specific NAT and PAT pools, the ASA cannot switch connections over in case of the original interface failure.
If you use interface-specific PAT pools, multiple connections from the same host might load-balance to different interfaces and use different mapped IP addresses. Internet services that use multiple concurrent connections may not work correctly in this case.
– Service Rules—Use the global service policy, or assign the same policy to each interface in a zone.
QoS traffic policing is not supported.
service-policy outside_policy interface outside1
service-policy outside_policy interface outside2
service-policy outside_policy interface outside3
Note For VoIP inspections, zone load balancing can cause increased out-of-order packets. This situation can occur because later packets might reach the ASA before earlier packets that take a different path. Symptoms of out-of-order packets include:
- Higher memory utilization at intermediate nodes (firewall and IDS) and the receiving end nodes if queuing is used.
- Poor video or voice quality.
To mitigate these effects, we recommend that you use IP addresses only for load distribution for VoIP traffic.
- Configure routing with ECMP zone capabilities in mind.
Monitoring Traffic Zones
Shows zone ID, context, security level, and members.
See the following output for the show zone command:
ciscoasa# show zone outside-zone
Shows the interface names and zone names.
See the following output for the show nameif zone command:
ciscoasa# show nameif zone
Interface Name zone-name Security
GigabitEthernet0/0 inside-1 inside-zone 100
GigabitEthernet0/1.21 inside inside-zone 100
GigabitEthernet0/1.31 4 0
GigabitEthernet0/2 outside outside-zone 0
- show conn [ long | detail ] [ zone zone_name [ zone zone_name ] [...]]
The show conn zone command displays connections for a zone. The long and detail keywords show the primary interface on which the connection was built and the current interface used to forward the traffic.
See the following output for the show conn long zone command:
ciscoasa# show conn long zone zone-inside zone zone-outside
TCP outside-zone:outside1(outside2): 10.122.122.1:1080 inside-zone:inside1(inside2): 10.121.121.1:34254, idle 0:00:02, bytes 10, flags UO
Shows the accelerated security path tables for debugging purposes.
- show local-host [ zone zone_name [ zone zone_name ] [...]]
Shows the network states of local hosts within a zone.
See the following output for the show local-host zone command. The primary interface is listed first, and the current interface is in parentheses.
ciscoasa# show local-host zone outside-zone
Zone:outside-zone: 4 active, 5 maximum active, 0 denied
local host: <10.122.122.1>,
TCP flow count/limit = 3/unlimited
TCP embryonic count to host = 0
TCP intercept watermark = unlimited
UDP flow count/limit = 0/unlimited
TCP outside-zone:outside1(outside2): 10.122.122.1:1080 inside-zone:inside1(inside2): 10.121.121.1:34254, idle 0:00:02, bytes 10, flags UO
Shows the routes for zone interfaces.
See the following output for the show route zone command:
ciscoasa# show route zone
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, 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
S 192.168.105.1 255.255.255.255 [1/0] via 172.16.1.1, outside-zone:outside1
C 192.168.212.0 255.255.255.0 is directly connected, lan-zone:inside,
C 172.16.1.0 255.255.255.0 is directly connected, wan-zone:outside2
S 10.5.5.0 255.255.255.0 [1/0] via 172.16.1.1, wan-zone:outside2
O 10.2.2.1 255.255.255.255 [110/11] via 192.168.212.3, 2:09:24, lan-zone:inside
O 10.1.1.1 255.255.255.255 [110/11] via 192.168.212.2, 2:09:24, lan-zone:inside
Shows the accelerated security path tables for debugging purposes, and shows the zone associated with each route.
See the following output for the show asp table routing command:
ciscoasa# show asp table routing
route table timestamp: 60
in 255.255.255.255 255.255.255.255 identity
in 10.1.0.1 255.255.255.255 identity
in 10.2.0.1 255.255.255.255 identity
in 10.6.6.4 255.255.255.255 identity
in 10.4.4.4 255.255.255.255 via 10.4.0.10 (unresolved, timestamp: 49)
in 220.127.116.11 255.255.255.255 identity
in 18.104.22.168 255.255.255.0 wan-zone:outside2
in 10.85.43.0 255.255.255.0 via 10.4.0.3 (unresolved, timestamp: 50)
in 10.85.45.0 255.255.255.0 via 10.4.0.20 (unresolved, timestamp: 51)
in 192.168.0.0 255.255.255.0 mgmt
in 192.168.1.0 255.255.0.0 lan-zone:inside
out 255.255.255.255 255.255.255.255 mgmt
out 22.214.171.124 255.255.255.255 mgmt
out 126.96.36.199 255.255.255.0 mgmt
out 10.4.0.0 240.0.0.0 mgmt
out 255.255.255.255 255.255.255.255 lan-zone:inside
out 10.1.0.1 255.255.255.255 lan-zone:inside
out 10.2.0.0 255.255.0.0 lan-zone:inside
out 10.4.0.0 240.0.0.0 lan-zone:inside