Just wanted to put out a quick note letting you know that I’m still well and alive. I’ve recently taken on a large contract job with a large VAR who has me out of the state during the week. Hopefully I’ll be able to find some time to finish some of the articles I have drafted up and get those out to you. I apologize for my absence and hope to be back to writing again soon.
Best wishes,
-Tony
{ 1 comment }
Greg Ferro of Etheralmind.com has started a petition asking Cisco to embrace those who pursue Cisco’s certifications a legal course of licensing without the cost of building a home made space shuttle. Please take some time and read / sign the petition.
We want to be able to practice that knowledge, and demonstrate our competence. We know that you are considering the value. This petition is to show our need for this solution. Wendel Odom discusses the possibility Cisco Considers IOS for Certifcation Self Study and we are calling for Cisco to make an option available.
This experience and knowledge we gain gives us the capability to make the most of Cisco equipment for our employers, your customers. We help drive the best return on investment, and keep the network performing in the way that your customers expect. We can test configurations prior to making and be better prepared. We can develop more complex configurations than would otherwise be possible, and not blame the equipment afterwards.
{ 0 comments }
Cisco IOS has plenty of gems contained within, but few are as fun, and as endlessly useful as the Embedded Event Manager, or EEM. To define it simply, EEM is a technology that allows you to run a script or a set of commands upon an event. Basically, it’s an IOS scripting language that allows you to insert additional functionality to the IOS.
I think an example is in order. Lets say, you want to make sure loopback0 never gets shut down accidentally. We can create a EEM applet to watch for the syslog message that loopback0 has been shutdown, and automagicly bring it back up!
event manager applet WatchLo0 event syslog pattern "Interface Loopback0.* down" period 1 action 2.0 cli command "enable" action 2.1 cli command "config t" action 2.2 cli command "interface lo0" action 2.3 cli command "no shutdown" action 3.0 syslog msg "Interface Loopback0 was brought up via EEM" !
{ 2 comments }
Learning the particulars of Cisco IOS is one of the most valuable things a network engineer can do. These skills will be the basis of everything you do on the lab and on your network. The following is a collection of things that most everyone uses these days.
Prevent timeout on the serial console. You can also apply this to the VTY lines if you ssh / telnet into the router.
Router(config)#line con 0 Router(config-line)#exec-timeout 0 0 ! 0-minutes 0-seconds
The following configuration will allow you to work uninterrupted from system messages.
Router(config)#line con 0 Router(config-line)#logging synchronous
{ 4 comments }
The Cisco IOS archive command is not only very useful in keeping configuration archives, but it can also be used to log commands entered into the router, along with their user name. As with most technologies, their options can be rather extensive so we will just be covering the basics here.
In IOS 12.3, Cisco introduced the archive, and archive config commands. At a bare minimum, you can start archiving configs with a 2 line setup! Here we’ve simply defined an archive path, and manually told the router to make two archives of the configuration using the archive config command.
[ read more... ]
{ 1 comment }
The concepts behind Private VLANs are in fact rather simple, but it is quite easy to get discombobulated in the details. In their simplest form, PVLANs can dissociate ports within a PVLAN as if they were on separate VLANS, but still allow them to communicate with a common default gateway. i.e. these ports share a subnet, but can be prevented from communicating to each other.
In order to accomplish this we split our VLAN into sub-VLANS and classify these into one of three groups depending on how we want to segregate traffic. These groups are as follows.
In our example we’re using VLAN 100 as our primary VLAN. Our host machines will be setup on VLAN 101 which will be configured as Isolated. Our servers will be configured as Community ports on VLAN 102. Essentially, once established, VLAN 100 will forward frames from P-ports to I and C-ports. VLAN 101 and 102 are considered secondary VLANs.
[ read more... ]
{ 4 comments }
Bidirectional Forwarding Detection (BFD) is a UDP-based protocol that provides fast (very fast!) routing protocol independent detection of layer-3 next hop failures. BFD can be used to replace the routing protocol timers with a fast and reliable failure detection mechanism. BFD also provides low-overhead detection of faults even on interfaces that don’t support failure detection of any kind, such as Ethernet, virtual circuits, tunnels and MPLS Label Switched Paths.
The inner workings of the BFD protocol resemble the hello mechanisms used in most of today’s routing protocols, with a few exceptions. BFD packets can be processed on interface modules, whereas routing protocol hello packets are always processed by the control plane. BFD tests bidirectional communication. The hello protocol that EIGRP uses has been known to have issues with detecting unidirectional connections. Finally, BFD packets are typically smaller than keepalive packets from routing protocols. (24bytes + headers)
[ read more... ]
{ 1 comment }
A while back, I was playing on a 3750 switch in a customers lab and came across something I’ve never seen before. It seems that some Cisco switches have a built in Time-domain reflectometer, or TDR. While this is pretty standard on something like my Fluke gear, its nothing that I would expect to find on a Catalyst switch!
According to what I could find, this should be present on the 3560, 3750, and some modules for the 4500, 6500 and 7600 series. Quite an interesting feature if you ask me! This could be quite helpful for discovering cables that have been damaged. You can find the Cisco command reference for this feature here.
Switch#test cable-diagnostics tdr interface g1/0/12
TDR test started on interface Gi1/0/12
A TDR test can take a few seconds to run on an interface
Use 'show cable-diagnostics tdr' to read the TDR results.
Switch#show cable-diagnostics tdr int g1/0/12
TDR test last run on: May 21 21:31:09
Interface Speed Local pair Pair length Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi1/0/14 auto Pair A 25 +/- 4 meters N/A Open
Pair B 25 +/- 4 meters N/A Open
Pair C 24 +/- 4 meters N/A Open
Pair D 25 +/- 4 meters N/A Open
{ 1 comment }
Recent Comments