Cisco ASA5500 (5505, 5510, 5520, etc) Series Firewall Security Appliance Startup Configuration & Basic Concepts

Introducing the Cisco ASA 5500 Series Firewall Appliance

The Cisco ASA 5500 series security appliances have been around for quite some time and are amongst the most popular hardware firewalls available in the market. Today Firewall.cx takes a look at how to easily setup a Cisco ASA5500 series firewall to perform basic functions, more than enough to provide secure & restricted access to the Internet, securely access and manage the ASA Firewall and more.

While many consider the Cisco ASA Firewalls complex and difficult to configure devices, Firewall.cx aims to break that myth and show how easy you can setup an ASA Firewall to deliver basic and advanced functionality. We’ve done it with other Cisco technologies and devices, and we’ll do it again :)

The table below provides a brief comparison between the different ASA5500 series security appliances:

Feature	Cisco ASA 5505	Cisco ASA 5510	Cisco ASA 5520	Cisco ASA 5540	Cisco ASA 5550
Users/Nodes	10, 50, or unlimited	Unlimited	Unlimited	Unlimited	Unlimited
Firewall Throughput	Up to 150 Mbps	Up to 300 Mbps	Up to 450 Mbps	Up to 650 Mbps	Up to 1.2 Gbps
Maximum Firewall and IPS Throughput	• Up to 150 Mbps with AIP-SSC-5	• Up to 150 Mbps with AIP-SSM-10 • Up to 300 Mbps with AIP-SSM-20	• Up to 225 Mbps with AIP-SSM-10 • Up to 375 Mbps with AIP-SSM-20 • Up to 450 Mbps with AIP-SSM-40	• Up to 500 Mbps with AIP-SSM-20 • Up to 650 Mbps with AIP-SSM-40	Not available
3DES/AES VPN Throughput***	Up to 100 Mbps	Up to 170 Mbps	Up to 225 Mbps	Up to 325 Mbps	Up to 425 Mbps
IPsec VPN Peers	10; 251	250	750	5000	5000
Premium AnyConnect VPN Peers* (Included/Maximum)	2/25	2/250	2/750	2/2500	2/5000
Concurrent Connections	10,000; 25,000*	50,000; 130,000*	280,000	400,000	650,000
New Connections/Second	4000	9000	12,000	25,000	33,000
Integrated Network Ports	8-port Fast Ethernet switch (including 2 PoE ports)	5 Fast Ethernet ports; 2 Gigabit Ethernet + 3 Fast Ethernet ports*	4 Gigabit Ethernet, 1 Fast Ethernet	4 Gigabit Ethernet, 1 Fast Ethernet	8 Gigabit Ethernet, 4 SFP Fiber, 1 Fast Ethernet
Virtual Interfaces (VLANs)	3 (no trunking support)/20 (with trunking support)*	50/100*	150	200	400

Users can also download the complete technical datasheet for the Cisco ASA 5500 series firewalls by visiting our Cisco Product Datasheet & Guides Download section.

Perhaps one of the most important points, especially for an engineer with limited experience, is that configuring the smaller ASA 5505 Firewall does not really differ from configuring the larger ASA5520 Firewall. The same steps are required to setup pretty much all ASA 5500 series Firewalls – which is Great News!

The main differences besides the licenses, which enable or disable features, are the physical interfaces of each ASA model (mainly between the ASA 5505 and the larger 5510/5520) and possibly modules that might be installed. In any case, we should keep in mind that if we are able to configure a small ASA5505 then configuring the larger models won’t be an issue.

At the time of writing of this article Firewall.cx came across a Cisco ASA5505, so we decided to put it to good use for this article, however, do note that all commands and configuration philosophy is the same across all ASA5500 series security appliances.

Note: ASA software version 8.3.0 and above use different NAT configuration commands. This article provides both old style (up to v8.2.5) and new style (v8.3 onwards) NAT configuration commands.

 

ASA5500 Series Configuration Check-List

We’ve created a simple configuration check-list that will help us keep track of the configured services on our ASA Firewall. Here is the list of items that will be covered in this article:

• Erase existing configuration
• Configure Hostname, Users, Enable password & Disable Anonymous Reporting
• Configure interface IP addresses or Vlan IP addresses (ASA5505) & Descriptions
• Setup Inside (private) & Outside (public) Interfaces
• Configure default route (default Gateway) & static routes
• Configure Network Address Translation (NAT) for Internal Networks
• Configure ASA DHCP Server
• Configure AAA authentication for local database user authentication
• Enable HTTP Management for inside interface
• Enable SSH & Telnet Management for inside and outside interfaces
• Create, configure and apply TCP/UDP Object-Groups to firewall access lists
• Configuration of access-lists for ICMP packets to the Internet
• Apply Firewall access lists to ‘inside’ and ‘outside’ interfaces
• Configure logging/debugging of events and errors

Note: it is highly advisable to frequently save the ASA configuration to ensure no work is lost in the event of a power failure or accident restart.

Saving the configuration can be easily done using the write memory command:

ASA5505(config)# write memory

Building configuration...

Cryptochecksum: c0aee665 598d7cd3 7fbfe1a5 a2d40ab1

3270 bytes copied in 1.520 secs (3270 bytes/sec)

[OK]

Erasing Existing Configuration

This first step is optional as it will erase the firewall’s configuration. If the firewall has been previously configured or used it is a good idea to start off with the factory defaults. If we are not certain, we prefer to wipe it clean and start from scratch. Once the configuration is deleted we need to force a reboot, however, take note that it’s important not to save the system config to ensure the running-config is not copied to the startup-config otherwise we’ll have to start this process again:

ciscoasa(config)# write erase

Erase configuration in flash memory? [confirm]

[OK]

ciscoasa(config)# reload

System config has been modified. Save? [Y]es/[N]o:  N

Proceed with reload? [confirm]

ciscoasa(config)#

***

*** --- START GRACEFUL SHUTDOWN ---

Shutting down isakmp

Shutting down webvpn

Shutting down File system

***

*** --- SHUTDOWN NOW ---

Process shutdown finished

Rebooting.....

Configure Hostname, Users, 'Enable' Password & Disable Anonymous Reporting

Next, we need to configure the Enable password, required for privileged exec mode access, and then user accounts that will have access to the firewall. 

The ASA Firewall won’t ask for a username/password when logging in next, however, the default enable password of ‘cisco’, will be required to gain access to privileged mode:

Ciscoasa> enable

Password: cisco

ciscoasa#  configure terminal

ciscoasa(config)#

***************************** NOTICE *****************************

Help to improve the ASA platform by enabling anonymous reporting,

which allows Cisco to securely receive minimal error and health

information from the device. To learn more about this feature,

please visit: http://www.cisco.com/go/smartcall

Would you like to enable anonymous error reporting to help improve

the product? [Y]es, [N]o, [A]sk later: N

In the future, if you would like to enable this feature,

issue the command "call-home reporting anonymous".

Please remember to save your configuration.

At this point we need to note that when starting off with the factory default configuration, as soon as we enter the ‘configure terminal’ command, the system will ask if we would like to enable Cisco’s call-home reporting feature. We declined the offer and continued with our setup:

ciscoasa(config)# hostname ASA5505

ASA5505(config)# enable password firewall.cx

ASA5505(config)# username admin password s1jw$528ds2 privilege 15

The privilege 15 parameter at the end of the command line ensures the system is aware that this is an account with full privileges and has access to all configuration commands including erasing the configuration and files on the device’s flash disk, such as the operating system.

Configure Interface IP addresses / VLAN IP Addresses & Descriptions

Depending on the ASA appliance we have, we can configure physical interfaces (inside/outside) with IP addresses, usually done with ASA5510 and larger models,  or create VLANs (inside/outside) and configure them with IP addresses, usually with the smaller ASA5505 models.

In many cases network engineers use VLAN interfaces on the larger ASA5500 models, however, this depends on the licensing capabilities of the device, existing network setup and more.

In the case of the ASA5505 we must use VLAN interfaces, which are configured with their appropriate IP addresses and then (next step) characterised as inside (private) or outside (public) interfaces:

ASA5505(config)# interface vlan 1

ASA5505(config)# description Private-Interface

ASA5505(config-if)# ip address 10.71.0.1 255.255.255.0

ASA5505(config-if)# no shutdown

!

ASA5505(config)# interface vlan 2

ASA5505(config)# description Public-Interface

ASA5505(config-if)# ip address 192.168.3.50 255.255.255.0

ASA5505(config-if)# no shutdown

!

ASA5505(config)# interface ethernet 0/0

ASA5505(config-if)# switchport access vlan 2

ASA5505(config-if)# no shutdown

Alternatively, the Public interface  (VLAN2) can be configured to obtain its IP address automatically via DHCP with the following command:

ASA5505(config)# interface vlan 2

ASA5505(config)# description Public-Interface

ASA5505(config-if)# ip address dhcp setroute

ASA5505(config-if)# no shutdown

The setrouteparameter at the end of the command will ensure the ASA Firewall sets its default route (gateway) using the default gateway parameter the DHCP server provides.

After configuring VLAN1 & VLAN2 with the appropriate IP addresses, we configured ethernet 0/0 as an access link for VLAN2 so we can use it as a physical public interface.  Out of the 8 total Ethernet interfaces the ASA5505 has, at least one must be set with the switchport access vlan 2 otherwise there won’t be any physical public interface on the ASA for our frontend router to connect to. Ethernet ports 0/1 to 0/7 must also be configured with the no shutdown command in order make them operational. All of these ports are, by default, access links for VLAN1. Provided are the configuration commands for the first two ethernet interface as the configuration is identical for all:

ASA5505(config)# interface ethernet 0/1

ASA5505(config-if)# no shutdown

ASA5505(config-if)# interface ethernet 0/2

ASA5505(config-if)# no shutdown

Setup Inside (private) & Outside (public) Interfaces

Next, we must designate the Inside (private) and Outside (public) interfaces. This step is essential and will help the ASA Firewall understand which interface is connected to the trusted (private) and untrusted (public) network:

ASA5505(config)# interface vlan 1

ASA5505(config-if)# nameif inside

INFO: Security level for "inside" set to 100 by default.
!

ASA5505(config)# interface vlan 2

ASA5505(config-if)# nameif outside
INFO: Security level for "outside" set to 0 by default.

The ASA Firewall will automatically set the security level to 100 for inside interfaces and 0 to outside interfaces.  Traffic can flow from higher security levels to lower (private to public), but not the other way around (public to private) unless stated by an access-lists. 

To change the security-level of an interface use the security-level xxx command by substituting xxx with a number from 0 to 100. The higher the number, the higher the security level.  DMZ interfaces are usually configured with a security level of 50.

It is extremely important the necessary caution is taken when selecting and applying the inside/outside interfaces on any ASA Firewall.

Configure Default Route (default gateway) & Static Routes

The default route configuration command is necessary for the ASA Firewall to route packets outside the network via the next hop, usually a router. In case the public interface (VLAN2) is configured using the ip address dhcp setroute command, configuration of the default gateway is not required.

ASA5505(config)# route outside 0.0.0.0 0.0.0.0 192.168.3.1 

At this point, it’s a good idea to try testing the next-hop router and confirm the ASA Firewall can reach it:

ASA5505(config)# ping 192.168.3.1

Type escape sequence to abort.

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

!!!!!

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

For networks with multiple internal VLANs, it is necessary to configure static routes to ensure the ASA Firewall knows how to reach them. Usually these networks can be reached via a Layer3 switch or an internal router.  For our example, we’ll assume we have two networks: 10.75.0.0/24 & 10.76.0.0/24 which we need to provide Internet access to. These additional networks are contactable via a Layer3 device with IP address 10.71.0.100:

ASA5505(config)# route outside 10.75.0.0 0.0.0.0 10.71.0.100
ASA5505(config)# route outside 10.76.0.0 0.0.0.0 10.71.0.100

Configure Network Address Translation (NAT) for Internal Networks

This is the last step required to successfully provide Internet access to our internal networks. Network Address Translation is essential to masquerade our internal network using the single IP address our Public interface has been configured with.  Network Address Translation, along with all its variations (Static, Dynamic etc), is covered in great depth in our popular Network Address Translation section.

We should note at this point that NAT configuration has slightly changed with ASA software version 8.3 and above. We will provide both commands to cover installations with software version up to v8.2.5 and from v8.3 and above.

The following commands apply to ASA appliances with software version up to 8.2.5:

ASA5505(config)# global (outside) 1 interface

INFO: outside interface address added to PAT pool

ASA5505(config)# nat (inside) 1 10.71.0.0 255.255.255.0

ASA5505(config)# nat (inside) 1 10.75.0.0 255.255.255.0

ASA5505(config)# nat (inside) 1 10.76.0.0 255.255.255.0

In the above configuration, the ASA Firewall is instructed to NAT all internal networks using the NAT Group 1. The number ‘1’ is used to identify the NAT groups for the NAT process between the inside and outside interfaces.

The global (outside) 1 interface command instructs the ASA Firewall to perform NAT using the IP address assigned to the outside interface.

Another method of configuring NAT is with the use of access lists. In this case, we define the internal IP addresses to be NAT’ed with the use of access lists:

ASA5505(config)# access-list NAT-ACLs extended permit ip 10.71.0.0 255.255.255.0 any

ASA5505(config)# access-list NAT-ACLs extended permit ip 10.75.0.0 255.255.255.0 any

ASA5505(config)# access-list NAT-ACLs extended permit ip 10.76.0.0 255.255.255.0 any

ASA5505(config)# global (outside) 1 interface

INFO: outside interface address added to PAT pool

ASA5505(config)# nat (inside) 1 access-list NAT-ACLs

NAT with the use of access lists provides greater flexibility and control which IP addresses or networks will use the NAT service.

With software version 8.3 and newer, things have changed dramatically and there are no more access lists in NAT configuration lines.

The new NAT format now utilizes "object network", "object service" and "object-group network" to define the parameters of the  NAT  configuration.

The following commands (software version 8.3 and above) will provide NAT services to our internal networks so they can access the Internet:

ASA5505(config)# object network network1

ASA5505(config-network-object)# subnet 10.71.0.0 255.255.255.0

ASA5505(config-network-object)# nat (inside,outside) dynamic interface
!

ASA5505(config)# object network network2

ASA5505(config-network-object)# subnet 10.75.0.0 255.255.255.0

ASA5505(config-network-object)# nat (inside,outside) dynamic interface
!

ASA5505(config)# object network network3

ASA5505(config-network-object)# subnet 10.76.0.0 255.255.255.0

ASA5505(config-network-object)# nat (inside,outside) dynamic interface

Configuring the ASA DHCP Server

The existence of a DHCP server is necessary in most cases as it helps manage the assignment of IP address to our internal hosts. The ASA Firewall can be configured to provide DHCP services to our internal network, a very handy and welcome feature.

Again, there are some limitations with the DHCP service configuration which vary with the ASA model used. In our ASA5505, the maximum assigned IP addreses for the DHCP pool was just 128!

Note that the DHCP service can run on all ASA interfaces so it is necessary to specify which interface the DHCP configuration parameters are for:

ASA5505(config)# dhcpd address 10.71.0.50-10.71.0.200 inside

Warning, DHCP pool range is limited to 128 addresses, set address range as: 10.71.0.50-10.71.0.177

ASA5505(config)# dhcpd address 10.71.0.50-10.71.0.128 inside

ASA5505(config)# dhcpd dns 8.8.8.8 interface inside

Once configured, the DHCP service will begin working and assigning IP addresses to the clients. The Gateway IP address parameter is automatically provided to client and is not required to be configured on the ASA Firewall appliance.

We can verify the DHCP service is working using the show dhcpd statistics command:

ASA5505(config)# show dhcpd statistics

DHCP UDP Unreachable Errors: 0

DHCP Other UDP Errors: 0

Address pools        1

Automatic bindings   1

Expired bindings     0

Malformed messages   0

    Message              Received

    BOOTREQUEST          0

    DHCPDISCOVER        1

    DHCPREQUEST          1

    DHCPDECLINE          0

    DHCPRELEASE          0

    DHCPINFORM           1

If required, we can clear the DHCP bindings (assigned IP addresses) using the clear dhcpd bindingcommand.

Configure AAA Authentication for Local Database User Authentication

Configuring AAA authentication is always a good idea as it instructs the ASA Firewall to use the local user database for the various services it's running. For example, we can tell the ASA Firewall to use a radius server for VPN user authentication, but use its local database for telnet, ssh or HTTP (ASDM) management access to the Firewall appliance.

As mentioned, our example instructs the ASA Firewall to use its local database:

ASA5505(config)# aaa authentication telnet console LOCAL

ASA5505(config)# aaa authentication http console LOCAL

ASA5505(config)# aaa authentication ssh console LOCAL

 

Enable HTTP Management for Inside Interface

We now turn to the management settings of our ASA Firewall to enable and configure HTTP management. This will allow access to the Firewall’s management via the popular ASDM management application:

ASA5505(config)# http 10.71.0.0 255.255.255.0 inside

WARNING: http server is not yet enabled to allow ASDM access.

ASA5505(config)# http server enable

The above commands enable HTTP management on the ASA Firewall only for the network 10.71.0.0/24.

Enable SSH & Telnet Management for Inside and Outside Interfaces

Enabling SSH and Telnet access to the Cisco Firewall is pretty straightforward. While we always recommend the use of SSH, especially when accessing the Firewall from public IPs, telnet is also an option, however, we must keep in mind that telnet management methods do not provide any security as all data (including username, passwords and configurations) are sent in clear text.

Before enabling SSH, we must generate RSA key pairs for identity certificates. Telnet does not require any such step as it does not provide any encryption or security:

ASA5505(config)# crypto key generate rsa modulus 1024

INFO: The name for the keys will be:

Keypair generation process begin. Please wait...

ASA5505(config)# ssh 10.71.0.0 255.255.255.0 inside

ASA5505(config)# ssh 200.200.90.5 255.255.255.255 outside

ASA5505(config)# telnet 10.71.0.0 255.255.255.0 inside

Note that the ASA Firewall appliance will only accept SSH connections from host 200.200.90.5 arriving on its public interface, while SSH and telnet connections are permitted from network 10.71.0.0/24 on  the inside interface.

Create, Configure and Apply TCP/UDP Object-Groups

An essential part of any firewall configure is to define the Internet services our users will have access to. This is done by either creating a number of lengthy access lists for each protocol/service and then applying them to the appropriate interfaces, or utilising the ASA Firewall Object-Groups which are then applied to the interfaces. Using Object-groups is easy and recommended as they provide a great deal of flexibility and ease of management.

The logic is simple:  Create your Object-Groups, insert the protocols and services required, and then reference them in the firewall access -lists. As a last step, we apply them to the interfaces we need.

Let’s use an example to help visualise the concept. Our needs require us to create two Object-Groups, one for TCP and one for UDP services:

ASA5505(config)#object-group service Internet-udp udp

ASA5505(config-service)# description UDP Standard Internet Services

ASA5505(config-service)# port-object eq domain

ASA5505(config-service)# port-object eq ntp

ASA5505(config-service)# port-object eq isakmp

ASA5505(config-service)# port-object eq 4500
!

ASA5505(config-service)#object-group service Internet-tcp tcp

ASA5505(config-service)# description TCP Standard Internet Services

ASA5505(config-service)# port-object eq www

ASA5505(config-service)# port-object eq https

ASA5505(config-service)# port-object eq smtp

ASA5505(config-service)# port-object eq 465

ASA5505(config-service)# port-object eq pop3

ASA5505(config-service)# port-object eq 995

ASA5505(config-service)# port-object eq ftp

ASA5505(config-service)# port-object eq ftp-data

ASA5505(config-service)# port-object eq domain

ASA5505(config-service)# port-object eq ssh

ASA5505(config-service)# port-object eq telnet

Now we need to reference our two Object-groups using the firewall access lists. Here we can also define which networks will have access to the services listed in each Object-group:

ASA5505(config)# access-list inside-in remark -=[Access Lists For Outgoing Packets from Inside interface]=-

ASA5505(config)# access-list inside-in extended permit udp 10.71.0.0 255.255.255.0 any object-group Internet-udp

ASA5505(config)# access-list inside-in extended permit tcp 10.71.0.0 255.255.255.0 any object-group Internet-tcp

ASA5505(config)# access-list inside-in extended permit tcp 10.75.0.0 255.255.255.0 any object-group Internet-tcp

ASA5505(config)# access-list inside-in extended permit tcp 10.76.0.0 255.255.255.0 any object-group Internet-tcp

Note that the 10.71.0.0/25 network has access to both Object-groups services, our other networks are restricted to only the services defined in the TCP Object-group. To understand how Object-groups help simplify access list management: without them, we would require 37 access lists commands instead of just 4!

Configuration of Access-Lists for ICMP Packets to the Internet

To complete our access list configuration we configure our ASA Firewall to allow ICMP echo packets (ping) to any destination, and their replies (echo-reply):

ASA5505(config)# access-list inside-in extended permit icmp 10.71.0.0 255.255.255.0 any

ASA5505(config)# access-list outside-in remark -=[Access Lists For Incoming Packets on OUTSIDE interface]=-

ASA5505(config)# access-list outside-in extended permit icmp any any echo-reply

Appling Firewall Access-Lists to ‘inside’ and ‘outside’ Interfaces

The last step in configuring our firewall rules involves applying the two access lists, inside-in & outside-in, to the appropriate interfaces. Once this step is complete the firewall rules are in effect immediately:

ASA5505(config)# access-group inside-in in interface inside
ASA5505(config)# access-group outside-in in interface outside

Configure Logging/Debugging of Events & Errors

This last step in our ASA Firewall configuration guide will enable logging and debugging so that we can easily trace events and errors. It is highly recommended to enable logging because it will certainly help troubleshooting the ASA Firewall when problems occur.

ASA5505(config)# logging buffered 7

ASA5505(config)# logging buffer-size 30000

ASA5505(config)#  logging enable

The commands used above enable log in the debugging level (7) and sets the buffer size in RAM to 30,000 bytes (~30Kbytes).

Issuing the show log command will reveal a number of important logs including any packets that are processed or denied due to access-lists:

ASA5505(config)# show 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, 39925 messages logged
    Trap logging: disabled
    History logging: disabled
    Device ID: disabled
    Mail logging: disabled
    ASDM logging: disabled
n" [0x0, 0x0]
%ASA-4-106023: Deny tcp src inside:10.71.0.50/54843 dst outside:10.0.0.10/445 by access-group "inside-in" [0x0, 0x0]
%ASA-4-106023: Deny tcp src inside:10.71.0.50/54845 dst outside:10.0.0.10/445 by access-group "inside-in" [0x0, 0x0]
%ASA-4-106023: Deny tcp src inside:10.71.0.50/54844 dst outside:10.0.0.10/445 by access-group "inside-in" [0x0, 0x0]
%ASA-4-106023: Deny tcp src inside:10.71.0.50/54850 dst outside:10.0.0.10/139 by access-group "inside-in" [0x0, 0x0]
%ASA-4-106023: Deny tcp src inside:10.71.0.50/54843 dst outside:10.0.0.10/445 by access-group "inside-in" [0x0, 0x0]
%ASA-4-106023: Deny tcp src inside:10.71.0.50/54845 dst outside:10.0.0.10/445 by access-group "inside-in" [0x0, 0x0]
%ASA-4-106023: Deny tcp src inside:10.71.0.50/54844 dst outside:10.0.0.10/445 by access-group "inside-in" [0x0, 0x0]
%ASA-4-106023: Deny tcp src inside:10.71.0.50/54850 dst outside:10.0.0.10/139 by access-group "inside-in" [0x0, 0x0]
%ASA-4-106023: Deny udp src inside:10.71.0.50/137 dst outside:10.0.0.10/137 by access-group "inside-in" [0x0, 0x0]
%ASA-6-302014: Teardown TCP connection 4718 for outside:173.194.40.49/443 to inside:10.71.0.50/54803 duration 0:02:00 bytes 1554462 TCP FINs

Conclusion

This article serves as an introduction configuration guide for the ASA5500 series Firewall appliances. We covered all necessary commands required to get any ASA5500 Firewall working and servicing network clients, while also explaining in detail all commands used during the configuration process.

Read More

Six Predictions for Cloud Collaboration in 2013

As we move into 2013 and attempt a glance further into the future, we see shifts in the conversation around cloud collaboration. I’ve outlined a few thoughts on what we can expect soon, over the course of the next few years, and in the future.
In 2013, we’ll see the cloud conversation shift to flexibility and agility as primary drivers of adoption.

“Businesses will have to provide an environment in which their employees are connected in ways they have never been connected before.”

As more companies understand the problems that arise in the collection of big data and the number of employees who work outside the office increases, cloud adoption will grow exponentially. Gartner data shows 71 percent of businesses adopted Software as a Service (SaaS) within the past three years, with three quarters of businesses planning on increasing SaaS spending. However, the reason companies increasingly invest in SaaS will shift. As a recent Forrester survey shows, a decreasing number of businesses are prioritizing lower costs as a reason to adopt SaaS, while an increasing number of businesses are focusing on “business agility” as a reason to deploy a SaaS solution.
In order to compete effectively in the future, businesses will have to provide an environment in which their employees are connected in ways they have never been connected before – connecting employees to customers, partners, and suppliers real time, anytime, anywhere, and providing context to these collaborative sessions.  This can only be accomplished through leveraging an increasing set of collaborative technology, and exposing the most relevant data across the traditional mediums of voice, video, and chat. Cloud accelerates the roll-out of this technology consistently across entire companies and their business partners, so they can improve the efficiency of their decision-making and the quality of their customers’ experience. As the cloud and macroeconomic factors increase the speed of business and collaboration, businesses will look to the cloud to as a means to deploy the growing set of integrated collaborative tools and gain a competitive edge.
As cloud collaboration moves beyond early adopters in 2013, hybrid models will proliferate and customers will increasingly demand a seamless, uncompromising user experience between the cloud and the customer premises.

“More than 50 percent of enterprises began cloud migrations in 2011.”

Increasingly, businesses will look to a world of many clouds where some services are hosted on private clouds for policy/regulatory compliance or balance sheet reasons while others are hosted by public-cloud providers. Businesses will move to find a right balance between the two with hybrid cloud models. More than 50 percent of enterprises began cloud migrations in 2011 and at least 12 percent of all enterprise workloads will run on clouds (public, private, hybrid, community) globally by 2013.
In 2013, cloud delivery of video will enable a cost paradigm shift leading to acceleration of adoption of pervasive, any-to-any video conferencing.

“Deploying these advancements in the cloud will allow us to make any-to-any video connections between mobile, personal and room-based systems.”

Historically three key factors prevented widespread adoption of video: high infrastructure and endpoint costs, consistent quality of experience and lack of interoperability between systems. In 2013 we will see advances across all three of these challenges, particularly in software capabilities that will dramatically lower infrastructure and endpoint costs.  Deploying these advancements in the cloud will allow us to make any-to-any video connections between mobile, personal and room-based systems while optimally allocating resources depending on the endpoint, resulting in significantly lower costs and higher quality.  This will enable businesses of all sizes to take advantage of the power of video collaboration.
Over the next few years, mobile phones will connect to 4G LTE networks and be fully –featured devices for business collaboration, leveraging network intelligence to deliver unparalleled quality of experience for voice, messaging and video.

“LTE provides sufficient bandwidth to carry voice, video and data on a single radio network.”

LTE provides sufficient bandwidth to carry voice, video and data on a single radio network. With deployments already accelerating around the world, mobile operators are transitioning from circuit switch voice (GSM/CDMA) toward an all IP SIP-based architecture (IMS) over LTE, supporting high-bandwidth multimedia and real-time applications. This year, Metro-PCS and South Korea Telcos launched voice over LTE based on IMS (VoLTE), and major operators expect to launch similar offerings in late 2013 or 2014. Because the VoLTE architecture is based on SIP, integrating a mobile device as a business extension will become possible without the installation of a soft client.  Providers will enable a foundational set of enterprise-class voice, video, or messaging features via the network while enriching and unifying those experiences with a soft client or mobile browser.  As businesses demand more collaboration over video and social enterprise applications, the support provided by these new 4G LTE networks will increase the quality of communications and collaboration.
In the coming years, the Internet of Everything will connect people and ‘things,’ allowing for contextual collaboration, enabling new work styles, and empowering people to accomplish the extraordinary.  

 ”These experiences will be enabled by the Internet of Everything, resulting in a massive amount of data that provides us context and information in everything we do.”

Knowledge workers using enterprise software to instant message, meet via voice and video, and share content with coworkers and clients may also be using social tools, such as Facebook and Twitter, that are not fully integrated into the enterprise. Currently, a knowledge worker may enter an online and video meeting and not recognize another attendee’s name. Today, with some plug-in applications as early examples of a growing trend, scrolling over that person’s name may bring up recent email exchanges, providing a small amount of context going into the meeting. Now imagine a meeting solution that provides even more contextual cues. As you hover over another attendee’s name, a LinkedIn profile pops up with a picture, job title and description, and a list of shared professional contacts. A profile from enterprise and/or consumer social software instantly enlightens you to the personal and professional interests you share with this attendee. These experiences will be enabled by the Internet of Everything, resulting in a massive amount of data that provides us context and information in everything we do, even in the workplace.
2013 will “mark the beginning of a new era in IT; the emergence of the Celebrity CIO”.

“2013 will be the year of the CIO.”

During 2012 we saw the role and demands on IT grow exponentially, and as we enter 2013 we will see this accelerate.  The rise of the Cloud and the migration from the desktop (PC) to the workspace (multiple devices and platforms) will start to become central to business strategy and operational success.  Successful CIOs will react to this challenge as they are less measured by network uptime, and increasingly concerned with service availability, the impact they make on the business and how they can drive efficient business processes, innovation and business transformation.  2013 will be the year of the CIO.  The CIO’s influence and image will transform through the year and we will start to see ‘celebrity’ CIOs emerge.  They will rise like the stars of Silicon Valley have in recent times.  Their broadening skills will become highly prized by any business looking to drive innovation, market appeal and share value.  In turn they will become more influential, command greater recognition and wielding greater power.
As we continue seeing growth in these areas, the importance of collaboration and social interactions in the workplace continue to be prioritized as necessary components of a successful business. Feel free to share your thoughts on how you think cloud collaboration will change in the comments section below.

Read More

Understanding VLAN Trunk Protocol (VTP)

Introduction

VLAN Trunk Protocol (VTP) reduces administration in a switched network. When you configure a new VLAN on one VTP server, the VLAN is distributed through all switches in the domain. This reduces the need to configure the same VLAN everywhere. VTP is a Cisco-proprietary protocol that is available on most of the Cisco Catalyst series products.
Note: This document does not cover VTP Version 3. VTP Version 3 differs from VTP Version 1 (V1) and Version 2 (V2), and it is only available on Catalyst OS (CatOS) 8.1(1) or later. VTP Version 3 incorporates many changes from VTP V1 and V2. Make certain that you understand the differences between VTP Version 3 and earlier versions before you alter your network configuration. Refer to one of these sections of Configuring VTP for more information:

• Understanding How VTP Version 3 Works
  
• Interaction with VTP Version 1 and VTP Version 2 (VTP Version 3)
  

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software or hardware versions.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Understand VTP

Flash Animation: VTP

Refer to the VLAN Trunk Protocol (VTP) Flash animation, which explains these concepts for VTP V1 and V2:

• Introduction to VTP
  
• VTP domain and VTP modes
  
• Common VTP problems and solutions
  

Note: This document does not cover VTP Version 3. VTP Version 3 differs from VTP V1 and V2 and is only available on CatOS 8.1(1) or later. Refer to one of these sections of Configuring VTP for more information:

• Understanding How VTP Version 3 Works
  
• Interaction with VTP Version 1 and VTP Version 2 (VTP Version 3)
  

VTP Messages in Detail

VTP packets are sent in either Inter-Switch Link (ISL) frames or in IEEE 802.1Q (dot1q) frames. These packets are sent to the destination MAC address 01-00-0C-CC-CC-CC with a logical link control (LLC) code of Subnetwork Access Protocol (SNAP) (AAAA) and a type of 2003 (in the SNAP header). This is the format of a VTP packet that is encapsulated in ISL frames:

Of course, you can have a VTP packet inside 802.1Q frames. In that case, the ISL header and cyclic redundancy check (CRC) is replaced by dot1q tagging.
Now consider the detail of a VTP packet. The format of the VTP header can vary, based on the type of VTP message. But, all VTP packets contain these fields in the header:

• VTP protocol version: 1, 2, or 3
  
• VTP message types:
  
  • Summary advertisements
    
  • Subset advertisement
    
  • Advertisement requests
    
  • VTP join messages
    
• Management domain length
  
• Management domain name
  

Configuration Revision Number

The configuration revision number is a 32-bit number that indicates the level of revision for a VTP packet. Each VTP device tracks the VTP configuration revision number that is assigned to it. Most of the VTP packets contain the VTP configuration revision number of the sender.
This information is used in order to determine whether the received information is more recent than the current version. Each time that you make a VLAN change in a VTP device, the configuration revision is incremented by one. In order to reset the configuration revision of a switch, change the VTP domain name, and then change the name back to the original name.

Summary Advertisements

By default, Catalyst switches issue summary advertisements in five-minute increments. Summary advertisements inform adjacent Catalysts of the current VTP domain name and the configuration revision number.
When the switch receives a summary advertisement packet, the switch compares the VTP domain name to its own VTP domain name. If the name is different, the switch simply ignores the packet. If the name is the same, the switch then compares the configuration revision to its own revision. If its own configuration revision is higher or equal, the packet is ignored. If it is lower, an advertisement request is sent.

This list clarifies what the fields means in the summary advertisement packet:

• The Followers field indicates that this packet is followed by a Subset Advertisement packet.
  
• The Updater Identity is the IP address of the switch that is the last to have incremented the configuration revision.
  
• The Update Timestamp is the date and time of the last increment of the configuration revision.
  
• Message Digest 5 (MD5) carries the VTP password, if MD5 is configured and used to authenticate the validation of a VTP update.
  

Subset Advertisements

When you add, delete, or change a VLAN in a Catalyst, the server Catalyst where the changes are made increments the configuration revision and issues a summary advertisement. One or several subset advertisements follow the summary advertisement. A subset advertisement contains a list of VLAN information. If there are several VLANs, more than one subset advertisement can be required in order to advertise all the VLANs.

This formatted example shows that each VLAN information field contains information for a different VLAN. It is ordered so that lowered-valued ISL VLAN IDs occur first:

Most of the fields in this packet are easy to understand. These are two clarifications:

• Code—The format for this is 0x02 for subset advertisement.
  
• Sequence number—This is the sequence of the packet in the stream of packets that follow a summary advertisement. The sequence starts with 1.
  

Advertisement Requests

A switch needs a VTP advertisement request in these situations:

• The switch has been reset.
  
• The VTP domain name has been changed.
  
• The switch has received a VTP summary advertisement with a higher configuration revision than its own.
  

Upon receipt of an advertisement request, a VTP device sends a summary advertisement. One or more subset advertisements follow the summary advertisement. This is an example:

• Code—The format for this is 0x03 for an advertisement request.
  
• Start-Value—This is used in cases in which there are several subset advertisements. If the first (n) subset advertisement has been received and the subsequent one (n+1) has not been received, the Catalyst only requests advertisements from the (n+1)th one.
  

Other VTP Options

VTP Modes

You can configure a switch to operate in any one of these VTP modes:

• Server—In VTP server mode, you can create, modify, and delete VLANs and specify other configuration parameters, such as VTP version and VTP pruning, for the entire VTP domain. VTP servers advertise their VLAN configuration to other switches in the same VTP domain and synchronize their VLAN configuration with other switches based on advertisements received over trunk links. VTP server is the default mode.
  
• Client—VTP clients behave the same way as VTP servers, but you cannot create, change, or delete VLANs on a VTP client.
  
• Transparent—VTP transparent switches do not participate in VTP. A VTP transparent switch does not advertise its VLAN configuration and does not synchronize its VLAN configuration based on received advertisements, but transparent switches do forward VTP advertisements that they receive out their trunk ports in VTP Version 2.
  
• Off (configurable only in CatOS switches)—In the three described modes, VTP advertisements are received and transmitted as soon as the switch enters the management domain state. In the VTP off mode, switches behave the same as in VTP transparent mode with the exception that VTP advertisements are not forwarded.
  

VTP V2

VTP V2 is not much different than VTP V1. The major difference is that VTP V2 introduces support for Token Ring VLANs. If you use Token Ring VLANs, you must enable VTP V2. Otherwise, there is no reason to use VTP V2. Changing the VTP version from 1 to 2 will not cause a switch to reload.

VTP Password

If you configure a password for VTP, you must configure the password on all switches in the VTP domain. The password must be the same password on all those switches. The VTP password that you configure is translated by algorithm into a 16-byte word (MD5 value) that is carried in all summary-advertisement VTP packets.

VTP Pruning

VTP ensures that all switches in the VTP domain are aware of all VLANs. However, there are occasions when VTP can create unnecessary traffic. All unknown unicasts and broadcasts in a VLAN are flooded over the entire VLAN. All switches in the network receive all broadcasts, even in situations in which few users are connected in that VLAN. VTP pruning is a feature that you use in order to eliminate or prune this unnecessary traffic.
Broadcast traffic in a switched network without pruning
This figure shows a switched network without VTP pruning enabled. Port 1 on Switch A and Port 2 on Switch D are assigned to the Red VLAN. If a broadcast is sent from the host connected to Switch A, Switch A floods the broadcast and every switch in the network receives it, even though Switches C, E, and F have no ports in the Red VLAN.
Broadcast traffic in a switched network with pruning
This figure shows the same switched network with VTP pruning enabled. The broadcast traffic from Switch A is not forwarded to Switches C, E, and F because traffic for the Red VLAN has been pruned on the links shown (Port 5 on Switch B and Port 4 on Switch D).
When VTP pruning is enabled on a VTP server, pruning is enabled for the entire management domain. Making VLANs pruning-eligible or pruning-ineligible affects pruning eligibility for those VLANs on that trunk only (not on all switches in the VTP domain). VTP pruning takes effect several seconds after you enable it. VTP pruning does not prune traffic from VLANs that are pruning-ineligible. VLAN 1 and VLANs 1002 to 1005 are always pruning-ineligible; traffic from these VLANs cannot be pruned. Extended-range VLANs (VLAN IDs greater than 1005) are also pruning-ineligible.

Use VTP in a Network

By default, all switches are configured to be VTP servers. This configuration is suitable for small-scale networks in which the size of the VLAN information is small and the information is easily stored in all switches (in NVRAM). In a large network, the network administrator must make a judgment call at some point, when the NVRAM storage that is necessary is wasteful because it is duplicated on every switch. At this point, the network administrator must choose a few well-equipped switches and keep them as VTP servers. Everything else that participates in VTP can be turned into a client. The number of VTP servers should be chosen in order to provide the degree of redundancy that is desired in the network.
Notes:

• If a switch is configured as a VTP server without a VTP domain name, you cannot configure a VLAN on the switch.
  Note: It is applicable only for CatOS. You can configure VLAN(s) without having the VTP domain name on the switch which runs on IOS.
  
• If a new Catalyst is attached in the border of two VTP domains, the new Catalyst keeps the domain name of the first switch that sends it a summary advertisement. The only way to attach this switch to another VTP domain is to manually set a different VTP domain name.
  
• Dynamic Trunking Protocol (DTP) sends the VTP domain name in a DTP packet. Therefore, if you have two ends of a link that belong to different VTP domains, the trunk does not come up if you use DTP. In this special case, you must configure the trunk mode as on or nonegotiate, on both sides, in order to allow the trunk to come up without DTP negotiation agreement.
  
• If the domain has a single VTP server and it crashes, the best and easiest way to restore the operation is to change any of the VTP clients in that domain to a VTP server. The configuration revision is still the same in the rest of the clients, even if the server crashes. Therefore, VTP works properly in the domain.
  

Configure VTP

Refer to Configuring VLAN Trunk Protocol (VTP) for information to configure VTP.

Troubleshoot VTP

Refer to Troubleshooting VLAN Trunk Protocol (VTP) for information to troubleshoot VTP.

Conclusion

There are some disadvantages to the use of VTP. You must balance the ease of VTP administration against the inherent risk of a large STP domain and the potential instability and risks of STP. The greatest risk is an STP loop through the entire campus. When you use VTP, there are two things to which you must pay close attention:

• Remember the configuration revision and how to reset it each time that you insert a new switch in your network so that you do not bring down the entire network.
  
• Avoid as much as possible to have a VLAN that spans the entire network.
  

Read More

Getting to Know the OSI Model for the CCNA Exam

The CCNA exam asks you to provide at least three reasons that the "industry" uses layered interconnection models. Examples of layered networking models include the seven-layer OSI model (which you need to know inside and out) and the Department of Defense (DOD) five-layer model (which you don't). The basic reason for using a layered networking approach is that a layered model takes a task, such as data communications, and breaks it into a series of tasks, activities, or components, each of which is defined and developed independently.

Reasons for a layered model

Expect to see a question on the exam that asks you to identify the reasons a layered model is used in internetworking. Actually, a myriad of reasons exist for why a layered model is used, but you should memorize these possible responses:

• Change: When changes are made to one layer, the impact on the other layers is minimized. If the model consists of a single, all-encompassing layer, any change affects the entire model.

• Design: A layered model defines each layer separately. As long as the interconnections between layers remain constant, protocol designers can specialize in one area (layer) without worrying about how any new implementations affect other layers.

• Learning: The layered approach reduces a very complex set of topics, activities, and actions into several smaller, interrelated groupings. This makes learning and understanding the actions of each layer and the model generally much easier.

• Troubleshooting: The protocols, actions, and data contained in each layer of the model relate only to the purpose of that layer. This enables troubleshooting efforts to be pinpointed on the layer that carries out the suspected cause of the problem.

• Standards: Probably the most important reason for using a layered model is that it establishes a prescribed guideline for interoperability between the various vendors developing products that perform different data communications tasks. Remember, though, that layered models, including the OSI model, provide only a guideline and framework, not a rigid standard that manufacturers can use when creating their products.

The layers of the OSI model

Under its official name, the Open Systems Interconnection Reference Model, or the OSI model, was developed by the International Organization for Standardization, which uses the abbreviation of ISO. And, yes, the full acronym of the OSI is ISO OSI.

The OSI model is a layered model that describes how information moves from an application program running on one networked computer to an application program running on another networked computer. In essence, the OSI model prescribes the steps to be used to transfer data over a transmission medium from one networked device to another. The OSI model is a seven-layer model developed around five specific design principles:

• Whenever a discrete level of abstraction is required, a new layer should be created.

• Each layer of the model should carry out a well-defined function.

• The function of each layer should define internationally standardized protocols.

• The boundaries of the layers should be placed to minimize the flow of information across interfaces.

• There should be a sufficient number of layers defined to prevent unnecessary grouping of functions and the number of layers should also be small enough so that the model remains manageable.

Moving down through the layers

The OSI model breaks the network communications process into seven separate layers. From the top, or the layer closest to the user, down, these layers are:

• Layer 7, Application: The Application layer provides services to the software through which the user requests network services. Your computer application software is not on the Application layer. This layer isn't about applications and doesn't contain any applications. In other words, programs such as Microsoft Word or Corel are not at this layer, but browsers, FTP clients, and mail clients are.

• Layer 6, Presentation: This layer is concerned with data representation and code formatting.

• Layer 5, Session: The Session layer establishes, maintains, and manages the communication session between computers.

• Layer 4, Transport: The functions defined in this layer provide for the reliable transmission of data segments, as well as the disassembly and assembly of the data before and after transmission.

• Layer 3, Network: This is the layer on which routing takes place, and, as a result, is perhaps the most important OSI layer to study for the CCNA test. The Network layer defines the processes used to route data across the network and the structure and use of logical addressing.

• Layer 2, Data Link: As its name suggests, this layer is concerned with the linkages and mechanisms used to move data about the network, including the topology, such as Ethernet or Token Ring, and deals with the ways in which data is reliably transmitted.

• Layer 1, Physical: The Physical layer's name says it all. This layer defines the electrical and physical specifications for the networking media that carry the data bits across a network.

Other interesting OSI layer stuff

Layers 5 through 7 are generally referred to as the upper layers. Conversely, Layers 1 through 4 are collectively called the lower layers. Seems obvious, but you'll see these references on the test.

You need to know the seven layers in sequence, either top-to-bottom or bottom-to-top. Here are some mnemonic phrases to help you remember the layers of the OSI model:

• "Please Do Not Throw Salami Pizza Away" — this works for bottom-to-top. If you don't like salami pizza, then how about seafood or spinach pizza instead?

• "All People Seem To Need Data Processing" — a top-to-bottom reminder.

• "APS Transports Network Data Physically" — APS refers to Application, Presentation, and Session. This one separates the upper and lower layer groups.

• "Please Do Not Tell Secret Passwords Anytime" — Shh! Another bottom-to-top phrase.

Packaging the data

Each layer of the OSI model formats the data it receives to suit the functions to be performed on that layer. In general, the package of data that moves through the layers is called a Protocol Data Unit (PDU). However, as the data is reformatted and repackaged, it takes on unique names on certain layers. Table 1 lists the name each layer uses to refer to a message.

Absolutely memorize the information in Table 1 to the point that you can recite the data unit name associated with each of the OSI model's layers.

Table 1: PDU Names on the Layers of the OSI Model

OSI Layer	PDU Name
Application	Data
Presentation	Data
Session	Data
Transport	Segment
Network	Packet
Data Link	Frame
Physical	Bits

Read More