As a new connection enters the ASA it is processed using the Session Management Path.

Part of the Session Management Path’s processing is to inspect and create the relevant entry in the ASA’s state/connection table, if a policies exists allowing the traffic.

Generally any further packets received for these established connections, does not require further inspection and are subsequently handled by the Fast Path. Although, there may be certain packets that would continue to use the session management path or be passed to the control plane path, such as flows requiring HTTP inspection, FTP or H.232 etc.

This is akin to Process switching and CEF switching in IOS Routers.

The Session Management Path and Fast Path combined are what make up the Accelerated Security Path.

ASP can come in handy when we want to troubleshoot traffic flows through the ASA. This is done via a suite of ASP show commands, and can also be incorporated into packet captures, using a capture type of asp-drop.

With ASP debugging we can drill down into the output to see what functions or methods are responsible for dropping the traffic on the ASA. There are two set of commands available to us, both of which have a substantial amount of optional keywords; these are, ‘show asp drop’ and show asp table’.

Starting with ‘show asp drop’ will give us a summary of packets or connections that have been denied by ASP providing an associated reason and hits on each. As we can see from the output below it is split into 2 sections; Frame Drop – which is based on packet failures; and Flow Drop – based on inspected traffic flow failures.

It gives us a brief breakdown of denies based on malformed TCP sessions, Reverse Path Forwarding violations, or simply denies based on ACL entries etc.

ASA# show asp drop
Frame drop:
Reverse-path verify failed (rpf-violated)                                 1432
Flow is denied by configured rule (acl-drop)                         100495787
First TCP packet not SYN (tcp-not-syn)                                    2234
TCP failed 3 way handshake (tcp-3whs-failed)                                20
TCP packet SEQ past window (tcp-seq-past-win)                               28
TCP replicated flow pak drop (tcp-fo-drop)                                   8
TCP RST/SYN in window (tcp-rst-syn-in-win)                                   2
TCP packet failed PAWS test (tcp-paws-fail)                                  3
Slowpath security checks failed (sp-security-failed)                         1
Expired flow (flow-expired)                                                  2
ICMP Inspect seq num not matched (inspect-icmp-seq-num-not-matched)          6
FP L2 rule drop (l2_acl)                                               7911378
Interface is down (interface-down)                                        1143
Dropped pending packets in a closed socket (np-socket-closed)               19
Last clearing: Never
Flow drop:
Inspection failure (inspect-fail)                                            2
Last clearing: Never

You can also further drill into more specific output using optional keywords, based on either frame or flow drop, such as “show asp drop frame ifc-classify” – when in virtual firewall mode shows counts for packets that failed to be classified to context; or “show asp drop flow conn-limit-exceeded” – increments when the value applied to set connection conn-max is breached.

These are just a couple of the vast amount of options available for use. Check out the ASA Command Reference document for a full listing.

A key point with the ASP drop output is when running in Multi Context Mode, the information provided is a summary for all of the virtual contexts not just the context you are currently logged into.

The other side of ASP is the “show asp table” commands. These are typically used by TAC, so contain a great deal of info on a production appliance. These tables are primarily used for debugging, so the output is prone to regular changes.

Below are the asp tables available:

ASA# show asp table ?
arp
classify    Show ASP classifier tables
interfaces  Show ASP interfaces tables
routing     Show ASP route tables
socket      Show ASP socket info

The “show asp table arp” for instance can be used to check that traffic is flowing to/from a specific host/s based on an incrementing hit count. It is important to remember that this is dynamic real time output though and will be subject to resetting.

ASA# sh asp table arp
Context: LEFT, Interface: Inside
10.1.1.66                            Active   0050.56a5.35b9 hits 15
10.1.1.65                            Active   0050.56a5.7d06 hits 0

The “show asp table routing” can give us further info into how specific nets are routed. This is provided based on two tables; an input routing table and an output routing table, each showing the routable nets and their associated interfaces.

ASA# sh asp table routing
in   	10.1.1.64   	255.255.255.192	Inside
out  	10.1.1.64   	255.255.255.192	Inside
in 	0.0.0.0		0.0.0.0			Outside
out 	0.0.0.0		0.0.0.0			via 10.1.1.254, Outside

And to finish off a quick look at the classify table. This table consists of multiple classifier domains which correspond to a specific rule action within the ASA, I.e. Inspection rules, filtering rules nat rules etc. Again check out the command reference for a list of the options.

Below is an example showing SMTP traffic is being inspected and allowed to the inside interface:

ASA# sh asp table classify domain inspect-smtp
Interface Inside:
in  id=0x1d43bbf0, priority=70, domain=inspect-smtp, deny=false
hits=89, user_data=0x1d1a18f0, cs_id=0x0, use_real_addr, flags=0x0, protocol=6
src ip=0.0.0.0, mask=0.0.0.0, port=0
dst ip=0.0.0.0, mask=0.0.0.0, port=25, dscp=0x0

The documentation for ASP is minimal, the best way forward with this is get your head into the output and retain what you feel is useful.

So the next time your caught in a troubleshooting exercise check out the ASP output and see whether combining this with your debug, captures and logs, can assist in resolving your issues!!

–
Stuart Hare
CCIE #25616 (Security), CCSP, Microsoft MCP
Sr. Support Engineer – IPexpert, Inc.
URL: http://www.ipexpert.com

Print Friendly

The ASA’s Local CA Server provides the appliance with a basic level of Certificate provisioning functionality. The primary use for the Local CA is to provide registered users the ability to enroll for certificates, which can then be used with features such as WebVPN.

Some of the available features of the Local CA are as follows:

• Issuing of Certificates for enrolled users
• Secure certificate revocation
• Browser based enrollment
• SSL VPN Support
• Local database and external filesystem support
• Support for both CLI and ASDM configuration

As usual there are also some restrictions related to the Local CA:

• Support for Root CA mode only, no Subordinate or RA modes available.
• Not supported when Active/Active Failover mode is in use
• Not supported when VPN load balancing is in use
• The ASA can only contain a single Local CA instance at any one time.

In truth the Local CA is pretty basic and easy to configure, but before we look at the config lets define some of the core components:

• The Default Local CA Server – minimal configuration is required to create a CA Server instance which utilizes of a number of default parameters.
• CRL – Certificate Revocation List – a distributed update list containing details for revoked or un-revoked certificates.
• CDP – The CRL Distribution Point – typically the URL for the local or remote copy of the CRL.
• CA Database Storage – information regarding certificates, users, CRL’s etc. are held in this database, which can utilize both local flash storage and remote CIFS or FTP external storage.

OK so lets delve into the basic setup of the Local CA. As stated above it has a number of predefined default settings, that allows us to quickly enable the CA. This can be carried out in 4 easy steps:

1. Enter CA server config mode
2. Specify a valid ‘from email address’ used by the ca server to send emails to users that contain one time passwords for enrollment.
3. Define a default DN to be included in issued certificates.
4. Enable the CA server.

The minimum config we need is as follows:

crypto ca server
smtp from-address <email.address>
  subject-name-default <distinguished.name>
  no shutdown

Upon enabling the CA server, a passphrase will be requested to protect the CA’s private key, and a Certificate and key pair will be generated.

By default this setup provides us with the following configuration:

• 1024 bit modulus for our keys and certificates;
• A CDP URL of: http://hostname.domain/+CSCOCA+/asa_ca.crl;
• And an issuer-name of: cn=FQDN
• Default storage is local flash memory
• (Full default values are listed in the ASA Config guide, under the Local CA table 41-1)

Its key to note that the once the CA server has been enabled with the no shutdown command, the values for the ‘issuer-name’ and ‘keysize server’ commands cannot be changed.

You need to completely remove and recreate the CA server config to amend these values prior to enabling the server.  You will be warned during the process.

Removal of the CA can be done using the ‘clear config crypto ca server’ command.

Example:

LocalCA#conf t
LocalCA(config)#crypto ca server
LocalCA(config-ca-server)#smtp from-address ipxca@ipexpert.com
LocalCA(config-ca-server)#subject-name-default cn=ipxca, o=ipexpert, c=US
LocalCA(config-ca-server)#no shutdown
% Some server settings cannot be changed after CA certificate generation.
% Please enter a passphrase to protect the private key
% or press return to exit
Passphrase: ********
Re-enter passphrase: ********
Keypair generation process begin. Please wait...
Completed generation of the certificate and keypair...
Archiving certificate and keypair to storage... Complete
INFO:
Certificate Server enabled.

We can quickly see the status of the CA using the following:

LocalCA#show crypto ca server
Certificate Server LOCAL-CA-SERVER:
Status: enabled
State: enabled
Server's configuration is locked  (enter "shutdown" to unlock it)
Issuer name: CN=LocalCA.ipexpert.com
CA certificate fingerprint/thumbprint: (MD5)
1b934fa8 dbe60db9 6c77f919 dd692935
CA certificate fingerprint/thumbprint: (SHA1)
354ced13 7e4fe4a8 06920a8a 4624b524 daf56a9f
Last certificate issued serial number: 0x1
CA certificate expiration timer: 17:57:26 UTC Mar 17 2013
CRL NextUpdate timer: 23:57:26 UTC Mar 18 2010
Current primary storage dir: flash:/LOCAL-CA-SERVER/
Auto-Rollover configured, overlap period 30 days
Autorollover timer: 17:57:25 UTC Feb 15 2013

Notice that the Status and State are both enabled, the server configuration is locked while enabled, and that the Issuer name has defaulted to the Fully qualified domain name of the ASA as expected. Checking our keys also proves the default 1024bit key size has been used.

LocalCA# show crypto key mypubkey rsa
Key pair was generated at: 17:57:26 UTC Mar 18 2010
Key name: LOCAL-CA-SERVER
Usage: General Purpose Key
Modulus Size (bits): 1024
Key Data:
30819f30 0d06092a 864886f7 0d010101 05000381 8d003081 89028181 00968a49
9a082f87 d6243001 0652a2a3 974265ce 20168adf aca83ead 1a8588a2 48112537
5cd2b3c2 bc2e0e12 3a250852 a31400e2 0e5da985 87e4324c 1d7ad4c3 19eb286f
31896f71 19a8e8f6 6ac56aa5 466438fe 599b7046 41548bee 0a91ad45 cb4ad283
52188306 f082cc14 ba42219d b051aeeb c69cbbc9 df17c5eb 0f1c07e5 ed020301 0001

And confirmation that our CA files have been stored in flash:

LocalCA# sh flash: | i CA
103  8192        Mar 18 2010 17:57:27  LOCAL-CA-SERVER
106  32            Mar 18 2010 17:57:26  LOCAL-CA-SERVER/LOCAL-CA-SERVER.ser
107  114          Mar 18 2010 17:57:26  LOCAL-CA-SERVER/LOCAL-CA-SERVER.cdb
108  0              Mar 18 2010 17:57:26  LOCAL-CA-SERVER/LOCAL-CA-SERVER.udb
110  230          Mar 18 2010 17:57:26  LOCAL-CA-SERVER/LOCAL-CA-SERVER.crl
111  1595        Mar 18 2010 17:57:27  LOCAL-CA-SERVER/LOCAL-CA-SERVER.p12

Before we can enroll though we have a few more tasks that need to be completed; first off is to enable the WebVPN component; and then add a user that will be registered and authorized for enrollment. Enter WebVPN config mode and enable it on the inside interface.

LocalCA(config)# webvpn
LocalCA(config-webvpn)# enable inside
INFO: WebVPN and DTLS are enabled on 'inside'.
LocalCA(config-webvpn)# exit
Next step is to register a new user on the ASA and authorize it to enroll with the CA Server:
LocalCA(config)# crypto ca server user-db add ipxuser
LocalCA(config)# crypto ca server user-db allow ipxuser display-otp
Username: ipxuser
OTP: 8A87D45D637E3E45
Enrollment Allowed Until: 20:32:57 UTC Sun Mar 21 2010

By issuing the display-otp keyword we have chosen to have the one time password dumped to the screen instead of via email delivery. Now we need to enroll with the CA which is easily done using a web browser to access the enrollment page, ‘https://hostname/+CSCOCA+/enroll.html’.

Enter the username and One Time Password in the login fields provided.  This then triggers the certificate download.

Open and install the certificate into the store. Once completed verify that the certificate is installed via the internet options panel in your browser.

Going back to the ASA we can now check to see if the user status has changed to enrolled:

LocalCA# sh crypto ca server user-db
username: ipxuser
email:    ipxuser@ipexpert.com
dn:       <None>
allowed:  20:32:57 UTC Sun Mar 21 2010
notified: 1 times
enrollment status: Enrolled, Certificate valid until 20:38:58 UTC Fri Mar 18 2011,
Renewal: Allowed

Excellent so we have now enrolled with the Local CA and installed our certificate, but now what!

Lets give it a test. Nice easy way to do this is to enable certificate authentication on the ASA’s WebVPN, which will allow us to login using the certificate instead of a username and password.

Using the default webvpn tunnel group we need to change the authentication type to certificate:

LocalCA(config)# tunnel-group DefaultWEBVPNGroup webvpn-attributes
LocalCA(config-tunnel-webvpn)# authentication certificate
LocalCA(config-tunnel-webvpn)# exit

Now try and logon to the WebVPN: https://hostname/

Highlight your installed certificate in the Choose Digital Certificate window and click ok. You should then be directed to the WebVPN homepage.

There you have it a successful login to WebVPN using user based certificates and the Local CA.

Further confirmation of successful certificate login can be seen by simply enabling debug level logging to the buffer.

LocalCA(config)# sh log
Syslog logging: enabled
Facility: 20
Timestamp logging: disabled
Standby logging: disabled
Debug-trace logging: disabled
Console logging: disabled
Monitor logging: disabled
Buffer logging: level debugging, 1961 messages logged
Trap logging: disabled
History logging: disabled
Device ID: disabled
Mail logging: disabled
ASDM logging: disabled
%ASA-7-725012: Device chooses cipher : RC4-SHA for the SSL session with client inside:10.4.4.100/1311
%ASA-7-717025: Validating certificate chain containing 1 certificate(s).
%ASA-7-717029: Identified client certificate within certificate chain. serial number: 03, subject name: cn=ipxuser,cn=ipxca,o=ipexpert,c=US.
%ASA-7-717030: Found a suitable trustpoint LOCAL-CA-SERVER to validate certificate.
%ASA-6-717022: Certificate was successfully validated. serial number: 03, subject name:  cn=ipxuser,cn=ipxca,o=ipexpert,c=US.
%ASA-6-717028: Certificate chain was successfully validated with warning, revocation status was not checked.
%ASA-6-725002: Device completed SSL handshake with client inside:10.4.4.100/1311
%ASA-6-113009: AAA retrieved default group policy (DfltGrpPolicy) for user = ipxca
%ASA-6-716038: Group <DfltGrpPolicy> User <ipxca> IP <10.4.4.100> Authentication: successful, Session Type: WebVPN.
%ASA-7-734003: DAP: User ipxca, Addr 10.4.4.100: Session Attribute aaa.cisco.grouppolicy = DfltGrpPolicy
%ASA-7-734003: DAP: User ipxca, Addr 10.4.4.100: Session Attribute aaa.cisco.username = ipxca
%ASA-7-734003: DAP: User ipxca, Addr 10.4.4.100: Session Attribute aaa.cisco.tunnelgroup = DefaultWEBVPNGroup
%ASA-6-734001: DAP: User ipxca, Addr 10.4.4.100, Connection Clientless: The following DAP records were selected for this connection: DfltAccessPolicy
%ASA-6-716001: Group <DfltGrpPolicy> User <ipxca> IP <10.4.4.100> WebVPN session started.
%ASA-6-302013: Built inbound TCP connection 129 for inside:10.4.4.100/1312 (10.4.4.100/1312) to identity:10.4.4.10/443 (10.4.4.10/443)
%ASA-6-725001: Starting SSL handshake with client inside:10.4.4.100/1312 for TLSv1 session.
%ASA-6-725003: SSL client inside:10.4.4.100/1312 request to resume previous session.
%ASA-6-725002: Device completed SSL handshake with client inside:10.4.4.100/1312
%ASA-6-716002: Group <DfltGrpPolicy> User <ipxca> IP <10.4.4.100> WebVPN session terminated: Idle Timeout.
%ASA-4-113019: Group = DefaultWEBVPNGroup, Username = ipxca, IP = 10.4.4.100, Session disconnected. Session Type: SSL, Duration: 0h:34m:52s, Bytes xmt: 145676, Bytes rcv: 30042, Reason: Idle Timeout

Check out the ASA configuration guide under ‘Configuring Certificates’ for Version 8.0 and above, if you want to delve into more of the customizable features available to the ASA’s Local CA.

http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/cert_cfg.html#wp1067484

–
Stuart Hare
CCIE #25616 (Security), CCSP, Microsoft MCP
Sr. Support Engineer – IPexpert, Inc.
URL: http://www.ipexpert.com

Print Friendly

DMVPN provides the ability for large scale VPN’s, in a Hub and Spoke topology, while using a simplified Dynamic deployment model for the spokes. This is due to the reduced configuration required on the Hub device.

DMVPN combines the use of four key technologies; IPSec, Generic Routing Encapsulation (GRE) Tunnels, Next Hop Resolution Protocol (NHRP) and a Dynamic Routing Protocol (OSPF, EIGRP etc.). In DMVPN we need to look to the NHRP protocol to provide us with a method of implementing Per Tunnel QoS; this feature is called NHRP Groups.

We should start to see a pattern emerging here; Tunnel Groups on the ASA; QoS Groups for IOS VPN; and now NHRP Groups for DMVPN! All of which, we use as classifiers for our QoS policies.

NHRP groups are configured on the Spokes GRE tunnel interfaces, and acts to identify each tunnel to the Hub device. The NHRP group is passed to the Hub during the NHRP registration process, which is sent from Spoke to Hub. Static mappings are applied to each spoke so they can identify where to initiaite their registration to. This is the key to the operation of DMVPN as a whole, as its responsible for dynamically updating the Hubs NHRP tables with the registering spokes information. This spoke info allows the establishment of the IPSec SA’s in both directions.

Assuming that the DMVPN configuration is already in place, several requirements/restrictions exist for NHRP groups:

• CEF must be enabled to use NHRP Groups

• You can only use 1 NHRP Group Per DMVPN Tunnel Interface

• If multiple tunnel interfaces exist on the spoke then seperate groups names can be used on each interface.

The slight difference we have over the previous examples for VPN QoS, is although the groups are defined on the spoke router, the policy is defined and applied on the Hub.

The Spoke side configuration is pretty simple, all we need to do is enter tunnel interface config mode and apply the group to the GRE Interface, so for example set an NHRP group of SpokeGrp1 to the interface for Tunnel1:

interface Tunnel 1
 ip nhrp group SpokeGrp1

Simple huh! The bulk of the configuration is actually done on the Hub router, so all were doing here is tagging the tunnel with an ID. Now for the Hub.

In comparison to our previous examples the NHRP group is not matched within the Class Map, instead we use an NHRP Map command to associate the group to a defined QoS policy. This leaves us the flexibility to match on specific traffic in our class maps.

For example on the Hub GRE interface map the group to a policy:

Interface Tunnel 1
 ip nhrp map group SpokeGrp1 service-policy output SpokeGrp1_QoS

Ok lets move on to an example scenario.

Above we have a simple Hub and two spoke DMVPN setup. The tunnel for R4 Spoke 1 will be tagged with the NHRP Group of WEST, and R5 Spoke 2 will be tagged as EAST.

QoS policies will be defined on the Hub router using the following:

• R4’s WEST group requires to be shaped to 1Mb

• R5’s EAST group requires a nested policy for the following:

• Prioritise critical application traffic marked as DSCP AF43 to 512k

• Shape all traffic to 1mb

Configuration:

So starting with the Spokes we need to assign the NHRP groups:

R4:

Interface Tunnel 1
 ip nhrp group WEST

R5:

Interface Tunnel 1
 ip nhrp group EAST

Then we move to the Hub router to define the QoS policies and associate them to each group:

R2:

class-map match-all PRIORITY
 match ip dscp af43
!
policy-map PRIORITY_QOS
 class PRIORITY
 priority 512
!
policy-map WEST_QOS
 class class-default
 shape average 1000000
!
policy-map EAST_QOS
 class class-default
 shape average 1000000
 service-policy PRIORITY_QOS
!
interface Tunnel1
 ip nhrp map group EAST service-policy output EAST_QOS
 ip nhrp map group WEST service-policy output WEST_QOS

There you have it, the configuration for the above requirements. Class defaults are used to match on any traffic flow. The small addition here is the inclusion of the hierarchical nested policy. This is made up of two separate policies, a Child policy (PRIORITY_QOS) that is in turn applied to the Parent policy (EAST_QOS). The Parent / Child relationship allows a more granular approach, by providing the ability to assign different actions to both Parent and Child, based on the traffic flows defined with their respective classes.

A nice plus point to this method is that the QoS is applied on the arrival of the next packet without the need to restart the IPSec SA’s.

Verification:

Now we have the config in place next step is to verify it. Verification should be done on the Hub Router. Show DMVPN Detail is a good place to start. Here we can see the peer information, the group mapping and the applied service policies.

R2_Hub#show dmvpn detail
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding
UpDn Time --> Up or Down Time for a Tunnel
===================================================================

Intferface Tunnel1 is up/up, Addr. is 10.1.245.2, VRF ""
Tunnel Src./Dest. addr: 192.1.2.2/MGRE, Tunnel VRF ""
Protocol/Transport: "multi-GRE/IP", Protect "DMP"
Type:Hub, Total NBMA Peers (v4/v6): 2

# Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb    Target Network
----- --------------- --------------- ----- -------- ----- -----------------
1      192.1.2.4      10.1.245.4    UP 01:15:20    D      10.1.245.4/32
NHRP group: WEST
Output QoS service-policy applied: WEST_QOS

1      192.1.2.5      10.1.245.5    UP 01:15:31    D      10.1.245.5/32
NHRP group: EAST
Output QoS service-policy applied: EAST_QOS

Or alternatively, show ip nhrp group-map provides the more specific information:

R2_Hub#show ip nhrp group-map
Interface: Tunnel1
NHRP group: EAST
QoS policy: EAST_QOS
Tunnels using the QoS policy:
Tunnel destination overlay/transport address
10.1.245.5/192.1.2.5

NHRP group: WEST
QoS policy: WEST_QOS
Tunnels using the QoS policy:
Tunnel destination overlay/transport address
10.1.245.4/192.1.2.4

Final piece of verification is to check that the policy is in effect.

Use the show policy-map multipoint to confirm this:

R2_Hub#show policy-map multipoint

Interface Tunnel1 <--> 192.1.2.4

Service-policy output: WEST_QOS

Class-map: class-default (match-any)
4630 packets, 5171238 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Queueing
queue limit 250 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
shape (average) cir 1000000, bc 4000, be 4000
target shape rate 1000000

Interface Tunnel1 <--> 192.1.2.5

Service-policy output: EAST_QOS

Class-map: class-default (match-any)
4979 packets, 1989296 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Queueing
queue limit 250 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
shape (average) cir 1000000, bc 4000, be 4000
target shape rate 1000000

Service-policy : PRIORITY_QOS

queue stats for all priority classes:

queue limit 128 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0

Class-map: PRIORITY (match-all)
1000 packets, 124000 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp af43 (38)
Priority: 512 kbps, burst bytes 12800, b/w exceed drops: 0

Class-map: class-default (match-any)
255 packets, 22278 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any

queue limit 122 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
R2_Hub#

For reference, Ive included the core configs for each router below.

R2_Hub#
!
hostname R2_Hub
!
crypto isakmp policy 10
 encr aes
 authentication pre-share
 group 5
 crypto isakmp key cisco address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set TS esp-aes esp-sha-hmac
!
crypto ipsec profile DMP
 set transform-set TS
!
class-map match-all PRIORITY
 match ip dscp af43
!
policy-map PRIORITY_QOS
 class PRIORITY
 priority 512
 class class-default
policy-map WEST_QOS
 class class-default
 shape average 1000000
policy-map EAST_QOS
 class class-default
 shape average 1000000
 service-policy PRIORITY_QOS
!
interface Tunnel1
 ip address 10.1.245.2 255.255.255.0
 no ip redirects
 ip mtu 1400
 no ip next-hop-self eigrp 1
 ip nhrp authentication cisco
 ip nhrp map multicast dynamic
 ip nhrp map group EAST service-policy output EAST_QOS
 ip nhrp map group WEST service-policy output WEST_QOS
 ip nhrp network-id 245
 ip nhrp holdtime 300
 ip tcp adjust-mss 1360
 no ip split-horizon eigrp 1
 tunnel source FastEthernet1/1
 tunnel mode gre multipoint
 tunnel protection ipsec profile DMP
!
interface FastEthernet1/0
 no switchport
 ip address 10.1.2.2 255.255.255.0
!
interface FastEthernet1/1
 no switchport
 ip address 192.1.2.2 255.255.255.0
!
router eigrp 1
 network 10.1.2.0 0.0.0.255
 network 10.1.245.0 0.0.0.255
 no auto-summary
!

R4_Spoke1#
!
crypto isakmp policy 10
 encr aes
 authentication pre-share
 group 5
 crypto isakmp key cisco address 0.0.0.0 0.0.0.0
!
crypto ipsec transform-set TS esp-aes esp-sha-hmac
!
crypto ipsec profile DMP
 set transform-set TS
!
interface Tunnel1
 bandwidth 1000
 ip address 10.1.245.4 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication cisco
 ip nhrp group WEST
 ip nhrp map multicast 192.1.2.2
 ip nhrp map 10.1.245.2 192.1.2.2
 ip nhrp network-id 245
 ip nhrp holdtime 300
 ip nhrp nhs 10.1.245.2
 ip tcp adjust-mss 1360
 tunnel source FastEthernet0/1
 tunnel mode gre multipoint
 tunnel protection ipsec profile DMP
!
interface FastEthernet0/0
 ip address 10.1.4.4 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet0/1
 ip address 192.1.2.4 255.255.255.0
 duplex auto
 speed auto
!
router eigrp 1
 network 10.1.4.0 0.0.0.255
 network 10.1.245.0 0.0.0.255
 no auto-summary
!

R5_spoke2#
!
crypto isakmp policy 10
encr aes
authentication pre-share
group 5
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set TS esp-aes esp-sha-hmac
!
crypto ipsec profile DMP
set transform-set TS
!
interface Tunnel1
bandwidth 1000
ip address 10.1.245.5 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication cisco
ip nhrp group EAST
ip nhrp map multicast 192.1.2.2
ip nhrp map 10.1.245.2 192.1.2.2
ip nhrp network-id 245
ip nhrp holdtime 300
ip nhrp nhs 10.1.245.2
ip tcp adjust-mss 1360
tunnel source FastEthernet0/1
tunnel mode gre multipoint
tunnel protection ipsec profile DMP
!
interface FastEthernet0/0
ip address 10.1.5.5 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 192.1.2.5 255.255.255.0
duplex auto
speed auto
!
router eigrp 1
network 10.1.5.0 0.0.0.255
network 10.1.245.0 0.0.0.255
no auto-summary
!
end

Hopefully these three Techtorials have provided some insight into the ways we can incorporate common Quality of Service methods into our VPN deployments, and ultimately bolster the knowledge required for success in your future lab attempts. See ya soon with some more posts :-)

Stu…

Regards,

Stuart Hare

CCIE #25616 (Security), CCSP, Microsoft MCP

Sr. Support Engineer – IPexpert, Inc.

URL: http://www.IPexpert.com

Print Friendly

The similarities appear when we look into the methods of configuration, both use Classes, Polices and Service-policies to define and apply the required methods of QoS.

The big difference is that we have far more granularity in terms of the match criteria within the Classes, and the Set / Action criteria we can apply in these Policies. Not only can we control the traffic flow, we can also mark the traffic to a specific DSCP or IP Precedence value, so it can be controlled in another part of the network.

There are too many methods to list here so check out the following QoS documentation for a detailed list of supported match and action criteria:

http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/qos_mqc.html#wp1043620

When it comes to QoS and IPSec in IOS we have a nice feature called qos-groups.

Qos-groups allow us to tag IPSec flows with a group id or number, which we can use as match criteria in a class map, to differentiate between multiple tunnels (similar to the match tunnel-group on the ASA).

To use qos-groups we also need to utilize another VPN feature, the ISAKMP profile.

The ISAKMP Profile provides us with the ability, to uniquely identify, different flows of VPN traffic, using its own version of match statements. Match statements here typically match on identities using peer IP addresses, hostnames, or even groups as used in EZVPN.

They can be used to set IKE Phase 1.5 (XAUTH) parameters, such as client configs, authentication and authorization lists, and also CA Trustpoint’s and VRF’s etc.

Note that qos groups cannot be used currently without the ISAKMP profile.

Ok so lets see how we combine these two features for our QoS configuration.

First off we need to create an ISAKMP profile, and define the match type. Then from within the profile we set the qos group tag or id.

Valid values for the qos-group number are 1 – 1023.

crypto isakmp profile <profile name>

match identity address <ip address>

qos-group <number>

What we are actually doing here is very much like QoS marking, if this is matched then mark with this. So effectively if the VPNs peer IP address is X, then set the qos group for this VPN to Y. Now we have the basic ISAKMP profile defined and the qos-group set, we then need to look at how we manipulate this.

Thinking back to part 1, what we needed to do next was to identify our interesting traffic using Class Maps. And this is where we will look to use our qos group as part of the match criteria.

class-map match-all <class_name>

match qos-group <number>

Then we are back in the land of policies and service polices, where we call our classes and apply our required QoS methods.

Lets look at a scenario to tie this all together.

Here we have a basic Head Office, Branch Office environment with support for Remote Access VPN. R1 is our Hub device and is terminating both a Site to Site VPN for the Branch to R2, and Remote Access VPN for remote users using EZVPN.

As we used both Policing and LLQ/Priority Queueing for the ASA example in Part 1, we will look at utilizing two different methods here. Traffic Shaping will be used for the Branch Office, while the RAS VPN will be dedicated a percentage of the available interface bandwidth.

Assuming the VPN’s have an existing setup, and that we are applying our QoS to R1, lets first look at the config for the Branch office. Recapping, we need to first create our ISAKMP profile, define the match for the peer IP address of R2, and set the qos-group, which we will assign the value of 1. One extra step is that we will also use a Crypto keyring for the pre shared key.

crypto keyring Branch

pre-shared-key address 192.1.2.2 key cisco

crypto isakmp profile Branch

keyring Branch

match identity address 192.1.2.2 255.255.255.255

qos-group 1

crypto map CM 10 ipsec-isakmp

set isakmp-profile Branch

If we now reestablish the VPN to R2 we should see that IPSec SA now has the qos-group assigned to it:

R1#show crypto ipsec sa

interface: FastEthernet0/1

Crypto map tag: CM, local addr 192.1.2.1

protected vrf: (none)

local  ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (192.1.1.0/255.255.255.0/0/0)

current_peer 192.1.2.2 port 500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 134, #pkts encrypt: 134, #pkts digest: 134

#pkts decaps: 134, #pkts decrypt: 134, #pkts verify: 134

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 1, #recv errors 0

qos group is set to 1

Next step is to define our QoS policy and assign it. Remembering our three main steps, we need to use the class map to classify our interesting traffic, create a policy map to assign our QoS method and the Service Policy to apply the policy to an interface.

class-map match-all Branch_QoS

match qos-group 1

policy-map VPN_QoS

class Branch_QoS

shape average 8000

interface FastEthernet0/1

ip address 192.1.2.1 255.255.255.0

crypto map CM

service-policy output VPN_QoS

So in a nutshell the above configuration is taking any VPN traffic marked with qos group 1, and applying traffic shaping to an average rate of 8kbps.

Note that when we apply the service policy to an interface to enable the QoS features, we need to ensure that it is assigned to the same interface that your crypto map is assigned to. Also note that QoS groups can only be applied to outbound service policies.

Moving on to the Remote Access clients, we pretty much follow the same procedure as we did for the branch office VPN. Main difference here is the match criteria for the ISAKMP profile. As the peer addresses of the clients can change regularly, we cant match on the peers IP address. But as we are using EZVPN we can match on its group name. For the RAS VPN we are using qos group 4.

crypto isakmp profile RAS

match identity group RASGrp

qos-group 4

crypto dynamic-map RASDM 20

set isakmp-profile RAS

class-map match-all RAS

match qos-group 4

policy-map VPN_QoS

class RAS

bandwidth percent 1

For the RAS VPNs the ISAKMP profile is applied to the existing dynamic crypto map, and the QoS method applies a set percentage of interface bandwidth (1%) for the VPN traffic.

The amount of actual bandwidth that gets assigned, will vary based on the interface and the hardware used. Once we have a RAS VPN established we can check the IPSec SA’s once more, to verify they are up and that the qos group has been set correctly:

R1#show crypto ipsec sa

interface: FastEthernet0/1

Crypto map tag: CM, local addr 192.1.2.1

protected vrf: (none)

local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

remote ident (addr/mask/prot/port): (10.4.4.7/255.255.255.255/0/0)

current_peer 192.1.2.100 port 1326

PERMIT, flags={}

#pkts encaps: 327095, #pkts encrypt: 327095, #pkts digest: 327095

#pkts decaps: 196642, #pkts decrypt: 196642, #pkts verify: 196642

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 0, #recv errors 0

qos group is set to 4

The final step we need to take is to generate some traffic to verify that our traffic is being classified correctly, matched on and ultimately have our QoS features applied to the traffic flows. Firing some large ICMP traffic between HostA and HostB, and, HostA and RAS Client will suffice for this test.

R1#show policy-map interface f0/1

FastEthernet0/1

Service-policy output: VPN_QoS

Class-map: Branch_QoS (match-all)

304 packets, 242280 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: qos-group 1

Traffic Shaping

Target/Average   Byte   Sustain   Excess    Interval  Increment

Rate           Limit  bits/int  bits/int  (ms)      (bytes)

8000/8000      2000   8000      8000      1000      1000

Adapt  Queue     Packets   Bytes     Packets    Bytes      Shaping

Active  Depth                         	      Delayed   Delayed   Active

-      		1         239       229090    202          215964    yes

Class-map: RAS (match-all)

314399 packets, 257760858 bytes

5 minute offered rate 2551000 bps, drop rate 0 bps

Match: qos-group 4

Queueing

Output Queue: Conversation 265

Bandwidth 1 (%)

Bandwidth 1000 (kbps)Max Threshold 64 (packets)

(pkts matched/bytes matched) 4/3352

(depth/total drops/no-buffer drops) 0/0/0

Class-map: class-default (match-any)

1624 packets, 181439 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any

R1#

From the policy-map output above, starting with the Branch Class, we see that 304 packets have been successfully matched for qos group 1, the traffic is being actively shaped to 8k, with packets being queued as the token bucket fills.

With the RAS class output, we needed to generate quite a bit more traffic as you can see. Again the successful matches are occurring based on qos group 4. And similar to shaping we see that by using the bandwidth method, we are also assigned a queue. The bandwidth queue comes into play as the bandwidth percentage is exceeded. Packets are placed into the queue, and are transmitted as and when it becomes available. This queue also has a threshold limit, and if this is exceeded then further packets will be dropped.

Looking at the pkts matched/bytes matched counter we see that 4 pkts and 3352 bytes were placed in to the queue, with no packets being dropped. Happy days :)

Just for completeness see R1’s configuration below.

Hopefully this post has provided some insight into how the simple use of QoS groups can be integrated to assist us in applying different QoS features to IOS VPN’s.

R1#sh run

Building configuration...

Current configuration : 2414 bytes

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname R1

!

boot-start-marker

warm-reboot

boot-end-marker

!

aaa new-model

!

aaa authentication login XAUTH local

aaa authorization network XAUTH local

!

aaa session-id common

memory-size iomem 15

!

dot11 syslog

!

ip cef

!

multilink bundle-name authenticated

!

voice-card 0

no dspfarm

!

vtp domain ipexpert

vtp mode transparent

username vpnuser password 0 cisco

!

crypto keyring Branch

pre-shared-key address 192.1.2.2 key cisco

!

crypto isakmp policy 10

encr aes

authentication pre-share

group 5

!

crypto isakmp policy 20

encr aes

authentication pre-share

group 2

crypto isakmp key cisco address 192.1.2.2

!

crypto isakmp client configuration group RASGrp

key cisco

pool RASPOOL

acl 100

save-password

netmask 255.255.255.0

!

crypto isakmp profile Branch

keyring Branch

match identity address 192.1.2.2 255.255.255.255

qos-group 1

!

crypto isakmp profile RAS

match identity group RASGrp

client authentication list XAUTH

isakmp authorization list XAUTH

client configuration address respond

qos-group 4

!

crypto ipsec transform-set TS esp-aes esp-sha-hmac

!

crypto dynamic-map RASDM 20

set transform-set TS

set isakmp-profile RAS

reverse-route

!

crypto map CM 10 ipsec-isakmp

set peer 192.1.2.2

set transform-set TS

set isakmp-profile Branch

match address VPN

crypto map CM 20 ipsec-isakmp dynamic RASDM

!

archive

log config

hidekeys

!

class-map match-all Branch_QoS

match qos-group 1

!

class-map match-all RAS

match qos-group 4

!

policy-map VPN_QoS

class Branch_QoS

shape average 8000

class RAS

bandwidth percent 1

!

interface FastEthernet0/0

ip address 10.1.1.1 255.255.255.0

duplex auto

speed auto

!

interface FastEthernet0/1

ip address 192.1.2.1 255.255.255.0

duplex auto

speed auto

crypto map CM

service-policy output VPN_QoS

!

ip local pool RASPOOL 10.4.4.0 10.4.4.10

ip forward-protocol nd

ip route 192.1.1.0 255.255.255.0 192.1.2.2

!

no ip http server

no ip http secure-server

!

ip access-list extended VPN

permit ip 10.1.1.0 0.0.0.255 192.1.1.0 0.0.0.255

!

access-list 100 permit ip 10.1.1.0 0.0.0.255 any

!

control-plane

!

line con 0

exec-timeout 0 0

line aux 0

line vty 0 4

!

scheduler allocate 20000 1000

!

end

R1#

Stuart Hare

CCIE #25616 (Security), CCSP, Microsoft MCP

Sr. Support Engineer – IPexpert, Inc.

URL: http://www.IPexpert.com

Print Friendly

Part 1 will concentrate on the VPN QoS for the ASA firewall, with Part 2 covering VPN QoS for IOS routers. So lets start by diving straight into the ASA.  Firstly, lets take a quick look at what Quality of Service features are available for the ASA:

Priority or Low Latency Queueing – This is the primary method used when dealing with traffic flows that do not react well to network latency, such as voice and video etc. Traffic in the Priority queue will be processed and transmitted ahead of all other traffic.

Policing – Uses a token bucket to limit the flow of traffic to the specified rate. If there are not enough tokens in the bucket, any further packets arriving are discarded.

Shaping – Uses a token bucket and data buffer to queue traffic so it can be transmitted at a specified rate, within the timing interval. Unlike Policing if the token bucket is full then the packets must wait in the queue until there is sufficient space to continue transmission.

Now we know whats available lets take a look at how to implement it for our VPN’s.

Well I guess we can go about looking at this in two different ways:

VPN traffic flowing through the ASA

OR

VPNs terminating on the ASA

Lets begin with VPN traffic through the ASA.

The above image shows a basic setup of two remote networks, separated by an ASA Firewall. In this instance imagine we have a LAN to LAN VPN terminating between routers R1 and R2. With ISAKMP & IPSEC traffic being permitted bidirectionally on the ASA.

The first step we have with any QoS deployment is to identify and classify the traffic we want to control. So with VPN traffic passing through the ASA, we potentially see three different protocols commonly in use.

ISAKMP – UDP 500

ESP – Protocol 50

NAT-T - UDP 4500

So that’s our interesting traffic identified, now we have to classify it. On the ASA, QoS is part of the Modular Policy Framework or MPF for short. In MPF we use class maps to classify the traffic we want to match against. Within the class map we have different criteria available for us to match on, for this scenario we will use an ACL which will permit any VPN traffic to be matched.

access-list VPNQOS permit udp any any eq 500
access-list VPNQOS permit esp any any
access-list VPNQOS permit udp any any eq 4500
class-map VPNQOS_CM
 description “Match ACL classifying any vpn traffic”
 match access-list VPNQOS

The next stage after classification is to apply an action to this traffic via the use of a policy map. In the policy map we will first call the previously configured class map and from the class sub-configuration mode we apply our desired method of QoS. For this instance we will police the outbound VPN traffic to a conform rate of 1Mb with a burst capacity of 37.5Kb

policy-map VPNQOS_PM
class VPNQOS_CM
police output 1000000 37500

The final stage is to enable the policy. This is done by assigning the policy map to either an interface or to the global plane. As there is a global policy map by default (policy-map global_policy), if we wanted to enable this globally we could have called the class VPNQOS_CM within the global policy instead, this would enable the VPN QoS on all available interfaces. Instead we are going to assign it to the outside interface of the ASA, this is done using the following:

service-policy VPNQOS_PM interface outside

To verify your configuration and statistics for policing use the following show command:

show service-policy police

asa# show service-policy police
Interface outside:
Service-policy: VPNQOS_PM
Class-map: VPNQOS_CM
Output police Interface outside:
cir 1000000 bps, bc 37500 bytes
conformed 2462 packets, 2005204 bytes; actions:  drop
exceeded 53 packets, 42926 bytes; actions:  drop
conformed 235616 bps, exceed 5048 bps
asa#

So there you have a QoS configuration using policing, for any VPN traffic traversing the ASA.

Now lets move on to QoS for VPN’s terminating on the ASA.

So here we extend our topology to include a branch office and an external partner. Both sites will have a VPN terminating on the ASA, using the VPN Tunnel Groups 192.1.2.2 and 192.1.2.3 respectively.

As the branch office will be using IP telephony, extending from the head office, we want to make sure that this VPN will have priority over any others. To accommodate this we will use LLQ (Priority) queue for the branch office VPN and For the External Partner VPN we will police the traffic to 2Mb.

Again as in the previous example we use the 3 stages for QoS configuration:

• Identify & Classify traffic

• Apply Action

• Assign & enable the Policy

OK, so when dealing with directly terminating VPN’s on the ASA, we have some different options to use in terms of the classification of the traffic. As we can differentiate between the two VPN’s, via the separate tunnel groups for each, we can also use this as a valid classifier in a match statement. In addition to this we can also match on flow characteristics, as well as QoS marking such as DSCP & IP Precedence.

The following defines a set of example class maps for this scenario:

class-map Branch_CM
 description “match on Branch Tunnel Group based on flows”
 match tunnel-group 192.1.2.2
 match dscp ef
class-map ExPart_CM
 description “match on External Partner Tunnel Group based on flows”
 match tunnel-group 192.1.2.3
 match flow ip destination-address

Each class map has 2 statements, and works in a first match, next match approach. For the Branch class our first match is the tunnel group 192.1.2.2, followed by our EF (DSCP 46) marked Voice traffic. In comparison the ExPart class first matches on the tunnel group 192.1.2.3, with the next match then based on each flow going through the tunnel based on the destination IP address.

Next on our list is applying the action, but as we are using Priority Queuing for the branch, we have an extra step, which is creating the Priority Queue itself. This has two parts; create the queue by assigning to an interface; and an optional stage of changing the size of the queue limit and the transmit ring limit. Defaults settings being 1024 and 128 packets respectively. So lets create our queue on the outside interface, using the optional values:

priority-queue outside
 queue-limit 512
 tx-ring-limit 64

Next comes the policy actions, as we can only have one policy assigned to an interface at any one time we will nest the classes into a single policy:

policy-map VPNQOS_PM
 class Branch_CM
 priority
 class ExPart_PM
 police output 2000000 25000

There we have our nested policy, first defining the Priority method for our Branches Voice traffic, and finally policing our external partners traffic.

We then finish off with assigning the policy to the outside interface as before.

service-policy VPNQOS_PM interface outside

The following show commands can be used to verify the QoS statistics for each method:

show service-policy police

asa# show service-policy police
Interface outside:
Service-policy: VPNQOS_PM
Class-map: ExPart_CM
Output police Interface outside:
cir 2000000 bps, bc 25000 bytes
conformed 25 packets, 4550 bytes; actions:  drop
exceeded 0 packets, 0 bytes; actions:  drop
conformed 0 bps, exceed 0 bps
asa#

show service-policy priority

asa# show service-policy priority
Interface outside:
Service-policy: VPNQOS_PM
Class-map: Branch_CM
Priority:
Interface outside: aggregate drop 0, aggregate transmit 25
asa#

show priority-queue statistics

asa# show priority-queue statistics
Priority-Queue Statistics interface outside
Queue Type         = BE
Tail Drops         = 0
Reset Drops        = 0
Packets Transmit   = 252
Packets Enqueued   = 0
Current Q Length   = 0
Max Q Length       = 0
Queue Type         = LLQ
Tail Drops         = 0
Reset Drops        = 0
Packets Transmit   = 25
Packets Enqueued   = 0
Current Q Length   = 0
Max Q Length       = 0

As you can see form the output the Voice traffic is correctly place in the Low Latency Queue while all other traffic is transmitted via the Best Effort Queue.

There concludes this post for QoS For ASA VPN’s. Next up will be part 2 featuring the QoS for IOS VPN’s

Regards,

Stuart Hare
CCIE #25616 (Security), CCSP, Microsoft MCP
Sr. Support Engineer – IPexpert, Inc.
URL: http://www.IPexpert.com

Print Friendly