|posted in Certifications|
|by eaadams on July 15th, 2013||tags: CCENT, CCNA, ICND1, ICND2|
On March 26, 2013, Cisco introduced new certification exams for ICND1, ICND2, and CCNA. In addition to content changes, there is also a significant change to the exam sequence structure.
This is a summary of these changes to the CCNA certification exams. The information is based on a number of public Cisco sources. For complete and official information about the CCNA certification exams refer to http://www.cisco.com/go/ccna.
Retiring CCNA Certification Exams
The current CCNA related exams retire on 30 September 2013:
- 640-802 CCNA
- 640-822 ICND1 (CCENT)
- 640-816 ICND2
CCNA certification is achieved by either passing the composite 640-802 exam or the 640-822 ICND1 exam and then the 640-816 ICND2 exam.
The retiring CCNA certification is the prerequisite for the CCNA specializations and for the three exam CCNP Routing and Switching certification.
|posted in Cisco Networking|
|by ristau5741 on January 7th, 2013||tags: 6500, Cisco, upgrade|
Upgrading IOS on a Cisco 6500 isn’t necessarily as simple as loading an IOS image and rebooting the switch. There are several other items that should also be considered such as modules, firmware, and field programmable devices. The firmware is the low level operating system beneath IOS that controls how the various components work and interact.
These are some items that might need to be upgraded in addition to the IOS:
- CEF720 line card firmware
- SUP720 switch processor firmware
- MSFC3 route processor firmware
- Field Programmable Device firmware
Each of the above have their own firmware naming conventions and it can be difficult to find these files. Try to Google partial file names to locate the correct images on the Cisco site. Here are some tips for finding firmware:
- The CEF720 line card firmware starts with c2lc-rm2. As of this writing, 12.2(18r)S1 is the current version and the current file name is c2lc-rm2.srec.122-18r-S1
- The SUP720 firmware starts with c6ksup720. As of this writing, 8.5(4) is the current version and the current file name is c6ksup720-rm2-srec.8-5-4.srec.
- The MSFC3 firmware starts with c6msfc, as of this writing 12.2(17r)SX7 is the current version and the current file name is c6msfc3-rm2-srec.122-17r.SX7.
- The field programmable device firmware starts with c6500-fpd-pkg. As of this writing, 12.2(33)SXJ3 is the current version and the current file name is c6500-fpd-pkg.122-33.SXJ3.pkg
- The IOS images for the 6500 series SUP720 firmware starts with s72033. As of this writing, 12.2(33)SXJ3 is the current version and the current file name is s72033-ipbase-mz.122-33.SXJ3, depending on your IOS license version
Field programmable devices start with SIP or SPA as part of the module name. You can verify if your chassis has a field programmable device by issuing the following command in the CLI:
show hw-module all fpd
|posted in Cisco Networking, Technical|
|by Perlhack on October 10th, 2012||tags: backups, Cisco, technical|
SNMP provides a common management interface across platforms that support the MIB OIDs. The ability to automate a process once and not having to worry about CLI syntax nuances across different platforms makes SNMP an ideal choice for network management. The CISCO-CONFIG-COPY-MIB can be used to backup configurations on devices that support this MIB.
There are many products on the market that can backup Cisco device configurations and typically require the user to make a config file that defines each IP address of the device to backup. I manage a lab infrastructure that consists of an aggregate /17 network (consists of ~700 live hosts at any one time) and devices in the lab are constantly being removed/added. Trying to track individual IP addresses in this environment is difficult. The ability to execute automatic host discovery, and once a host is discovered backup the configuration. The aforementioned challenge has to be solved post-haste and I have a budget of $0 for new products. Here is my solution for automated host discovery and config backup.
Configurations are backed up by FTP after writing to the appropriate MIB objects. Networks are scanned by NMAP using ICMP (automatic host discovery). Hosts that reply to the ICMP request are a candidate for backup. Configuration backup will succeed provided that device is using SNMPv2c write access communities or SNMPv3 write access users. Script below uses SNMPv3 as an example. Script will create a directory (named by date) under the users home directory and the backup files will appear as the IP addresses of the device.
|posted in Cisco Networking|
|by kannies on June 13th, 2012||tags: BGP, Cisco, failover, HSRP, IP SLA|
Service providers are moving away from from providing TDM point-to-point based circuits and we are now seeing more provisioning of Metro Ethernet to the customer site.
This leaves us with an issue in that when your BGP peer becomes unreachable, because your local FastEthernet interface on the CE will still be up/up as it will probably be connected to some Layer 2 device, the customer network could suffer a complete outage for up to 3 minutes. The BGP default hold time is 180 seconds. For a customer that has been sold a 100M pipe with resilience this is not going to make them happy.
|posted in Cisco Networking|
|by killabee on May 14th, 2012||tags: cisco 4500, ios, issu, upgrade|
I recently had to upgrade the IOS on a Cisco 4500. I figured it was the perfect opportunity to try out ISSU and to blog about it.
ISSU (In-Service Software Upgrade) is a feature that allows the operator to upgrade (or downgrade) the IOS on device without having to take the entire device down and potentially impact service. This is partly accomplished with the SSO supervisor redundancy mode that performs the subsecond supervisor switchovers while each supervisor is restarted and loaded with the new (or old) IOS.
In brief, the process works as follows: Both supervisors are running the old image. The standby supervisor is restarted and loaded with the new image. The operator switches over to the standby supervisor to ‘test drive’ the new image. The switchover automatically restarts the active supervisor, bringing it up as the standby and making the current standby supervisor the active. Finally, the standby supervisor, which started as the active, is restarted and loaded with the new image. In the end, both supervisors have the new image.
« Older Entries