Re: Migration Plan (6509) [7:55064]
In line (like a firewall)... The Long and Winding Road 10/09/02 01:46AM in line ( like the skates ) Ken Diliberto wrote in message news:200210090539.FAA09794;groupstudy.com... [snip] It's difficult to try keeping a hands-off approach to letting a vendor install a major piece of equipment in the core of MY network. Maybe you know how it is... watching an engineer (CCNP with some experience) who is supposed to know what he's doing but brings down the network instead. Add a CCIE with a few years experience to the mix, three more tries with two of them resulting in network outages. CL: Let he who has never brought a network down by accident ( or otherwise ) cast the first stone. Did I ever tell you the one about the newly minted Novell admin who decided to have some fun one afternoon unloading and loading NLM's? KD: The difference is, we hire consultants to make it work. It's my job to break it and I don't like to share. :-) KD: NLM's are designed to be loaded and unloaded. Was this a problem??? ;-) The suggested configuration for our first 6500 (a 6513 with dual Sup2/MSFC2/PFC2) was to run in HSRP between the two MSFCs. (For those who don't know, an MSFC - Multiservice Switch Feature Card or something like that, is a routing module on the switch supervisor). We are running IP, IPX and AppleTalk. What they didn't tell us was we had to keep the configurations sync'ed between the two MSFCs otherwise there would be problems. Config Sync doesn't support AppleTalk. Guess what... we had problems. We're now running SRM. CL: serves you right for running AppleTalk. KD: Ouch!!! That hurts. We're using things like Cisco stating Apple Talk will not be supported in EIGRP as a tool to migrate away from it. Several issues to overcome first, though. [snip] It seems our vendor keeps shooting itself in the foot. Their engineers keep doing things that prevents them from earning any respect from us. On a positive note, I know one engineer with that company who I do respect. Too bad they keep him in design. :-) CL: seriously, having spent wonderful quality ( but far too little ) time with the likes of Marty Adkins and Val Pavlichenko, not to mention a young guy at work I'm beginning to think is in this class, I suspect that there are very few top level network engineers in the world, and a lot of wannabe's. CL: Not everyone can be a brain surgeon. Most of us are just GP's. Of the CCIE's I have met, many are in this latter category as well. Let alone us CCNP / CCDP types. ;- We all just do the best we can, and live in fear that something we touch is going to break and we won't know how to fix it. KD: I'm not a brain surgeon. I'm a podiatrist. Or should that be... never mind. :-) KD: I know what you mean about talent levels. A brief technical talk with someone who really knows their stuff is very revealing. At a previous job our Cabletron SE knew more about the insides of Token Ring and the different flavors of Ethernet (not to mention FDDI) than I'll probably ever know. He also knew how to present it. KD: Working for a company IT group, I don't worry about breaking things. I tell my management that it could happen (and times it probably will happen) and go one with my job. As for knowing how to fix something I break, I'm not sure if that's happened yet. Usually backing out a change works. I do know what you mean, though. Definitely a down-side to consulting work. KD: Funny thing. I mentioned our vendor shooting themselves in the foot. Someone on this list (don't worry... I'll find out who it is) told the project manager about my message. The PM called my manager. Talk about hurting respect and burning bridges. Maybe we'll see Project Manager #5 in the near future. (I'm hoping he gets this message since he's too cowardly to talk to me directly). [snip] Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=55474t=55064 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Migration Plan (6509) [7:55064]
Ken Diliberto wrote in message news:200210122330.XAA04802;groupstudy.com... In line (like a firewall)... snip CL: Let he who has never brought a network down by accident ( or otherwise ) cast the first stone. Did I ever tell you the one about the newly minted Novell admin who decided to have some fun one afternoon unloading and loading NLM's? KD: The difference is, we hire consultants to make it work. It's my job to break it and I don't like to share. :-) KD: NLM's are designed to be loaded and unloaded. Was this a problem??? ;-) CL: depends on whether the NLM in question is the one that controls the server ethernet interface :-O CL: boy did that phone start ringing fast! snip Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=55476t=55064 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Migration Plan (6509) [7:55064]
in line ( like the skates ) Ken Diliberto wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Our parent company had the idea of letting a TelCo do the same for us. The TelCo was/is contracted to set up a gateway between the old network and the new network. Lucky for us we're smarter than they are (at least we think we are...) and are having things our way. :-) It's difficult to try keeping a hands-off approach to letting a vendor install a major piece of equipment in the core of MY network. Maybe you know how it is... watching an engineer (CCNP with some experience) who is supposed to know what he's doing but brings down the network instead. Add a CCIE with a few years experience to the mix, three more tries with two of them resulting in network outages. CL: Let he who has never brought a network down by accident ( or otherwise ) cast the first stone. Did I ever tell you the one about the newly minted Novell admin who decided to have some fun one afternoon unloading and loading NLM's? The suggested configuration for our first 6500 (a 6513 with dual Sup2/MSFC2/PFC2) was to run in HSRP between the two MSFCs. (For those who don't know, an MSFC - Multiservice Switch Feature Card or something like that, is a routing module on the switch supervisor). We are running IP, IPX and AppleTalk. What they didn't tell us was we had to keep the configurations sync'ed between the two MSFCs otherwise there would be problems. Config Sync doesn't support AppleTalk. Guess what... we had problems. We're now running SRM. CL: serves you right for running AppleTalk. I guess I should get to the point here. My experience says forklift upgrades are bad. Way too much room for things to go bad. Considering the problems introducing a single new core box, I'd take it slow. make sure everything runs as planned while you upgrade. Make sure Spamming-Tree (did I say that??) is working properly, VTP is communicating and the hardware has burned in. That brings up another thing: after the first few weeks, one of the lights on the switch fabric module stopped showing green (looked burned out). While tempted to say it's just a light, you have no idea what the root problem causing the light not to function is. We had the vendor replace the card. CL: advice certainly worth considering It seems our vendor keeps shooting itself in the foot. Their engineers keep doing things that prevents them from earning any respect from us. On a positive note, I know one engineer with that company who I do respect. Too bad they keep him in design. :-) CL: seriously, having spent wonderful quality ( but far too little ) time with the likes of Marty Adkins and Val Pavlichenko, not to mention a young guy at work I'm beginning to think is in this class, I suspect that there are very few top level network engineers in the world, and a lot of wannabe's. CL: Not everyone can be a brain surgeon. Most of us are just GP's. Of the CCIE's I have met, many are in this latter category as well. Let alone us CCNP / CCDP types. ;- We all just do the best we can, and live in fear that something we touch is going to break and we won't know how to fix it. Ken Chuck's Long Road 10/07/02 09:45PM interesting. The following may or may not be feasible, depending upon space in closets, and cost of implementation. It is something my employer is supposed to be doing for the various branch offices of a major customer we have during a major network forklift upgrade. It has tended not to happen this way for a lot of reasons, political and practical. 1) Place all new switches into the various closets. Connect them up 2) set up a gateway ( single link ) between the new core switch(s) and the old core switch(s) 3) test connectivity by taking a laptop with as many user applications as practical, and go from closet to closet testing connectivity to the various servers, services, etc. 4) assuming point three results in connectivity everywhere, do a closet by closet migration of users from the old switches to the new switches. 5) migrate all devices ( servers, internet, etc ) onto the new core switches. 6) assuming all remains well, unplug the old stuff and if Cisco is not offering you a generous trade in, sell it on one of the auction sites. Like I said, sometimes time, space, and cost does not permit this. Chuck -- www.chuckslongroad.info like my web site? take the survey! Azhar Teza wrote in message [snip] Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=55162t=55064 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Migration Plan (6509) [7:55064]
Sounds like you might want to check this seminar out. I guess you can contact your local Cisco Sales team to gain access info to the seminar. - Paul http://www.ciscopep.com/reglogin.lasso?event_id=PE9606457 --- Register now for the Cisco Catalyst 5000 Migration Program E-seminar at: ciscopep.com/reglogin.lasso?event_id=PE9606457 Now is the time to migrate your customers from the Catalyst 5000 to a Catalyst 4000/4500 or 6500. To assist you with this migration process Cisco has created a comprehensive program to provide you with the tools needed to identify, prepare, and migrate your customer base. Learn how you can successfully migrate your customers by attending the Catalyst 5000 E-Seminar. At this live E-seminar you will: Understand the details of the Catalyst 5000 migration program Hear about sales tools to prepare you to migrate your customers Learn how you can resolve your customers business issues by migrating their infrastructure Pose questions about the program directly to the Cisco Catalyst Switching product teams Broadcast Details: Date: Thursday, October 10 Time:10:00 a.m. Pacific Time Registration URL: ciscopep.com/reglogin.lasso?event_id=PE9606457 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=55097t=55064 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Migration Plan (6509) [7:55064]
Our parent company had the idea of letting a TelCo do the same for us. The TelCo was/is contracted to set up a gateway between the old network and the new network. Lucky for us we're smarter than they are (at least we think we are...) and are having things our way. :-) It's difficult to try keeping a hands-off approach to letting a vendor install a major piece of equipment in the core of MY network. Maybe you know how it is... watching an engineer (CCNP with some experience) who is supposed to know what he's doing but brings down the network instead. Add a CCIE with a few years experience to the mix, three more tries with two of them resulting in network outages. The suggested configuration for our first 6500 (a 6513 with dual Sup2/MSFC2/PFC2) was to run in HSRP between the two MSFCs. (For those who don't know, an MSFC - Multiservice Switch Feature Card or something like that, is a routing module on the switch supervisor). We are running IP, IPX and AppleTalk. What they didn't tell us was we had to keep the configurations sync'ed between the two MSFCs otherwise there would be problems. Config Sync doesn't support AppleTalk. Guess what... we had problems. We're now running SRM. I guess I should get to the point here. My experience says forklift upgrades are bad. Way too much room for things to go bad. Considering the problems introducing a single new core box, I'd take it slow. make sure everything runs as planned while you upgrade. Make sure Spamming-Tree (did I say that??) is working properly, VTP is communicating and the hardware has burned in. That brings up another thing: after the first few weeks, one of the lights on the switch fabric module stopped showing green (looked burned out). While tempted to say it's just a light, you have no idea what the root problem causing the light not to function is. We had the vendor replace the card. It seems our vendor keeps shooting itself in the foot. Their engineers keep doing things that prevents them from earning any respect from us. On a positive note, I know one engineer with that company who I do respect. Too bad they keep him in design. :-) Ken Chuck's Long Road 10/07/02 09:45PM interesting. The following may or may not be feasible, depending upon space in closets, and cost of implementation. It is something my employer is supposed to be doing for the various branch offices of a major customer we have during a major network forklift upgrade. It has tended not to happen this way for a lot of reasons, political and practical. 1) Place all new switches into the various closets. Connect them up 2) set up a gateway ( single link ) between the new core switch(s) and the old core switch(s) 3) test connectivity by taking a laptop with as many user applications as practical, and go from closet to closet testing connectivity to the various servers, services, etc. 4) assuming point three results in connectivity everywhere, do a closet by closet migration of users from the old switches to the new switches. 5) migrate all devices ( servers, internet, etc ) onto the new core switches. 6) assuming all remains well, unplug the old stuff and if Cisco is not offering you a generous trade in, sell it on one of the auction sites. Like I said, sometimes time, space, and cost does not permit this. Chuck -- www.chuckslongroad.info like my web site? take the survey! Azhar Teza wrote in message [snip] Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=55150t=55064 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Migration Plan (6509) [7:55064]
What is the best way to perform Migration? I have a customer who has currently running CAT5000 as a backbone switch and tons of 3COM switches at access layer. We would be installing (2) 6509 switches with 3524 switches will be used at access layers and server farms. It is a campus environments and they have tons of IDFs. We will have about 15 VLANS will be load balancing between (2) 6509 switches along with HSRP for Layer 3 redundancy. During the First phase, I want to configure (2) 6509 along with the Serverfarm switches. The way I would migrate is that I will connect their Existing backbone Cat 5000 with (2) 6509 switches, and will also force to Cat5000 to become non-root switch. By doing that I could slowly move users from their current network to the new switches and both the newtworks will have an access to the servers which will be on its own subnet in (5) 3524 gigastack switches. The only problem I see it here is these 15 VLANS. I guess I will also have to configure their existing subnets and VLANS to the 6509 switches only temporarily basis because those VLANS and Subnets coming from 3com switches to new 6509 via Cat5000, and in order to reply back, 6509 will have to know the routes and vlans. Is it right approach or someone have a better suggestion? Regards, Teza Changed your e-mail? Keep your contacts! Use this free e-mail change of address service from Return Path. Register now! Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=55064t=55064 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Migration Plan (6509) [7:55064]
interesting. The following may or may not be feasible, depending upon space in closets, and cost of implementation. It is something my employer is supposed to be doing for the various branch offices of a major customer we have during a major network forklift upgrade. It has tended not to happen this way for a lot of reasons, political and practical. 1) Place all new switches into the various closets. Connect them up 2) set up a gateway ( single link ) between the new core switch(s) and the old core switch(s) 3) test connectivity by taking a laptop with as many user applications as practical, and go from closet to closet testing connectivity to the various servers, services, etc. 4) assuming point three results in connectivity everywhere, do a closet by closet migration of users from the old switches to the new switches. 5) migrate all devices ( servers, internet, etc ) onto the new core switches. 6) assuming all remains well, unplug the old stuff and if Cisco is not offering you a generous trade in, sell it on one of the auction sites. Like I said, sometimes time, space, and cost does not permit this. Chuck -- www.chuckslongroad.info like my web site? take the survey! Azhar Teza wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... What is the best way to perform Migration? I have a customer who has currently running CAT5000 as a backbone switch and tons of 3COM switches at access layer. We would be installing (2) 6509 switches with 3524 switches will be used at access layers and server farms. It is a campus environments and they have tons of IDFs. We will have about 15 VLANS will be load balancing between (2) 6509 switches along with HSRP for Layer 3 redundancy. During the First phase, I want to configure (2) 6509 along with the Serverfarm switches. The way I would migrate is that I will connect their Existing backbone Cat 5000 with (2) 6509 switches, and will also force to Cat5000 to become non-root switch. By doing that I could slowly move users from their current network to the new switches and both the newtworks will have an access to the servers which will be on its own subnet in (5) 3524 gigastack switches. The only problem I see it here is these 15 VLANS. I guess I will also have to configure their existing subnets and VLANS to the 6509 switches only temporarily basis because those VLANS and Subnets coming from 3com switches to new 6509 via Cat5000, and in order to reply back, 6509 will have to know the routes and vlans. Is it right approach or someone have a better suggestion? Regards, Teza Changed your e-mail? Keep your contacts! Use this free e-mail change of address service from Return Path. Register now! Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=55077t=55064 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
