On 4/20/09, Clinton Work <clin...@scripty.com> wrote: > > Sound like a bug similiar to CSCee62455. From experience with the bug, > once all the VTY lines are locked up, the console port would not respond > either. The only way to clear the VTY lines was with SNMP, but it would > cause crashes from time to time. "service tcp-keepaliaves in/out" > didn't help either.
Another one of my "could someone please explain why" things is how come "service tcp-keepalives in/out" is considered a "best practice" and having a much more restrictive ACL on vty 4 isn't? We've got something like this on all routers: access-list 100 permit ip 10.1.1.0 0.0.0.255 any access-list 104 permit ip host 10.1.1.10 any line vty 0 3 access-class 100 in line vty 4 access-class 104 in Which means every single router fails when you put the config through RAT :( Lee > > Clinton. > > Dale Shaw wrote: >> Hmm, I guess it might come in useful if you're accessing the vty line >> via a firewall with particularly aggressive idle TCP session timers? >> >> Having said that though, it's not like "service tcp-keepalives >> (in|out)" can be tuned. The DocCD is quiet on how often the keepalives >> are sent, too. >> >> > > _______________________________________________ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/