Basic Cisco Commands and Descriptions

Suggested prerequisite reading
»Cisco Forum FAQ »The most straight-forward way to configure Cisco router: Introduction to CLI

CCNA level Cisco Commands and Descriptions


Following is a list of commands that are applicable to most IOS-based equipments such as routers and switches. Check out the following links for full commands.

IOS Commands 12.4 version on Routers
IOS and Catalyst OS Commands on 6500 series Switches
IOS Commands 12.2 version on 4500 series Switches
IOS Commands 12.2 version on 3560 series Switches
ASA and PIX Firewall OS Commands 6.2 version and above

? Gives you a help screen

0.0.0.0 255.255.255.255 A wildcard command; same as the any command

access-class Applies a standard IP access list to a VTY line

access-list Creates a list of tests to filter the networks 9

any Specifies any host or any network; same as the 0.0.0.0 255.255.255.255 command

Backspace Deletes a single character

bandwidth Sets the bandwidth on a serial interface

banner Creates a banner for users who log into the router

cdp enable Turns on CDP on an individual interface

cdp holdtime Changes the holdtime of CDP packets

cdp run Turns on CDP on a router

cdp timer Changes the CDP update timer

clear counters Clears the statistics from an interface

clear line Clears a connection connected via Telnet to your router

clear mac-address-table Clears the filter table created dynamically by the switch

clock rate Provides clocking on a serial DCE interface

config memory Copies the startup-config to running-config

config network Copies a configuration stored on a TFTP host to running-config

config terminal Puts you in global configuration mode and changes the running-config

config-register Tells the router how to boot and to change the configuration register setting

copy flash tftp Copies a file from flash memory to a TFTP host

copy run start Short for copy running-config startup-config; places a configuration into NVRAM

copy run tftp Copies the running-config file to a TFTP host

copy tftp flash Copies a file from a TFTP host to flash memory

copy tftp run Copies a configuration from a TFTP host to the running-config file

Ctrl+A Moves your cursor to the beginning of the line

Ctrl+D Deletes a single character

Ctrl+E Moves your cursor to the end of the line

Ctrl+F Moves forward one character

Ctrl+R Redisplays a line

Ctrl+Shift+6, then X (keyboard combination) Returns you to the originating router when you telnet to numerous routers

Ctrl+U Erases a line

Ctrl+W Erases a word

Ctrl+Z Ends configuration mode and returns to EXEC

debug dialer Shows you the call setup and teardown procedures

debug frame-relay lmi Shows the lmi exchanges between the router and the Frame Relay switch

debug ip igrp events Provides a summary of the IGRP routing information running on the network

debug ip igrp transactions Shows message requests from neighbor routers asking for an update and the broadcasts sent from your router to that neighbor router

debug ip rip Sends console messages displaying informa-tion about RIP packets being sent and received on a router interface

debug ipx Shows the RIP and SAP information as it passes through the router

debug isdn q921 Shows layer-2 processes

debug isdn q931 Shows layer-3 processes

delete nvram Deletes the contents of NVRAM on a 1900 switch

delete vtp Deletes VTP configurations from a switch

description Sets a description on an interface

dialer idle-timeout number Tells the BRI line when to drop if no interesting traffic is found

dialer list number protocol protocol permit/deny Specifies interesting traffic for a DDR link

dialer load-threshold number inbound/outbound/either Sets the parameters that describe when the second BRI comes up on an ISDN link

dialer map protocol address name hostname number Used instead of a dialer string to provide more security in an ISDN network

dialer string Sets the phone number to dial for a BRI interface

disable Takes you from privileged mode back to user mode

disconnect Disconnects a connection to a remote router from the originating router

duplex Sets the duplex of an interface

enable Puts you into privileged mode

enable password Sets the unencrypted enable password

enable password level 1 Sets the user mode password

enable password level 15 Sets the enable mode password

enable secret Sets the encrypted enable secret password. Supersedes the enable password if set

encapsulation Sets the frame type used on an interface

encapsulation frame-relay Changes the encapsulation to Frame Relay on a serial link

encapsulation frame-relay ietf Sets the encapsulation type to the Internet Engineering Task Force (IETF); connects Cisco routers to off-brand routers

encapsulation hdlc Restores the default encapsulation of HDLC on a serial link

encapsulation isl 2 Sets ISL routing for VLAN

encapsulation ppp Changes the encapsulation on a serial link to PPP

erase startup Deletes the startup-config

erase startup-config Deletes the contents of NVRAM on a router

Esc+B Moves back one word

Esc+F Moves forward one word

exec-timeout Sets the timeout in seconds and minutes for the console connection

exit Disconnects a connection to a remote router via Telnet

frame-relay interface-dlci Configures the PVC address on a serial interface or subinterface

frame-relay lmi-type Configures the LMI type on a serial link

frame-relay map protocol address Creates a static mapping for use with a Frame Relay network

Host Specifies a single host address

hostname Sets the name of a router or a switch

int e0.10 Creates a subinterface

int f0/0.1 Creates a subinterface

interface Puts you in interface configuration mode; also used with show commands

interface e0/5 Configures Ethernet interface

interface ethernet 0/1 Configures interface e0/1

interface f0/26 Configures Fast Ethernet interface 26

interface fastethernet 0/0 Puts you in interface configuration mode for a Fast Ethernet port; also used with show commands

interface fastethernet 0/0.1 Creates a subinterface

interface fastethernet 0/26 Configures interface f0/26

interface s0.16 multipoint Creates a multipoint subinterface on a serial link that can be used with Frame Relay networks

interface s0.16 point-to-point Creates a point-to-point subinterface on a serial link that can be used with Frame Relay

interface serial 5 Puts you in configuration mode for interface serial 5 and can be used for show commands

ip access-group Applies an IP access list to an interface

ip address Sets an IP address on an interface or a switch

ip classless A global configuration command used to tell a router to forward packets to a default route when the destination network is not in the routing table

ip default-gateway Sets the default gateway of the switch

ip domain-lookup Turns on DNS lookup (which is on by default)

ip domain-name Appends a domain name to a DNS lookup

ip host Creates a host table on a router

ip name-server Sets the IP address of up to six DNS servers

IP route Creates static and default routes on a router

ipx access-group Applies an IPX access list to an interface

ipx input-sap-filter Applies an inbound IPX SAP filter to an interface

ipx network Assigns an IPX network number to an interface

ipx output-sap-filter Applies an outbound IPX SAP filter to an interface

ipx ping A Packet Internet Groper used to test IPX packet on an internetwork

ipx routing Turns on IPX routing

isdn spid1 Sets the number that identifies the first DS0 to the ISDN switch

isdn spid2 Sets the number that identifies the second DS0 to the ISDN switch

isdn switch-type Sets the type of ISDN switch that the router will communicate with; can be set at interface level or global configuration mode

K Used at the startup of the 1900 switch and puts the switch into CLI mode

line Puts you in configuration mode to change or set your user mode passwords

line aux Puts you in the auxiliary interface configuration mode

line console 0 Puts you in console configuration mode

line vty Puts you in VTY (Telnet) interface configuration mode

logging synchronous Stops console messages from overwriting your command-line input

logout Logs you out of your console session

mac-address-table permanent Makes a permanent MAC address entry in the filter database

mac-address-table restricted static Sets a restricted address in the MAC filter database to allow only the configured interfaces to communicate with the restricted address

media-type Sets the hardware media type on an interface

network Tells the routing protocol what network to advertise

no cdp enable Turns off CDP on an individual interface

no cdp run Turns off CDP completely on a router

no inverse-arp Turns off the dynamic IARP used with Frame Relay; static mappings must be configured

no ip domain-lookup Turns off DNS lookup

no ip host Removes a hostname from a host table

No IP route Removes a static or default route

no shutdown Turns on an interface

o/r 0x2142 Changes a 2501 to boot without using the contents of NVRAM

ping Tests IP connectivity to a remote device

port secure max-mac-count Allows only the configured amount of devices to attach and work on an interface

ppp authentication chap Tells PPP to use CHAP authentication

ppp authentication pap Tells PPP to use PAP authentication

router igrp as Turns on IP IGRP routing on a router

router rip Puts you in router rip configuration mode

secondary Adds a second IPX network on the same physical interface

Service password-encryption Encrypts the user mode and enable password

show access-list Shows all the access lists configured on the router

show access-list 110 Shows only access list 110

show cdp Displays the CDP timer and holdtime frequencies

show cdp entry * Same as show cdp neighbor detail, but does not work on a 1900 switch

show cdp interface Shows the individual interfaces enabled with CDP

show cdp neighbor Shows the directly connected neighbors and the details about them

show cdp neighbor detail Shows the IP address and IOS version and type, and includes all of the information from the show cdp neighbor command

show cdp traffic Shows the CDP packets sent and received on a device and any errors

Show controllers s 0 Shows the DTE or DCE status of an interface

show dialer Shows the number of times the dialer string has been reached, the idle-timeout values of each B channel, the length of call, and the name of the router to which the interface is connected

show flash Shows the files in flash memory

show frame-relay lmi Shows the LMI type on a serial interface

show frame-relay map Shows the static and dynamic Network layer-to-PVC mappings

show frame-relay pvc Shows the configured PVCs and DLCI numbers configured on a router

show history Shows you the last 10 commands entered by default

show hosts Shows the contents of the host table

show int f0/26 Shows the statistics of f0/26

show inter e0/1 Shows the statistics of interface e0/1

show interface s0 Shows the statistics of interface serial 0

show ip Shows the IP configuration of the switch

show ip access-list Shows only the IP access lists

show ip interface Shows which interfaces have IP access lists applied

show ip protocols Shows the routing protocols and timers associated with each routing protocol configured on a router

show ip route Displays the IP routing table

show ipx access-list Shows the IPX access lists configured on a router

show ipx interface Shows the RIP and SAP information being sent and received on an individual interface; also shows the IPX address of the interface

show ipx route Shows the IPX routing table

show ipx servers Shows the SAP table on a Cisco router

show ipx traffic Shows the RIP and SAP information sent and received on a Cisco router

show isdn active Shows the number called and whether a call is in progress

show isdn status Shows if your SPIDs are valid and if you are connected and communicating with the provider's switch

show mac-address-table Shows the filter table created dynamically by the switch

show protocols Shows the routed protocols and network addresses configured on each interface

show run Short for show running-config; shows the configuration currently running on the router

show sessions Shows your connections via Telnet to remote devices

show snmp Gives you the router's serial number as the "chassis" output

show start Short for show startup-config; shows the backup configuration stored in NVRAM

show terminal Shows you your configured history size

show trunk A Shows the trunking status of port 26

show trunk B Shows the trunking status of port 27

show version Gives the IOS information of the switch, as well as the uptime and base Ethernet address

show vlan Shows all configured VLANs App.

show vlan-membership Shows all port VLAN assignments

show vtp Shows the VTP configuration of a switch

shutdown Puts an interface in administratively down mode

Tab Finishes typing a command for you

telnet Connects, views, and runs programs on a remote device

terminal history size Changes your history size from the default of 10 up to 256

trace Tests a connection to a remote device and shows the path it took through the internetwork to find the remote device

traffic-share balanced Tells the IGRP routing protocol to share links inversely proportional to the metrics

traffic-share min Tells the IGRP routing process to use routes that have only minimum costs

trunk auto Sets the port to auto trunking mode

trunk on Sets a port to permanent trunking mode

username name password password Creates usernames and passwords for authentication on a Cisco router

variance Controls the load balancing between the best metric and the worst acceptable metric

vlan 2 name Sales Creates a VLAN 2 named Sales

vlan-membership static 2 Assigns a static VLAN to a port

vtp client Sets the switch to be a VTP client

vtp domain Sets the domain name for the VTP configuration

vtp password Sets a password on the VTP domain

vtp pruning enable Makes the switch a pruning switch

vtp server Sets the switch to be a VTP server

GNS3 VPCs Tutorial

Many people are not aware of how to make the best use of the features the the Virtual PCs (VPCs) program, so I thought I’d run a small tutorial.
Technical note: This tutorial was written using VPCs version 0.21 – and some of the functions described here will not work exactly the same on 0.20a, and for version 0.16 – you will have to use echo instead of TCP and UDP ping options.
To get started, I’ll assume you are working with the GNS3 Workbench, and have access to some working configurations.  To keep things simple, I’m going to start with the nice triangular network that is found in Wendell Odom’s CCNA books. (If you are not working with the GNS3 Workbench, then download the topology, config and startup.vpc files here).  Or of course, you could just build your own network based on the diagram below.

To get to the working example, start by double-clicking the GNS3 Files-More exercises here icon.  This will open up a folder of exercises, and from there open the exercise 3Router-ICND_Book_Example.  In this folder you will see several files whose name begin with startup… Find the file called startup.2 (eigrp configured) and double click on it.  You will be prompted with:
Do you want to run “startup.2 (eigrp configured)”, or display its contents?”
Click on Run and the lab will load.
In the GNS3 application, from the menu select Control->Start/Resume all devices to start your routers, and once the routers have started, from the menu select Control->Console to all devices icon. After all the routers have started, and the routing protocol converged, you are ready to start learning about VPCs.
Start by activating the VPCs Konsole window. You should see:
Executing the startup file

PC1 : 10.1.1.1 255.255.255.0 gateway 10.1.1.251

PC2 : 10.1.2.1 255.255.255.0 gateway 10.1.2.252

PC3 : 10.1.3.1 255.255.255.0 gateway 10.1.3.253

NAME   IP/CIDR              GATEWAY           MAC                LPORT  RPORT
VPCS1  10.1.1.1/24          10.1.1.251        00:50:79:66:68:00  20000  30000
fe80::2050:79ff:fe66:6800/64
VPCS2  10.1.2.1/24          10.1.2.252        00:50:79:66:68:01  20001  30001
fe80::2050:79ff:fe66:6801/64
VPCS3  10.1.3.1/24          10.1.3.253        00:50:79:66:68:02  20002  30002
fe80::2050:79ff:fe66:6802/64
VPCS4  0.0.0.0/0            0.0.0.0           00:50:79:66:68:03  20003  30003
fe80::2050:79ff:fe66:6803/64
VPCS5  0.0.0.0/0            0.0.0.0           00:50:79:66:68:04  20004  30004
fe80::2050:79ff:fe66:6804/64
VPCS6  0.0.0.0/0            0.0.0.0           00:50:79:66:68:05  20005  30005
fe80::2050:79ff:fe66:6805/64
VPCS7  0.0.0.0/0            0.0.0.0           00:50:79:66:68:06  20006  30006
fe80::2050:79ff:fe66:6806/64
VPCS8  0.0.0.0/0            0.0.0.0           00:50:79:66:68:07  20007  30007
fe80::2050:79ff:fe66:6807/64
VPCS9  0.0.0.0/0            0.0.0.0           00:50:79:66:68:08  20008  30008
fe80::2050:79ff:fe66:6808/64
VPCS[1]>
The [1] shows that your focus is Virtual PC #1. From the output above, you can see that VPCS1‘s IP address is 10.1.1.1 and its default gateway is 10.1.1.251. In the GNS3 topology, it is marked as PC1Bugs.

Lesson #1 – Successful pings

In this lesson, you will see:
  • the purpose of the startup.vpc file
  • how to check your configuration
  • a successful ping to a local address (PC1Bugs’ default gateway – 10.1.1.251)
  • how to check the arp cache using the arp command
  • a successful ping to a remote address (PC2Sam – 10.1.2.1)
  • command abbreviation
It helps if you understand that the reason that your VPCs have any configuration is because there is a startup file that serves as a script file when you run vpcs.  You will learn more about script fiels in Lesson #7, but for now, I want you to understand that your startup.vpc script ended with the show command, and that you can use the show command any time you want to check your configuraiton, so begin by practicing that command.
VPCS[1]> show

NAME   IP/CIDR              GATEWAY           MAC                LPORT  RPORT
VPCS1  10.1.1.1/24          10.1.1.251        00:50:79:66:68:00  20000  30000
       fe80::2050:79ff:fe66:6800/64
VPCS2  10.1.2.1/24          10.1.2.252        00:50:79:66:68:01  20001  30001
       fe80::2050:79ff:fe66:6801/64
VPCS3  10.1.3.1/24          10.1.3.253        00:50:79:66:68:02  20002  30002
       fe80::2050:79ff:fe66:6802/64
VPCS4  0.0.0.0/0            0.0.0.0           00:50:79:66:68:03  20003  30003
       fe80::2050:79ff:fe66:6803/64
VPCS5  0.0.0.0/0            0.0.0.0           00:50:79:66:68:04  20004  30004
       fe80::2050:79ff:fe66:6804/64
VPCS6  0.0.0.0/0            0.0.0.0           00:50:79:66:68:05  20005  30005
       fe80::2050:79ff:fe66:6805/64
VPCS7  0.0.0.0/0            0.0.0.0           00:50:79:66:68:06  20006  30006
       fe80::2050:79ff:fe66:6806/64
VPCS8  0.0.0.0/0            0.0.0.0           00:50:79:66:68:07  20007  30007
       fe80::2050:79ff:fe66:6807/64
VPCS9  0.0.0.0/0            0.0.0.0           00:50:79:66:68:08  20008  30008
       fe80::2050:79ff:fe66:6808/64
Now continue by pinging the default gateway (10.1.1.251), check the arp cache using the arp command, then pinging PC2Sam, (VPCS2) whose IP address you can see from above is 10.1.2.1
VPCS[1]> ping 10.1.1.251
10.1.1.251 icmp_seq=1 ttl=255 time=8.741 ms
10.1.1.251 icmp_seq=2 ttl=255 time=3.502 ms
10.1.1.251 icmp_seq=3 ttl=255 time=1.943 ms
10.1.1.251 icmp_seq=4 ttl=255 time=3.289 ms
10.1.1.251 icmp_seq=5 ttl=255 time=2.909 ms
That worked, so there should be an arp entry for 10.1.1.251.
VPCS[1]> arp
c2:00:10:03:00:00  10.1.1.251
The arp entry is OK. When you ping a remote device, often the first ping times out if a router along the way has go through an arp request.
VPCS[1]> p 10.1.2.1
10.1.2.1 icmp_seq=1 timeout
10.1.2.1 icmp_seq=2 ttl=62 time=8.220 ms
10.1.2.1 icmp_seq=3 ttl=62 time=5.116 ms
10.1.2.1 icmp_seq=4 ttl=62 time=5.171 ms
10.1.2.1 icmp_seq=5 ttl=62 time=6.130 ms

Tip

Notice that in the second ping, I didn’t type the whole word ping, I abbreviated “ping” to “p“. This can be done with any command, so long as you type enough to identify the command.

Lesson #2 – Command history, basic navigation and help

This lesson takes you through:
  • The use of the up, down, left & right arrow keys
  • The help key (?)
  • The hist (history) command
  • Changing from one VPC to another
  • Aborting output by pressing CTRL+c
If you press the up-arrow then down-arrow keys, you will see that you can recall your previous commands. You can further edit these commands using the left-arrow and right-arrow keys. The command ? will give you a page of help, and from that help you can see there is a command hist which shows a list of the last 50 commands you have used – and hist can be abbreviated to h.
VPCS[1]> ?

show                       Print the net configuration of PCs
d                          Switch to the PC[d], d is digit, range 1 to 9
history                    List the command history
ip [arguments]             Configure PC's IP settings
dhcp                       Configure host/gateway address using DHCP
arp                        Show arp table
ping address [options]     Ping the network host
tracert address [maxhops]  Print the route packets take to network host
echo [text]                Display text in output
clear [arguments]          Clear ip/ipv6, arp/neighbor cache
set [arguments]            Set hostname, connection port and echo on or off
load filename              Load the configuration/script from the file 'filename'
save filename              Save the configuration to the file 'filename'
ver                        Show version
?                          Print help
quit                       Quit program


VPCS[1]> h
 1     show
2     ping 10.1.1.251
3     arp
4     p 10.1.2.1
5     ?
6     h

Tip

Your history is kept from session to session. If you quit a VPCs session, it saves the current command history in a file called vpcs.hist, so even when you run this lab next time, your command history will be preserved from last time!
To access one of the other VPCs, type a digit on a line by itself. In the example below, notice how I enter 2 to move to PC2, and then use the up-arrow to retrieve the ping command.
VPCS[1]> 2
VPCS[2]> ping 10.1.1.251

10.1.1.251 icmp_seq=1 ttl=254 time=4.113 ms
10.1.1.251 icmp_seq=2 ttl=254 time=7.437 ms
^C

Tip

You can stop a ping (or tracert) command by pressing CTRL+c. Notice how the last ping shows only two ping replies, then ^C on the last line, indicating that the ping was interrupted

Lesson #3 – Unsuccessful pings

This lesson will illustrate:
  • An arp request failure trying to reach a non-existant local address
  • A ping timeout trying to reach a non-existant remote address
  • An ICMP type:3, code:1 (Destination Host Unreachable) reply
This time you will ping three non-existant addresses, one on PC1Bugs’ local subnet, one to another subnet off the Yosemite router in the scenario, and the other to an address that is not part of this network at all.
VPCS[2]> 1
VPCS[1]> ping 10.1.1.2
host (10.1.1.2) not reachable

VPCS[1]> ping 10.1.2.2
10.1.2.2 icmp_seq=1 timeout
10.1.2.2 icmp_seq=2 timeout
10.1.2.2 icmp_seq=3 timeout
10.1.2.2 icmp_seq=4 timeout
10.1.2.2 icmp_seq=5 timeout

VPCS[1]> ping 4.4.4.4
*10.1.1.251 icmp_seq=1 ttl=255 time=4.660 ms (ICMP type:3, code:1, Destination host unreachable)
*10.1.1.251 icmp_seq=2 ttl=255 time=2.389 ms (ICMP type:3, code:1, Destination host unreachable)
*10.1.1.251 icmp_seq=3 ttl=255 time=2.793 ms (ICMP type:3, code:1, Destination host unreachable)
*10.1.1.251 icmp_seq=4 ttl=255 time=3.353 ms (ICMP type:3, code:1, Destination host unreachable)
*10.1.1.251 icmp_seq=5 ttl=255 time=3.166 ms (ICMP type:3, code:1, Destination host unreachable)
Notice that the first ping says that the local IP (10.1.1.2) was not reachable – in other words, VPCs sent an ARP request, but did not receive a reply. See how this is different to the second ping, which would have been sent all the way to Yosemite router, and of course Yosemite would not have been able to reach the non-existant 10.1.2.2, so the pings timeout.
For the third ping to 4.4.4.4, the ICMP packet was sent to the default gateway as well, but this time the gateway did not have a path to 4.4..4.4, so the gateway sent back an ICMP message, type:3, code:1, which equates to Destination Unreachable (type=3), Host Unreachable (code=1). (See http://www.iana.org/assignments/icmp-parameters
for a list of ICMP code/type numbers)

Configuration Update

To explore the many other ICMP replies you might get, you will first have to change some of the routing tables on these routers to make them think the network is different to what it physically is. In summary, you will:
  • Tell router Albuquerque that the 2.0.0.0/8 network is reachable via the Seville router (so the Seville router will send back Destination Unreachable messages)
  • Tell router Albuquerque that the 3.0.0.0/8 network is reachable via the Seville router, AND tell the Seville router that 3.0.0.0/8 is reachable via Albuquerque (setting up a routing loop, so packets sent to a 3.x.x.x address will loop until the TTL expires)
  • Apply an access list on Seville to stop any TCP/UDP packets on port 80 reaching PC3Elmer (so the Seville router will send ICMP Destination Administratively Prohibited messages back to the sender)
  • Make sure Albuquerque is NOT an http server, so when you send a TCP ping to its port 80, it will reply with a TCP RST
  • Make sure Albuquerque is both a tcp small server, so when you send a TCP ping to the TCP echo port (port 7) it will reply
  • Make sure Seville is an http server, so when you send a TCP ping to its port 80, it will reply
To do this, cut and paste the following lines into the configuration of Albuquerque router:
enable
configure terminal
ip route 2.0.0.0 255.0.0.0 10.1.130.253
ip route 3.0.0.0 255.0.0.0 10.1.130.253
no ip http server
service tcp-small-servers
end
And cut and paste the following lines into the configuration of Seville router:
enable
configure terminal
ip route 3.0.0.0 255.0.0.0 10.1.130.251
access-list 101 deny tcp any host 10.1.3.1 eq 80
access-list 101 deny udp any host 10.1.3.1 eq 80
access-list 101 permit ip any any
interface fa0/0
ip access-group 101 out
exit
ip http server
end

Lesson #4 – Explore ICMP replies and options

This lesson shows you how to interpret a variety of ICMP replies and options.  In particular you will explore:
  • an ICMP type:3, code:1 (Destination Host Unreachable) reply from a remote router
  • an ICMP type:11, code:0 (TTL expired) reply
  • viewing the options of the ping command
  • controlling the TTL of the ping packets you send
To achieve this you will need to:
  • send a ping from PC1Bugs to something on the 2.0.0.0 network.  Albuquerque should now send it on to Seville, and Seville reply with an ICMP Destination Unreachable.
  • send a ping from PC1Bugs to something on the 3.0.0.0 network.  Albuquerque should now send it on to Seville, and Seville return it to Albuquerque and so on.
  • issue the ping command without an ip address to see the help about the ping options.
  • issue the ping command with the -T option to control the TTL values.
Start with a ping to something on the 2.0.0.0 network.
VPCS[1]> ping 2.2.2.2
**10.1.130.253 icmp_seq=1 ttl=254 time=5.326 ms (ICMP type:3, code:1, Destination host unreachable)
*10.1.130.253 icmp_seq=2 ttl=254 time=9.323 ms (ICMP type:3, code:1, Destination host unreachable)
*10.1.130.253 icmp_seq=3 ttl=254 time=6.267 ms (ICMP type:3, code:1, Destination host unreachable)
*10.1.130.253 icmp_seq=4 ttl=254 time=5.789 ms (ICMP type:3, code:1, Destination host unreachable)
Note how the pings went to Seville, and Seville (10.1.130.253) replied with the ICMP Destination Unreachable messages (type:3, code:1) as expected.
Now test the loop condition you set up.
VPCS[1]> ping 3.3.3.3
*10.1.130.253 icmp_seq=1 ttl=254 time=83.237 ms (ICMP type:11, code:0, TTL expired in transit)
*10.1.130.253 icmp_seq=2 ttl=254 time=60.351 ms (ICMP type:11, code:0, TTL expired in transit)
*10.1.130.253 icmp_seq=3 ttl=254 time=54.258 ms (ICMP type:11, code:0, TTL expired in transit)
*10.1.130.253 icmp_seq=4 ttl=254 time=72.232 ms (ICMP type:11, code:0, TTL expired in transit)
*10.1.130.253 icmp_seq=5 ttl=254 time=74.451 ms (ICMP type:11, code:0, TTL expired in transit)
Note how the pings looped until the TTL expired at Seville, which sent back ICMP TTL Expired messages (type:11).  Try that again, but this time change the TTL of the packets sent so that they start with an odd number rather than the default even number (64).   Issue a ping command by itself to see the ping options.
VPCS[1]> ping

ping address [options], Ping the network host, Ctrl+C to stop the command
    -1             ICMP mode, default
    -2             UDP mode
    -3             TCP mode
    -P [protocol]  Same as above, setting ip protocol
                    1 - icmp, 17 - udp, 6 - tcp
    -c count       packet count
    -l size        data size
    -T ttl         set TTL, default 64
    -p port        source and destination port
    -f flag        tcp head flag, |C|E|U|A|P|R|S|F|
                             bits |7 6 5 4 3 2 1 0|
    -t             send packet until interrupt by Ctrl+C
    -i ms          wait 'ms' milliseconds between sending each packet
    -w ms          wait 'ms' milliseconds to receive the response
Notice that the option to control the starting TTL value is -T. Use it in the following command.
VPCS[1]> ping 3.3.3.3 -T 3
*10.1.130.251 icmp_seq=1 ttl=255 time=6.718 ms (ICMP type:11, code:0)
*10.1.130.251 icmp_seq=2 ttl=255 time=4.172 ms (ICMP type:11, code:0)
^C
Note that this time, the TTL Expired (Type=11) message came from Albuquerque (10.1.130.252), because the TTL expired after 3 hops.

Lesson #5 – TCP & UDP pinging

This lesson shows you how to send packets to TCP and UDP ports, and interpret the results. You will:
  • use the -P and -p options with the ping command
  • see a successful VPCs TCP ping connection
  • learn how VPCs TCP ping works
  • observe an ICMP Administratively Denied (type:3, code:13) reply to a TCP ping
  • observe a TCP RST reply
  • see a successful VPCs UDP ping
  • observe that an unsuccessful UDP ping draws a ICMP Destination Port Unreachable (type:3, code:3)
To test the Access Control List (ACL), you will use one of VPCs most powerful features – the ability to send packets to TCP and UDP ports.  To do this you will:
  • add a -P 6 (protocol=6, TCP) and a -p 23 (TCP port 23, telnet) and a -p 80 (TCP port 80, HTTP) to your “TCP” pings to see what happens when a TCP “ping” gets through, and when a TCP is denied by an ACL.
  • test a TCP “ping” to the Seville router as well, because you made it a HTTP server when you pasted the ip http server command.
  • see what happens when you try to send a “TCP ping” to Albuquerque TCP port 80 (Albuquerque is NOT an HTTP server – you made sure by pasting a no ip http server command)
  • observe the result when you send a TCP ping to the default TCP port (which happens to be port 7) on Albuquerque – that should work because you issued a service tcp-small-servers command on Albuquerque.
So here’s the plan:
From PC1Bugs
  • Ping PC3Elmer’s TCP port 23 – that should work
  • Ping PC3Elmer’s TCP port 80 – that should be denied by the ACL
  • Ping Seville router’s TCP port 80 – that should work, because you issued an ip http server command.
  • Ping Albuquerque router’s TCP port 80 – that should draw a TCP reset, because issued a no ip http server command. It is NOT an http server.
  • Ping Albuquerque router’s default TCP port (TCP port 7 is the TCP echo port) – that should work, because you issued a service tcp-small-servers command.
VPCS[1]> ping 10.1.3.1 -P 6 -p 23
Connect   23@10.1.3.1 seq=1 ttl=62 time=1311.560 ms
SendData  23@10.1.3.1 seq=1 ttl=62 time=12.115 ms
Close     23@10.1.3.1 seq=1 ttl=62 time=10.617 ms
Connect   23@10.1.3.1 seq=2 ttl=62 time=9.944 ms
SendData  23@10.1.3.1 seq=2 ttl=62 time=10.744 ms
Close     23@10.1.3.1 seq=2 ttl=62 time=17.752 ms
Connect   23@10.1.3.1 seq=3 ttl=62 time=8.096 ms
SendData  23@10.1.3.1 seq=3 ttl=62 time=12.436 ms
Close     23@10.1.3.1 seq=3 ttl=62 time=15.322 ms
Connect   23@10.1.3.1 seq=4 ttl=62 time=12.134 ms
SendData  23@10.1.3.1 seq=4 ttl=62 time=20.260 ms
Close     23@10.1.3.1 seq=4 ttl=62 time=17.187 ms
Connect   23@10.1.3.1 seq=5 ttl=62 time=13.777 ms
SendData  23@10.1.3.1 seq=5 ttl=62 time=11.590 ms
Close     23@10.1.3.1 seq=5 ttl=62 time=14.084 ms
A VPCs TCP ping works like this:
  1. A TCP SYN is sent, and if a TCP SYN/ACK is received, the VPC finishes the connection with an ACK and displays Connect, along with the time taken.
  2. A data packet (containing a few CR characters) is sent, and if TCP ACK is received, SendData is displayed, along with the time taken.
  3. A TCP FIN/ACK is sent, and if both an ACK and FIN/ACK are returned, the VPC finishes the termination handshake with an ACK and displays Close, along with the time taken.
    Sometimes the remote system, if it is not another VPC, may respond with a RST rather than a FIN/ACK, in which case VPC will display Close xx@x.x.x.x timeout
VPCS[1]> ping 10.1.3.1 -P 6 -p 80
*10.1.130.253 tcp_seq=1 ttl=254 time=9.455 ms (ICMP type:3, code:13, Communication administratively prohibited)
*10.1.130.253 tcp_seq=3 ttl=254 time=3.924 ms (ICMP type:3, code:13, Communication administratively prohibited)
*10.1.130.253 tcp_seq=5 ttl=254 time=6.600 ms (ICMP type:3, code:13, Communication administratively prohibited)
Note how the Seville router sent an ICMP Destination Unreachable (type:3) Administratively Prohibited (code:13) message for the TCP ping to PC3Elmer’s port 80. What a great tool to test ACLs!!
VPCS[1]> ping 10.1.3.253 -P 6 -p 80
Connect   80@10.1.3.253 seq=1 ttl=254 time=12.448 ms
SendData  80@10.1.3.253 seq=1 ttl=254 time=215.492 ms
Close     80@10.1.3.253 seq=1 ttl=254 time=16.636 ms
Connect   80@10.1.3.253 seq=2 ttl=254 time=5.434 ms
SendData  80@10.1.3.253 seq=2 ttl=254 time=234.653 ms
Close     80@10.1.3.253 seq=2 ttl=254 time=13.759 ms
Connect   80@10.1.3.253 seq=3 ttl=254 time=6.927 ms
SendData  80@10.1.3.253 seq=3 ttl=254 time=232.419 ms
Close     80@10.1.3.253 seq=3 ttl=254 time=10.550 ms
Connect   80@10.1.3.253 seq=4 ttl=254 time=6.130 ms
SendData  80@10.1.3.253 seq=4 ttl=254 time=235.334 ms
Close     80@10.1.3.253 seq=4 ttl=254 time=11.846 ms
Connect   80@10.1.3.253 seq=5 ttl=254 time=5.188 ms
SendData  80@10.1.3.253 seq=5 ttl=254 time=202.523 ms
Close     80@10.1.3.253 seq=5 ttl=254 time=12.864 ms
That proves that Seville is indeed listening on port 80!
VPCS[1]> ping 10.1.1.251 -P 6 -p 80
Connect   80@10.1.1.251 RST returned
Connect   80@10.1.1.251 RST returned
Connect   80@10.1.1.251 RST returned
Connect   80@10.1.1.251 RST returned
Connect   80@10.1.1.251 RST returned
As expected, Albuquerque is NOT listening on port 80, and says so!
VPCS[1]> ping 10.1.1.251 -P 6 
Connect   7@10.1.1.251 seq=1 ttl=255 time=8.001 ms
SendData  7@10.1.1.251 seq=1 ttl=255 time=6.384 ms
Close     7@10.1.1.251 seq=1 ttl=255 time=9.536 ms
Connect   7@10.1.1.251 seq=2 ttl=255 time=4.909 ms
SendData  7@10.1.1.251 seq=2 ttl=255 time=4.741 ms
Close     7@10.1.1.251 seq=2 ttl=255 time=6.241 ms
Connect   7@10.1.1.251 seq=3 ttl=255 time=3.352 ms
SendData  7@10.1.1.251 seq=3 ttl=255 time=4.962 ms
Close     7@10.1.1.251 seq=3 ttl=255 time=9.370 ms
Connect   7@10.1.1.251 seq=4 ttl=255 time=4.476 ms
SendData  7@10.1.1.251 seq=4 ttl=255 time=5.269 ms
Close     7@10.1.1.251 seq=4 ttl=255 time=7.219 ms
Connect   7@10.1.1.251 seq=5 ttl=255 time=4.735 ms
SendData  7@10.1.1.251 seq=5 ttl=255 time=7.637 ms
Close     7@10.1.1.251 seq=5 ttl=255 time=7.043 ms
Note that the last ping didn’t specify a port number – I just specified the protocol,  (-P 6) and the VPC sent it to TCP port 7, which is the well-known TCP echo port.

Tip

VPCs has some shortcuts for IP protocols 1, 6, & 17 – see the output of the ping help above. I could have said ping 10.1.1.251 -3 instead of ping 10.1.1.251 -P 6. Personally I prefer -P 6, because it makes me remember that TCP is IP protocol #6, which may be handy information in an exam one day!
And as you can see from the output above, all predictions were correct. That is:
  • The Ping to PC3Elmer’s TCP port 23 worked
  • The Ping to PC3Elmer’s TCP port 80 was denied by the ACL
  • The Ping to Seville router’s TCP port 80 worked.
  • The Ping to Albuquerque router’s TCP port 80 returned a TCP reset, because it is NOT an http server.
  • The Ping to Albuquerque router’s default TCP port worked, because you issued a service tcp-small-servers command.
Now let’s try some UDP pings. This time you will see some new ICMP replies – specifically ICMP Destination Port unreachable. When you send a TCP SYN packet to a device that is not listening on a particular port, the target device sends back a TCP RST (reset) segment. However, if you send a UDP packet to a device that is not listening on a particular port, the target device sends back am ICMP type:3, code:3 – Destination Port unreachable.
So here’s the plan:
From PC1Bugs
  • Ping PC3Elmer’s UDP port 99 – that should work – VPCs respond to all UDP packets from other VPCs
  • Ping PC3Elmer’s UDP port 80 – that should be denied by the ACL
  • Ping Seville router’s UDP port 99 – that should see an ICMP Destination Port Unreachable reply (type:3, code:3)
VPCS[1]> ping 10.1.3.1 -P 17 -p 99
10.1.3.1 udp_seq=1 ttl=62 time=7.920 ms
10.1.3.1 udp_seq=2 ttl=62 time=5.623 ms
10.1.3.1 udp_seq=3 ttl=62 time=4.979 ms
10.1.3.1 udp_seq=4 ttl=62 time=8.003 ms
10.1.3.1 udp_seq=5 ttl=62 time=6.732 ms

VPCS[1]> ping 10.1.3.1 -P 17 -p 80
**10.1.130.253 udp_seq=1 ttl=254 time=6.053 ms (ICMP type:3, code:13, Communication administratively prohibited)
*10.1.130.253 udp_seq=2 ttl=254 time=4.337 ms (ICMP type:3, code:13, Communication administratively prohibited)
^C

VPCS[1]> ping 10.1.3.253 -P 17 -p 99
*10.1.3.253 udp_seq=1 ttl=254 time=12.187 ms (ICMP type:3, code:3, Destination port unreachable)
*10.1.3.253 udp_seq=2 ttl=254 time=6.813 ms (ICMP type:3, code:3, Destination port unreachable)
^C
And as you can see from the output, all predictions were correct. That is:
  • The Ping to PC3Elmer’s UDP port 99 worked
  • The Ping to PC3Elmer’s UDP port 80 was denied by the ACL
  • The Ping to Seville router’s TCP port 99 caused an ICMP Destination Port Unreachable reply (type:3, code:3) reply.

Lesson #6 – Trying Tracert (traceroute)

Tracert actually uses the fact that routers send ICMP destination unreachable messages to trace the path through a network.  In this lesson, you will:
  • watch a tracert succeed
  • watch a tracert strike a ICMP Destination Unreachable reply along the path
  • watch a tracert detect a loop
  • control the number of hops that tracert will trace for
Using the existing topology, trace the path from PC1Bugs to
  • PC2Sam (10.1.2.1) – this should succeed
  • unknown remote address, 4.4.4.4 and 2.2.2.2 – you can expect that PC1Bugs’ default gateway (Albuquerque) will reply with a Destination Unreachable for the 4.4.4.4 address, and since you added a route to Albuquerque directing traffic to the 2.0.0.0 network to Seville, you can expect that Seville will reply with a Destination Unreachable for the trace to 2.2.2.2
  • unknown remote address, 3.3.3.3 – you can expect that Albuquerque will forward this to Seville, and Seville pass it back to Albuquerque and so on because I have engineered the loop with the route statements you added earlier.
VPCS[1]> trace 4.4.4.4
traceroute to 4.4.4.4, 64 hops max, press Ctrl+C to stop
 1   10.1.1.251   3.669 ms  1.977 ms  3.064 ms
 2   *10.1.1.251   2.238 ms (ICMP type:3, code:1, Destination host unreachable)
The ICMP type:3, code:1 is an ICMP Destination Host Unreachable, as was predicted.
Note that the default gateway router (Albuquerque) did actually reply to the first round of packets sent with a TTL of 1, proving that routers actually make the routing decision before they decrement the TTL.
Note that reply 2 has a * character at the beginning of the line to indicate that this reply indicates a failure of some kind.
VPCS[1]> trace 2.2.2.2
traceroute to 2.2.2.2, 64 hops max, press Ctrl+C to stop
 1   10.1.1.251   2.579 ms  3.204 ms  3.462 ms
 2   10.1.130.253   7.917 ms  4.209 ms  4.673 ms
 3   *10.1.130.253   12.890 ms (ICMP type:3, code:1, Destination host unreachable)
This time the trace got to Seville, but Seville has no route to the 2.0.0.0 network, so replied with the ICMP Destination Host Unreachable (type:3, code:1)
VPCS[1]> trace 3.3.3.3
traceroute to 3.3.3.3, 64 hops max, press Ctrl+C to stop
 1   10.1.1.251   2.979 ms  1.700 ms  2.143 ms
 2   10.1.130.253   6.280 ms  4.980 ms  5.108 ms
 3   10.1.130.251   9.438 ms  9.512 ms  4.398 ms
 4   10.1.130.253   4.758 ms  6.241 ms  6.453 ms
 5   10.1.130.251   6.460 ms  10.098 ms  7.811 ms
 6   10.1.130.253   8.771 ms  9.053 ms  8.533 ms
 7   10.1.130.251   11.545 ms  13.584 ms  9.932 ms
 8   10.1.130.253   10.501 ms  11.806 ms  12.095 ms
 9   10.1.130.251   55.977 ms  60.101 ms^C  *
As expected, the trace ran back and forth between Albuquerque and Seville.
Note I had to stop the trace by hitting CTRL+c, but I could have limited the number of replies by specifying the maxhops option.
VPCS[1]> trace 3.3.3.3 4
traceroute to 3.3.3.3, 4 hops max, press Ctrl+C to stop
 1   10.1.1.251   3.577 ms  2.185 ms  1.404 ms
 2   10.1.130.253   5.021 ms  3.862 ms  5.262 ms
 3   10.1.130.251   4.358 ms  4.557 ms  4.890 ms
 4   10.1.130.253   9.543 ms  9.636 ms  5.829 ms
By specifying the number 4 at the end of the tracert command, I didn’t need to hit CTRL+c to stop the trace this time.

Lesson #7 – Fun Stuff

There are a few other features that haven’t been explored yet, but can be very useful especially for documentation and test scripts.  You are about to explore:
  • Changing the VPCs display name
  • Changing a VPCs IP address
  • Creating a VPCs script file
  • Running a VPCs script file
  • Editing a VPCs script
  • How to use the echo command
  • How to control the output of scripts the set echo on and set echo off commands
In this lesson you will:
  • Change VPCs 1 -3 to names to match the diagram – ie PC1=Bugs, PC2=Sam and PC3=Elmer using the set pcname command.
  • Change the IP address of PC2Sam to 10.1.2.2/24
  • Save your configuration to a file called script1 using the save command
  • Execute a series of commands to load them into your history buffer
  • Quit VPCs to save your history buffer
  • Use a text editor to combine parts of your history buffer (vpcs.hist) with your script file (script1) to create a test script called script2
  • Document your script with comments and echo commands
  • load the text script2 into VPCs using the load command
  • change the behaviour of your script by using the set echo on and set eco off commands
Start with the name changing as shown below.  Note that you can get help about the set command by typing set, and that the first attempt to set the pcname to PC1Bugs shows you that the maximum length of a pcname is 6 characters
VPCS[1]> set   

set [lport|rport|pcname|echo], Set connection port, hostname or echo setting
    lport port     local port, listen by VPCS
    rport port     remote port, listen by dynamips
    pcname name    rename the current pc
    echo [on|off]  set echoing on or off

VPCS[1]> set pcname PC1Bugs
Hostname is too long. (should be less than 6)

VPCS[1]> set pcname Bugs   

Bugs[1]> 2
VPCS[2]> set pcname Sam 

Sam[2]> 3
VPCS[3]> set pcname Elmer

Elmer[3]>
So far, the PC IP addresses have stayed constant, so for practice, change Sam’s IP address to 10.1.2.2, leave the gateway as 10.1.2.252 and set the mask to 24 bits
Elmer[3]> 2
Sam[2]> ip          

ip [dhcp|auto|address], Configure PC's IP settings
    dhcp         Configure host/gateway address using DHCP, only ipv4
    auto         Stateless address autoconfiguration, only ipv6
                 PC will try to get the ipv6 address from the router at startup
    address [gateway] [CIDR]
                 set the PC's ip, gateway's ip and network mask
                 Default IPv4 CIDR is 24, IPv6 is 64. In the ether mode,
                 the ip of the tapx is the maximum host ID of the subnet.

                 'ip 10.1.1.70 10.1.1.65 26', set the host ip to 10.1.1.70,
                 the gateway ip to 10.1.1.65, the netmask to 255.255.255.192,
                 the tapx ip to 10.1.1.126 in the ether mode.

Sam[2]> ip 10.1.2.2 10.1.2.252 24
PC2 : 10.1.2.2 255.255.255.0 gateway 10.1.2.252
Note that since the default mask is 24 bits, I could have just issued the command, ip 10.1.2.2 10.1.2.152
Now that you have changed the hostnames and one of the IP addresses, it is a good time to save your configuration, and quit VPCs, which will force VPCs to save the history file, which you will need in the next step.
Sam[2]> save script1
.........  done

Sam[2]> quit
Of course, if you are running VPCs from within the GNS3 Workbench environment, VPCs will actually automatically restart, because I have run this instance of VPCs from within a script which saves people from accidentally quitting.  However that doesn’t matter, because you saved your configuration remember?
So now reload your configuration, and check it with the show command.  You should see all your pcnames restored, and the ip address for Sam has changed.
VPCS[1]> load script1

Executing the startup file

PC1 : 10.1.1.1 255.255.255.0 gateway 10.1.1.251

PC2 : 10.1.2.2 255.255.255.0 gateway 10.1.2.252

PC3 : 10.1.3.1 255.255.255.0 gateway 10.1.3.253

VPCS[9]> showNAME   IP/CIDR              GATEWAY           MAC                LPORT  RPORT
Bugs   10.1.1.1/24          10.1.1.251        00:50:79:66:68:00  20000  30000
       fe80::2050:79ff:fe66:6800/64
Sam    10.1.2.2/24          10.1.2.252        00:50:79:66:68:01  20001  30001
       fe80::2050:79ff:fe66:6801/64
Elmer  10.1.3.1/24          10.1.3.253        00:50:79:66:68:02  20002  30002
       fe80::2050:79ff:fe66:6802/64
VPCS4  0.0.0.0/0            0.0.0.0           00:50:79:66:68:03  20003  30003
       fe80::2050:79ff:fe66:6803/64
VPCS5  0.0.0.0/0            0.0.0.0           00:50:79:66:68:04  20004  30004
       fe80::2050:79ff:fe66:6804/64
VPCS6  0.0.0.0/0            0.0.0.0           00:50:79:66:68:05  20005  30005
       fe80::2050:79ff:fe66:6805/64
VPCS7  0.0.0.0/0            0.0.0.0           00:50:79:66:68:06  20006  30006
       fe80::2050:79ff:fe66:6806/64
VPCS8  0.0.0.0/0            0.0.0.0           00:50:79:66:68:07  20007  30007
       fe80::2050:79ff:fe66:6807/64
VPCS9  0.0.0.0/0            0.0.0.0           00:50:79:66:68:08  20008  30008
       fe80::2050:79ff:fe66:6808/64

VPCS[9]> 2
Sam[2]>
The next task is to create a new file which will become our second script file, and you will use the contents of the script1 you saved in VPCs and the contents of vpcs.hist to create this script. In a file browser, navigate to the folder /opt/GNS3/Project/3Router_ICND_Book_Example – it is the same folder where you fond the startup.2 (eigrp configured) file when you started in Lesson #1.
Create a blank file called script2 in this folder – you can do this by clicking File->Create Document -> Empty file, and giving it the name script2.
Double click on this file to open it in gedit.  Put a comment right at the top something like this:
#Script file created for testing vpcs

Tip

Comments can be placed in script files by starting the comment with the # character.
Now locate the file called script1 in the same directory and double-click on it to open it also in gedit. It should look like this:
1
set pcname Bugs
ip 10.1.1.1 10.1.1.251 24
2
set pcname Sam
ip 10.1.2.2 10.1.2.252 24
3
set pcname Elmer
ip 10.1.3.1 10.1.3.253 24
4
set pcname VPCS
5
set pcname VPCS
6
set pcname VPCS
7
set pcname VPCS
8
set pcname VPCS
9
set pcname VPCS
Copy and paste the first 9 lines into your script2 file. It should now look like:
#Script file created for testing vpcs
1
set pcname Bugs
ip 10.1.1.1 10.1.1.251 24
2
set pcname Sam
ip 10.1.2.2 10.1.2.252 24
3
set pcname Elmer
ip 10.1.3.1 10.1.3.253 24
Now open (in the same directory) the file called vpcs.hist. In it you will find all the commands you have entered so far. If you have followed this tutorial to the letter, it should look like this:
show
ping 10.1.1.251
arp
p 10.1.2.1
?
h
2
p 10.1.2.1
1
ping 10.1.1.2
ping 10.1.2.2
ping 4.4.4.4
ping 2.2.2.2
ping 3.3.3.3
ping
ping 3.3.3.3 -T 3
ping 10.1.3.1 -P 6 -p 23
ping 10.1.3.1 -P 6 -p 80
ping 10.1.3.253 -P 6 -p 80
ping 10.1.1.251 -P 6 -p 80
ping 10.1.3.1 -P 17 -p 99
ping 10.1.3.1 -P 17 -p 80
ping 10.1.3.253 -P 17 -p 99
trace 4.4.4.4
trace 2.2.2.2
trace 3.3.3.3
trace 3.3.3.3 4
set
set pcname Bugs
2
set pcname Sam
3
set pcname Elmer
2
ip
ip 10.1.2.2 10.1.2.252 24
save script1
quit
Now I want you to copy all of the lines from vpcs.hist EXCEPT the last 2 lines – the save command and the quit command at the end. You are about to paste them in script2, but there is one more task before we do that!
Back in the script2 file, go to the end of the file and add these commands:
1
echo Here is the beginning of the history file
The command 1 on a line by itself is to ensure that we start at the correct PC. The echo command will display a message as our script is executing. Now, immediately after these lines, paste the contents of vpcs.hist that you just copied, and save the file. Don’t close it, you have more to do yet.
And now let’s see this script run! Back in VPCs, load this updated script.
load script2
And watch all those commands being executed – did you see the message “Here is the beginning of the history file” appear?
But if you look closely, you will see there is a problem – you can’t see exactly which commands are producing which output. Never fear there is an answer for that.
Go back to your script2 file in the editor, and add the single command at the top of the file (after your comment)
set echo on
Save the file again, and load it one more time. If you get sick of waiting for it to complete, hit CTRL+c

Tip

Script files can be aborted by hitting CTRL+c
Now notice that while the script is executing, the command that produces the output is displayed before the command. This is the effect of the set echo on command. However, there is a catch.
Enter a command like ping 10.1.1.251
Bugs[1]> ping 10.1.1.251
ping 10.1.1.251
10.1.1.251 icmp_seq=1 ttl=255 time=2.756 ms
10.1.1.251 icmp_seq=2 ttl=255 time=2.895 ms
10.1.1.251 icmp_seq=3 ttl=255 time=3.437 ms
10.1.1.251 icmp_seq=4 ttl=255 time=3.104 ms
10.1.1.251 icmp_seq=5 ttl=255 time=4.335 ms
See how the command is echoed on the output after you type it? This can be corrected by reversing the set echo on command we put at the beginning of the file by putting a set echo off at the end of the file – but of course you will have to let the whole script run without interruption for it to take effect. Of course you could just type: set echo off at the vpcs command line to turn it off yourself.

Footnote: What VPCs DOESN’T do
VPCs is a VERY useful troubleshooting tool when used in your GNS3 environment, and does everything you’d want it to do almost 100% of the time. There are some minor features not implemented that you might want to be aware of:
  1. VPCs has no concept of MTU or IP fragmentation.  If you ask it to send a ping of 2000 bytes, it will.  All in one packet!  This makes it impossible to use to test IP fragmentation.
  2. Still on the fragmentation, if you send a VPCs host a ping that arrives in fragments, it can’t put the fragments back together, so the pings will fail.
  3. The DF (Don’t Fragment) bit on your pings is set by default, so you can test links with MTUs less than 1500 OK – however, if you want to set fragmentation across that link, you can’t turn the DF bit off.
  4. Similarly, other fancy IP options, like record route can’t be set either.
  5. VPCs don’t have any layer 3 routing capability beyond a default gateway.  Therefore VPCs can’t act upon ICMP re-directs if it ever receives one.

Thanks to http://rednectar.net

Understanding PIX Firewall/ASA

Official Cisco Support
Using PIX Firewall
Cisco Security Appliance Command Line Configuration Guide, Version 7.0

Security Level as Stateful Firewall feature foundation

Cisco ASA/PIX Firewall is designed as stateful firewall. From Cisco implementation perspective, there is a concept of Security Level as foundation of all stateful firewall features.

In basic firewall concept, there are three security zones. The first zone is Untrusted network where Cisco implements as Outside network. The second zone is Trusted network where Cisco implements as Inside network. The third zone is DMZ network where Cisco also implements as DMZ network.

Following basic firewall concept, a firewall is designed as perimeter guarding traffic flow between zones. With the concept of Security Level, the Untrusted (Outside) network has the lowest level of trust where Cisco by default assign the trust level as 0 (zero). Consequently the Trusted (Inside) network has the highest level of trust where Cisco by default assign the security level of 100. Since DMZ network is considered somewhat trusted and untrusted, Cisco by default assign (typically) even number between 0 and 100.

Based on associated Security Level; you may notice that the higher a network level is, the more trusted a network is. In other words, Inside network is more trusted or more secure that DMZ network and DMZ network is more trusted or more secure than Outside network. When you put Cisco ASA/PIX Firewall as your Internet gateway or Internet firewall for example, the Outside network is the Internet, the Inside network is your internal network, and the DMZ network is your publicly-accessible web or email server.

If you like to go further, you may segment your internal network further by putting a dedicated firewall between your internal servers and users' PC where the Inside network is where the internal servers are and the Outside network is where the users' PC are. When you consider to use only one firewall for all, then you may want to create multiple DMZ networks where the Outside network (Security Level 0) is the Internet, Inside network (Security Level 100) is the internal servers, DMZ 1 network (i.e. Security Level 1) is the publicly-accessible web or email server, DMZ 2 network (i.e. Security Level 4) is a guest wireless network, DMZ 3 network (i.e. Security Level 6) is the user's PC, and so on and so forth.

Also based on associated Security Level, any incoming traffic from lower Security Level to higher Security Level is by default denied. When you have publicly-accessible web or email server let's say on your DMZ network, then you have to permit certain incoming traffic from the lower Security Level (the Internet or Outside) network to enter higher Security Level network which is the DMZ by using either nat command or static command. You can also control how many incoming permitted sessions for further protection.

How Cisco ASA/PIX Firewall Treats TCP-based traffic differently than ICMP-based traffic

You also have to permit incoming ICMP echo reply packets from least trusted network as a response of ICMP echo packets issued by a machine within more trusted network. For TCP-based traffic, by default all returning TCP traffic coming from least trusted network as a response of TCP packet initiated by a machine within more trusted network are permitted. Therefore you don't need to create rules to permit such returning TCP traffic.

The reason of no need to create rules to permit such returning TCP traffic is that the firewall understands the concept of 3-way TCP handshake. Every time there is outbound TCP-based traffic initiated from more trusted network to less trusted network is inspected and stored in connectivity table (the show conn command reveals such table). When the firewall sees matching TCP packet coming from less trusted network toward the more trusted network as part of the 3-way handshake, the firewall permits those returning traffic.

ICMP-based traffic however has different properties. Since there is no concept of 3-way handshake in ICMP, each ICMP traffic is treated as one-way traffic. Therefore you have to permit any necessary incoming ICMP traffic from less trusted network towards more trusted network when you plan to use something like ICMP ping or traceroute from more trusted network to less trusted network.

TCP Transaction Protection

For those TCP traffic, all incoming TCP traffic are inspected by Cisco ASA/PIX Firewall to make sure that there will be a 3-way handshake per TCP mechanism to complete TCP transaction. The firewall will drop any incomplete TCP transaction for protection from possible TCP-based attack.

As example, the firewall keeps TCP session as part of the TCP 3-way handshake protection mechanism where there is some kind of hold timer. The firewall expects to receive responses from server within the hold timer interval, which the timer will expire. At the time the firewall does not receive the server response when the timer expires, the firewall drops any related TCP session and also drops "late" server response.

Another example is having the firewall drops TCP packets when the TCP client keeps sending TCP synchronization (SYN) packet or sending TCP acknowledge (ACK) packet without sending TCP SYN packet first. In this situation, the firewall drops the TCP SYN and TCP ACK accordingly.

There is also a TCP Initial Sequence Number (ISN) randomization protection feature which by default randomizing TCP sequence number to negotiate between client and server in order to provide TCP Sequence Prediction Attacks protection.

One optional feature is setting maximum number of simultaneous TCP and UDP connections through the firewall for the entire subnet. The default is 0, which means unlimited connections and the firewall lets the server determine the number.

Another optional feature is specifying the maximum number of embryonic connections per host. An embryonic connection is a connection request that has not finished the necessary handshake between source and destination. Set a small value for slower systems, and a higher value for faster systems. The default is 0, which means unlimited embryonic connections.

The embryonic connection limit lets you prevent a type of attack where processes are started without being completed. When the embryonic limit is surpassed, the TCP intercept feature intercepts TCP SYN packets from clients to servers on a higher security level. The software establishes a connection with the client on behalf of the destination server, and if successful, establishes the connection with the server on behalf of the client and combines the two half-connections together transparently. Thus, connection attempts from unreachable hosts never reach the server. The PIX firewall and ASA accomplish TCP intercept functionality using SYN cookies.

TCP/UDP Application-Specific Protocol Protection

By default, the PIX Firewall and ASA provide TCP/UDP application-specific protection of the following protocols.
Protocol                      TCP/UDP Port            Protocol-Specific Protection
dns                                53                  packet maximum length 512
ftp                                21
h323 h225                         1720
h323 ras                        1718-1719
http                               80
rsh                                514
rtsp                               554
sip                               5060
sip udp                           5060
skinny                            2000
smtp                               25
sqlnet                            1521
tftp                               69


Various Cisco ASA/PIX Firewall Features

1. SSH and Telnet as firewall management access

You can only use SSH for the firewall management access when you are sitting in non-Inside network. By default you can use either telnet or SSH for the firewall management access when you are sitting in Inside network.

2. NAT

In the PIX or ASA OS version prior 8.3, by default there is NAT in place for traffic between zones. In earlier OS version, you typically use the nat 0 command to eliminate NAT for traffic between zones. You could also use static command with the same IP subnet of pre- and post- NAT process. Further, there is a rule called NAT Order of Operation in earlier OS version to make sure that the NAT-related business is in order.

NAT Concept on PIX Firewall running OS version 6.3 or later and ASA running OS version prior 8.3

Introduction to NAT Operation

In network environment where there is a private network that is not (and should not) be visible directly from Outside network should be made invisible to the Outside network. PIX Firewall and ASA were originally designed to provide such invisibility and do NAT by default for traffic across security zones such as between Inside and Outside network.

When the Outside network access is needed from more trusted network, you need to NAT the outbound traffic by using nat command. If the traffic is just outbound where connections are initiated from more trusted network to less trusted network, then the nat command should be associated with a global command.

For inbound traffic where connections are initiated from less trusted network to more trusted network, the static command is needed to accommodate the NAT process. With the static command, the traffic flow between the less and more trusted network is established both way; meaning that the Outside network (less trusted network) can initiate traffic to the Inside network (more trusted network) at anytime and vice versa. There is no need to create specific nat command to accommodate the traffic flow.

In regards of the static command use, you have a choice to either use the same or different IP address/subnet between the less and more trusted network. Following is list of possibilities where you want to use different IP address/subnet appearing on the less trusted network.

1. The private network (residing at the more trusted network) uses IP scheme that is not routable at the less trusted network; i.e. Internet access from LAN using private network of 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16

2. The less trusted network is unable to do routing. In this case, the more trusted network uses NAT-ed IP address that is within the less trusted network IP subnet

3. There is conflicting IP scheme between less and more trusted network. In this case, the more trusted network uses NAT-ed IP address that is within the less trusted network IP scheme. Furthermore, you need to NAT the inbound traffic from less to more trusted network using NAT-ed IP address that is within the more trusted network IP scheme.

When none of the above situation meets, you should use the same IP address/subnet between less and more trusted network. Note that just because you use the same IP address/subnet between less and more trusted network, it does not mean that there will be security risk on the more trusted network since the PIX Firewall or ASA provides sufficient stateful security feature as mentioned at earlier discussion.

Different Types of NAT

1. Dynamic PAT

Commands to use: nat, global
Objective: to allow outbound traffic from more trusted network to less trusted network where inbound traffic is not needed

Example 1.1
nat (inside) 1 192.168.1.0 255.255.255.0
global (outside) 1 203.43.45.93

Description:
Any hosts within Inside IP subnet of 192.168.1.0/24 will be PAT-ed into 203.43.45.93 when there is outbound traffic from Inside to Outside network

Example 1.2
nat (outside) 1 203.43.45.0 255.255.255.0
global (inside) 1 192.168.1.93

Description:
Any hosts within Outside IP subnet of 203.43.45.0/24 will be PAT-ed into 192.168.1.93 when there is inbound traffic from Outside to Inside network

2. Static PAT

Commands to use: static
Objective: to allow outbound traffic from more trusted network to less trusted network where inbound traffic is needed

Example 2.1
static (inside,outside) tcp 203.43.45.93 80 192.168.45.93 80 netmask 255.255.255.255

Description:
Host 192.168.45.93 will be PAT-ed to 203.43.45.93 when there is outbound traffic initiated from 192.168.45.93 (within the Inside network) using TCP port 80 as source TCP port to the Outside network. Similarly, any IP address within Outside network will access 203.43.45.93 using TCP port 80 as destination TCP port in order to access 192.168.45.93 on TCP port 80

Example 2.2
static (outside,inside) tcp 192.168.45.93 80 203.43.45.93 80 netmask 255.255.255.255

Description:
Host 203.43.45.93 will be PAT-ed to 192.168.45.93 when there is inbound traffic initiated from 203.43.45.93 (within the Outside network) using TCP port 80 as source TCP port to the Inside network. Similarly, any IP address within Inside network will access 192.168.45.93 using TCP port 80 as destination TCP port in order to access 203.43.45.93 on TCP port 80

3. Static NAT of single IP address

Commands to use: static
Objective: to allow outbound traffic from more trusted network to less trusted network where inbound traffic is needed. Furthermore, the command uses the entire IP protocols and ports within the provided IP address.

Example 3.1
static (inside,outside) 203.43.45.93 192.168.45.93 netmask 255.255.255.255

Description:
Host 192.168.45.93 will be NAT-ed to 203.43.45.93 when there is outbound traffic initiated from 192.168.45.93 (within the Inside network) using any IP protocol (including ESP, TCP, and UDP) to the Outside network. Similarly, any IP address within Outside network will access 203.43.45.93 using any IP protocol in order to access 192.168.45.93.

Note:
This static statement may seem as security risk since you are opening the IP address to any incoming IP protocol from less to more trusted network. Such risk is mitigated when there is access-list controlling inbound traffic to open necessary IP protocol and ports (i.e. just open inbound TCP port 80 and 443 where others are denied).

Example 3.2
static (outside,inside) 192.168.45.93 203.43.45.93 netmask 255.255.255.255

Description:
Host 203.43.45.93 will be PAT-ed to 192.168.45.93 when there is inbound traffic initiated from 203.43.45.93 (within the Outside network) using any IP protocol (including ESP, TCP, and UDP) to the Inside network. Similarly, any IP address within Inside network will access 192.168.45.93 using any IP protocol in order to access 203.43.45.93.

4. Static NAT of entire IP subnet

Commands to use: static
Objective: to allow outbound traffic from more trusted network to less trusted network where inbound traffic is needed. Furthermore, the command uses the entire IP protocols and ports within the provided IP address.

Example 4.1
static (inside,outside) 203.43.45.0 192.168.45.0 netmask 255.255.255.0

Description:
Any hosts within 192.168.45.0/24 will be NAT-ed to 203.43.45.0/24 when there is outbound traffic initiated from 192.168.45.0/24 (within the Inside network) using any IP protocol (including ESP, TCP, and UDP) to the Outside network. Similarly, any IP address within Outside network will access 203.43.45.0/24 using any IP protocol in order to access 192.168.45.0/24.

Using IP subnet static NAT indicates the following static NAT in place
  Outside                  Inside
203.43.45.1     <====>  192.168.45.1         
203.43.45.2     <====>  192.168.45.2
203.43.45.3     <====>  192.168.45.3
     .
     .
     .
203.43.45.254   <====>  192.168.45.254

As you can see, the last octet will be the same while only the first three octets are different between the Outside and the Inside IP addresses.

Note:
The command is useful when you need to NAT the entire subnet without the requirement of creating multiple static command of each pair of Outside-Inside IP addresses. You can simply create static NAT for the entire subnet instead.

Example 4.2
static (outside,inside) 192.168.45.0 203.43.45.0 netmask 255.255.255.0

Description:
Any hosts within 203.43.45.0/24 will be NAT-ed to 192.168.45.0/24 when there is outbound traffic initiated from the Inside network using any IP protocol (including ESP, TCP, and UDP) to the Outside network. Similarly, IP address within 203.43.45.0/24 Outside network will access the any IP addresses within Inside network as 192.168.45.0/24 using any IP protocol.

5. Static NAT of entire IP subnet and keep the same IP scheme between less and more trusted network

Command to use: access-list, nat 0, and/or static
Objective: to allow outbound traffic from more trusted network to less trusted network where inbound traffic is needed. Furthermore, the command uses the entire IP protocols and ports within the provided IP address. All of these processes take place while keeping the same IP scheme between less and more trusted network.

Example 5.1 - NAT exemption

access-list nonat_inside-outside permit ip 192.168.45.0 255.255.255.0 192.168.1.0 255.255.255.0
nat (inside) 0 access-list nonat_inside-outside

Description:
Any hosts within 192.168.45.0/24 will appear as themselves when there is outbound traffic initiated from 192.168.45.0/24 (within the Inside network) using any IP protocol (including ESP, TCP, and UDP) to the Outside network of 192.168.1.0/24. Similarly, any IP address within Outside network of 192.168.1.0/24 will access 192.168.45.0/24 using any IP protocol directly.

Example 5.2

static (inside,outside) 192.168.45.0 192.168.45.0 netmask 255.255.255.0

Description:
Any hosts within 192.168.45.0/24 will appear as themselves when there is outbound traffic initiated from 192.168.45.0/24 (within the Inside network) using any IP protocol (including ESP, TCP, and UDP) to any Outside network IP address. Similarly, any IP address within Outside network will access 192.168.45.0/24 using any IP protocol directly.

Example 5.3 - Identity NAT

nat (inside) 0 192.168.45.0 255.255.255.0
static (inside, outside) 192.168.45.0 192.168.45.0 netmask 255.255.255.0

Description:
The behavior is similar as Examples 5.1 and 5.2. This configuration is less popular since it seems more complex than it has to.

6. Static NAT Policy

Command to use: access-list and static
Objective: to allow outbound traffic from more trusted network to less trusted network where inbound traffic is needed. Furthermore, the command uses the entire IP protocols and ports within the provided IP address. All of these processes take place while keeping the same IP scheme between less and more trusted network.

Example 6.1

access-list nat1_inside-outside permit ip 192.168.45.0 255.255.255.0 23.54.6.0 255.255.255.0
access-list nat2_inside-outside permit ip 192.168.45.0 255.255.255.0 23.54.7.0 255.255.255.0
nat (inside) 1 0.0.0.0
static (inside,outside) 23.54.6.254 access-list nat1_inside-outside
static (inside,outside) 23.54.7.254 access-list nat2_inside-outside
global (outside) 1 203.43.45.32

Description:
Any 192.168.45.x within Inside network will be statically NAT as 23.54.6.254 when 192.168.45.x access 23.54.6.x that resides at Outside network. Similarly, any 192.168.45.x within Inside network will be statically NAT as 23.54.7.254 when 192.168.45.x access 23.54.7.x that resides at Outside network. When 192.168.45.x access any other IP addresses at Outside network beside 23.54.6.x and 23.54.7.x, the 192.168.45.x will be dynamically PAT-ed as 203.43.45.32.

NAT Implementation Illustration

For the sake of illustration, we assume the following

Outside network: any IP subnet
DMZ 1 network: 192.168.0.0/24, 192.168.1.0/24
DMZ 2 network: 192.168.2.0/24, 192.168.3.0/24
Inside network: 192.168.32.0/24, 192.168.33.0/24, 192.168.45.0/24

Example 1

access-list nonat permit ip 192.168.32.0 255.255.255.0 192.168.1.0 255.255.255.0
nat (inside) 0 access-list nonat
nat (inside) 1 192.168.32.0 255.255.255.0
global (outside) 1 203.45.32.84

Description:
When any IP address within 192.168.32.0/24 access the 192.168.1.0/24, the 192.168.32.x appears as themselves. If the 192.168.32.x access anything else that is at Outside network, there will be dynamic PAT to use 203.45.32.84 IP address to appear on the Outside network.

Further, any machine within 192.168.1.0/24 can access 192.168.32.0/24 as themselves. In other words, 192.168.32.0/24 appears as themselves in the 192.168.1.0/24 presence and vice versa.

The 192.168.33.x cannot access anything beyond Inside network. Similarly, the 192.168.0.x cannot access anything beyond DMZ 1 network. Anything at Outside and DMZ 2 cannot access anything at DMZ 1 and 192.168.33.x Inside network.

Example 2

access-list nonat permit ip 192.168.32.0 255.255.255.0 192.168.0.0 255.255.255.0
nat (inside) 0 access-list nonat
nat (inside) 1 0.0.0.0
nat (dmz1) 2 192.168.0.0 255.255.255.0
global (dmz2) 1 192.168.2.254
global (outside) 2 204.54.65.231
static (inside,outside) 192.168.32.0 192.168.32.0 netmask 255.255.254.0

Description:
The 192.168.0.x and 192.168.32.x can see each other as themselves. Any IP address within Inside network (including those that are not 192.168.32.x or 192.168.33.x if any such as 192.168.45.x) is able to access 192.168.2.x and 192.168.3.x using PAT-ed IP address of 192.168.2.254. Both 192.168.32.x and 192.168.33.x will appear as themselves when they are accessing Outside network. Any 192.168.0.x will appear as 204.54.65.231 to access Outside network.

Example 3

access-list nonat permit ip 192.168.32.0 255.255.254.0 192.168.0.0 255.255.254.0
access-list nonat permit ip 192.168.45.0 255.255.255.0 192.168.0.0 255.255.254.0
access-list nat1_inside-dmz2 permit ip 192.168.32.0 255.255.254.0 192.168.2.0 255.255.255.0
access-list nat1_inside-dmz2 permit ip 192.168.45.0 255.255.255.0 192.168.2.0 255.255.255.0
access-list nat2_inside-dmz2 permit ip 192.168.32.0 255.255.254.0 192.168.3.0 255.255.255.0
access-list nat2_inside-dmz2 permit ip 192.168.45.0 255.255.255.0 192.168.3.0 255.255.255.0
access-list nat_inside-outside permit ip 192.168.32.0 255.255.254.0 any
access-list nat_inside-outside permit ip 192.168.45.0 255.255.255.0 any
nat (inside) 0 access-list nonat
nat (inside) 1 access-list nat1_inside-dmz2
nat (inside) 2 access-list nat2_inside-dmz2
nat (inside) 3 access-list nat_inside-outside
global (dmz2) 1 192.168.2.254
global (dmz2) 2 192.168.3.254
global (outside) 3 204.54.65.231-204.54.65.253
global (outside) 3 204.54.65.254
static (dmz1,outside) 204.54.64.0 192.168.0.0 netmask 255.255.255.0

Description:
The 192.168.32.x, 192.168.33.x, and 192.168.45.x appear as themselves when they access 192.168.0.x, 192.168.1.x and vice versa. The 192.168.32.x, 192.168.33.x, and 192.168.45.x appear as 192.168.2.254 when they access 192.168.2.x and appear as 192.168.3.254 when they access 192.168.3.x.

The 192.168.0.x appear as 204.54.64.x when they access Outside network. Similarly, Outside network access 204.54.64.x in order to access 192.168.0.x.

The 192.168.32.x, 192.168.33.x, and 192.168.45.x on the Inside network appear as any available IP address within range of 204.54.65.231 and 204.54.65.253 when those Inside networks access Outside network. Such range is called NAT pool where there will be dynamic one-one NAT relationship between 192.168.32.x, 192.168.33.x, 192.168.45.x on the Inside network and any available IP address within range of 204.54.65.231 and 204.54.65.253. When all IP addresses within the NAT pool are used up, the 204.54.65.254 will be used as last resort (as dynamic PAT instead of dynamic NAT).

Note:
For illustration, please check out all sample configuration using Cisco ASA/PIX Firewall in this Cisco Forum FAQ to better understand how Cisco firewall implementation look like.

Traffic Flow Across Security Zones

1. Default Behavior and Ways To Tweak

As a firewall, PIX Firewall and ASA by default expect to have traffic flow comes from one security zone to another. Any routing traffic that comes from one security zone and bounce back to the same security zone (called hair pinning) is denied. Another default behavior is to block traffic flow between security zones with equal security level.

In regards of traffic flow coming from one security zone to another, following is default behavior

* Initiated from Less-Trusted zone to More-Trusted zone, traffic is denied
* Initiated from More-Trusted zone to Less-Trusted zone, traffic is permitted
* Initiated from one security zone to another with equal security level, traffic is denied
* Initiated from one security zone and bounce back (hair pinning), traffic is denied

To adjust the above default behavior, following is the list of choices that applies for PIX Firewall and ASA running OS version 6.3 and later

* Implement nat 0 or static command in addition to implement access-group command tied with specific access-list command to allow initiating traffic from Less-Trusted zone to More-Trusted zone
* Implement access-group command tied with specific access-list command to restrict initiating traffic from More-Trusted zone to Less-Trusted zone

When the PIX Firewall or ASA runs OS version 7.0 or later, following is a list of choices to adjust various default behaviors

* Implement same-security-traffic permit command to allow initiating traffic from one security zone to another with equal security level. The same command is used to also allow hair-pinning traffic
* Transform the Layer-3 firewall default behavior into Layer-2 firewall using firewall transparent command to avoid the firewall participating in routing
* Transform the single physical firewall into multiple virtual firewall using mode command to allow Active/Active or Active/Standby traffic flow separating routing table between each virtual firewall

2. Traffic Flow Order of Operation

For those traffic flow initiating from Less-Trusted to More-Trusted network, here is what Cisco devices including PIX Firewall and ASA expect

* Incoming traffic hits IP address as seen in the IP scheme of the Less-Trusted network. If there is NAT in place, then the incoming traffic hits the NAT-ed IP address.
* Cisco devices check incoming traffic to see if there is a match within the access-list. When there is a match; Cisco devices stop searching, treat the traffic per the rule, and exit. When there is no match, by default Cisco devices deny traffic
* If static command is in place to manage the NAT/PAT-ed IP addresses, Cisco devices translate IP address accordingly and forward the traffic based on the routing table

Since PIX Firewall and ASA are firewall, by design the firewall does traffic inspection before forwarding traffic based on the routing table as mentioned in early discussion. Any traffic that do not pass the inspection will be dropped and will not be forwarded.

What Is New On ASA (Or PIX OS 7.2 and above) Compared To PIX Firewall Running PIX OS 6.3?

Note:
* PIX Firewall 500 series only support PIX OS up to 8.0(4) version. The ASA 5500 series support beyond OS 8.0(4) with possible DRAM/Flash upgrade
* There is no known "real" differences between PIX OS 7.x and ASA OS 7.x from software perspective

For further info, check out the following official Cisco online documentation links for specific OS version features.

Features

Legacy OS 6.3(5)
http://www.cisco.com/en/US/docs/security/pix/pix63/release/notes/pixrn635.html

OS 7.0(1)
http://www.cisco.com/en/US/docs/security/pix/pix70/release/notes/pix_70rn.html#wp169795

OS 7.0(4)
http://www.cisco.com/en/US/docs/security/pix/pix70/release/notes/pix704rn.html#wp213502

OS 7.0(5)
http://www.cisco.com/en/US/docs/security/pix/pix70/release/notes/pix705rn.html#wp213502

OS 7.2(1)
http://www.cisco.com/en/US/docs/security/pix/pix72/release/notes/pixrn72.html#wp185529

OS 7.2(2)
http://www.cisco.com/en/US/docs/security/pix/pix72/release/notes/pixrn722.html#wp191103

OS 7.2(3)
http://www.cisco.com/en/US/docs/security/pix/pix72/release/notes/pixrn723.html#wp213761

OS 8.0
http://www.cisco.com/en/US/docs/security/pix/pix80/release/notes/pixrn80.html#wp191103

OS 8.0(3)
http://www.cisco.com/en/US/docs/security/pix/pix80/release/notes/prn803.html#wp191103

OS 8.0(4)
http://www.cisco.com/en/US/docs/security/pix/pix80/release/notes/pixrn804.html#wp191103

OS 8.1
http://www.cisco.com/en/US/docs/security/asa/asa81/release/notes/asarn81.html#wp229690

Enable/Disable Communication on OS 7.0 image and newer

1. Troubleshooting on OS 7.0 image and newer

Establish and Troubleshoot Connectivity through PIX/ASA
Packet/Traffic Troubleshooting

2. Sample Configuration on OS 7.0 image and newer

ASA/PIX EIGRP Routing Support

Backup/Failover Routing

Single Firewall Partitioned Into Multiple Independent Firewalls: Introduction to Multiple Context

Active/Active PIX/ASA Stateful Redundancy

Active/Standby PIX/ASA Stateful Redundancy

Transparent (Layer-2) Firewall

QoS

ASA As SSL Server
SSL VPN Client (SVC) on ASA with ASDM Configuration Example
Clientless SSL VPN (WebVPN) on ASA Configuration Example
Thin-Client SSL VPN (WebVPN) on ASA with ASDM Configuration Example

Block or Restrict the Instant Messaging (IM) Traffic

URL Filtering

New Features and Deprecated Commands Starting OS version 8.3

You may notice that PIX Firewall appliances are unable to run latest OS version. PIX 501 can only run up to OS version 6.3(5) while PIX 515E and larger appliances can only run up to OS version 8.0. You need ASA 5500 series appliance to run newer OS version than 8.0.

Cisco ASA 5500 Migration Guide for Version 8.3

Discussion of OS version 9.1
»ASA 5520 Fan Question

Licenses

For those who are eager to get their hands on ASA or PIX Firewall, they need to consider the license factor. With either ASA or PIX Firewall, you should get the one with Unlimited Inside Hosts instead of 10 or 50 Inside Hosts. For PIX Firewall, one with Unrestricted license has more features compared to one with Restricted license; while one with the Failover license can only work as backup firewall of the Unrestricted license. For ASA, one with Security Plus license supports more features similarly. Both Inside Hosts number and license type that firewall carries can be verified through the show version.

Upgrading from lower license to higher license may cost you dearly where at that point, getting a new firewall with higher license may cost you less compared to upgrade your existing firewall to have higher license.

You can check out the following discussion for some illustration.
»[HELP] Upgrade ASA 5505 License



Thanks to http://www.dslreports.com/faq/15531