We’re pleased to announce the launch of a service that’s been requested for years, a CCIE job / recruiting service. In the past we’ve attempted to partner with various firms, but in the end – it just didn’t work. So – if you’re a CCIE (or even a CCVP or CCNP) and you’re seeking a new job or interested in hearing about new career opportunities – or, if you’re on the opposite end of the spectrum and you’re the company, organization (or even another recruiting firm) looking for the ideal high-end CCIE for a job opening you have – I encourage you to visit Platinum Placement Services. You can also follow their Facebook, Twitter and LinkedIn social initiatives where various CCIE jobs will be posted periodically.

- Wayne

This post will provide a brief overview of a seldom referred to part of the ASA, the Accelerated Security Path (ASP). As we know the ASA’s Adaptive Security Algorithm is responsible for inspecting all traffic that traverses the ASA, and based on its configured security policies will either permit or deny the traffic.

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

Another new addition to the ASA v8.x code was the introduction of the Local Certificate Authority Server. Although this is not specifically mentioned in the current CCIE Security Lab blueprint I thought it a useful topic to touch on, in case of future inclusion, or for potential real world applications.

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

Have you ever wanted to attend one of IPexpert’s industry-leading CCIE classes?
Have you ever had problems really understanding a specific technical topic?
Do you want to improve your chances at pass the CCIE Lab?
Do you want to see why IPexpert’s  CCIE instructors are considered the best in the training industry?
Do you want IPexpert, the company who has trained more CCIEs in the world, to help you?
…How would you like some FREE CCIE Lab training?

IPexpert is now offering FREE online training sessions to all IPexpert clients. If you want to improve your chances at passing Cisco’s rigorous and prestigious CCIE certifications, or if you simply want to fully-understand a specific technical topic – you can’t miss our FREE Online vLectures! Several times a week, you will be able to sit in, watch and interact with the IPexpert Instructor who will be teaching technology-focused classes on a specific track and topic. If you’re an IPexpert client and wish to join these sessions, please be sure to reserve a “virtual seat” now, these have been highly anticipated and we’re quite confident that these online training seats will fill up quickly.

IPexpert’s FREE vLecture schedule for this week and next is as follows:

CCIE Security:

• Date / Time: July 29^th at 2.00 PM EST
• Instructor:  Tyson Scott
• Topic: NAT

If you’re interested in this FREE online session, click here to Schedule Now!

CCIE Voice:

• Date / Time: July 27^th at 3.00 PM EST
• Instructor: Vik Malhi
• Topic: Ask the Expert

• Date / Time: August 3^rd at 2.00 PM EST
• Instructor:  Vik Malhi
• Topic: Cube

If you’re interested in this FREE online session, click here to Schedule Now!

CCIE lab exam has been with us for more than 15 years now. In these 15 years, many strategies and many techniques were developed and established themselves as axioms – things you should do when you are taking the lab exam. One of these things is “redraw the diagrams”. In recent months, things in CCIE R&S have changed in such a that may need to force us to rethink that approach. While the main audience of this post are CCIE R&S candidates, other CCIE students may benefit from these words. What happens in R&S, invevitably comes to other tracks, as well!

Challenge of Complex Diagrams

First off, let’s examine a simple network diagram presented below. Let’s work with the assumption that other relevant information, like IP addressing and routing protocols are drawn on the diagram. They are not on this one, but this is just an illustration of the concept anyway.

After 15-20 or so minutes, we may end up having diagram that looks something like this.

Other than wasting time and introducing few mistakes (let me know when you spot them!), what would be the benefit of redrawing the entire diagram, when the one provided is pretty good to begin with? If we continue working with our own hand-drawn diagram, introduced errors may cost us deerly in the lab.

Does this mean we shouldn’t draw our own diagrams in the lab, you may ask? The answer, as with so many things in our wonderful CCIE world is – it depends.

Section Diagrams

Redrawing the entire diagram may be pointless and a waste of time. However, when faced with apparently difficult task, or a troubleshooting ticket, drawing a section of the diagram may be of great help. Let’s play along and take a look at few possible questions related to the network from our diagram.

Ticket 5
• Fix OSPF on routers R12, R19, R20 and R21 so they are able to ping each other’s Loopback0 interfaces.
• Do not modify any configuration on router R30.

What I may do at this point, is quickly redraw the relevant section of the diagram to make things a little bit more clear. Let’s take a look at that.

Since I’m not allowed to touch R30, I’m not even going to draw it. It’s a cloud – a Frame Relay cloud. R12 looks like a hub, with R19, R20 and R21 as spokes. That tells me pretty much what I need to do there…

Let’s look at a little bit more challenging task next.

Redistribution
• RIP is running between R10, R11, R13 and R14.
• EIGRP is running between R13, R14, R15, R16, R17 and R18.
• Interfaces connecting only R13 and R14 run EIGRP.
• Mutually redistribute between all protocols running on R13 and R14.

Again, we can quickly draw a redistribution diagram here that can help us understand what needs to be done. Remember, if you can – use colors. Personally, I have color code for all IGPs. I use red for RIP, green for EIGRP and blue for OSPF. You are, of course, free to use whatever you like! Let’s take a look at the diagram I might make.

In this section diagram, I have everything I need. I know which routers are running RIP, which are running EIGRP and more importantly, I see the redistribution points clearly. Tags that will be used for filtering are also there. I indicated cyan and magenta redistribution directions. I have added descriptive rules in upper corners, indicating what needs to be disallowed and allowed in each direction. In bottom corners I included route-map names for both redistribution directions. This is something I always do when I have anything but very straight-forward redistribution scenario!

This may look confusing at first glance, but after you sit in one of our Instructor Led Classes, it may make much more sense!

Conclusions

Unless you have a really bad diagram in front of you, don’t waste time redrawing entire topology, especially if it’s particularly large. Use diagrams you have provided and if they are missing some information or you may need to analyze specific case in depth, create a section diagram and use that one instead. You are much less likely to make mistakes and you can more easily add the relevant information for the task at hand. This can become very useful when you start end-of-day verification process!

Being able to draw quick section diagrams is very important and this blog barely scratches the surface. You should practice this technique as it will probably save you a lot of time and help prevent mistakes in the lab.

–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List

Background

L2-Protocol Tunnels and 802.1q tunnels seems to be a topic that often confuse people and people misunderstand the requirements to run these services.

The 802.1q tunnel feature allows a provider to tunnel customer traffic thru the provider network without revealing the underlying L2 architecture of the provider network.  In addition many customers will likely share the same L2 VLAN’s thus there is a need to keep the customer VLAN traffic separated.

With 802.1q tunneling the PE devices will add a second dot1q header, which is the access VLAN configured on the switchport, to the customer traffic to allow the traffic to be tunneled thru the provider cloud.  This may be referred to as a Metro tag or double tagging traffic.  Now obviously when you add additional headers to traffic you need to account for these extra tags in the size of the frames.  Meaning make sure you remember to increase the system mtu of the devices to at least 1504, I personally typically like to use 1508.

One pitfall to be aware of when configuring 802.1q tunnels is the native VLAN.  If a customers native VLAN is the same as the access VLAN configured for the tunnel port the Metro tag will not be added to traffic of the native VLAN when using default 802.1q values on the Metro devices.  There are two ways to avoid this pitfall.

1. Use ISL trunking in the Metro Ethernet
2. Configure the Provider devices with the command “vlan dot1q tag native”.  This causes the native VLAN to also be tagged with the dot1q header on trunk ports.

It is also important to understand some of the limitations of 802.1q tunnels. Namely:

• They do not support carrying VTP, DTP, or CDP packets to the remote device
• Spanning-tree filtering is automatically enabled on the PE (Provider Edge) port.
• Layer 3 features on the  PE ports are not supported such as L3 QoS and L3 ACL’s
• Fallback bridging is not supported for VLAN’s carrying customer traffic in the Metro Ethernet

Now to address a few of these shortcomings we have the additional L2 Protocol tunneling feature.  The L2 Protocol tunneling feature allows for traffic that would typically be terminated on the switchport for evaluation to be carried to the remote PE (Provider Edge) port for evaluation by the remote customer device.  Such as:

• Spanning-tree traffic can now be carried between each site to allow for properly building the spanning-tree topology between both sites.
• CDP packets can now be carried between devices to properly recognize the “Pseudo” connected device.
• VTP can be carried between both sites
• LACP PAGP and UDLD traffic can be shared between two point-to-point interfaces.

If both Customer devices terminate on the same provider device L2 Protocol tunneling can be used independently of 802.1q tunneling but if you must traverse more than 1 switch then the two should be used in conjunction.

Example

So let’s work thru an example of configuring these two features with an EtherChannel between two switches that is carried over a provider cloud.  Below is a basic diagram of our topology we will work with.

Diagram

Now there are a few configuration requirements we should keep in mind as we work thru this example.

• System MTU on Metro Switches must be increased to 1504 or more. (Remember this needs a reboot.)
• We are using 802.1q trunks so we need to command “vlan dot1q tag native”

Configuration

Following is the configuration for each device

Cat1

vlan 14
!
interface FastEthernet0/23
 switchport trunk encapsulation dot1q
 switchport mode trunk
 udld port
 channel-group 14 mode active
!
interface FastEthernet0/24
 switchport trunk encapsulation dot1q
 switchport mode trunk
 udld port
 channel-group 14 mode active
!
interface Vlan14
 ip address 10.1.14.1 255.255.255.0
!

Cat2

vlan dot1q tag native
system mtu 1508
! ### remember reboot
!
interface FastEthernet0/19
 switchport trunk encapsulation dot1q
 switchport mode trunk
 spanning-tree portfast trunk
!
interface FastEthernet0/20
 switchport trunk encapsulation dot1q
 switchport mode trunk
 spanning-tree portfast trunk
!
interface FastEthernet0/23
 switchport access vlan 114
 switchport mode dot1q-tunnel
 l2protocol-tunnel cdp
 l2protocol-tunnel stp
 l2protocol-tunnel vtp
 l2protocol-tunnel point-to-point lacp
 l2protocol-tunnel point-to-point udld
 no cdp enable
!
interface FastEthernet0/24
 switchport access vlan 124
 switchport mode dot1q-tunnel
 l2protocol-tunnel cdp
 l2protocol-tunnel stp
 l2protocol-tunnel vtp
 l2protocol-tunnel point-to-point lacp
 l2protocol-tunnel point-to-point udld
 no cdp enable
!

Cat3

vlan dot1q tag native
system mtu 1508
! ### remember reboot
!
interface FastEthernet0/19
 switchport trunk encapsulation dot1q
 switchport mode trunk
 spanning-tree portfast trunk
!
interface FastEthernet0/20
 switchport trunk encapsulation dot1q
 switchport mode trunk
 spanning-tree portfast trunk
!
interface FastEthernet0/23
 switchport access vlan 114
 switchport mode dot1q-tunnel
 l2protocol-tunnel cdp
 l2protocol-tunnel stp
 l2protocol-tunnel vtp
 l2protocol-tunnel point-to-point lacp
 l2protocol-tunnel point-to-point udld
 no cdp enable
!
interface FastEthernet0/24
 switchport access vlan 124
 switchport mode dot1q-tunnel
 l2protocol-tunnel cdp
 l2protocol-tunnel stp
 l2protocol-tunnel vtp
 l2protocol-tunnel point-to-point lacp
 l2protocol-tunnel point-to-point udld
 no cdp enable
!

Cat4

vlan 14
!
interface FastEthernet0/23
 switchport trunk encapsulation dot1q
 switchport mode trunk
 udld port
 channel-group 14 mode active
!
interface FastEthernet0/24
 switchport trunk encapsulation dot1q
 switchport mode trunk
 udld port
 channel-group 14 mode active
!
interface Vlan14
 ip address 10.1.14.4 255.255.255.0
!

Let’s talk about a few of the key configuration components here.  When I gave the background information above on L2 Protocol Tunneling, note that LACP and UDLD are only support in a point-to-point operation.  This is the reason we used two different VLAN’s, 114 and 124, for the two ports connected to the customer.

The L2 Protocol tunneling allows us to carry the CDP, LACP, spanning-tree, UDLD, and VTP packets between Cat1 and Cat4.  The 802.1q handles the carrying of the traffic between the two ports by adding the Metro Tag of 114 and 124 to traffic coming in from Cat1 and Cat4 respectively.

The reason that running UDLD is important is we are load balancing traffic between two ports.  Because our neighboring device is not directly connected we need to be aware of a device failure on the remote end.  UDLD provides this function by testing the neighboring device and taking down a port in the event of a failure on the remote end or in the provider path.  You could compare this to FREEK in reference to Frame-Relay technologies.

Now let’s test it out and see how things are working.

Cat1#show udld neighbors
Port     Device Name   Device ID     Port ID    Neighbor State
----     -----------   ---------     -------    --------------
Fa0/23   CAT1029ZJBJ     1            Fa0/23     Bidirectional
Fa0/24   CAT1029ZJBJ     1            Fa0/24     Bidirectional
Cat1#show udld Fa0/23
Interface Fa0/23
---
Port enable administrative configuration setting: Enabled
Port enable operational state: Enabled
Current bidirectional state: Bidirectional
Current operational state: Advertisement - Single neighbor detected
Message interval: 15
Time out interval: 5
Entry 1
---
Expiration time: 39
Device ID: 1
Current neighbor state: Bidirectional
Device name: CAT1029ZJBJ
Port ID: Fa0/23
Neighbor echo 1 device: CAT1029ZJD6
Neighbor echo 1 port: Fa0/23
Message interval: 15
Time out interval: 5
CDP Device name: Cat4
Cat1#show udld Fa0/24
Interface Fa0/24
---
Port enable administrative configuration setting: Enabled
Port enable operational state: Enabled
Current bidirectional state: Bidirectional
Current operational state: Advertisement - Single neighbor detected
Message interval: 15
Time out interval: 5
Entry 1
---
Expiration time: 37
Device ID: 1
Current neighbor state: Bidirectional
Device name: CAT1029ZJBJ
Port ID: Fa0/24
Neighbor echo 1 device: CAT1029ZJD6
Neighbor echo 1 port: Fa0/24
Message interval: 15
Time out interval: 5
CDP Device name: Cat4
Cat1#show spanning-tree vlan 14
VLAN0014
Spanning tree enabled protocol ieee
Root ID    Priority    32782
Address     0019.0606.7180
Cost        12
Port        160 (Port-channel14)
Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
Bridge ID  Priority    32782  (priority 32768 sys-id-ext 14)
Address     0019.060c.5e80
Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
Aging Time 300
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Po14                Root FWD 12        128.160  P2p
Cat1#show int trunk
Port        Mode             Encapsulation  Status        Native vlan
Po14        on               802.1q         trunking      1
Port        Vlans allowed on trunk
Po14        1-4094
Port        Vlans allowed and active in management domain
Po14        1,14
Port        Vlans in spanning tree forwarding state and not pruned
Po14        1,14
Cat1#ping 10.1.14.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.14.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/8 ms
Cat1#show cdp nei
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
Cat4             Fas 0/24          121           S I      WS-C3560- Fas 0/24
Cat4             Fas 0/23          120           S I      WS-C3560- Fas 0/23
Cat1#show etherchannel summary
Flags:  D - down        P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3      S - Layer2
U - in use      f - failed to allocate aggregator
M - not in use, minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port
Number of channel-groups in use: 1
Number of aggregators:           1
Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
14     Po14(SU)        LACP      Fa0/23(P)   Fa0/24(P)

Looks like it worked just as expected.  Thanks for Reading.

–
Tyson Scott – CCIE # 13513 (R&S/Security/SP)
Managing Partner / Sr. Technical Instructor – IPexpert Inc.
Mailto: tscott@ipexpert.com

A brief introduction to GNS3 and Dynamips

GNS3 is a front end for Dynamips.  Dynamips, which was written by Chris and released at http://www.ipflow.utc.fr/blog/, is the backend that emulates the router platforms.  Sadly the final version released is 2.8 RC2. Reportedly Chris had worked on some enhancements after this release but those enhancements never made it into public hands.

Dynagen, written by Greg, was the first non-gui interface made for Dynamips to make life easier. It has a very nice command line interface and is quite stable. It also has a slight performance edge over GNS3. But the ease of use with GNS3 still makes it more attractive than a slight performance enhancement.

If you would like to use Dynagen, it can be downloaded from http://dynagen.org/

GNS3

GNS3 started as a project for university students. And it is the most successful graphical interface for Dynamips.  Although some Chinese authored a few GUI interfaces they never take off.  They are also out of scope for this guide to discuss those reasons.

GNS3 is maintained at following site: http://gns3.net/

Important Note: In this IPexpert Guide, GNS3 is used as a collective word for the combination of the backend software (Dynamips) and the frontend software (GNS3 itself).

GNS3 is well known as the non official Cisco emulator; it can run Cisco IOS on the platforms supported by the program. It’s important to note that, GNS3 is not a simulator it is an emulator. It can support all the commands and features supported on the hardware it emulates.  When people say, GNS3 cannot emulate switching; they are misunderstanding the purpose of GNS3. GNS3 supports switching based on the capabilities of the supported platforms. Restrictions in switching are not because GNS3 doesn’t support it.  The limitations are put on the hardware platform that is supported, namely the NM-16ESW.

Platforms and modules supported by GNS3.

1. 1700 routers
2. 2600 routers
3. 3600 routers
4. 3700 routers
5. 7200VXR series
6. NM-16ESW switching module
7. WIC modules
8. NM-CID
9. NM-NAM
10. NM-xT/ NM-xFT
11. Native Etherswitch support and Frame-Relay support

Some important GNS3 components:

Autostart = False/True

This setting allows you to automatically start all the devices when you load you topology if it is set to “True”. We recommended this value be set to “False”.

Ghostios = True/False

This allows GNS3 to run multiple copies of a single image, reducing resources on the workstation. We highly recommended setting it to “True”, in all situations.

Sparsemem = False/True

This setting allows GNS3 to control memory handling. In case this feature is set to “True”, GNS3 will only utilize memory as needed by each running device and unused memory will be swapped to hard disk. This feature is good for machines which lack memory.

But this feature makes your overall performance much slower.  This is because excessive swapping of virtual memory with the hard drive.  If your computer can handle the memory required by to run all the devices (memory required by one device x number of devices) then you should set this to “False”.

IDLEPC = 0x????????

Many consider this “THE” most important part of GNS3 configuration.  It can dramatically change your overall experience. Basically, this value defines the resources the emulated Cisco Routers will use. The IDLE PC value instructs devices to release resources and go idle during while the router is running idle.  This then allows resources to be freed up and made available to the other devices. It is kind of co-operative multi-tasking being done among the emulated instances.  You should spend sufficient time to find a good combination of IDLEPC value suited for his/her IOS and computer platform.

It is important to understand that our goal is for you to have smooth GNS3 experience. If you can emulate the IPexpert topology with your PC’s CPU running around a scale of 60-70% when all of your devices powered on and you have a handful of configurations loaded, then don’t waste more time on finding better values. This is the performance you should expect.  Don’t waste additional time trying to tweak GNS3 settings to get better performance.  Just like in the actual lab you need to meet the requirements of the questions, no more, no less.

Image files: GNS3 supports (like normal routers) booting form compressed IOS images. During IOS initialization, routers being emulated have to decompress the image every time it boots and this takes a lot of time. The best way to save time during the initial boot process is to use GNS3 with decompressed images.

IOS files can be decompressed using command-line “uzip” utility easily. Ignore the warning that the decompression process wil report about corrupt headers – this is IOS “bootstrap”. Resulting file is decompressed IOS you can use with GNS3.

Enough talking, let’s move on to the actual setup!!!!!!

Linux (Ubuntu 9.10 Installation and dual booting)

By nature GNS3 is a CPU intensive application and requires a lot of resources.  Windows client operating systems are not best suited for Dynamips for this reason as they are not the best tuned for applications like this.  Linux, on the other hand, is a very stable Operating System and is better suited for applications, such as GNS3, that require optimized CPU resources.  Linux can also better control the utilization of these resources in a more optimized way. Now there are many flavors of Linux on the market.  You will have many users which prefer one versus the other but for someone first being introduced to Linux there is none better than Ubuntu.  Ubuntu has a very large user community and many of the support forums are heavily supported and have a lot of good resources for guidance in unfamiliar territories.  For this reason we will use Ubuntu in this guide as our recommended Flavor.

Ubuntu is available in both 32bit and 64bit version, for this IPexpert guide we will only discuss 64 bit version of Ubuntu. Although there is no difference among 32 bit or 64 bit installation. The current version of 64bit Ubuntu can be obtained from following link: http://www.ubuntu.com/GetUbuntu/download

If you are going to be starting with a clean installation, meaning you have no previous OS installed, then you can start installation of Ubuntu without any other requirements to keep in mind.  If case your computer already has another operating system installed, the following links can help with steps to install Ubuntu using a dual boot of Linux and Window’s. (Dual booting Ubuntu and other OS is simple process but if you don’t take the necessary steps for this process you can damage your data; it is always a wise decision to backup your data before proceeding).

Dual boot Windows XP (XP installed first) and Ubuntu:

http://apcmag.com/how_to_dual_boot_windows_xp_and_linux_xp_installed_first.htm

Dual boot Windows Vista (Vista installed first) and Ubuntu :

http://apcmag.com/how_to_dualboot_vista_with_linux_vista_installed_first.htm

Dual booting Windows 7 and Ubuntu will follow the same strategy as the Vista link given above.

Let’s prepare Ubuntu for GNS3 installation now!

Preparing Ubuntu for GNS3 installation

GNS3, in itself, is a small application but it has some dependencies (Linux terminology meaning required software components prior to installation). Installation of these dependencies is the most difficult part of the GNS3 installation, but we are fortunate enough that Ubuntu can do this process automatically with the Synaptic Package Manager.

GNS3 Installation:

Step 1: Launch Synaptic Package Manager software by going to System – Administration – Synaptic Package Manager

A window like Fig-1 below will appear

Fig-1

In quick search type gns3 and it will fetch software related to GNS3. You can see from above Fig-1 that for me it fetched gns3 and dynamips. Click on check box for gns3 and dynamips one by one and select “Mark for Installation”.  When you will select “Mark for Installation”, it will bring a pop up window that will show all of the dependencies which these two packages require. Click “Mark” for these as well.

Note: Without these dependencies GNS3 will not work.

After that, from top bar click “Apply”, this will start downloading dynamips, gns3 and all of dependencies automatically. After all the applications have been downloaded, Synaptic Software Manager will start installation of applications automatically.

Installation of Tabbed terminal client:

When the installation of GNS3 is done, again open Synaptic Software manager and install a tabbed telnet client called Konsole. If you don’t want to use tabbed telnet client then you can skip this step.

Fig-2

In the Synaptic Software Manager window type konsole in quick search. It will fetch a few related software packages, just select konsole by clicking on “Mark for Installation”. This will bring once again show a dependencies pop up message and you have to click on “Mark”. Same as previous, click on “Apply” from top bar, this will start downloading and installation of konsole (tabbed terminal client).

Running GNS3 under root:

In Ubuntu (Linux) separation of roles is a very important concept.  Meaning normal users are separated from the root and other important system accounts.  GNS3 can be run as a normal user but for simplicity sakes I highly recommend running GNS3 as root. This will keep everything simple and straightforward. This will avoid a lot of permission issues, which can cause you some major headaches in normal operation of GNS3. If you have plenty of time and wish to spend that time on Linux issues rather than putting that time into CCIE studies then go ahead and figure out things that way… I am not in that mood :)

Creating necessary Shortcuts and supporting folder structure:

We will create shortcuts and folder structure in following way

images will be used for storing images.

projects will be used for storing .net files.

configs will be used for storing initial and final configs for IPexpert labs.

captures will used for capturing network traffic.

supporting files here you can find all the files necessary or useful for running your GNS3 more easily.

tmp will be used for temporary files created by GNS3

Automatic way of GNS3 Configuration: Life cannot be easier than this

Note: For proper operation of GNS3 and to make life easier we will create supporting directory structure. This structure and supporting files can be obtained from attached IPexpert.tar.gz file.  Click here to download this file

Note: If you prefer manually configuring GNS3, skip these steps and proceed to Manual configuration.

Decompressing Ipexpert.tar.gz file:

Copy this IPexpert.tar.gz file to your desktop and double click it. Extract the files to the desktop, from here you can move files to proper locations. Here we extracted two folders to the desktop, shortcuts and IPexpert, along with gns3.ini file as shown in Fig.

Fig-3

Move the “GNS3 File Browser (root)” and “gns3 Graphical Network Simulator (root)” shortcuts on Desktop, these two shortcuts are in folder “shortcuts” folder. These two shortcuts will launch browser and GNS3 as root.

Fig-4

When you will first time launch application then you will see an error message like following:

Fig-5

Click Mark as Trusted and it will fix the issue.

Next move the contents in the IPexpert folder to the root directory. To move these files to root, open “GNS3 File Browser (root)” and navigate to /home/yourusername/Desktop, from here copy the IPexpert folder, navigate back to / and past it there. (You can reach to / by clicking on “File System”)

Fig-6

Now copy gns3.ini file to /root/.gns3 location (this folder may not appear by default, you have to press crtl+h). If after pressing crtl+h it does not appear then create one.

You can save original file as gns3-old.ini

Fig-7

Setting Proper Permissions

After moving the IPexpert folder to root (/IPexpert), we have to adjust permissions on this folder. Right click the IPexpert folder, then chose properties. A new window will open; click on Permissions and set permissions as shown in fig (don’t forget to click on “Apply Permissions to Enclosed Files” button). Click Close

Fig-8

Next set the permission settings on the folder /root/.gns3 (this folder may not appear by default, you have to press crtl+h) should be like fig-07

Fig-9

Make sure you have configured permissions properly as shown in above figures.

And that is it!!!!!!!! Now you can proceed to Creating first project step and can skip manual configuration steps.

GNS3 Configuration Manually:: Let me see all what it takes

If you opt not to use the attached file use the following Steps.  If you have already followed the steps for the Automatic way please skip to the Creating First project Steps.

First, create a browser shortcut which will explore files in “/root” anything launched through this explorer will be automatically launched to “/root” directory.

Run the following commands in a terminal session, (terminal can be reached by Applications – System Tools – konsole or Applications – Accessories – Terminal)

In the terminal window execute the following command:

sudo gedit /usr/share/applications/Nautilus-root.desktop

This will ask you to enter root password which is same as your user password. Once you entered password and its correct then a new window will open in that window paste the following code:

[Desktop Entry]
Name=GNS3 File Browser (Root)
Comment=Browse the filesystem with root privileges
Exec=gksudo “nautilus”
Icon=file-manager
Terminal=false
Type=Application
Categories=Application;System;

After saving the document close the window.

Enter the following command to refresh the “Desktop” in the terminal window.

killall gnome-panel

Go to Applications – System Tools and right click “GNS3 File Browser (root)”  and select “Add this launcher to desktop”.

Create a second shortcut for GNS3 by right clicking on Applications – Education – GNS3 Graphical Network Simulater and choosing “Add this launcher to desktop”.

After you are done, will see the following shortcuts on Desktop:

Fig-10

Right click on GNS3 shortcut select “Properties” and enter the text (gksudo gns3) as shown in following fig, in command box.

Fig-11

Creating the Supporting Folder Structure

Open file browser by double clicking the created shortcut “GNS3 File Browser (Root)”, the first time it will ask for root password, this is same password you used for your login on this system.

Click on File system and create a folder called “IPexpert”, keep in mind in Ubuntu file names are case sensitive which means ipexpert and IPexpert are not same folders.

Fig – 12

Now create the directory structure inside IPexpert as shown in the figure below, remember this structure is provided in attached IPexpert.tar.gz file also.

Inside IPexpert folder we will create the directories of images, projects, configs, captures, supporting files, and tmp.

Fig-13

Before preceding further please put at least one IOS image in /IPexpert/images/ directory in an unzipped format.

I used c3725-advipservicesk9.124-15.T6.bin image along with 0x6271c1a0 idlepc value. This image has proved to be stable and provide all the functionality required for the CCIE R&S blue print.

Configuration of GNS3

1- Launch GNS3 by double clicking on GNS3 shortcut on Desktop. It will ask for the root password which is same as your normal user password. After entering root password, it will show the following window.

Fig-14

For now just press Cancel, we need to configure and fine tune GNS3 before we do anything else.

IOS Images and Hypervisors

I assume that you have finished the file structure steps explained previously. Now we will use that file structure for GNS3 configuration.

1- Configure ISO images and Hypervisor. Click on Edit > ISO Images and hypervisors

Fig-15

Use the following steps for IOS Images:

1-    Image file: Select the image you have placed in the /IPexpert/images folder. You must have at least one image for the platform you will be using in the topology.  (We are using /IPexpert/images/c3725-advipservicesk9.124-15.T6.bin) image.

2-    Choose Platform, this should match with the IOS image you provided in the previous step. (We used the 3725 image so will choose the 3700 platform)

3-    Choose the correct Model of your selected platform.

4-    Provide the IDLE PC value, if you have one. (We used 0x6271c1a0.  For the 3725 with the selected IOS image above, this value has shown promising results.  But you may find this not to work so be aware this may need to be adjusted).

5-    Select the Default RAM for the Platform.  For best results use Cisco feature navigator to seek recommended RAM for the particular model. This model’s recommended RAM is 256 MB, but our experience has shown giving 128MB is sufficient.

Our Topology uses 15 devices so using 128MB for each device, 128×15 = just shy of 2GB. So your laptop/PC should have a minimum of 3GB.  With 4GB or more you will have smooth sailing.

6-    Put the check in Default Image for this platform.  And Click Save.

Fig-16

Click on External hypervisor and duplicate the Settings as shown in Fig-10.

1-    Host 127.0.0.1

2-    Working directory /IPexpert/tmp

Note: Click Save at least 4 times to create 4 Hypervisors. You should see four instances when finished in the right window as shown above. Using four instances will make these settings optimal for Intel’s Core Ix processors, which support Hyper-Threading.

Click Close.

Configuring Preferences

Fig-17

Click on Edit -> Preferences you will see a dialog box as shown in Fig-10

Click on General

Change the Terminal Command to the following line:

/usr/bin/konsole –profile “gb” –new-tab -p tabtitle=%d -e telnet %h %p >/dev/null 2>&1 &

Note: This setting is only required if you want to use konsole as the default terminal software.     In real CCIE lab the terminal emulation program provided doesn’t have tabs.  We have found the benefit of tabs for doing practice labs, that in our opinion, far outweighs the benefit of duplicating the actual lab.  Of course you will have your own opinion on this as well.

Setting gb profile:

In the above config line for console, we used “gb”, this is name for a Konsole profile “gb”. This profile loads green text on black back ground. To configure this profile open Konsole (terminal software) menu; go to Settings -> Manage Profiles and create a new profile named “gb”, edit settings as you like e.g Green on Black. After you have created new profile delete default profile named shell. Close your terminal and open again all will be set to go.

Last change the Project directory and Image directory settings as shown in Fig-11, then Click Apply.

Dynamips Settings:

Fig-18

1-    Change the Working directory to /IPexpert/tmp

2-    Leave “Enable ghost IOS feature” and “Enable mmp feature” checked.

3-    Uncheck “Enable sparse memory feature”.

4- Click Apply.

5-    Click Test.  If everything works well you will see “Dynamips successfully started” in green as shown in Fig-11.

Note: this test will only be successful if you have completed all the steps and already have software that supports a telnet client.

Configuring Capture Directory:

Fig-19

If you want to use packet captures, which is supported by GNS3 with no extra software or settings, you can use the settings as shown above.  You should have Wireshark or some other capture reader installed prior to configuring this.  Instructions for this are beyond the scope of this document.

Define path for captured packets, /IPexpert/captures

Click Apply and OK to close this dialog box.

Creating the First Project:

1 – Go to /ipexpert/projects folder and create one file and rename it Ipexpert-test.net. Right click it and chose “Open with”, then “Open with other application”. In the command line type gns3, and click open.

NOTE: This will help you to open any .net file by double clicking on it, (this is the way of handling .net files because of an open bug in GNS3 for Linux).

2 – From the node types area, drag two instances of a router 3700 to the middle of the workspace ( I used the 3700 image, if you have used any other supported image, then drag that platform). Connect the devices using the Connect tool and then run the topology using the Run button.

3- Click Save As to save it.

Loading IPexpert topology:

We will load the IPexpert topology now to see how it all works. This topology is shipped with the zip file, and should be located in the folder “/IPexpert/projects/” if you used our file to create your folder structure.

Fig-20

Important Notes: This guide recommends using GNS3 IPexpert topology on at least an Intel Core 2 Duo 2.0 processor and we recommend a minimum RAM of 4GB for optimal performance. For best results if Intel Core i”x” can be acquired then that will be great.

Written by contributing Customer: Nadeem Rafi

The week of Cisco Live! 2010 in Las Vegas came to an end. It started on Sunday and up until Thursday, thousands (apparently more than 15.000) of network engineers gathered in one place to participate in the largest of Cisco’s social and learning events. Of course, we were there and here is just brief summary of the things future will bring

There were two things that were on everyone’s mind before “Networkers” started. Will there be a new CCIE track announced (CCIE Data Center) and the overdue blueprint change for CCIE Service Provider. We waited in anticipation for both of these, alas… nothing came out from Cisco. But, there were a lot of technical sessions, marketing presentations and very open and frank conversations with Cisco people that helped us understand what future holds. Without further ado, here we go.

CCIE Routing and Switching

Blueprint is currently in version 4.0 and it is likely to remain like that for at least the next six months. However, that doesn’t mean there are not going to be changes and tweaks. Just to quote one of the people from the program who told me “we are bringing routing to routing and switching”. What that means is that there is going to be more emphasis on the core subjects, like IGP and BGP, as well as interaction (redistribution) between protocols. Another thing that is coming is more in-depth and more relevant troubleshooting tickets. As you will see with some of the other tracks, troubleshooting is becoming a major component of the CCIE exam and students going for the exam must absolutely be ready for it!

What does more distant future for R&S hold? Since troubleshooting is 100% in virtual environment, we believe it’s only a matter of time (perhaps within next 2-3 years) that R&S lab will be 100% virtualized, or at least hybrid of virtual and real equipment, allowing Cisco to create more modular and dynamic lab content. The team of engineers within Cisco responsible for CCIE R&S is very capable and eager to keep this track as the most important and relevant IT certification and they are doing a pretty good job at it!

Summary:

• No pending blueprint update.
• More in-depth troubleshooting
• More focus on “core routing topics”
• More virtualization in the distant future

IPexpert’s Summary:

• Changes mentioned are very well covered by our CCIE R&S Blended Learning Solution
• Minor content update may be forthcoming to include more troubleshooting exercises

CCIE Voice

There were no changes to the blueprint announced (thankfully!). All software versions will remain at 7.0 and are likely to remain at this release for a couple of years. It is worth pointing out that Cisco are well aware of the fact that there are several “bugs/undocumented features” that can be expected with any “.0” release. However candidates are expected to provide workarounds where applicable.

As most of you know, the Core Knowledge questions were removed some time in May 2010 and were replaced with troubleshooting tasks. The speaker repeatedly brought attention to the types of troubleshooting tasks candidates can expect. We have tried to summarize some of the most important points raised below.

• There is no dedicated troubleshooting section for the time being- troubleshooting is embedded into the configuration tasks of the exam. This is subject to change- in other words they may look at providing a dedicated troubleshooting section at some point in the future.
• Troubleshooting tasks account for approximately 15% of the points on the CCIE Voice Lab exam.
• Candidates will have to troubleshoot existing configuration which has built-in errors. More details of example errors are given below.
• Infrastructure tasks will for the most part be complete and will not be the responsibility of the candidate. However configuration might not be 100% correct!
• Going forward phones will be pre-configured into the UCM database. It was mentioned that SIP endpoints have not been tested thus far but candidates should expect SIP endpoints in the lab in the very near future. Interestingly it is the intention to have phones pre-registered with the correct firmware in advance- that means candidates will not be responsible for changing the firmware of the phone. This will come as a relief to many of you since this process is time-consuming.
• Troubleshooting tasks could potentially include in depth knowledge of the protocols used for establishing call setup. Detailed knowledge of the call flow involved in protocols such as SIP/MGCP/H323/SCCP/Q931/etc will be required in order to explain why certain calls to the “provider” are failing. It was mentioned that the candidate may not even have to fix the problem and instead create a text file with the relevant traces/debugs and a suitable explanation. A process not too dissimilar when you create a TAC case.
• Cisco will continuously modify the content of the lab and this includes changing the number of UCM and UCME sites. You can expect 3 UCM sites, 3 UCME sites or anything in between!
• Gatekeeper/CUBE/SIP Trunk tasks will be added to the lab at some point in the near future (if not already!). The PSTN provider in the lab may not necessarily be a T1/E1 connection but rather a H323 or SIP ITSP.
• Security related tasks (authentication and encryption of signaling and media) are not going to be tested since these tasks are too difficult to maintain and implement. However the CCIE Voice Written test which will be updated later this year will cover those topics.
• The Voice CCIE pass rate is currently between 20% and 25% but expect that figure to drop as the impending lab updates will no doubt increase the difficulty of the test.

Overall we were very pleased with the outcome of the discussion- no major updates for a couple of years will come as a huge relief to all training vendors. The IPexpert BLS and bootcamps have for more than a year now been covering SIP Phones, CUBE, multiple UCME sites and detailed knowledge of the protocols involved in call set up. The biggest takeaway from the session was undoubtedly troubleshooting is going to be the singular most important skill candidates will need to pass the lab – if you are going to pass the CCIE Voice going forward you need to focus on the why and not only the how as has been the case in the past.

CCIE Security

This seems to be the least exciting track as far as news go. The content is stable, there are no immediate pending blueprint changes and content updates.

IPexpert’s Summary:

• No pending product updates, based on changes.

CCIE Service Provider

Let me get this out of the way, first. There was no new Service Provider blueprint announced. However, it is ready and will be announced very, very shortly. Blueprint and content are ready, what is pending are hardware upgrades for lab locations. We can expect it to happen at any moment. So, what are the forthcoming changes, then?

IOS XR is making the appearance. It is not a rumor, it is not a speculation, it is going to be there. The major focus area is on IP and MPLS, still, but there will be also a focus on service provider approach to IPv6 and interaction between IOS and IOS XR. We can expect any number of routers running IOS and IOS XR in the new lab, where there will be a mix of IOS and IOS XR devices in the “core” and the same at the edges. CE routers will remain strictly IOS.

Also, there will be troubleshooting on the exam, but it is still not 100% certain whether that includes a dedicated troubleshooting section, or preconfigured faults in the configuration section. For this, we need to wait the official announcement. Everyone afraid of pending changes, should aim to proceed with their lab preparations. If you are not concerned (and really, there is no need to be), keep to your schedule, as planned.

Summary:

• Blueprint change is imminent.
• IOS XR and IOS will be tested.
• IPv6 will be tested.
• Troubleshooting will be a component.

IPexpert’s Summary:

• We are, like everyone else, waiting for blueprint update.

CCIE Service Provider Operations

This track was a mystery for me before going to Cisco Live! What is the idea behind it? Well, after talking to relevant people at Cisco, I actually like this track and I’m likely to go for it in the future. So, let’s see…

CCIE SP Ops is the track that focuses strictly on NOC personell. Cisco sees this as one the fastest growing CCIE tracks in the future, in fact. There is heavy focus on troubleshooting and processes in this exam. In fact, two sections of the lab reflect this. The lab will be split in two parts. The first part is dedicated troubleshooting section, which will include complex problems involving both IOS and IOS XR devices. The second section is scenario-based test, focusing on processes (ITIL) and high-level problem troubleshooting and escalation.

Since this exam is still not available to general public, it remains to be seen what will happen here.

Summary:

• Heavy focus on troubleshooting complex IOS and IOS XR issues.
• Heavy focus on processes and process frameworks (ITIL).

IPexpert’s Summary:

• At this point, we do not have immdiate plans to provide training for this track.

CCIE Wireless

Petentially, one of the most interesting tracks in the future. Fast growing market and ever evolving technology. Cisco understands this and CCIE Wireless is in good hands within Cisco in that respect. So, what’s going on with the exam? First of all, there will be some changes in the next couple of months, but no immediate blueprint change – which will happen within 9-12 months, though. The biggest change that is going to happen soon is that Cisco is “quietly” going to remove Location appliance from the exam. The reason for that is that it’s end-of-life and Cisco wants to replace it with something more relevant. The more relevant thing is Mobilite Services Engine. However, that will require major software changes on the rest of the equipment in the lab and requires blueprint change, which they are not ready for at this moment.

One thing was very much stressed out during the technical session on CCIE Wireless – candidates must understand routing and switching in order to complete the lab successfully! It’s is not as deep as in R&S track, but it is definitely covered on the exam. Students must know how to configure basic spanning-tree, IGP routing and redistribution to be successful. According to Cisco, this is one of the biggest hurdles candidates experience in the exam.

Summary:

• No pending blueprint change.
• Minor content upgrade – Location appliance will be removed.
• Basic switching, unicast and multicast routing configuration.

IPexpert’s Summary:

• Stay tuned for pending product announcements for this track. We will be updating our website this month to reflect the following products:
• CCIE Wireless racks
• Self-study Workbooks (Volume 1 and 2) with Detailed Solution Guides
• A Video on Demand Boot Camp
• A Live 5-Day Instructor Led Class

CCIE Storage

We all expected to see CCIE Data Center announced this year. However, it was not, nor is it planned for immediate future. That being said, Cisco engineers involved in the program informally refer to the Storage track as the CCIE Data Center. Also, they are investigating the future possibility of creating more comprehensive Data Center CCIE, but it’s in the early planning stages as of right now.

However, there are important bullet points that we should mention here for the people who are preparing for this track. First of all, focus of the exam is only on Cisco equipment and devices. Carefully examine the list of devices mentioned in the blueprint and focus the studes on this equimpent.

The world of data centers is fast evolving, which makes it very difficult to create a “stable blueprint” and CCIE program managers are waiting for the product range and technology to stabilise, before they introduce major changes. There are probably going to be blueprint updates in the next 6-12 months, but no major changes will happen overnight.

Summary:

• No pending blueprint update.
• Fast-changing and evolving technology that will only grow in the future.
• Strict focus on Cisco equipment in the exam.

IPexpert’s Summary:

• Stay tuned…Although we currently have several CCIE Storage Racks and Tyson Scott (IPexpert’s x3 CCIE is working on this track, currently) we’re going to wait until the Data Center is announced before we pursue any products in this space.

Overall Summary

It has been a great week for IPexpert and everyone who attended Cisco Live! We met with great people, our former, current and future students. We enjoyed the excellence of Cisco’s technical presentations, immersed ourselves in deep technical discussion with our peers and had the great opportunity to socialize with like-minded network engineers, both from Cisco and elsewhere.

See you all in classes and next year at Cisco Live! 2011 in the CCIE lounge – where you all need to be with fellow CCIEs!

Regards – The IPexpert team

Hello Everyone,

Some time ago Brandon wrote an excellent article titled “Working with ISAKMP Profiles”. This blog is going to complement this giving you few configuration examples.

ISAKMP Profiles can be thought of VPN connection distinguishers. They group Phase 1 and 1.5 parameters and allow mapping them to different IP Security (IPSec) tunnels. This is somewhat similar to the ASA tunnel-group concept.

An ISAKMP profile applies parameters to an incoming IPSec connection identified uniquely through its concept of match identity criteria. These criteria are based on the IKE identity that is presented by incoming IKE connections and includes IP address, FQDN, VPN group name and Subject Name from a certificate.

Most common ISAKMP Profile applications are as follows :

1. Different phase 1 or 1.5 parameters are required for different peers. Examples are : Aggressive Mode/Main Mode, separate IKE_IDs, different Keepalives (DPD) values, AAA parameters
2. Certificate to Profile matching
3. VRF-Aware IPSec
4. Per-VPN connection QoS

Each ISAKMP Profile can apply connection parameters in two ways – during the connection initiation and during connection reception. This is called Request and Respond Profile, respectively.

In this article we will take a closer look at points 1 and 2. The topology consists of three routers (R6, R7 and R8) that are in the same LAN (192.0.2.0/24) and each one is having a loopback network configured (which is going to emulate our private networks).

IP addressing scheme and configuration :

R6 LAN – 192.0.2.6/24

R6 Loop0 – 10.6.6.6/24

R7 LAN – 192.0.2.7/24

R7 Loop0 – 10.7.7.7/24

R8 LAN – 192.0.2.8/24

R8 Loop0 – 10.8.8.8/24

Example 1

Let’s say R6 is required to use AM only with R8. Here is how we configure our ISAKMP Profile :

R6(config)#crypto isakmp profile ISA_PROF

R6(conf-isa-prof)# keyring default

R6(conf-isa-prof)# initiate mode aggressive

R6(config)#cry map MAP1 10 ipsec-isa

R6(config-crypto-map)#set isakmp-profile ISA_PROF

Now initiate VPN connection from R6 to R8 and take a look at debugs. :

 R6#ping 10.8.8.8 so l0 rep 2

Type escape sequence to abort.

Sending 2, 100-byte ICMP Echos to 10.8.8.8, timeout is 2 seconds:

Packet sent with a source address of 10.6.6.6

*Mar 22 22:05:12.567: ISAKMP:(0): SA request profile is ISA_PROF

-- Output omitted –

*Mar 22 22:05:12.595: ISAKMP:(0): beginning Aggressive Mode exchange

*Mar 22 22:05:12.595: ISAKMP:(0): sending packet to 192.0.2.8 my_port 500 peer_port 500 (I) AG_INIT_EXCH

*Mar 22 22:05:12.595: ISAKMP:(0):Sending an IKE IPv4 Packet.

*Mar 22 22:05:12.631: ISAKMP (0): received packet from 192.0.2.8 dport 500 sport 500 Global (I) AG_INIT_EXCH

*Mar 22 22:05:12.631: ISAKMP:(0): processing SA payload. message ID = 0

*Mar 22 22:05:12.631: ISAKMP:(0): processing ID payload..!

Success rate is 50 percent (1/2), round-trip min/avg/max = 1/1/1 ms

So far, so good. But wait, what about if we want R8 to initiate the tunnel to R6… (normally when you are using AM you are doing some kind of Remote Access connections which means this would not be necessary) :

 R6#clear cry sess

R8#ping 10.6.6.6 so l0 rep 2

Type escape sequence to abort.

Sending 2, 100-byte ICMP Echos to 10.6.6.6, timeout is 2 seconds:

Packet sent with a source address of 10.8.8.8

..

Success rate is 0 percent (0/2)

R6#

-- Output omitted –

*Mar 22 22:11:25.111: ISAKMP:(1004): processing ID payload. message ID = 0

*Mar 22 22:11:25.111: ISAKMP (1004): ID payload

next-payload : 8

type         : 1

address      : 192.0.2.8

protocol     : 17

port         : 500

length       : 12

*Mar 22 22:11:25.111: ISAKMP:(0):: peer matches *none* of the profiles

*Mar 22 22:11:25.111: ISAKMP:(1004): processing HASH payload. message ID = 0

-- Output omitted--

R6# map_db_check_isakmp_profile profile did not match

*Mar 22 22:11:55.027: map_db_check_isakmp_profile profile did not match

*Mar 22 22:11:55.027: map_db_find_best did not find matching map

*Mar 22 22:11:55.027: IPSEC(ipsec_process_proposal): proxy identities not supported

*Mar 22 22:11:55.027: ISAKMP:(1004): IPSec policy invalidated proposal with error 32

*Mar 22 22:11:55.027: ISAKMP:(1004): phase 2 SA policy not acceptable! (local 192.0.2.6 remote 192.0.2.8)

*Mar 22 22:11:55.027: ISAKMP: set new node -1577755417 to QM_IDLE

*Mar 22 22:11:55.027: ISAKMP:(1004):Sending NOTIFY PROPOSAL_NOT_CHOSEN protocol 3

spi 1224831320, message ID = -1577755417

*Mar 22 22:11:55.027: ISAKMP:(1004): sending packet to 192.0.2.8 my_port 500 peer_port 500 (R) QM_IDLE

*Mar 22 22:11:55.027: ISAKMP:(1004):Sending an IKE IPv4 Packet.

*Mar 22 22:11:55.027: ISAKMP:(1004):purging node -1577755417

*Mar 22 22:11:55.027: ISAKMP:(1004):deleting node 238869279 error TRUE reason "QM rejected"

*Mar 22 22:11:55.027: ISAKMP:(1004):Node 238869279, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH

*Mar 22 22:11:55.027: ISAKMP:(1004):Old  State = IKE_QM_READY  New State = IKE_QM_READY

R6#

R6#

*Mar 22 22:11:58.827: ISAKMP:(1003):purging SA., sa=48D64614, delme=48D64614

The problem with this configuration is that our ISAKMP Profile does not have a “match identity” statement configured. What it basically means is that it has been configured as a Request Profile only. If the crypto map has an ISAKMP Profile attached, IPSec will try to find a respective SPD entry based on the Profile Information. If there was no match (no “match identity”), or a mismatch in identities, router cannot find the SPD at all which implies that our Proxy ACL will never match.

Now if we add the “match identity” statement the profile, it will also start acting as a Respond Profile which essentially turns it into Request/Respond Profile.

 R6(config)#cry isa prof ISA_PROF

R6(conf-isa-prof)#match identity address 192.0.2.8

R8#ping 10.6.6.6 so l0 rep 2

R6#

-- Output omitted--

*Mar 22 22:20:44.575: ISAKMP (1005): ID payload

next-payload : 8

type         : 1

address      : 192.0.2.8

protocol     : 17

port         : 500

length       : 12

*Mar 22 22:20:44.575: ISAKMP:(0):: peer matches ISA_PROF profile

*Mar 22 22:20:44.575: ISAKMP:(1005):Found ADDRESS key in keyring default

-- Output omitted--

And we are good to go.

 R8#sh cry sess br

Status: A- Active, U - Up, D - Down, I - Idle, S - Standby, N - Negotiating

K - No IKE

ivrf = (none)

Peer     I/F        Username          Group/Phase1_id   Uptime Status

192.0.2.6   Fa0/1                                192.0.2.6 00:00:41    UA

Example 2

Another common usage for ISAKMP Profiles are Certificate ACLs. R7 and R8 has been configured to use digital certificates for VPN connection between them. R7 uses DN for it’s ISAKMP ID and we will configure R8 to apply an ISAKM Profile for this tunnel based on the peer’s CN attribute from the DN.

 R8(config)#crypto pki certificate map CERTMAP 10

R8(ca-certificate-map)# subject-name co cn = r7.ipexpert.com

R8(config)#crypto isakmp profile ISA_PROF2

R8(conf-isa-prof)# match certificate CERTMAP

R8(config)#crypto map MAP1 20 ipsec-isakmp

R8(config-crypto-map)# set isakmp-profile ISA_PROF2

Bring the tunnel up.

 R7#ping 10.8.8.8 so l0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.8.8.8, timeout is 2 seconds:

Packet sent with a source address of 10.7.7.7

.!!!!

Success rate is 80 percent (4/5), round-trip min/avg/max = 1/3/4 ms

R7#

Go to R8 and make sure the profile has been matched.

 Mar 22 23:28:06.155: ISAKMP:(1007): processing ID payload. message ID = 0

Mar 22 23:28:06.155: ISAKMP (1007): ID payload

next-payload : 6

type         : 9

Dist. name   : hostname=R7.ipexpert.com,cn=R7.ipexpert.com,ou=CCIE

protocol     : 17

port         : 500

length       : 83

Mar 22 23:28:06.159: ISAKMP:(0):: peer matches *none* of the profiles

Mar 22 23:28:06.159: ISAKMP:(1007): processing CERT payload. message ID = 0

Mar 22 23:28:06.159: ISAKMP:(1007): processing a CT_X509_SIGNATURE cert

Mar 22 23:28:06.159: ISAKMP:(1007): peer's pubkey isn't cached

Mar 22 23:28:06.171: ISAKMP:(0): certificate map matches ISA_PROF2 profile

Mar 22 23:28:06.171: ISAKMP:(0): Trying to re-validate CERT using new profile

Mar 22 23:28:06.171: ISAKMP:(0): CERT validity confirmed.

R8#sh cry sess remote 192.0.2.7 de

Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection

K - Keepalives, N - NAT-traversal, T - cTCP encapsulation

X - IKE Extended Authentication, F - IKE Fragmentation

Interface: FastEthernet0/1

Profile: ISA_PROF2

Uptime: 00:02:23

Session status: UP-ACTIVE

Peer: 192.0.2.7 port 500 fvrf: (none) ivrf: (none)

Phase1_id: hostname=R7.ipexpert.com,cn=R7.ipexpert.com,ou=CCIE

Desc: (none)

IKE SA: local 192.0.2.8/500 remote 192.0.2.7/500 Active

Capabilities:(none) connid:1018 lifetime:23:57:36

IPSEC FLOW: permit ip 10.8.8.0/255.255.255.0 10.7.7.0/255.255.255.0

Active SAs: 2, origin: crypto map

Inbound:  #pkts dec'ed 4 drop 0 life (KB/Sec) 4440281/3456

Outbound: #pkts enc'ed 4 drop 0 life (KB/Sec) 4440281/3456

Piotr Kaluzny

CCIE #25665 (Security), CCSP, CCNP
Sr. Support Engineer  IPexpert, Inc.
URL: http://www.IPexpert.com

I often come up with ideas for my posts based on questions I have from my students. In a CCIE Security 5-day ILT I had a student ask me the question: Does the ASA use a config-register like a router does?

The answer is yes it does, kinda. Let me explain. First off, lets see what the Cisco ASA configuration register is configured for by default. We do this using the show version command.

ciscoasa# sh ver

Cisco Adaptive Security Appliance Software Version 8.2(1) 

Device Manager Version 6.1(5)

Compiled on Tue 05-May-09 22:45 by builders

System image file is "disk0:/asa821-k8.bin"

Config file at boot was "startup-config"

ciscoasa up 4 mins 13 secs

Hardware:   ASA5510, 256 MB RAM, CPU Pentium 4 Celeron 1600 MHz

Internal ATA Compact Flash, 256MB

BIOS Flash M50FW080 @ 0xffe00000, 1024KB

Encryption hardware device : Cisco ASA-55x0 on-board accelerator (revision 0x0)

Boot microcode   : CN1000-MC-BOOT-2.00

SSL/IKE microcode: CNLite-MC-SSLm-PLUS-2.03

IPSec microcode  : CNlite-MC-IPSECm-MAIN-2.04

0: Ext: Ethernet0/0         : address is 001b.53ff.0360, irq 9

1: Ext: Ethernet0/1         : address is 001b.53ff.0361, irq 9

2: Ext: Ethernet0/2         : address is 001b.53ff.0362, irq 9

3: Ext: Ethernet0/3         : address is 001b.53ff.0363, irq 9

4: Ext: Management0/0       : address is 001b.53ff.0364, irq 11

5: Int: Not used            : irq 11

6: Int: Not used            : irq 5

Licensed features for this platform:

Maximum Physical Interfaces  : Unlimited

Maximum VLANs                : 100

Inside Hosts                 : Unlimited

Failover                     : Active/Active

VPN-DES                      : Enabled

VPN-3DES-AES                 : Enabled

Security Contexts            : 2

GTP/GPRS                     : Disabled

SSL VPN Peers                : 2

Total VPN Peers              : 250

Shared License               : Disabled

AnyConnect for Mobile        : Disabled

AnyConnect for Linksys phone : Disabled

AnyConnect Essentials        : Disabled

Advanced Endpoint Assessment : Disabled

UC Phone Proxy Sessions      : 2

Total UC Proxy Sessions      : 2

Botnet Traffic Filter        : Disabled

This platform has an ASA 5510 Security Plus license.

Serial Number: JMX1122L0VX

Running Activation Key: 0xb3165a49 0xf8ec70c2 0xb8523520 0x9a040038 0xc70a2f90

Configuration register is 0x41

Configuration has not been modified since last system restart.

ciscoasa#

So there we have it.  The configuration register is set to 0×41.  Lets break this down further.  With the ASA configuration register there are five configurable HEX characters. We know from basic HEX that each character is 4 bits and the way that’s numbered is from the left to the right as seen here:

4, 3, 2, 1, 0

Let’s examine these values:

Character 4

When the ASA boots up there is a 10 second period of time where a break countdown is seen:

Cisco Systems ROMMON Version (1.0(11)2) #0: Thu Jan 26 10:43:08 PST 2006

Platform ASA5510

Use BREAK or ESC to interrupt boot.
Use SPACE to begin boot immediately.
Boot in 8 seconds.

By changing the left most character, character 4, you can disable this break countdown.  The only valid values are a 0 or a 1, therefore if the value is 0 the countdown occurs and if set to 1 the countdown is disabled.

Character 3

To understand character three you need to understand a command available to the ASA in configuarion mode.  That command is boot system and it lets you tell the ASA where you would like it to find and load the system image from.  As you can see in the output below you have a few choices, one of which is a TFTP server.

ciscoasa(config)# boot system ?

configure mode commands/options:

disk0:  Path and filename on disk0:

disk1:  Path and filename on disk1:

flash:  Path and filename on flash:

tftp:   A URL beginning with this prefix.

ciscoasa(config)# boot system

Now here is where the third character comes into play.  If for some reason you have told your ASA that it should go out to a TFTP server to get its system configuration and that TFTP server is not available what should happen next?  Well with character three you can tell the ASA to boot to ROMMON instead.  The valid values are 0 or 2, so it its set to 0 it does not boot into ROMMON and if the value is set to 2 it will provided the TFTP boot fails.

Character 2

This one is pretty easy as it’s reserved for future use.  So for now we just ignore it.

Character 1

The acceptable values here are 0,1,4 or 5.  If you set it to 1 you are saying that you want to boot to TFTP defined in ROMMON.  If you set it to 4 you are going to ignore the startup config file, something that’s handy for a password recovery.  Now if you set the value to 5 it actually does both 1 and 4, thus killing two birds with one stone.

Character 0

This is the right most character with values from 1-9.  This section specifies which image you want to boot.
These are all listed in the command reference for ASA under config-register

Password Recovery

So now this brings me to the question, how can I perform a password recovery on an ASA?  Is it similar to the routers?  The answer is “Yes.”  It is similar to the routers.  Here is what you do:

1. Power off the ASA and then power it back on while connected with a terminal application to the console port.
2. During the bootup process hit the escape key when the countdown starts.
3. At the Rommon prompt type confreg:

rommon #1> confreg 0x41
Update Config Register (0x41) in NVRAM...
rommon #1> confreg 

1. Next You’ll want to simply follow the prompts. Accepting the default will modify the config-register value so that you ignore the startup-config next boot.
2. Type boot and you are in business.

Now there is of course, more that we could discuss, but I’ll keep this post short and let you take it and run. Have fun with it, play with the options, and PLEASE break something- just make sure you break something in the labs and not your production network! :)

-Regards

Brandon Carroll – CCIE #23837

Senior Technical Instructor – IPExpert

Mailto: bcarroll@ipexpert.com
Telephone: +1.810.326.1444
Fax: +1.810.454.0130