While this version came earlier than I would expect, there are some exciting new features, some of them definitely worth upgrading for. I have no intention telling the full story (or chewing the release notes for you ) but I do want to go over some of the features and the new commands they bring to the world:
EtherChannel support - up to 48 802.3ad EtherChannels of eight active interfaces each
new commands: channel-group, lacp port-priority, interface port-channel, lacp max-bundle, port-channel min-bundle, port-channel load-balance, lacp system-priority, clear lacp counters, show lacp, show port-channel.
Show Top CPU Processes – You can now monitor the processes that run on the CPU to obtain information related to the percentage of the CPU used by any given process.
new command: show process cpu-usage sorted
TCP Ping Enhancement - you can specify a source IP address and a port and source interface to send pings to a hostname or an IPv4 address
new command: command: ping tcp
Stateful Failover with Dynamic Routing Protocols - Routes that are learned through dynamic routing protocols (such as OSPF and EIGRP) on the active unit are now maintained in a Routing Information Base (RIB) table on the standby unit.
modified command: show failover, show route, show route failover.
Host Scan Package Support - support for the ASA to install or upgrade a Host Scan package and enable or disable Host Scan
new command: csd hostscan image path
These are only few changes that I find exciting and they show Cisco’s commitment to this product. If you’re running ASA (or even an old PIX) in your environment I highly recommend spending the time and reading the release notes. even if you’re not going to upgrade any time soon, it is always good to know what are the available options – you never know when you’ll need it.
If you already upgrade your ASA to 8.4 or even better – upgraded and used one of the new features, we want to hear about it!
While troubleshooting a VPN connection I wanted to confirm that the pre-shared key is identical on both ends. In order to do so I used a cool, relatively unknown command that allow you to recover the pre-shared key:
Using the more system:running-config command result in clear text pre-shared key:
tunnel-group tunnel_name ipsec-attributes
While this is the easiest way, you might encounter a device with an old version (pre 7.x) that does not support this command. Don’t worry, there are more opitons. using TFTP you can copy the config to your TFTP server which saves the password in clear text. This is the required command:
copy running-config tftp:
You can also use the less known write net command for the same task. In both cases, the text file containing the configuration on the TFTP server will show the pre-shared key in clear text.
By the way, older ASDM versions will show the passwords in clear text but I hope you’re not using those old versions
After a long while I had a chance to work with our firewall. Part of the task was setting up our old PIX as DHCP server.
The configuration is simple:
dhcpd address 172.16.1.100-172.16.1.200 inside dhcpd dns 172.16.1.1 dhcpd wins 172.16.1.2
You can see that the configuration is really simple but I found on interesting detail I wasn’t aware of: You can only use 256 addresses
Well, to be exact it is 253 addresses and it is a software limitation:
The size of the address pool is limited to 256 addresses per pool on the security appliance. This cannot be changed and is a software limitation. The total can only be 256.
One note – this limitation is per interface so if you have more than one inside interface you can use 253 addresses per interface.
This an email I just received from WordPress:
The stats helper monkeys at WordPress.com mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:
The Blog-Health-o-Meter™ reads Wow.
About 3 million people visit the Taj Mahal every year. This blog was viewed about 54,000 times in 2010. If it were the Taj Mahal, it would take about 7 days for that many people to see it.
In 2010, there were 129 new posts, growing the total archive of this blog to 131 posts. There were 128 pictures uploaded, taking up a total of 11mb. That’s about 2 pictures per week.
The busiest day of the year was January 26th with 660 views. The most popular post that day was New CCNP – Official Announcement.
Where did they come from?
The top referring sites in 2010 were linkedin.com, social.technet.microsoft.com, routemyworld.com, en.wordpress.com, and Google Reader.
Some visitors came searching, mostly for new ccnp track 2010, ospf bgp lab, netdom.exe, new ccnp, and eigrp variance.
Attractions in 2010
These are the posts and pages that got the most views in 2010.
New CCNP – Official Announcement January 2010
Cisco VPN Client for Win7 64-bit (beta) March 2010
New CCNP track – Countdown started January 2010
Labs February 2010
BSCI – BGP Lab February 2010
If you’re learning for your CCNA or want to refresh your memory AND have an iPhone\iPad\iTouch check out this OSI model app - NOW FREE
The most engaging OSI Model Video e-learning combining multiple modalities to help you understand the theory behind the OSI Model.Over 31000 people have viewed these video’s with a rating of 4.7.
The App is broken up into 3 videos:
1. Introduction to the OSI Model
2. Layer 1-3 of the OSI Model
3. Layer 4-7 of the OSI Model.
The video’s were created in a high quality production mode, not boring powerpoints or wipe boards. These videos were created by a Cisco Learning Solutions Partner – Tech 2000 and can be used to help you fulfill your CCENT or CCNA knowledge requirements. The commentator is a Cisco Certified Instructor.
As I wrote in my last post, I’m working on a PIX to ASA migration.
One of the things that came up when I checked the PIX config is nat-control. What is it doing and should I use it in my ASA? Reading this post will answer some of the questions.
Historically, PIX required NAT translation for traffic flowing from one interface to another. It all changed in PIX 7.0 when Cisco added the nat-control command which let you configure your PIX\ASA to allow traffic to flow across without the usage of NAT.
How does it work?
You should decide using the nat-control command in configuration mode to specify if NAT is required for outside communications. When NAT control is enabled, configuration of NAT rules is required in order to allow outbound traffic, as is the case with earlier versions of PIX software (older than 7.0).
If NAT control is disabled (using no nat-control), inside hosts can communicate with outside networks without the configuration of a NAT rule as long as they have valid public addresses.
This is how it looks in ASDM:
- Translation method – this can be a static translation with the static command, or a dynamic translation with a nat or global rule.
- Access control list (ACL) – If an ACL is present, then it must allow the source host access to the destination host with the use of the specific protocol and port.
To figure out if nat-control is enabled or disabled, use this simple show command:
show run nat-control
When enabled, the output would be
When disabled it will show
To sum, newer PIX\ASA do not need require NAT configuration and you have the option to disable nat-control. You should figure out the types of connections you pass through your firewall and make a decision if you want to enable or disable nat-control. At least you have the option
Yes, I’ve been gone for a while. I’m busy with my Exchange work and studies and with everything else around me I hardly get to even look at my home lab. But as they say, good things happen to those who wait and we’re upgrading our company PIX to ASA so I have some real use for my Cisco knowledge.
When coming to perform this task there are few things to remember, I’ll review the most important points (at least as I see it).
First there is the technical detail – End-of Sale and End-of-Life for PIX is past due. The important meaning is that Cisco will not support PIX (so go ahead and either upgrade to ASA or find another solution), if you have issues with existing PIX you’re not going to get Cisco’s help and if (god help you) your hardware will die, you’re doomed…
You can always migrate manually (and there are some benefits here, I’ll get to it in a sec) or take the shortcut and use the configuration migration tool. If you’re not sure which option fits your knowledge and experience I bet the migration tool is your option, for the rest of you – read further to get the main points of each option.
So now that you’ve decided on performing the upgrade using the migration tool, check your PIX software version. If your PIX is running 7.X or higher you are in a good place as the configuration migration tool mostly match up your old PIX interfaces with the new interfaces of the ASA. If the number of interfaces on ASA is lower than the number of existing PIX interfaces you’ll have to use dot1q (if you want to use the migration tool).
The other less pretty case is when your PIX is running an older than 7.X version as you have to convert the PIX conduit and outbound commands. The rest of the process is similar, use the migration tool and you should be okay.
You might ask yourself why would you go the hard way and build your configuration manually? Like many times in life, sometimes it’s just better starting from scratch. When you build the configuration you have in mind the existing network environment with current and future needs. When migrating from existing configuration you tend to live the past, keeping old configurations (mostly access rules and objects) because they exist – not always because they are being used.
If you have the knowledge and time building new configuration is, in my opinion, the better option. You get a more accurate configuration that suit your needs and clean old unused objects. And there is one more pro, whether you’re the new guy in the company (as in my case) or a few year veteran that knows the network inside out – planning and building the new configuration let you get familiar with all the needs and review the method you’re using. Veteran’s tend to get stuck with their old doctrines and rebuilding can prevent it, make them rethink their work.