Comments for CCIE Lab

Comment on Anti-lockout best practice by bogd

bogd — Mon, 12 Mar 2012 12:15:51 +0000

The “reload in” command should be a last resort – in 99% of the cases, you will not lock yourself out, so you can issue a “reload cancel”.

I agree that it’s a completely different story when dealing with production routers serving “zounds of users”, but then again… you _really_ shouldn’t be making potentially disruptive changes (or any kind of changes!) on such routers outside of a maintenance window.

And to answer the Juniper part – I really do love the “commit” feature, but… if you commit a non-working config, you’re just as scre^H^H^H^H much in trouble .

Comment on IOS + Linux = Quagga by AlexJ » Blog Archive » [CCIELab]

AlexJ » Blog Archive » [CCIELab] — Thu, 05 Jan 2012 14:10:04 +0000

[...] [Originally posted on ccielab.ro] [...]

Comment on ACL case study: The hidden defaults of ACLs by AlexJ » Blog Archive » [CCIELab]

AlexJ » Blog Archive » [CCIELab] — Wed, 14 Dec 2011 17:44:12 +0000

[...] [Originally posted on ccielab.ro] [...]

Comment on Telnet handler in Firefox-(K)Ubuntu by Sumit

Sumit — Tue, 25 Oct 2011 14:44:00 +0000

Brillaint!
Easy and concise.

Comment on Anti-lockout best practice by Mircea

Mircea — Fri, 07 Oct 2011 09:06:08 +0000

Yes, it’s a good idea the reload in command, but imho when you are dealing with production routers it is better to lock yourself out than having zounds of users complaining they were disconnected from their applications.
In my opinion there are like 3 viable solutions:
1. be careful!
2. use a EEM applet that would issue a “no ip access-list” or reset the acl config to a template-based one, say after 10 minutes, if no “wr mem” is issued.
3. use Juniper ( ), that has the “commit” command

PS: anyway, I’m just being picky, I actually used “reload in” many times..but never on backbone equipments

Comment on RIP lab: Send RIP routes to remote neighbours by AlexJ » Blog Archive

AlexJ » Blog Archive — Tue, 19 Jul 2011 00:06:27 +0000

[...] [Originally posted on ccielab.ro] [...]

Comment on DHCP Relay Server and NAT Case Study by 3rett

3rett — Mon, 11 Oct 2010 17:49:18 +0000

Thanks alot buddy. This is exactly what I was looking for. I’m assuming one way to effectively forward DHCP relay through NAT/PAT would be a VPN. So that’s what I’ll look into next……….

Comment on Frame Relay Switching by AlexJ » Blog Archive » [CCIELab] Frame Relay Switching

AlexJ » Blog Archive » [CCIELab] Frame Relay Switching — Mon, 16 Aug 2010 11:42:00 +0000

[...] [Originally posted on ccielab.ro] [...]

Comment on Back-to-back Frame Relay by AlexJ » Blog Archive » [CCIELab] Back-to-back Frame Relay

AlexJ » Blog Archive » [CCIELab] Back-to-back Frame Relay — Mon, 16 Aug 2010 11:36:29 +0000

[...] [Originally posted on ccielab.ro] [...]

Comment on Output manipulation in Cisco IOS by mike

mike — Mon, 02 Aug 2010 13:00:45 +0000

Salut,

Ai fi interesat sa participi la documentarea unui site cu specific –> certificari Cisco
…daca da ….reply pe adresa mea…daca nu…. asta e