Friday, December 13, 2013
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.
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
Subscribe to:
Posts (Atom)