You're not the only one I reckon. I'd expect any engineer that's had
anything to do with live networks has had this (router lockout) or
something similar which has caused them to utter OMFG or similar at
some point or another and lose a couple years off their life
expectancy due to the experience.
On Sun, Aug 16, 2009 at 2:38 AM, ALL From_NJ<all.from.nj_at_gmail.com> wrote:
> Hey team,
>
> Good stuff ... I love the EEM discussions, and I need to use this more.
> Another thought and one that I used to use when configuring remote devices
> is the command:
>
> reload in 30
>
> This tells the router to reload in 30 minutes, of course you can change the
> number to be something besides 30 minutes ...
>
> A note when using this command. Put this command in a check list for your
> config and verification steps. It is easy to forget to do this command ...
>
> I learned this the hard way one night when working on a remote router. I
> locked myself out of it during the change window at night ... when the first
> employee came in that next morning, I had to get them to pull the plug and
> put it back in. That sucked ...
>
> If you are using the reload in xyz command, AND ... if you totally screw up,
> the configs are not saved yet, and you can simply log back in after the
> reload is complete.
>
> Also, never add the wr mem or copy run start in your config scripts ... ;-)
> ... I hope I am not the only one with some humorous battle scars / stories
> ... lol.
>
> Just a thought ... hope this helps.
>
> Andrew Lee Lissitz
>
>
>
>
> On Sat, Aug 15, 2009 at 9:11 AM, Ryan West <rwest_at_zyedge.com> wrote:
>
>> Persio,
>>
>> I would change the remote side first in one terminal window on the port
>> channel and let it get pushed to the members, while making the same change
>> to the local end a second or two later. The document you provided _I think_
>> is referring to making changes to a particular member after bringing up the
>> port channel. As you've already found out, you do run a risk of ports going
>> into err-disable / shutdown or losing the entire port-channel. To prevent
>> the channel from going down and staying down, you might consider using an
>> EEM script to watch for syslog port-channel / port down messages and trigger
>> your allowed-list on the ports and doing a shut / no shut on them. The EEM,
>> combined with a 'rel in 5' should keep you out of any real danger in
>> accessing the switch again.
>>
>> I would lab up the EEM though and see if it can keep you out of trouble.
>>
>> event manager applet port-channel
>> event syslog occurs 1 pattern "%EC-5-CANNOT_BUNDLE2"
>> action 1.0 cli command "enable"
>> action 2.0 cli command "configure terminal"
>> action 3.0 cli command "in range f0/19-20 , po1"
>> action 4.0 cli command "swi t a v 3-8,11"
>> action 5.0 cli command "shut"
>> action 6.0 cli command "no shut"
>> action 7.0 syslog msg "port-channel reconfigured"
>>
>> If you want more thorough examples of EEM, check out Ivan's blog:
>> http://blog.ioshints.info or http://wiki.nil.com/Category:EEM
>>
>> You'll want to test this, of course, to make sure nothing blows up. In my
>> own internal testing and real world experience, I have the most luck making
>> the change at the port-channel. Making range changes and using TACACS+
>> authorization can cause some sequencing errors get your EC killed before all
>> the commands take.
>>
>> -ryan
>>
>> -----Original Message-----
>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
>> Persio Pucci
>> Sent: Saturday, August 15, 2009 12:10 AM
>> To: Cisco certification
>> Subject: OT: Changing Etherchannel configurations the safe way
>>
>> Hi guys,
>>
>> need your thoughts on this:
>>
>> I am going to change the "allowed vlan" list on several PortChannel
>> interfaces. Would like to hear your thought on the best/safest way of doing
>> that.
>>
>> One problem is that some of the switches are only reachable via the
>> portchannel (and therefore via the member interfaces), so if anything goes
>> wrong (for instance, a configuration mismatch on each end) the portchannel
>> will go down.
>>
>> I read on one Cisco pdf
>> (link<
>> http://www.cisco.com/en/US/docs/switches/blades/3120/software/release/12.2_40_ex/configuration/guide/swethchl.pdf
>> >,
>> page 11) that the allowed vlan list should actually be changed on the
>> member
>> interfaces also (changing on the Po only will not do it).
>>
>> One of my thoughts were to do the changes on the startup config and then
>> merge it to the running config, so they are all applied at once at the
>> remote side. Will try my best to do it in synchrony to the local side, but
>> if timming is not good enough, at least I still have connection to the side
>> that also needs to be configured.
>>
>> We've tried pushing the configs using SNMP and it worked on some cases, but
>> in another case it did not go so well and impacted a whole site.
>>
>> Tks.
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Andrew Lee Lissitz
> all.from.nj_at_gmail.com
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
Received on Sun Aug 16 2009 - 09:19:55 ART
This archive was generated by hypermail 2.2.0 : Tue Sep 01 2009 - 05:43:56 ART