[c-nsp] VTY Lines

[Stanly Johns]

Hi there,

even after clearing the vty lines they were still there. I was unable to
telnet to the router.

I had to restart the router to clear all the lines.

any clue what could be the reason ?

thanks.

Perimeter#sh users
Line User Host(s) Idle Location
* 0 con 0 idle 00:00:00
322 vty 0 idle 5w1d 190.42.12.218
323 vty 1 idle 5w0d
client-201.230.86.15.speedy.net.pe
324 vty 2 idle 3w5d 151.56.21.165
325 vty 3 idle 2w4d
client-190.40.212.198.speedy.net.pe
326 vty 4 idle 1w5d 84.36.28.19

Interface User Mode Idle Peer Address

Perimeter#
Perimeter#clear line vty 2
[confirm]
[OK]
Perimeter#
Perimeter#sh users
Line User Host(s) Idle Location
* 0 con 0 idle 00:00:00
322 vty 0 idle 5w1d 190.42.12.218
323 vty 1 idle 5w0d
client-201.230.86.15.speedy.net.pe
324 vty 2 idle 3w5d 151.56.21.165
325 vty 3 idle 2w4d
client-190.40.212.198.speedy.net.pe
326 vty 4 idle 1w5d 84.36.28.19

Interface User Mode Idle Peer Address

line con 0
stopbits 1
line aux 0
stopbits 1
line vty 0 4
password 7

login
!
scheduler allocate 20000 1000
!
end

Perimeter#
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Wouter Prins]

Hi Stanly,

You have to use 'disconnect x' to clear a vty terminal, 'clear x' is for
async lines.

Post by Stanly Johns
Hi there,
even after clearing the vty lines they were still there. I was unable to
telnet to the router.
I had to restart the router to clear all the lines.
any clue what could be the reason ?
thanks.
Perimeter#sh users
Line User Host(s) Idle Location
* 0 con 0 idle 00:00:00
322 vty 0 idle 5w1d 190.42.12.218
323 vty 1 idle 5w0d
client-201.230.86.15.speedy.net.pe
324 vty 2 idle 3w5d 151.56.21.165
325 vty 3 idle 2w4d
client-190.40.212.198.speedy.net.pe
326 vty 4 idle 1w5d 84.36.28.19
Interface User Mode Idle Peer Address
Perimeter#
Perimeter#clear line vty 2
[confirm]
[OK]
Perimeter#
Perimeter#sh users
Line User Host(s) Idle Location
* 0 con 0 idle 00:00:00
322 vty 0 idle 5w1d 190.42.12.218
323 vty 1 idle 5w0d
client-201.230.86.15.speedy.net.pe
324 vty 2 idle 3w5d 151.56.21.165
325 vty 3 idle 2w4d
client-190.40.212.198.speedy.net.pe
326 vty 4 idle 1w5d 84.36.28.19
Interface User Mode Idle Peer Address
line con 0
stopbits 1
line aux 0
stopbits 1
line vty 0 4
password 7
login
!
scheduler allocate 20000 1000
!
end
Perimeter#
_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Jim Devane]

Well, restarting the router will do it, when that is not as feasible you can try:

Sh tcp br to get the TCB address, then clear that out with cle ip tcp tcb XXXXX

Router# sh tcp br
TCB Local Address Foreign Address (state)
5AEE7990 2.2.2.2.179 2.2.2.3.17492 ESTAB
58F2E668 2.2.2.2.22 lifebook.11004 ESTAB

Router# cle ip tcp tcb 58F2E668

Take care to enter the right address, otherwise you may get some BGP messages for good measure. = )

HTH,
Jim



-----Original Message-----
From: cisco-nsp-***@puck.nether.net [mailto:cisco-nsp-***@puck.nether.net] On Behalf Of Stanly Johns
Sent: Wednesday, April 15, 2009 3:07 AM
To: cisco-***@puck.nether.net
Subject: [c-nsp] VTY Lines

Hi there,

even after clearing the vty lines they were still there. I was unable to telnet to the router.

I had to restart the router to clear all the lines.

any clue what could be the reason ?

thanks.

Perimeter#sh users
Line User Host(s) Idle Location
* 0 con 0 idle 00:00:00
322 vty 0 idle 5w1d 190.42.12.218
323 vty 1 idle 5w0d
client-201.230.86.15.speedy.net.pe
324 vty 2 idle 3w5d 151.56.21.165
325 vty 3 idle 2w4d
client-190.40.212.198.speedy.net.pe
326 vty 4 idle 1w5d 84.36.28.19

Interface User Mode Idle Peer Address

Perimeter#
Perimeter#clear line vty 2
[confirm]
[OK]
Perimeter#
Perimeter#sh users
Line User Host(s) Idle Location
* 0 con 0 idle 00:00:00
322 vty 0 idle 5w1d 190.42.12.218
323 vty 1 idle 5w0d
client-201.230.86.15.speedy.net.pe
324 vty 2 idle 3w5d 151.56.21.165
325 vty 3 idle 2w4d
client-190.40.212.198.speedy.net.pe
326 vty 4 idle 1w5d 84.36.28.19

Interface User Mode Idle Peer Address

line con 0
stopbits 1
line aux 0
stopbits 1
line vty 0 4
password 7

login
!
scheduler allocate 20000 1000
!
end

Perimeter#
_______________________________________________
cisco-nsp mailing list cisco-***@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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Yevgeniy Voloshin]

Hi,

I have the same problem on ME-C3750-24TE with Cisco IOS Software ->
C3750ME Software (C3750ME-I5-M), Version 12.2(44)SE, RELEASE SOFTWARE (fc1)

In 'sh tcp brief | i \.2[23]' output nothing about telnet ports. But all
vty lines busy:
Line User Host(s) Idle Location
* 0 con 0 idle 00:00:00
1 vty 0 idle 1y11w xxx.xxx.xxx.xxx
2 vty 1 idle 1y11w xxx.xxx.xxx.xxx
3 vty 2 idle 1y11w xxx.xxx.xxx.xxx
4 vty 3 idle 1y11w xxx.xxx.xxx.xxx
5 vty 4 idle 1y11w xxx.xxx.xxx.xxx
6 vty 5 idle 1y11w xxx.xxx.xxx.xxx
7 vty 6 idle 1y11w xxx.xxx.xxx.xxx
8 vty 7 idle 41w5d xxx.xxx.xxx.xxx
9 vty 8 idle 34w5d xxx.xxx.xxx.xxx
10 vty 9 idle 34w5d xxx.xxx.xxx.xxx
11 vty 10 idle 31w0d xxx.xxx.xxx.xxx
12 vty 11 idle 17w2d xxx.xxx.xxx.xxx
13 vty 12 idle 16w6d xxx.xxx.xxx.xxx
14 vty 13 idle 16w6d xxx.xxx.xxx.xxx
15 vty 14 idle 2w2d xxx.xxx.xxx.xxx
16 vty 15 idle 2w2d xxx.xxx.xxx.xxx


So right now I am waiting MW to reload box with IOS upgrade.


---
Yev.
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Dracul]

If you are running a critical network without the convenience of rebooting,
Jim's Router# cle ip tcp tcb 58F2E668 worked for me

but take note some IOS use the Router#clear tcp tcb (without the 'ip')

regards,
chris

Hi,
I have the same problem on ME-C3750-24TE with Cisco IOS Software -> C3750ME
Software (C3750ME-I5-M), Version 12.2(44)SE, RELEASE SOFTWARE (fc1)
In 'sh tcp brief | i \.2[23]' output nothing about telnet ports. But all
Line User Host(s) Idle Location
* 0 con 0 idle 00:00:00 1 vty 0
idle 1y11w xxx.xxx.xxx.xxx
2 vty 1 idle 1y11w xxx.xxx.xxx.xxx
3 vty 2 idle 1y11w xxx.xxx.xxx.xxx
4 vty 3 idle 1y11w xxx.xxx.xxx.xxx
5 vty 4 idle 1y11w xxx.xxx.xxx.xxx
6 vty 5 idle 1y11w xxx.xxx.xxx.xxx
7 vty 6 idle 1y11w xxx.xxx.xxx.xxx
8 vty 7 idle 41w5d xxx.xxx.xxx.xxx
9 vty 8 idle 34w5d xxx.xxx.xxx.xxx
10 vty 9 idle 34w5d xxx.xxx.xxx.xxx
11 vty 10 idle 31w0d xxx.xxx.xxx.xxx
12 vty 11 idle 17w2d xxx.xxx.xxx.xxx
13 vty 12 idle 16w6d xxx.xxx.xxx.xxx
14 vty 13 idle 16w6d xxx.xxx.xxx.xxx
15 vty 14 idle 2w2d xxx.xxx.xxx.xxx
16 vty 15 idle 2w2d xxx.xxx.xxx.xxx
So right now I am waiting MW to reload box with IOS upgrade.
---
Yev.
_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Eric Van Tol]

Post by Jim Devane
-----Original Message-----
Sent: Thursday, April 16, 2009 12:19 AM
Subject: Re: [c-nsp] VTY Lines
If you are running a critical network without the convenience of rebooting,
Jim's Router# cle ip tcp tcb 58F2E668 worked for me
but take note some IOS use the Router#clear tcp tcb (without the 'ip')
regards,
chris

If you can't gain access to the CLI, it is possible to reset vty TCP sessions using SNMP, assuming you have a read-write string configured on the device. I personally don't know the procedure, but there are tools out there such as the Solarwinds Engineers Edition toolset that let you do this. If anyone knows the right procedure, maybe they can post it here.

-evt
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Lee]

Post by Eric Van Tol

Post by Jim Devane
-----Original Message-----
Sent: Thursday, April 16, 2009 12:19 AM
Subject: Re: [c-nsp] VTY Lines
If you are running a critical network without the convenience of rebooting,
Jim's Router# cle ip tcp tcb 58F2E668 worked for me
but take note some IOS use the Router#clear tcp tcb (without the 'ip')
regards,
chris

If you can't gain access to the CLI, it is possible to reset vty TCP
sessions using SNMP, assuming you have a read-write string configured on the
device. I personally don't know the procedure, but there are tools out
there such as the Solarwinds Engineers Edition toolset that let you do this.
If anyone knows the right procedure, maybe they can post it here.

How to Detect and Clear Hung TCP Connections using SNMP

http://www.cisco.com/en/US/tech/tk648/tk362/technologies_problem_troubleshooting09186a00802b93ef.shtml
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[John Jensen]

I was under the impression that the "service tcp-keepalives-in" and
"service tcp-keepalives-out" commands will prevent this from happening
to your VTYs.

-JJ

Post by Lee

Post by Eric Van Tol

Post by Jim Devane
-----Original Message-----
Sent: Thursday, April 16, 2009 12:19 AM
Subject: Re: [c-nsp] VTY Lines
If you are running a critical network without the convenience of rebooting,
Jim's Router# cle ip tcp tcb 58F2E668 worked for me
but take note some IOS use the Router#clear tcp tcb  (without the 'ip')
regards,
chris

If you can't gain access to the CLI, it is possible to reset vty TCP
sessions using SNMP, assuming you have a read-write string configured on the
device.  I personally don't know the procedure, but there are tools out
there such as the Solarwinds Engineers Edition toolset that let you do this.
 If anyone knows the right procedure, maybe they can post it here.

How to Detect and Clear Hung TCP Connections using SNMP
http://www.cisco.com/en/US/tech/tk648/tk362/technologies_problem_troubleshooting09186a00802b93ef.shtml
_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Lee]

Post by John Jensen
I was under the impression that the "service tcp-keepalives-in" and
"service tcp-keepalives-out" commands will prevent this from happening
to your VTYs.

No necessarily. Tcp keepalives will only kill a connection if the
other side doesn't answer. But what happens when your Ciscoworks
machine has a bad script that never exits? Every <however many>
minutes it ssh's in and leaves the connection open. Router sends a
keepalive, CW answers, VTY stays open. After a while all the VTYs are
in use..

What I'd like to know is what extra protection "service
tcp-keepalives-in" gives you that the exec-timeout on the VTYs
doesn't.

Lee

Post by John Jensen
-JJ

Post by Lee

Post by Eric Van Tol

Post by Jim Devane
-----Original Message-----
Sent: Thursday, April 16, 2009 12:19 AM
Subject: Re: [c-nsp] VTY Lines
If you are running a critical network without the convenience of rebooting,
Jim's Router# cle ip tcp tcb 58F2E668 worked for me
but take note some IOS use the Router#clear tcp tcb (without the 'ip')
regards,
chris

If you can't gain access to the CLI, it is possible to reset vty TCP
sessions using SNMP, assuming you have a read-write string configured on the
device. I personally don't know the procedure, but there are tools out
there such as the Solarwinds Engineers Edition toolset that let you do this.
If anyone knows the right procedure, maybe they can post it here.

How to Detect and Clear Hung TCP Connections using SNMP
http://www.cisco.com/en/US/tech/tk648/tk362/technologies_problem_troubleshooting09186a00802b93ef.shtml
_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Dale Shaw]

Hi Lee,

Post by Lee
What I'd like to know is what extra protection "service
tcp-keepalives-in" gives you that the exec-timeout on the VTYs
doesn't.

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.

Old thread: http://puck.nether.net/pipermail/cisco-nsp/2004-July/011508.html
<--- is that you? :-)

cheers,
Dale
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Peter Rathlev]

Post by Dale Shaw
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.

By default TCP keep-alives should be in at least 2 hour intervals as per
RFC 1122 4.2.3.6; I think most implementations follow this.

But same RFC says that the interval MUST be configurable. :-)

Regards,
Peter


_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Clinton Work]

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.

Clinton.

Post by Dale Shaw
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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Lee]

Post by Clinton Work
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

Post by Clinton Work
Clinton.

Post by Dale Shaw
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.

_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Justin Shore]

Post by Lee
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 :(

I went round and round with a security guy who audited our gear once
over that. He made a huge stink over how we didn't have have passwords
on our VTYs, con and aux ports. He took everything RAT had to say as
gospel, as if there was no other (or better) way to address a security
issue. We use AAA on all interfaces including con0. I have TACACS+ set
up with local auth as the backup (and only one user account on the
devices which I've gone to great lengths to protect). Aux is explicitly
disabled. He just didn't get it. Sure I could add the password command
to the VTY to appease him even though it wouldn't do a damn thing with
AAA enabled. I didn't though and I used the password stink as part of
my justification that RAT really only points out common and basic
security problems and doesn't take into account any of the numerous ways
of mitigating those problems with more advanced methods. In the end the
audit was dropped. The actual problems in the audit were addressed.
Any RAT fluff was ignored. There were several other things like that
but the line passwords were the most obvious to even a non-technical person.

While my installs may not be perfect, they are far better than average.
I don't need someone second-guessing my work with a tool like RAT.

Justin

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Jens Link]

Post by Justin Shore
While my installs may not be perfect, they are far better than
average. I don't need someone second-guessing my work with a tool like
RAT.

Agreed. But (IIRC) you can write your own rules for RAT. Combine this
with rancid and you have a great way of finding thing you may have
forgotten to configure.

cheers,

Jens

[Lee]

Post by Jens Link

Post by Justin Shore
While my installs may not be perfect, they are far better than
average. I don't need someone second-guessing my work with a tool like
RAT.

Agreed. But (IIRC) you can write your own rules for RAT. Combine this
with rancid and you have a great way of finding thing you may have
forgotten to configure.

Yes, but an auditor isn't going to allow your own rules for RAT so
you're still stuck with justifying every 'failure' RAT comes up with.

I tried sending them feedback a few years ago & got a very nice
rejection reply. Maybe including patches with my feedback will work
better this time..

Lee
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Andrew Yourtchenko]

on all interfaces including con0. I have TACACS+ set up with local auth as
the backup (and only one user account on the devices which I've gone to
great lengths to protect). Aux is explicitly disabled. He just didn't get
it. Sure I could add the password command to the VTY to appease him even

I'd venture to think it was more about trying to prevent the potential
corner cases. Of course there is a lot of preconditions for that "line
of the defense" to be hit - but it all depends. After all, most of us
have an insurance for the case of the proverbial "being hit by a bus"
- even though those are the events we all carefully try to avoid.
(Or so I would hope:-)

Back to the original post - without the version hard to tell, but I've
seen CSCsc70644 causing similar symptoms.

If that does not match, I'd say open up a case so the TAC folks take a
closer look.

cheers,
andrew
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Lee]

Hi Dale,

Post by Dale Shaw
Hi Lee,

Post by Lee
What I'd like to know is what extra protection "service
tcp-keepalives-in" gives you that the exec-timeout on the VTYs
doesn't.

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?

It probably would.. I went at it from the other direction tho; set
the keepalive time on my ssh client to 10 minutes.

Post by Dale Shaw
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.

I don't remember seeing anything on how often keepalives are sent
either - just that sessions were killed after 5 minutes with no
answer.

Post by Dale Shaw
http://puck.nether.net/pipermail/cisco-nsp/2004-July/011508.html
<--- is that you? :-)

Yup, that's me :) Discretion being the better part of valor, etc.,
etc., I use a non-work email address now.

Regards,
Lee
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Engelhard Labiro]

Is this bug or just config under vty that disabled session timeout?
Do you have entry "exec timeout 0 0" at line vty?

On 2009/04/16, at 12:53, Yevgeniy Voloshin

Post by Yevgeniy Voloshin
Hi,
I have the same problem on ME-C3750-24TE with Cisco IOS Software ->
C3750ME Software (C3750ME-I5-M), Version 12.2(44)SE, RELEASE
SOFTWARE (fc1)
In 'sh tcp brief | i \.2[23]' output nothing about telnet ports. But
Line User Host(s) Idle Location
* 0 con 0 idle 00:00:00 1 vty
0 idle 1y11w xxx.xxx.xxx.xxx
2 vty 1 idle 1y11w xxx.xxx.xxx.xxx
3 vty 2 idle 1y11w xxx.xxx.xxx.xxx
4 vty 3 idle 1y11w xxx.xxx.xxx.xxx
5 vty 4 idle 1y11w xxx.xxx.xxx.xxx
6 vty 5 idle 1y11w xxx.xxx.xxx.xxx
7 vty 6 idle 1y11w xxx.xxx.xxx.xxx
8 vty 7 idle 41w5d xxx.xxx.xxx.xxx
9 vty 8 idle 34w5d xxx.xxx.xxx.xxx
10 vty 9 idle 34w5d xxx.xxx.xxx.xxx
11 vty 10 idle 31w0d xxx.xxx.xxx.xxx
12 vty 11 idle 17w2d xxx.xxx.xxx.xxx
13 vty 12 idle 16w6d xxx.xxx.xxx.xxx
14 vty 13 idle 16w6d xxx.xxx.xxx.xxx
15 vty 14 idle 2w2d xxx.xxx.xxx.xxx
16 vty 15 idle 2w2d xxx.xxx.xxx.xxx
So right now I am waiting MW to reload box with IOS upgrade.
---
Yev.
_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/