Cisco ACE

ACE 1.
0 NPI Training Application Control Engine (ACE)
Curt Kersey Technical Leader L4-7 Security Engineering eck@cisco.com
Jay Cedrone TME ADBU jcedrone@cisco.com
2006 Cisco Systems, Inc. All rights reserved.
ACE 1.0 NPI Training Application Control Engine (ACE)
Srini Sudireddi Technical Leader L4-7 Security Engineering ssudired@cisco.com
Derek Huckaby TME ADBU dhuckaby@cisco.com
Terminology
Deciphering Codenames
Project has had several codenames, which you may see in slides and software output. The names:
Itasca: Cat6k hardware platform. Trinity: Software running on Itasca hardware. Nagog: Original name for appliance box note: there are 3 new codenames to cover this! ACE: The actual product name.
CA Training
ACE Hardware Architecture
Hardware Architecture Introduction
This module covers the hardware components of the Application Control Engine (ACE). To comprehend how the ACE device processes traffic it essential to understand the HW Architecture chosen to implement ACE. By understanding the hardware the user can better understand packet flows through ACE.
CA Training
HW Architecture Module Objectives
After completing this module you will be able to:

Name the major HW components of the ACE module Describe the functions preformed in the Control Plane and Data Plane List the different usages of Micro Engines Differentiate the functions implemented on the IXPs and the Xscale
CA Training
Agenda
Hardware Architecture IXP Architecture Data Plane Architecture
Micro Engine (ME) usage Xscale usage
Control Plane Architecture Software Versioning
CA Training
Hardware Architecture
Application Control Engine
Same Hardware supports 4G, 8G, and 16G Functionally ACE is a superset of: CSM + SSLM + Basic FW
CA Training
10
ACE Hardware Architecture

San OS Monta Vista Linux 60Gbps switching Capacity IPv4, IPv6 Classifications TCP Checksum Generation Verification Variable Laod Distribution Parallel IXPs handle Data Processing 16 ME (1.4 GHz) XScale 700MHz 1.5 GB RDRAM 32MB SRAM 20B ops/s
2x 700MHz MIPS 1 GB Memory

Control Plane Software
Daughter Card Expansion Slot

SiByte 1250
20 Gbps Switch Fabric 100 Mbps
Field upgradeable
DRAM 1.5 GB
Intel IXP 2800

Micro Engines
10 Gbps 16 Gbps
Supervisor Connection 1 Gbps
16 Gbps
Hyperion
10 Gbps
Classification Distribution Engine

10 Gbps 4 FIFO Interlinks
8 Gbps
X S c a l e
8 Gbps
DRAM 1.5 GB
Intel IXP 2800

Micro Engines
SSL, IPSec Crypto
Nitrox II
DBUS 16 Gbps Bus RBUS EOBC
Daughter Card Expansion Slot

Field upgradeable
X S c a l e
40K RSA ops
CEF720 Linecard
11
CA Training
IXP2800 Internal Architecture

16 Microengines (1.4 GHz)
Each has 8K control store
XScale Processor (700 MHz) 1.5GB RDRAM (433 MHz DDR) 32MB SRAM (200 MHz DDR) Both IXPs run in parallel
process data independently Inter Process Communication Protocol (IPCP) Required for IXP to share information (sticky lookups)
CA Training
12
IXP2800 Micro Engines (ME)

Handles the bulk of the data processing:
Connection management (ICM, OCM, CM_CLOSE). Fastpath. ACL classification and NAT. TCP termination. SSL Record Layer (record framing & bulk crypto). HTTP and Regular Expression (Regex) parsing.
CA Training
13
IXP2800 XScale
700 Mhz ARM 5 core running QNX QNX is chosen because
Supports FCSE (Fast Context Switch Extensions) mode Real time scheduling Small efficient microkernel, fast context switch Virtual memory
IXP2800 XScale Processors

Layer7 policy matching Load balancing algorithms SSL Handshake FTP and RTSP control channel fixups
CA Training
14
ACE Integration with Supervisor720

The blade is seen by the supervisor as single 16 gigabit port. VLANs are allocated to the ACE via svclc command.
CA Training
15
Classification Distribution Engine (CDE)

Provides 60 Gbps switching capacity. Capable of IPv4 and IPv6 Classification. CDE distributes traffic between the IXPs based on the traffic type using the following hashing schemes:
Non fragmented TCP/UDP - port hash. IP - source, destination IP hash. Non IP source, destination MAC hash. Note: fragmented IP traffic uses a source/dest IP hash to select which IXP will do the reassembly.
CA Training
16
CDE: Functions
Inbound: Classify the packet as L2, L3, or L4. Verifies the IP and TCP checksum. Creates IMPH header and pre-pends to pkt. IMPH header has info about which IXP, etc. Outbound: Generates IP and TCP checksum. Generates header for Hyperion (Cat6k). Checks status of output queue; if it is full, it will assert backpressure on the IXP that is feeding it.
CA Training
17
Traffic Distribution
IXPs work in parallel independent of each other:
Scales nicely for both PPS and CPS. System pools are split between the two (e.g., NAT/PAT pools, sticky table). System tables are duplicated on both (e.g., ACL & FIB tables).
Due to distributed system, must have protocol to communicate within system IPCP is proprietary protocol developed for ACE. Each ME has a specialized functionality that is defined by that subsystem. Fastpath connections for client and server are independently allocated and linked together. System uses fixed size packet buffers (particles) that can be chained together.
CA Training
18
Data Plane Architecture
19
Dataplane Subsystems on MEs

Receive + Fastpath (+ Transmit) IP Reassembly + Timers + Syslog Inbound Connection Manager Outbound Connection Manager Connection Close Management TCP RX and TX HTTP with REGEX Application fixups SSL Record Layer Application Fixups HTTP HTTP OCM CCM TCP RX TCP TX Fast Path Rx Fast Path Fast Path Fast Path Fast Path
IP Frag ICM Timers
SSL FixUps Record
Xscale
CA Training
20
Receive (RX) ME
Takes inbound packets from CDE FIFO via SPI and reassembles packets into internal representation, Particle Buffers. Once packets are transferred from FIFO, RxME signals FastPath. Can also support Jumbo frames.
CA Training
21
FastPath ME: Receive Processing

Determines the incoming interface of the packet based on VLAN and (optionally) Destination MAC. Does some IP normalization by checking validity of L2/L3 information. Sends management traffic from outside like ARP and BPDU directly to the Control Plane (CP). If packet is fragmenting, it will be sent to reassembly ME for processing. Performs connection lookup based on 5-tuple.
CA Training
22
FastPath ME: Lookups

Per packet atomic checks 5/6 Tuple Connection Lookup
Hash based exact match lookup
Interface Lookup
PVLAN to VLAN mapping Resolves shared interface (VLAN + MAC) Resolves connection lookup key
CA Training
23
FastPath ME: Connection Miss

If connection is not found, then FastPath will do a lookup for Virtual context. If Virtual context is found, then FastPath will signal ICM for a new connection setup. If no Virtual context is found, then packet is dropped.
CA Training
24
FastPath ME: Connection Hit

If connection is found in lookup, then the following are performed:
L2/L3 Firewall checks. NAT/PAT + L2 header rewrite. TCP/IP normalization/checks + FIN/RST processing. Per context BW policing. Statistics gathering. TCP Re-proxy condition checking. Packet Transmit unless packet needs to go to another subsystem for processing first (e.g. TCP if in a proxy state).
CA Training
25
FastPath ME: Transmit Processing

Transmit Processing:
Make sure there is no back-pressure in communication with CDE. If there is back-pressure, packet could be dropped. Get L2/L3 encapsulation information. Make sure packet is <= MTU for interface. Allocate transmit buffer space. Transmit buffer space is done for IXP. Copy L2/L3 headers and packet data to transmit buffer space. From there, packet is sent to CDE.
CA Training
26
FastPath ME: More Information

Fastpath treats traffic as a connection unless:
The header of a CP packet indicates it can be sent out as is. Packets not considered as a flow/connection, such as ARP, receive minimal modification.
CA Training
27
Backpressure: Definition
Backpressure is the mechanism used to slow the system down if queues start to fill up internally. Queues that can be affected and create backpressure:
FIFOs for CDE, IXPs, and Nitrox. Internal queues for each ME.
It is possible that some packets that are received by the system could be dropped internally if backpressure is applied.
CA Training
28
Backpressure: How to Tell if Occurring

There are counters to alert if backpressure is being enabled. Details on that in the debugging section.
CA Training
29
Inbound Connection Manager (ICM) ME

On receipt of a packet buffer, it will first do a connection setup request. If there is no connection found, then ICM will do all the work to get it setup:
Allocate internal connection object. Setup PathID, which determines the packets path through the system. Send a new connection message to the necessary subsystem.
If a connection is found, then ICM will process the packet as needed.

CA Training
30

Some connectionless traffic could hit ICM in bridge mode (e.g. MPLS), so per packet ETYPE ACL and bridge table lookup done. Depending on incoming interface type, stickysource MAC, etc. the encapsulation ID is determined.
CA Training
31

ACL Lookup
Layer 3/4 ACLs are merged to give all results in one lookup including Security, Virtual Server, NAT, AAA, etc.
Per connection IP/TCP normalization Unicast RPF + L2 Firewall checks IP forwarding lookup Client-side FastPath connection setup Proxy connection id allocation Control Point traffic management ICMP Inspect Data structures referenced: icmiflookup table, MTRIE, reverse encap table , encap table, policy MTRIE, connection table.
CA Training
32
Outbound Connection Manager (OCM) ME

OCM will first be called with a connection setup request for outbound connection.
This will typically come from an ICM/LB decision.
Work done:
Egress ACL lookup. NAT/PAT allocation. Route/bridge table lookup. Setup the egress connection record. Buddy connection management.
CA Training
33
Outbound Connection Manager (OCM) ME

TCP Connection re-use:
Supported in setup of server-side connection.
Connection create syslog message is generated. Data structures referenced: MTRIE, reverse encap table, encap table, connection table, xlate
CA Training
34
Connection Close Management (CCM) ME

Connection idle and pending timeout processing. Connection Replication
In High Availability setup, the connection closing indicator will be sent to the other unit.
Connection close syslog messages generated.
CA Training
35
TCP ME
Full TCP state machine
Based on CSS-SSL Module. Out of order segment support.
Support for TCP options:

MSS, Maximum Segment Size: allows the largest possible data sizes to be sent. Window scaling: allows the connection to have the largest size window available based on network latency, etc.
CA Training
36
TCP ME
Support for TCP options, continued:
Timestamp: Improve RTT measurements, which will allow for better use of congestion window and slowstart algorithms during connection. When combined with window scaling is useful when there is a great deal of latency between the endpoints as RTT is less accurate using the normal van Jacobsen algorithm. SACK, Selective ACKs: allows the other side to ACK any holes in data so that the segment can be re-sent by ACE more quickly than the normal TCP timers allow.
CA Training
37
HTTP ME
Support for persistent and pipelined requests. Match URLs and Cookies against user defined regular expressions. Insert user defined cookies and other headers in request/response. Facilitate server side connection reuse. Ability to perform HTTP RFC compliance checks, MIME type checks, URL/Content/URL Header checks etc.
CA Training
38
SSL Record Layer ME

Partitions TCP stream into SSL records. Decodes SSL commands to check if they are handshake or bulk records. Interfaces with Nitrox crypto processor for SSL bulk data encryption / decryption. Interfaces with the SSL Handshake layer on the Xscale processor.
CA Training
39
Syslog
40
Modes of operation
Two modes of operation: 1. All syslog processing in CP (default mode) Benefit: Syslogs will be delivered in sequence in accordance to event occurrence. One TCP connection per syslog server. Caveat: Cannot achieve marketing requirement of syslog rate matching connection throughput rate. DP messages will be rate-limited based on pre-defined CP processing limit.
CA Training
41
Modes of operation (cont)

Two modes of operations (cont): 2. Enable syslog processing in DP Benefit: connection setup and teardown messages will be processed by DP marketing requirement of connection rate syslog can be achieved Caveat: syslogs will be delivered out of sequence DP syslog processing does not support delivery over TCP
CA Training
42
Syslog Message Format

Standard log message structure: <fac|pri> [mmm dd yyyy hh:mm:ss] <ip or dns> %ACE-<level>-<msg id>: <msg text>
Emblem message structure: <fac|pri>: [mmm dd hh:mm:ss TimeZone:] <ip or dns>:%ACE-[SUBFACILITY-]SEVERITY-<msg id>: <Message-text>
CA Training
43
CP Syslog
Handle CLI commands Receive syslogs from CP modules via Unix socket and place them in internal queue Receive syslogs from IXP and Xscale modules via IPCP and place them in internal queue: Generate timestamp. Support sending syslogs via UDP and TCP to external servers. Periodically retrieve syslog statistics from DP.
CA Training
44
DP Syslog
Disabled by default. Enable via command logging fastpath. Syslogs that will be sent out directly from DP to external syslog servers:
302028: Built TCP connection 302029: Teardown TCP connection 302030: Built UDP connection 302031: Teardown UDP connection
These syslogs will not be forwarded to CP when this option is enabled, which means they will not be seen on console, buffer, supervisor, telnet sessions, SNMP.
CA Training
45
Dataplane Subsystems using the XScale

Load Balancer SSL Handshake Layer Application Inspects (FTP/RTSP) High Availability Heartbeats Dataplane show command processing IPCP server
CA Training
46
Load Balancer (LB)

Policy match engine ties in with HTTP. Load balancing algorithms. Sticky database management.
CA Training
47
SSL Handshake Layer

Works on records passed by the SSL ME record layer.
Must only receive full SSL records for processing, which is what the SSL ME does.
Communicates to Nitrox using the APIs provided to implement the handshake protocol. Will communicate via the SSL ME for talking to the rest of the system.
CA Training
48
Control Plane Architecture
49
Control Plane: Sub-systems Running

Configuration Manager DHCP Relay Interface Forwarding & Management Virtualization Health Monitoring High Availabilithy
CA Training
50
Configuration Manager
Two parts to configuration manager:
Top-half: pertains to getting the actual CLI commands entered either via console, remotely, or from AAA. Also does some data sanity checking of configuration before it gets downloaded (e.g., duplicate IPs, etc). Bottom-half: pertains to getting data to DP where lookup tables and data structures are available. Additionally, this can also be triggered due to probes running on CP.
Other work:
Gathering of statistics. show running
CA Training
51
Configuration Manager: Top-half Handler
H T T P /X M L
C L I: T e ln e t /S S H / C o n s o le
L o g in
A u th e n tic a tio n L o c a l/R e m o te
R e m o te A u t h e n t ic a t io n S e rv e r
V S H /P a r s e r
V ir tu a liz a tio n C o n tr o lle r
C o n fig m a n a g e r (T o p H a lf)
CA Training
52
Config Manager: Bottom-half Handler

Config manager: Bottom Half Thread
- Rcvs a valid config object - Reposible for notifying the appropriate subsytems with appropriate configuration data - Handles global config version and any config delay ARP
IF
LB feature compiler and downloader agent
TCP feature compiler and downloader agent
Nat Feature Comiler
Regex HealthMon
RIB
TNRPC
Various Compile Process

FIB manager ACL feature comiler and downloader Nat Download manger
CA Training
53
DHCP Relay
ACE can be configured to relay a clients DHCP request to a defined list of DHCP servers. Used if DHCP client and server are on different networks. Command to enable:
ip dhcp relay enable
DHCP relay is a process on CP

Configured per interface or at the interface level. If configured in a context, it will apply to all interfaces in that context.
CA Training
54
Interface Management and Forwarding
55
Control Plane: Packets

All packets for CP come via the CDE/IXPs. Some traffic is always sent to the CP:
BPDU ARP IGMP HSRP
CA Training
56
CP Packet Forwarding
CP packet forwarding has no knowledge of connections; it operates on a packet-by-packet basis.
No SLB policies get applied. No support for bridging (i.e. outgoing packets are always routed).
If ECMP enabled, only the 1st entry in route table is used. There are two code paths out of the CP based on traffic:
encap_decap based. socket interface (LINUX stack) based.
CA Training
57
CP Packet Forwarding: encap_decap

No support for fragmentation/reassembly. So restriction on maximum sized ping packet. Packets with source IP as floating IP (i.e. VIP and alias IP) are handled here. Decides based on source IP whether to use BIA or VMAC as SMAC. This works off the Encapsulation Table, MTRIE and flow lookup identical to what is in DP.
In case of an encap miss for a connected destination, it would notify ARP to resolve.
CA Training
58
CP Packet Forwarding: LINUX Socket

Only sees EOBC interface from Cat6k and one additional interface. The additional interface has no IP address. Forwarding code will always populate the route cache (by calling into encap_decap). Encap_decap will return the L2 rewrite and MTU if available and the LINUX cache gets populated. In the event of a change in the above, the entire LINUX route cache is flushed. Fragmentation and reassembly support from LINUX. No traffic with source IP == floating IP.
CA Training
59
Agenda
Interface Management ARP and adjacency Routing
CA Training
60
Interface Management
61
Interface Modes
Routed Interface Bridged Interface
CA Training
62
Routed Interface
L3 interface: all traffic hitting this are routed. IP address (mandatory). Alias IP address (Optional). Peer IP address (Optional). IP subnets cannot overlap within a context. Can overlap between interfaces in different contexts. Across context on a shared VLAN the IP address cannot be identical. On a non-shared VLAN they can be identical.
CA Training
63
Routed Interface (contd.)

Alias IP is similar semantic as HSRP IP floating. Only ping to alias IP is allowed.
CA Training
64
Bridged Interface
L2 interface: non-loadbalanced traffic hitting this interface is bridged.
LoadBalanced traffic is always routed.
IOS style configuration: put interfaces in a bridge group. 2 interfaces in a bridge group. No MAC learning. Bridge lookup based on <bridge-group-id, dest-MAC>. Bridged Traffic never unknown-unicast-flooded. Multicast and broadcast bridged traffic automatically sent to the other interface of the bridge-group.
CA Training
65
Interface Types
VLAN Interface BVI Interface Fault Tolerant (FT) Interface
CA Training
66
VLAN interface
Associated with VLANs on the SUP. Must be routed or bridged
A bridge-group or an IP address is required to be useable.
No restriction on what can be configured on these interfaces.
CA Training
67
BVI interface
Is a routed interface. Associated with bridge-group. Interface number must be same as bridge-group-id (BGID). BGID is a number between 1 and 4k. Internal BGID starts at 8K+1 and goes up to 12K. Allowed configs: IP addresses, shut/no shut. In order to be able to use BVI to terminate management traffic, need to put management policy on the specific L2 interface from which management traffic expected.
CA Training
68
BVI interface (contd.)

BVI associated with up to 2 VLAN interfaces in the bridge-group. Possible to have a BVI with no VLAN interfaces. MAC address of BVI is equal to the MAC address of the associated L2 interfaces. BVI and the L2 interface need to be UP for the L2 interface to forward traffic.
CA Training
69
Fault Tolerance (FT) Interface

Interface used for talking to High Availability (HA) peer. Routed interface. Permitted config: IP addresses and shut/no shut.
CA Training
70
Interface goes up if
It is not administratively down ("no shut"). There must be an IP address or bridge-group configured. If it is a VLAN interface:
VLAN must be assigned to this module on the SUP. auto-state UP (auto-state is off by default). It must be primary or normal (not a private VLAN).
If it's an L2 interface, its BVI must be UP. Interface subnet change also causes interface flap.
CA Training
71
Shared VLANs
Multiple interfaces in different contexts on the same VLAN. Only L3 interfaces can be sharing a VLAN (shared VLAN configuration for L2 interfaces not permitted). All these interfaces must be on the same subnet. Different MAC addresses for the interfaces sharing the VLAN. No routing across contexts even when shared VLANs configured.
CA Training
72
System limits
8K interfaces entries total. 4K BVI entries. 1K instances of shared interfaces entries.
4 interfaces on a shared VLAN => 3 instances of shared interfaces.
CA Training
73
MAC Address Allocation

8 IDPROM MACs:
1st is used by the SUP for the 10G trunk interface towards ACE. 2nd is used as Burned in Address (BIA) for all unshared interfaces. Rest are unused.
16K MACs reserved for all ACEs modules in the world.

Split into 16 pools of 1K. The pool is identified by the shared-vlan-hostid, so 16 ACE modules per subnet. Shared VLAN MACs for an ACE module come from its 1K MACs, so 1K sharing instances per ACE module.
Shared MAC => Shared VLAN interface. Converse not TRUE. VMACs come from a pool of 1K MACs shared across all ACEs. The VMAC is a function of ft-group-id. Therefore different cards must have different ft-group-ids. Floating IPs (e.g. alias, VIP etc.) have VMACs.
CA Training
74
ARP and adjacency
75
ARP: Types of entries

Local
Interface NAT Pool VIP
External
RServer Gateway HA Peer Learned
Default refresh period for configured entries is 5 mins and for learned entries is 4 hours. This and retry timeout and number of retries configurable per context.
CA Training
76
ARP: Feature Description

Handles ARP Requests: Does interface validation of the incoming request. Requests for local addresses (e.g. VIP, NAT pool). No proxy ARP support. Sends gratuitous ARP packets at significant events such as duplicate IP detection, interface UP, switchover etc. For all the external entries resolves the IP<->MAC mapping by ARP packets and learning thru incoming ARP packets and gratuitous ARP packets. The learning in L2 mode is from request and response. The learning in L3 mode is however restricted to the case where the DMAC is myMAC.
CA Training
77
ARP: Feature Description (contd.)

Programs the encap structure in the DP for packet forwarding. Over and above conventional Objective:
Never let an unknown unicast flood of packet with user payload happen. So IP->MAC and outgoing interface to be resolved and this is where ARP comes in. Never let an ARP spoof happen which collides with a configured information (e.g. static ARP or interface subnet). L3 mode interface validation is based on subnet of incoming interface and source-IP of the request. L2 mode interface validation in the most basic form is same as above except that it is based on the BVI. More complicated validations done when static ARP is configured (later).
CA Training
78
ARP: Feature Description (contd.)

The source <IP, MAC, interface> of an incoming ARP packet is validated against any static ARP configuration. Global static ARPs and interface static ARPs (for L2 interfaces). No static ARP resolving to the BVI interface allowed. ARP bridging in L2 mode interfaces No MAC learning in the system. So ARP is the way to learn IP to MAC and interface mapping. Host move detection (slow) and ARP inspection.
CA Training
79
ARP: Exception cases

For connected network nodes, if the ARP is not already resolved, (on a packet arrival) DP would send a message to CP (ARP) to resolve the IP (to MAC mapping) and setup the encap entry. Information contained in it would be incoming interface, dest-IP, sourceIP, source-MAC, dest-MAC. Depending on whether whether the unresolved IP (to MAC mapping) is in the same subnet as the incoming interface or not, an ARP or a ping request would be used for resolving.
CA Training
80
ARP: Exception cases (contd.)

Interface IP = 1.1.1.1/24, source IP = 2.2.2.2. Dest IP = 3.3.3.3. Source MAC = aaaa.aaaa.aaaa Dest MAC = myMAC. Upstream routers encap missing and we do not know the upstream routers IP address. Do a ping with TTL=1 with source IP = 1.1.1.1, source MAC = myMAC, dest MAC = aaaa.aaaa.aaaa, dest IP = 2.2.2.2 Upstream router would give a TTL exceeded and that would cause the eventual resolution of the IP<->MAC mapping of the upstream router.
CA Training
81
ARP: Host Move

L2 mode interface feature. Move: Same (IP<->MAC) but appears on the other L2 interface of the bridge-group. For learned entries: easy. For static ARP entries, the move would have to be in the form of deletion from one L2 interface and configuring on the other. Learned entry and static entry collision is flagged and the host is not moved.
CA Training
82
ARP: ARP Inspection

L2 mode interface feature. The source <IP, MAC, interface> of an incoming ARP packet is validated against any static ARP configuration. This is regardless of the feature being turned on. If any mismatch, the packet is dropped. If matched the packet is bridged. If not found there is a knob to say whether we should flood the ARP request or not.
CA Training
83
ARP: Show commands

Show arp Show arp timeout Show arp statistics Show arp inspection Clear arp no-refresh | statistics Note: sample output in Notes section.
CA Training
84
Routing
85
Routing: Feature Description

Context global static routes. ECMP supported up to 8 paths per prefix. No metrics supported. Default gateway supported with ECMP. Recursive routes not supported. Since routes are static, attempt is made to resolve them ASAP. This is different from IOS, where a routes ARP may be resolved on packet arrival.
CA Training
86
Routing: Type of Routes Stored

Interface subnet entry Interface and related drop entries NAT entry Static route entry Connected host entry
CA Training
87
Routing Information Base, RIB

This is a purely control path structure. 2-D Array of hash tables indexed by context-id and mask. So each context has 32 hash tables. Hash key is IP address Each of the earlier mentioned entries found here with appropriate flags as indications. Searching all nodes with a given next-hop-IP-address is an exhaustive search. Entry is considered resolved when the encap-id for the entry is determined and that is when it is programmed in the DP.
CA Training
88
ECMP linkage in the RIB

All ECMP entries linked together in RIB. Only 1st element has the count; the others have 0. The flag is set in each element to indicate it is an ECMP member. The 1st element points to the ECMP chain thru ecmp_next; other elements point to the next ECMP member thru next_entry
CA Training
89
CP Packet Forwarding: ARP/ICMP/BPDU

One process handles ARP, BPDU fixup and ICMP handling.
ARP table is virtualized per Logical Interface. Each ARP table can hold up to 32K entries. Type awareness, NAT, VIP, Real, Alias etc. IP/MAC learning, bridging ARP in transparent mode, inspection. Rate control, interval control. Produces MAC rewrite table, ENCAP table.
CA Training
90
CP Packet Forwarding: ICMP
ICMP thread
Virtualized context aware. Integrated with HA state machine, no ping if standby unit Uses virtual MAC when active. Integrated with VIP state change
CA Training
91
Virtualization
92
Agenda
Virtualization Overview Resource Management Roles Domains Role-Domain based Access Control
CA Training
93
Virtualization Overview
Provides means to partition one physical unit into independently managed logical engines
Provisions resource per logical device Almost every feature subsystem is virtualized including Linux kernel
Logical devices are called virtual contexts

Each with independent resource allocation and policies.
Default context called Admin context is available initially

Customers who do not wish to use virtualization can perform all operations from within Admin context.
250 contexts + Admin context supported for first release.
CA Training
94
Virtualization: Logical view
Admin Context (Blade level control and view, provisioning) System level file, HA grouping etc. Context foo Context Blah My config DB My LIFs My FIB My Resource My file directory My users
My config DB My LIFs My FIB My Resource My file directory My users
CA Training
95
Virtualization: Logical Interface

Logical Interface, LIF: VLAN + [MAC if shared]. A set of LIFs belong to a particular context. DP FastPath parses header and packet to get the LIF info and context information from there. A similar logic takes place on the CP side. If (vlan is shared) each context is treated just like multiple PCs on a same subnet. Broadcast/Multicast are given to every possible context in CP.
CA Training
96
Admin Context
Created at the time of system initialization. Cannot be removed/changed by user. Global configurations handled in Admin context
Creation of contexts Creation of resource-classes ft-groups
Admin users defined in the Admin context have system wide privileges. Users logging over console are logged into the Admin context. Only users authenticated in Admin context can use changeto.
CA Training
97
Process Interaction on Login

Telnet/SSH + Login
Vsh (Parser) Stub Code
Radius/ Tacacs Client Local DB AAA Client
AAA Server
TNRPC / MTS
Config Manager
VACd
CA Training
98
Resource Management
By default, every context is a member of the default resource-class, with unlimited access to system resources. Resources can be guaranteed in three ways
1. No guaranteed resources but access to any available resource 2. X% of resources guaranteed, with no access to other additional resources 3. X% of resources guaranteed and access to any available resource
Minimum limit is specified as a percentage (5.00%) Maximum limit can equal the Min value or be unlimited Only one resource-class can be applied per context Maximum 100 resource-classes can be configured
CA Training
99
Resource Manager Design

SRAM Table VACd
Connections Proxy-Connections Mgmt-connections SSL-connections Connections per sec Bandwidth (bytes / sec) SSL-bandwidth (bytes / sec) Mgmt-traffic (bytes / sec) Mac-miss (pkts / sec) Xlates
Config Mgr
Sticky Regexp
ACL
Syslog
Syslog buffer Syslog rate
ACL memory
NOTE 1: Only min limits allowed for sticky resources in Phase 1 NOTE 2: No sticky resource are applied by default! They must be added manually for sticky to work!
CA Training
100
Filesystem Virtualization
root
(/mnt/cf) TN-CONFIG (70 Mb) TN-CERTKEYSTORAGE (30 Mb) TN-COREFILE (100 Mb) TN-LOGFILE (10 Mb) dir disk0: -> TN-HOME, dir core: -> TN-COREFILE, dir image: -> /mnt/cf Access to image directory allowed from Admin context only
CA Training
TN-HOME (10 Mb)
Admin Startup-config chkpt Context 1 Context 2
...
101
RBAC Overview
Roles and Domains for access control Roles: Feature privilege
User has a set of roles
Domains: A set of objects

An user belongs to a set of domains
The Role X Domain provides the final authentication for any object Users are defined in a context
User name space is unique within the context only
CA Training
102
Roles
Roles
Define actions a user can perform Maximum of 16 Roles per Context (9 are user configurable) 7 are predefined roles, and cannot be removed Each role is comprised of up to 16 rules. Default role for new user is Network-Monitor
Rules
Each rule is associated with a Feature, A Feature is a grouping of one or more CLIs. Rule number determines order in which rules are applied
Default for new roles is to deny all Features, until a Rule has been applied
CA Training
103
Role Configuration
switch/Admin(config)# role Network-Operator switch/Admin(config-role)# rule 1 permit ? create debug modify monitor Commands for creation of new objects Commands for debugging Commands for modifying existing configurations Commands for monitoring
switch/Admin(config-role)# rule 1 permit create switch/Admin(config-role)# rule 2 deny create feature interface
CA Training
104
Default Roles
Admin
Access to all functions in the context/device.
SLB-Admin
Permit create on Serverfarm, Real, VIP,Probe, Loadbalance, NAT, Interface
Security-Admin
Permit create ACL, Inspect, AAA, NAT, TCP, Interface
Server-Maintenance
Permit modify on feature Real-Inservice. Permit debug Probe, Real, VIP, Serverfarm, Loadbalance
Server-Application-Maintenance
Permit create on Probe, Real, VIP, Serverfarm, Loadbalance
Network-Admin
Permit create on Interface, Routing, NAT, VIP, TCP
Network-Monitor
Access to all show commands only
CA Training
105
Domains
Domains are used to group object within a single context to control access. Each ACE context has a default-domain, which is used if no other domain is specified. For example the admin user a member of the default-domain for the Admin context. A maximum of 10 domains can be created per context. Objects can belong to multiple domains within the context. Objects with a hierarchical relationship implicitly added to a domain. New objects created by user automatically added to user domain. Default domain for new user created in Admin context is entire device, for new user in any other context is entire context.
106
CA Training
Domain Configuration
Types of objects that can be added to a domain include Interfaces Access-lists Policy-maps Class-maps Parameter-maps Serverfarms Rservers Probes Scripts Sticky-groups.
To create a domain and add an object to it switch/Admin(config)# domain SF-domain switch/Admin(config-domain)# add-object serverfarm sf1
CA Training
107
Software Versioning
108
Software Versioning
Based on SanOS, which has a common version numbering scheme. Version number:
Major.Minor(Maint.Interim)BUidBUminor(BUmaint.BUinterim.BUrebuild)
Major = SanOS major build number. Minor = SanOS minor build number. Maint = SanOS maintenance build number. Interim = SanOS interim build number. BUid = Business unit identifier (unique per BU). BUminor = Business unit minor build number. BUmaint = Business unit maintenance build number. BU rebuild = Business unit rebuild number.
CA Training
109
Number for ACE

Version number for ACE:
3.0(0)A1(1.1) Based on SanOS release 3.0(0). BU identifier is A. ACE software version 1.1(1).
CDETS version string:

03.0(00)A01(01.07)
CA Training
110

Cisco ACE

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cisco ACE

Transféré par

Droits d'auteur :

Formats disponibles

ACE 1.

0 NPI Training Application Control Engine (ACE)

Curt Kersey Technical Leader L4-7 Security Engineering eck@cisco.com

Jay Cedrone TME ADBU jcedrone@cisco.com

2006 Cisco Systems, Inc. All rights reserved.

ACE 1.0 NPI Training Application Control Engine (ACE)

Srini Sudireddi Technical Leader L4-7 Security Engineering ssudired@cisco.com

Derek Huckaby TME ADBU dhuckaby@cisco.com

2006 Cisco Systems, Inc. All rights reserved.

2006 Cisco Systems, Inc. All rights reserved.

2006 Cisco Systems, Inc. All rights reserved.

ACE Hardware Architecture

2006 Cisco Systems, Inc. All rights reserved.

Hardware Architecture Introduction

2006 Cisco Systems, Inc. All rights reserved.

HW Architecture Module Objectives

After completing this module you will be able to:

2006 Cisco Systems, Inc. All rights reserved.

Control Plane Architecture Software Versioning

2006 Cisco Systems, Inc. All rights reserved.

2006 Cisco Systems, Inc. All rights reserved.

Application Control Engine

ACE Hardware Architecture

2x 700MHz MIPS 1 GB Memory

Daughter Card Expansion Slot

Intel IXP 2800

Classification Distribution Engine

Intel IXP 2800

SSL, IPSec Crypto

Daughter Card Expansion Slot

40K RSA ops

2006 Cisco Systems, Inc. All rights reserved.

IXP2800 Internal Architecture

2006 Cisco Systems, Inc. All rights reserved.

IXP2800 Micro Engines (ME)

2006 Cisco Systems, Inc. All rights reserved.

IXP2800 XScale Processors

ACE Integration with Supervisor720

2006 Cisco Systems, Inc. All rights reserved.

Classification Distribution Engine (CDE)

2006 Cisco Systems, Inc. All rights reserved.

2006 Cisco Systems, Inc. All rights reserved.

2006 Cisco Systems, Inc. All rights reserved.

Data Plane Architecture

2006 Cisco Systems, Inc. All rights reserved.

Dataplane Subsystems on MEs

IP Frag ICM Timers

SSL FixUps Record

2006 Cisco Systems, Inc. All rights reserved.

2006 Cisco Systems, Inc. All rights reserved.

FastPath ME: Receive Processing

2006 Cisco Systems, Inc. All rights reserved.

FastPath ME: Lookups

2006 Cisco Systems, Inc. All rights reserved.

FastPath ME: Connection Miss

2006 Cisco Systems, Inc. All rights reserved.

FastPath ME: Connection Hit

2006 Cisco Systems, Inc. All rights reserved.

FastPath ME: Transmit Processing

2006 Cisco Systems, Inc. All rights reserved.

FastPath ME: More Information

2006 Cisco Systems, Inc. All rights reserved.