Thursday, October 24, 2013

The next big project

The next big project, kind of.
This next project was just plain fun.  The team had to replace a Cisco 1700 series router with its blazing fast 6Mb (4 bundled T1 lines) up-link, with a Cisco 3750X layer 3 switch with 2 1Gb links to our fiber transport ring. 
After my colleague coordinated the fiber cut and fiber run to the facility, it was my responsibility to configure the new 3750X.  As this new switch would be sitting between two existing nodes on our fiber transport ring we decided to configure the uplink to the core on the 3750x as if it were the other node. This would ensure no changes needed to be done at the core node. On the down link to the other existing node a new /30 address was configured.  Once the new /30 address was added to the existing node and the EIGRP network statements were corrected for the new /30 network,  and the removal of the origin /30 network, all links were up.
One small item we needed to pay special attention to was the fiber transceiver. The distance between nodes is over 16,000 feet so we used CWDM 1590 SFPs  in point to point mode.

Anytime we can save 3500.00 dollars a month and provide the users with better performances, it’s a win, win (just plain fun).

Thursday, August 22, 2013

The Ready Big Project.

The Ready Big Project.
          This Project had our team upgrading the networking equipment of one of our main sites, in preparation of our IP Telephony roll out. This site houses one of our two UC clusters, and facilities three of our largest and most visible departments. The project included replacing the Cisco 3560E Layer 3 switch with a Cisco 6509, replacing a Cisco 3550 switch with a Cisco 3850, and adding a Cisco 3750X to an existing 3750X stack.
          Due to the 24/7 nature of the site the work had to be scheduled after hours and any loss of connectivity had to be kept to a minimum and a total maintenance window of three hours.
          A lot of planning went into ensuring the ports from the 3560E to the IDFs were mapped correctly on the 6509. Most of the optical transceivers were reused, but all of the fiber jumpers had to be replaced with longer lengths. Furthermore the new Ten Gigabit optics in the new 3850 meant an optic in the 6509 had to be changed and of course the jumper connecter type had to be changed as well. Additionally we had to add an optic and jumper for the additional 3750x. Once the 6509 was powered up and the configuration checked we broke the Ten Gigabit transport ring and connected the 6509’s 1st Supervisor’s Ten Gigabit port to the uplink while leaving the ring’s downlink in the 3560E so as we moved the IFD’s links the down time was minimized. To minimize any down time due to the boot-up of the 3850 one of the power cords was ran thought the rack to supply power to the switch so it would be booting while it was being mounted. After we mounted, cabled the stack cables, and powered up the new 3750x to the existing stack, we had to configure the “new” stack with an EtherChannel to the 6509. Once the EtherChannel came up we notice stack port 1 flapping, we reseated the stack cable on port 1, which fixed the issue. As we moved the IDFs off the 3560E and into the 6509, we tested connectivity to the IDFs with the Show CDP and Show Interface Trunk CLI commands.
          After all the IDFs were patched to the 6509, all IDFs were tested to ensure clients were receiving DHCP addresses as well as logging into the equipment in the IDFs remotely. Once the 3570x stack came up and the stack port issue was addressed, numerous extensions were called and they were checked in CUCM to ensure they had registered with the correct UC cluster.
          We did run into a few issues with this project, mostly with the count and types of fiber jumpers. As all the jumpers needed to be replace and some were Single Mode and others Multi Mode and with the addition of the new optics and jumpers, I lost count of the jumpers by type and did not bring enough of the correct type. This issue was fixed with a quick trip to the warehouse to pick up additional jumpers. Another issue appeared the next day as users started logging on. Users reported a scarcely use application was not working. The app used multicast and we realized when the config had been copied to the 6509 the IP multicast command syntax was different on the 6509 and did not take, and was not caught. The correct command was issued on the 6509 and because the IP PIM commands were on the interfaces the app start working.
          Lessons learned on this project are, always have another set of eyes double check the inventory list to ensure counts are correct. Also check command syntax when coping configs between different platforms. This was a really big project with a lot of moving parts. The entire project went well with very little disruption in service, and all work was completed in the maintenance window. Even with the issues, which were resolved quickly, we laid the foundation for the rest of the equipment upgrades and roll out. The team worked well together, and we learned about each other’s strengths.

Tuesday, July 2, 2013

Getting ready for CCNP ROUTE

Exam Topics The following information provides general guidelines for the content likely to be included on the exam. However, other related topics may also appear on any specific delivery of the exam. In order to better reflect the contents of the exam and for clarity purposes the guidelines below may change at any time without notice. Implement an EIGRP based solution, given a network design and a set of requirements Determine network resources needed for implementing EIGRP in a network Create an EIGRP implementation plan Create an EIGRP verification plan Configure EIGRP routing Verify an EIGRP solution was implemented properly using show and debug commands Document the verification results for an EIGRP implementation Implement a multi-area OSPF Network, given a network design and a set of requirements Determine network resources needed for implementing OSPF on a network Create an OSPF implementation plan Create an OSPF verification plan Configure OSPF routing Verify OSPF solution was implemented properly using show and debug commands Document the verification results for an OSPF implementation plan Implement an eBGP based solution, given a network design and a set of requirements Determine network resources needed for implementing eBGP on a network Create an eBGP implementation plan Create an eBGP verification plan Configure eBGP routing Verify eBGP solution was implemented properly using show and debug commands Document verification results for an eBGP implementation plan Implement an IPv6 based solution, given a network design and a set of requirements Determine network resources needed for implementing IPv6 on a network Create an IPv6 implementation plan Create an IPv6 verification plan Configure IPv6 routing Configure IPv6 interoperation with IPv4 Verify IPv6 solution was implemented properly using show and debug commands Document verification results for an IPv6 implementation plan Implement an IPv4 or IPv6 based redistribution solution, given a network design and a set of requirements Create a redistribution implementation plan based upon the results from a redistribution analysis Create a redistribution verification plan Configure a redistribution solution Verify that a redistribution was implemented Document results of a redistribution implementation and verification plan Identify the differences between implementing an IPv4 and IPv6 redistribution solution Implement Layer 3 Path Control Solution Create a Layer 3 path control implementation plan based upon the results of the redistribution analysis Create a Layer 3 path control verification plan Configure Layer 3 path control Verify that a Layer 3 path control was implemented Document results of a Layer 3 path control implementation and verification plan Implement basic teleworker and branch services Describe broadband technologies Configure basic broadband connections Describe basic VPN technologies Configure GRE Describe branch access technologies