technology | art | nature
On the journey to CCNA Security (210-260)
Correlating Log files are an important aspect when responding to incidents/attacks/outages regarding your Cisco devices.
However I have noticed for a while that my logging timestamps are off an hour from the actual clock synced by NTP.
After some digging I realized that Cisco devices use
service timestamps log datetime
as a default. You can check the default values using the command:
sh run all | inc timestamp
In order for your logs to use the local clock time you need to issue the command
device(config)# service timestamp log datetime localtime
From now on, your logging timestamp should be identical to your local time on the device.
The CCNA training videos from this Kickstarter Project are now available.
Managing Access Lists on Cisco IOS devices can be a real headache. Copying ACLs and Editing them in a Text Editor was a widely spread method until extended ACLs implemented Named Access Lists (nacls) with featured sequence numbers.
Extended IP access list my_acl_in 2 permit icmp ..... (1234 matches) 3 permit ip any host x.x.x.x 10 permit ip .... 11 permit ip .... 12 permit ip .... 13 permit ip .... 14 permit tcp any host ...... eq 443 15 permit tcp any host ...... eq www
Btw. the IPv6 Access list sequence numbers are placed at the end
permit tcp host 2001:DB8:1::32 host 2001:DB8:2::32 eq ssh sequence 1
Sequence Numbers allow for quick changes to an ACL without the copy&paste foo. A growing and ever changing ACL however can post a challange to your sequencing once the gaps are filled. In order to realign your Access Control Entries you can use the resequence command to put your ACEs in order again.
r1(config)#ip access-list resequence ? <1-99> Standard IP access-list number <100-199> Extended IP access-list number <1300-1999> Standard IP access-list number (expanded range) <2000-2699> Extended IP access list number (expanded range) WORD Access-list name r1(config)#ip access-list resequence my_acl_in ? <1-2147483647> Starting Sequence Number r1(config)#ip access-list resequence my_acl_in 5 ? <1-2147483647> Step to increment the sequence number r1(config)#ip access-list resequence my_acl_in 5 5
will resequence your ACEs to look something like this:
Extended IP access list my_acl_in 5 permit icmp ..... (1234 matches) 10 permit ip any host x.x.x.x 15 permit ip .... 20 permit ip .... 25 permit ip .... 30 permit ip .... 35 permit tcp any host ...... eq 443 40 permit tcp any host ...... eq www
This feature will definitely help to keep your sanity.
I find it quite a bit strange that this fuction is not mentioned on neither the 640-802 CCNA nor the 640-554 CCNA Security Cert Guides.
For more infos, check out the Cisco ACL sequence numbering guide
With Switched Virtual Interfaces, a Layer 3 Switch can forward packets between networks on its own – no external Router required.
Compared to a normal Router with FastEthernet or GigabitEthernet Interfaces, Layer 3 Switches using SVI can forward packets between VLANS at backplane speed! To get an idea how SVI works, take a look at this graphic:
In this example we have 3 VLAN on the Layer 3 Switch: Vlan 20, 30 and 40. To be able to forward packets, IP Routing first needs to be enabled on a Layer 3 Switch:
sw1(config)#ip routing
As we need a gateway for each VLAN, we simply assign the gateway IP address to the equivalent VLAN Interface. Note that I left out the subnet mask in the image due to space restrictions. After that we put the VLAN interface online using the no shut command. You should see IP Addresses assigned to your VLAN Interfaces when using the sh ip int brief command.
Once your VLAN Interfaces are up and running with an assigned IP Adress, your switch is ready to forward packets.
Note: SVIs are also used to provide Layer 3 connectivity to a switch – for example if you want to access the switch via SSH or Telnet (seriously, do no use Telnet if you can use SSH).
The advantages of using SVIs to forward packets between your VLANs compared to using a Router or Router on a Stick are pretty obvious: Speed and Port density.
The disadvantage of this method is pretty obvious as well: It requires a Layer Switch such as the 3750 im using in my lab.
With the Layer 3 Switch set up in Pt.1 it is time to look at some basic concepts of Layer 3 Switching. The Router on a Stick concept is technically not Layer 3 Switching since the Packet Forwarding (Routing) requires a Router.
The basic concept of Router on a stick is implemented by creating subinterfaces on a single physical Router port. After the Switchport has been set to trunk mode (802.1q for you non-Cisco networkers), the subinterfaces can be assigned a VLAN by setting the trunk encapsulation to dot1q and a VLAN ID.
This concept should work with any switch that supports VLANs. Another advantage of this concept is the fact that only one Router port is required in order to forward Layer 3 packets between the VLANs. The downsides however are a single point of failure and possible congestion (depending on the amount of VLANs and bandwidth utilization).
Coming up next: Inter-VLAN Routing with Switched Virtual Interfaces (SVI) and Routed Ports which require Layer 3 switches.
So I finally decided to take the CCNA exam – 12 years after going through a great portion of the topics during my training as an IT professional.
Since my vocational college was (and still is) a Cisco Networking Academy (1999-2003) we used the Curriculum as a part of our daily lectures and they have given me both the knowledge and the motivation to dig into one of my favorite areas of IT engineering.
Back when I set up my first 10Base2 Local Area Network at the age of 15 – I knew practically nothing about IP Adresses and how to deploy them correctly. At some point, I got the 192.168.1.1/255.255.255.0 thing right and Local Area Network gaming opened up a whole new world to us. Keep in mind, back then most of the kids our age had only limited access to the internet.
Together with the GNU/Linux Operating System networks not only became my profession, but also my passion.
The last few years I spent with designing, implementing and troubleshooting medium sized networks in a university campus environment. After recently planning and deploying a medium sized wireless network (130 Lightweight Access Points) my next 2 candidates on the list of exploration (and at some point perhaps mastering) will be BGP and MPLS at a CCNP level, so I might as well take the CCNA on my path and then go for the CCNP. Even with many years of experience the CCNA exam will definitely not be a cakewalk since there are always some gaps that need to be filled (Frame-Relay, y u no go extinct!) and the exam yet has a reputation to be hard.
My Lab is still missing some WIC-1T cards + DCE/DTE crossover cables but then i should be good to go.
So I recently bought some (refurbished) Cisco equipment for my CCNA/CCNP lab, a 2620 and a 2621 to be precise. I bought both of them from the same company although there was a small, but important difference.
The 2620 placed in my first order went to my home address, but since I am building the Lab at my office I decided to have the 2621 shipped to my company address to spare me the logistics. Turned out this decision made quite a difference when both products arrived. (I bought the 2620 about 5 days ahead).
The 2620 could not boot the default IOS due to the following error:
System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fc1) Copyright (c) 1999 by cisco Systems, Inc. TAC:Home:SW:IOS:Specials for info C2600 platform with 16384 Kbytes of main memory program load complete, entry point: 0x80008000, size: 0x403b9c Self decompressing the image : #####....] INSUFFICIENT MEMORY TO LOAD IMAGE! I/O memory percentage cannot be adjusted.
Checking the Cisco IOS Image downloads I noticed the requirements for the IOS Image on the shipped 2620 requires at least 32MB DRAM, like any other 2620 image listed there (bare minimum is 32MB Dram,8 MB flash). However the Router was only equipped with 16MB of DRAM making the Router unusable, even with the minimum feature IOS for the 2620.
Now since the Hardware was probably refurbished, it is clear that some memory was replaced/removed but not in a fashion that allows the Router to boot the IOS Image. Looks like somebody did not even boot up the Router to see if it works. Probably a mistake (to err is human, after all).
When my 2621 arrived (addressed to my company address) the package also included a “Testing Protocol” – basically a show version printed on a piece of paper. Someone actually took the time to boot it up, connect to the console port and copy & paste the output to add the print along with the product. As a customer, this ensures me that someone took the time to verify the functionality of the Router.
I do not now if that was just coincidence but it does seem to verify that depending on the shipping address quality assurance is handled differently. I will post an update on the situation.
But looks like the tl;dr of the whole story is: Use a corporate address if you can.
I am currently studying for my CCNA and would like to share some cheat sheets with you. They can be found at http://packetlife.net/library/cheat-sheets/
You will find cheat sheets for all kinds of network related topics such as: