Networking Tips

domingo, 14 de abril de 2013

[Chiste]. En caso de emergencia romper el vidrio. ¡Cable de consola adentro!

viernes, 22 de febrero de 2013

Publicar prefijos IPv4 sobre una sesión eBGP IPv6

Situación:
Deseo publicar redes/prefijos IPv4 sobre una sesión eBGP en IPv6

Historia:
A pesar de no ser común este caso pueden ocurrir en algunas situaciones.

Solución:
Afortunadamente BGP soporta llevar información de enrutamiento de distintos protocolos (pe. IPv6/IPv4). Por ello es posible intercambiar información IPv4 dentro de una sesión eBGP IPv6.

Configuración:
En un escenario con R1 conectado a R2 back-to-back la configuración queda de la siguiente manera (deseo que el prefijo anunciado por R2 lo aprenda R1).

R1:
!
interface Ethernet0
ip address 22.22.22.21 255.255.255.252
ipv6 address 2001:DB8::1/64
!
router bgp 1
bgp log-neighbor-changes
neighbor 2001:DB8::2 remote-as 2
neighbor 2001:DB8::2 ebgp-multihop 3
!
address-family ipv4
neighbor 2001:DB8::2 activate
neighbor 2001:DB8::2 route-map IPv4 in
no auto-summary
no synchronization
exit-address-family

!
route-map IPv4 permit 5
set ip next-hop 22.22.22.22
!
R2:
!
interface Ethernet0
ip address 22.22.22.22 255.255.255.252
half-duplex
ipv6 address 2001:DB8::2/64
!
router bgp 2
bgp log-neighbor-changes
neighbor 2001:DB8::1 remote-as 1
neighbor 2001:DB8::1 ebgp-multihop 3
!
address-family ipv4
neighbor 2001:DB8::1 activate
no auto-summary
no synchronization
network 2.2.2.0 mask 255.255.255.0
exit-address-family
!

"El truco":
* La sesión eBGP debe ser obligatoriamente multihop, sino, R1 no aprenderá la ruta. Reconozco que no entiendo 100% porque ocurre sin embargo en base a las lecturas el router se queja que el next-hop y el IP de establecimiento son diferentes y no en la misma subred (lógico, uno es IPv6 y el otro IPv4!).
* En R1 quien aprende la ruta debe tener un route-map aplicado cuando aprende las mismas (in) forzando el next-hop con la dirección IPv4 de R2

Mas información:
- http://www.cisco.com/en/US/docs/ios-xml/ios/ipv6/configuration/15-2mt/ip6-mptcl-bgp.html#GUID-06407EF3-4FAD-4519-A2A9-6CC6037288C0
- Publicando prefijos IPv6 sobre sesiones BGP IPv4 en Cisco

Espero sea útil!

domingo, 17 de febrero de 2013

Publicando prefijos IPv6 sobre sesiones BGP IPv4 en Cisco

Situación:
Deseo publicar redes/prefijos IPv6 sobre una sesión eBGP en IPv4

Historia:
A pesar de no ser común este caso pueden ocurrir en algunas situaciones. En esta oportunidad, tengo un router Cisco con soporte IPv6 (routing) pero su configuración BGP no permite definir neighbors IPv6

Error:
Mensaje que quizás estas recibiendo y el mismo te trajo a esta página :)

*Mar 1 02:05:00.663: BGP: 1.1.1.1 Advertised Nexthop ::FFFF:1.1.1.1: Non-local or Nexthop and peer Not on same interface
*Mar 1 02:05:00.663: BGP(1): 1.1.1.1 rcv UPDATE w/ attr: nexthop ::FFFF:1.1.1.1, origin i, metric 0, originator 0.0.0.0, path 1, community , extended community
*Mar 1 02:05:00.667: BGP(1): 1.1.1.1 rcv UPDATE about 2001:db8::/32 -- DENIED due to:
*Mar 1 02:05:00.667: BGP(0): Revise route installing 1 of 1 route for 10.0.0.0/24 -> 1.1.1.1 to main IP table
*Mar 1 02:05:00.771: BGP(0): 1.1.1.1 computing updates, afi 0, neighbor version 0, table version 25, starting at 0.0.0.0

Solución:
Afortunadamente BGP soporta llevar información de enrutamiento de distintos protocolos (pe. IPv6). Por ello es posible intercambiar información IPv6 dentro de una sesión eBGP IPv4.

Configuración:
En un escenario con R1 conectado a R2 back-to-back la configuración queda de la siguiente manera (deseo que el prefijo anunciado por R1 lo aprenda R2).

R1:
!
interface Ethernet1/0
ip address 1.1.1.2 255.255.255.252
full-duplex
ipv6 address 2001:db8::1/64
ipv6 enable
!
router bgp 1
no synchronization
bgp router-id 1.1.1.1
bgp log-neighbor-changes
neighbor 1.1.1.2 remote-as 2
neighbor 1.1.1.2 ebgp-multihop 2
no auto-summary
!
address-family ipv6
neighbor 1.1.1.2 activate
network 2001:db8::/32
no synchronization
redistribute static
exit-address-family
!
ipv6 route 2001:db8::/32 Null0

R2:
!
interface Ethernet1/0
ip address 1.1.1.2 255.255.255.252
full-duplex
ipv6 address 2001:db8::2/64
ipv6 enable
!
router bgp 2
no synchronization
bgp router-id 1.1.1.2
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 ebgp-multihop 2
no auto-summary
!
address-family ipv6
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 route-map IPv6-NextHop in
exit-address-family
!
route-map IPv6-NextHop permit 10
set ipv6 next-hop 2001:db8::1
!

"El truco":
* La sesión eBGP debe ser obligatoriamente multihop, sino, R2 no aprenderá la ruta (el mismo error que se ve arriba). Reconozco que no entiendo 100% porque ocurre sin embargo en base a las lecturas el router se queja que el next-hop y el IP de establecimiento son diferentes y no en la misma subred (lógico, uno es IPv6 y el otro IPv4!).
* En R2 quien aprende la ruta debe haber un route-map aplicado cuando aprende las rutas (in) forzando el next-hop con la dirección IPv6 de R1

Después de aplicar ebgp-multihop (todo funciona):

*Mar 1 02:01:42.539: BGP(1): 1.1.1.1 rcvd UPDATE w/ attr: nexthop ::FFFF:1.1.1.1, origin i, metric 0, path 1
*Mar 1 02:01:42.539: BGP(1): 1.1.1.1 rcvd 2800:26::/32
*Mar 1 02:01:42.543: BGP(0): Revise route installing 1 of 1 route for 10.0.0.0/24 -> 1.1.1.1 to main IP table
*Mar 1 02:01:42.543: BGP(1): Revise route installing 2001:db8::/32 -> 2001:db8::1 (::) to main IPv6 table

Mas información:
- https://supportforums.cisco.com/docs/DOC-21110
- http://ieoc.com/forums/p/15154/130174.aspx
- http://ieoc.com/forums/p/15154/130174.aspx

Espero sea útil!

lunes, 21 de enero de 2013

Convertir un Access point Cisco Aironet 1242 modo Lightweigth a Access point modo Autónomo/Stand Alone

Situacion:

La mayoría de estos equipos Cisco Aironet vienen con la IOS (Internetwork Operating System) para que funcione en modo Lightweigth y por más que trates de configurarlos por cualquier vía no lo vas a poder hacer si no tienes un WLC (Wireless Lan Controller) los cuales son algo costosos.

El problema de los Access Point (AP) en modo Lighweigth es que toman la configuración del WLC (Wireless Lan Controller) que esté presente en la red, por esto estos AP se les conoce como zero touch debido a que no hace falta realizarle casi ninguna configuración. En resumen si no tenemos un WLC no podremos configurar el AP vía web ni vía consola.

Si ingresas vía consola (Hiperterminal u otro) te va a pedir la contraseña de modo privilegiado la cual por defecto es “Cisco” después de eso cuando intentes pasar a modo global ejecutando el comando “configure terminal” como en el cualquier dispositivo CISCO te aparecerá el siguiente mensaje ”command not found”, yo también me preocupé en ese momento pensé que el dispositivo tenía algún tipo de problema, ejecuté cualquier cantidad de comandos existentes para pasar a modo de configuración pero nada.

Intenté conectarme vía web, por defecto el AP viene con la dirección 10.0.0.1 simplemente lo conecte mediante su puerto Ethernet a mi computadora a la cual le asigne la dirección 10.0.0.2, probé la conectividad con el comando ping entre ellos y todo estaba perfecto pero en el momento de intentaba ingresar vía web (mediante un explorador de internet e.g Internet Explorer ,Mozilla Firefox ,colocaba la dirección 10.0.0.1) no me dejaba ,simplemente es que en el modo Lightweight no tenemos acceso al AP vía web.

La solución:

La solución es cambiarle la IOS al AP para que este funcione en modo Autónomo o Stand Alone en vez de Lightweight y así poder configurar el AP normalmente ya sea vía Web o mediante consola.

Procedimiento:

Los siguientes son los pasos para revertir un AP que esta en modo LWAPP a modo Autónomo cargando un Cisco IOS utilizando un servidor TFTP.

1.- En nuestra PC cargamos un servidor TFTP en esta misma maquina configuraremos el AP.

2.- El PC se comportara como el servidor TFTP le asignaremos por ejemplo la dirección 10.0.0.2 (acordémonos que el AP por defecto tiene la 10.0.0.1)al mismo tiempo nos conectamos mediante el cable de consola al AP mediante la aplicación Hiperterminal.

3.- Después que conseguimos la nueva IOS (c1240-k9w7-tar.default) la copiamos a la carpeta donde guarda el servidor TFTP los archivos por defecto. (debemos que asegurarnos de que tenemos la nueva IOS en el PC que esta como servidor TFTP)

4.- El siguiente paso simplemente es conectar el AP a nuestro PC (servidor TFTP) mediante un cable utp.

5.- Desconecte el AP de la corriente eléctrica.

6.- Conectamos el AP a la corriente eléctrica al mismo tiempo que mantenemos presionado el botón MODE en el AP.

7.- Esto lo hacemos alrededor de 20 a 30 segundos el LED de AP se coloca de color lila, como tenemos abierta la aplicación Hiperterminal en ella nos debería aparecer el siguiente mensaje “button is pressed ,wait for button to be released…”

8.- En este momento la nueva IOS se esta copiando desde el servidor TFTP a la flash del AP, simplemente debemos esperar a que se termine de copiar.

9.- Automáticamente la nueva IOS reemplazara a la anterior.

10.- Lo único que nos queda es por fin empezar a configurar nuestro AP ya sea vía consola o vía web.

Nota: para conseguir la IOS que necesitamos solo debemos colocar en google lo siguiente “ c1240-k9w7-tar.default shared “ abrimos el primer resultado que nos arroje, y la descargamos.

Nota: para poder ingresar vía web al AP este necesita tener configurado una dirección ip, además de un usuario con nivel 15 de privilegio, lo creamos de la siguiente manera:

AP (config) username “nombre usuario” privilege 15 password “password”.

Nota: para descargar el servidor TFTP simplemente hazlo desde esta página http://www.winagents.com/en/downloads/download-tftp-server.php.

1.-Le colocamos nombre al AP

Router (config)hostname AP

2.-Configuramos un SSID al AP podemos tener varios SSID.(por ejemplo le colocamos WIRELESS)

AP (config)dot11 ssid WIRELESS

AP (config-ssid)authentication open

AP (config-ssid)infraestructura ssid

AP (config-ssid) guest mode (el AP divulgara el SSID para que los clientes lo puedan ver)

AP (config-ssid) authentication key management wpa versión 2(opcional le configuramos el protocolo WPA versión 2 para la forma en que administrara las claves)

AP (config-ssid)wpa-psk ascii “clave”(definimos la contraseña para que los clientes puedan conectarse al AP)

El AP posee 2 interfaces dot11radio0 (2.4 GHz) y dot11radio1 ( 5 GHz)

3.-Asociamos el SSID a la interface a cual queremos que los clientes se conecten.

Interface Dot11radio0

AP (config-if) ssid WIRELESS

AP (config-if) station-role root (por defecto viene así)

AP (config-if) encryption mode ciphers aes-ccm (opcional, definimos AES como el algoritmo de encriptamiento)

AP (config-if) no shutdown (levantamos la interface)

4.-Le asignamos una ip al AP estáticamente para administración (por ejemplo 192.168.1.1) o si existe un servidor DHCP simplemente dejamos que el AP reciba un IP del mismo.

(config) interface BVI 1

(config-if) ip address 192.168.1.1 255.255.255.0

(config-if) no shutdown

Procedimiento realizado por: @AlejandroFerrer

lunes, 14 de enero de 2013

Crucigrama IPv6

http://goo.gl/lVuv6

Espero les guste!....

miércoles, 2 de enero de 2013

DNS64 y NAT64 paso a paso con explicación

Introducción:
DNS64 y NAT64 son dos tecnología diferentes que comunmente trabajan en conjunto.

DNS64 y NAT64 es ideal para colocar en el borde una red donde unicamente existan host con IPv6, algo cada día es más común sobre todo en el mundo de redes celulares y se gran cantidad de sensores.

En Internet hay mucha información sobre como configurar NAT64 y DNS64, la mayoría dice que muy fácil, otros lo colocan más complicado. En lo personal no conseguí ninguna que explicara paso a paso como hacerlo y adicionalmente que explicara la topología de red donde se estaba configurando.

En este post comienzo instalando DNS64 y luego procedemos con NAT64. Se puede instalar en cualquier orden.

Que se necesita antes de comenzar:

- Una subred IPv6 libre (una /96 esta bien) para realizar el mapeo DNS entre IPv4 e IPv6. Esta misma subred la utilizaremos dentro de Tayga para el NAT64

- Logicamente conectividad IPv6 entre los clientes y el servidor DNS64 y NAT64 (no se requiere IPv4)

Topología:
a) Servidor realizando. Solo tiene una interfaz (eth1)

IPv6: 2001:db8:1:1::/64 (eth1).
IPv4: 192.168.124.107

b) IP de un cliente (eth2):

2001:db8:1:1::2/64

c) Subredes IPv6:

Red que "retorna" el DNS64 2001:db8:1:ffff::/96
Pool de NAT en el NAT64: 2001:db8:1:ffff::/96

(si, son el mismo bloque)

d) Interfaz dns64:

192.168.124.107/32
2001:db8:1::1/128

(correcto!, la IPv6 e IPv4 de eth1 se solapan con interfaz dns64)

Procedimiento de DNS64.

Paso 1:

Instalar BIND9:

#aptitude install bind9

Paso 2:

Configurar /etc/bind/named.conf.options:

a) Asegurar que BIND escuche en IPv6 (recordemos que los clientes van a estar en IPv6)

listen-on-v6 { any; };

b) Permitir consultas desde cualquier IP. Si estas utilizando un servidor público o en producción favor restringir las consultas a tus clientes

allow-query { any; };

c) Realizar el DNS64 con la siguiente directiva.

dns64 2001:db8:1:ffff::/96 {
    clients {
      any; };
};

La configuración del punto "c" lo que indica es que aquellas consultas DNS de aquellos registros que SOLO tienen tienen registro A (no tienen registro AAAA) serán entregadas a los clientes añadiendo 2001:db8::1:ffff::/96

d) Reiniciar bind9

#/etc.init.d/bind9 restart

Probar DNS64:

a) En un PC cliente colocar como servidor DNS: 2001:db8:1:1::1

b) Ubicarse en un cliente y realizar consultar DNS de hosts solo con direcciones IPv4 (registros A). Por ejemplo:

root@ubuntu-VirtualBox:~# dig ipv4.google.com aaaa @2001:db8:1:1::1

; <<>> DiG 9.8.0-P4 <<>> ipv4.google.com aaaa @2001:db8:1:1::1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- 64252="64252" br="br" id:="id:" noerror="noerror" opcode:="opcode:" query="query" status:="status:">;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;ipv4.google.com.               IN      AAAA

;; ANSWER SECTION:
ipv4.google.com.        0       IN      CNAME   ipv4.l.google.com.
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8268
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8269
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:826a
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8293
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8263
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8267

;; AUTHORITY SECTION:
google.com.             171975 IN      NS      ns1.google.com.
google.com.             171975 IN      NS      ns4.google.com.
google.com.             171975 IN      NS      ns2.google.com.
google.com.             171975 IN      NS      ns3.google.com.

;; Query time: 219 msec
;; SERVER: 2001:db8:1:1::1#53(2001:db8:1:1::1)
;; WHEN: Wed Jan 2 16:11:57 2013
;; MSG SIZE rcvd: 294

Nota: La parte a destacar en esta salida son las direcciones IPv6 que comienzan por: 2001:db8:1:ffff..., ya en este momento sabemos que DNS64 esta funcionando.

Ahora NAT64

1) Utilizamos Tayga. El sitio oficial y link para descargarlo se encuentra en: http://www.litech.org/tayga/

2) Lo descomprimimos y desempaquetamos:

#tar -jxvf tayga-0.9.2.tar.bz2
#cd tayga-0.9.2
#./configure
#make
#make install

3) Creamos el directorio donde Tayga guardará los logs:

#mkdir /var/log/tayga

4) Editamos el archivo /usr/local/etc/tayga.conf

y copiamos y pegamos:

tun-device nat64
ipv4-addr 192.168.255.1
prefix 2001:db8:1:ffff::/96
dynamic-pool 192.168.255.0/24
data-dir /var/log/tayga

Tayga es stateless y realiza un nat 1:1 entre IPv6 e IPv4. En la configuración anterior a cada cliente IPv6 se le asignará un IP del pool 192.168.255.0/24; por ello si tenemos más de 255 hosts será necesario utililzar un pool más grande que /24. En caso de que tengas IPv4 públicas suficientes puede ser útil para evitar un doble NAT IPv4.

La directiva prefix indica el prefijo que utilizará Tayga para reconocer los 32 bits de IPv4, es decir, cuando el destino IPv6 sea: 2001:db8:1:ffff::/96, Tayga tomará los ultimos 32 bits para reconocer que ese es el destino IPv4

5) Habilitar routing IPv6 e IPv4 en el servidor.

#echo "1" > /proc/sys/net/ipv6/conf/all/forwarding
#echo "1" > /proc/sys/net/ipv4/ip_forward

6) Creación y configuración de la interfaz nat64:

#tayga --mktun
#ip link set nat64 up
#ip addr add 192.168.124.107 dev nat64
#ip addr add 2001:db8:1::1 dev nat64

(estos comandos crean la interfaz nat64 con las direcciones ip 192.168.0.1/32 y 2001:db8:1::1/128, como dije anteriormente no importa que se solape con los IPs de eth1).

Para revisar:
root@aacosta-ThinkPad-E420:~# ifconfig nat64
nat64     Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:192.168.0.1 P-t-P:192.168.0.1 Mask:255.255.255.255
          inet6 addr: 2001:db8:1::1/128 Scope:Global
          UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
          RX packets:2393 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2395 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:1615556 (1.6 MB) TX bytes:1614316 (1.6 MB)

7) Creación de rutas:
#ip route add 192.168.255.0/24 dev nat64
#ip route add 2001:db8:1:ffff::/96 dev nat64

8) Ejecutamos Tayga

#tayga -d

(el -d es opcional, solo es para tener más información)

PROBAR NAT64
a) Probamos que todo este bien (el ping debe ser satisfactorio):

root@aacosta-ThinkPad-E420:~# ping6 2001:db8:1:ffff::192.168.0.1
PING 2001:db8:1:ffff::192.168.0.1(2001:db8:1:ffff::c0a8:1) 56 data bytes
64 bytes from 2001:db8:1:ffff::c0a8:1: icmp_seq=109 ttl=63 time=2.18 ms
64 bytes from 2001:db8:1:ffff::c0a8:1: icmp_seq=110 ttl=63 time=0.209 ms
64 bytes from 2001:db8:1:ffff::c0a8:1: icmp_seq=111 ttl=63 time=0.190 ms
64 bytes from 2001:db8:1:ffff::c0a8:1: icmp_seq=112 ttl=63 time=0.126 ms

b) Realizamos NAT con la interfaz IPv4 saliente (solo si el pool IPv4 en Tayga es privado):

#iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
#iptables -A FORWARD -i eth0 -o nat64 -m state --state RELATED,ESTABLISHED -j ACCEPT
#iptables -A FORWARD -i nat64 -o eth0 -j ACCEPT

c) Ahora solo debes dirigirte a la máquina cliente y todo debe estar funcionando. Ejemplos de ping y trace:

[root@localhost ~]# traceroute6 www.algo.com -n
traceroute to algo-com-prod-elb-170663297.us-east-1.elb.amazonaws.com (2001:db8:1:ffff::36f3:7ac3) from 2001:db8:1:1::2, 30 hops max, 16 byte packets
1 2001:db8:1:1::1 1.224 ms 3.8 ms 0.352 ms
2 2001:db8:1:ffff::c0a8:ff01 0.787 ms 0.772 ms 0.268 ms
3 2001:db8:1:ffff::c0a8:1 0.76 ms 0.869 ms 0.278 ms

[root@localhost ~]# ping6 www.parmalat.com.ve -n
PING www.parmalat.com.ve(2001:db8:1:ffff::c82f:4f04) 56 data bytes
64 bytes from 2001:db8:1:ffff::c82f:4f04: icmp_seq=1 ttl=56 time=7.30 ms
64 bytes from 2001:db8:1:ffff::c82f:4f04: icmp_seq=2 ttl=56 time=5.82 ms
64 bytes from 2001:db8:1:ffff::c82f:4f04: icmp_seq=3 ttl=56 time=5.93 ms
64 bytes from 2001:db8:1:ffff::c82f:4f04: icmp_seq=4 ttl=56 time=8.38 ms

Puedes ver un estado de las asignaciones de Tayga en: /var/log/tayga/dynamic.map

Voila!... todo debe estar funcionado en este momento!

Mas información:
http://www.litech.org/tayga/
http://www.litech.org/tayga/README-0.9.2

http://kurser.iha.dk/eit/itifn/workshops/vne_workshop_2.html
http://ipvsix.me/?tag=tayga

Notas importantes:
- El DNS64 no funciona cuando la respuesta DNS tenga registros AAAA y A. En realidad no es una eroor porque se asume que el host tiene acceso IPv6 a Internet
- Es importante que el DNS64 y NAT64 compartan el mismo prefijo IPv6 (en el ejemplo de este post 2001:db8:1:ffff::/96.
- Durante todo el post describo el procedimiento utilizando la subred IPv6 2001:db8::/32. Favor notar que esta subred debe ser sustituida por sus redes respectivas (al igual que la información referente a IPv4).
- Pueden utilizar 2001:db8::/32 y va a funcionar igualmente pero sin acceso a destinos a IPv6
- El servidor DNS64 y NAT64 pueden ser diferentes equipos/máquinas

to get detailed information about Managed IT Services visit https://wetheitteam.com

jueves, 27 de diciembre de 2012

Que hacer cuando falla "clear line N" en Cisco

Caso:
Al realizar un "clear line" en Cisco para desconectar una sesión Telnet o SSH sencillamente sigue apareciendo el usuario.

Ejemplo:

IMP#sh user
Line User Host(s) Idle Location
2 vty 0 aacosta idle 00:00:01 a.b.c.d
* 4 vty 2 pepe idle 00:00:00 xx.yy.zz.dd

Queremos sacar a pepe del equipo y realizamos:
IMP#clear line vty 2

y sigue apareciendo:

IMP#who
Line User Host(s) Idle Location
2 vty 0 aacosta idle 00:00:39 a.b.c.d
* 4 vty 2 pepe idle 00:00:00 xx.yy.zz.dd

Procedimiento y solución:
Hay dos manera de hacerlo:

a) Manera rápida y 99% seguro que funciona (y menos probabilidades de error de dañar otra cosa). En vez de utilizar "clear line vty" utilizaremos "clear tcp line":

Así (nuevamente para desconectar a pepe):

IMP#clear tcp line 2
[confirm]
[OK]

b) Manera más drástica:

Buscamos las conexiones TCP que tenga el router en ese momento. Para ello utilizamos el comando "show tcp brief". Filtramos el puerto 23 (Telnet) o 22 (SSH) según sea el caso. Por ejemplo:

IMP#show tcp brief | i \.23_

63820270 n.n.n.n.23 a.b.c.d.56691 ESTAB

637E1AC0 x.x.x.x.23 xx.yy.zz.dd.39431 ESTAB

El valor del lado izquiero es la dirección dentro del TCB (TCP Block), esto es precisamente la conexión TCP que estaremos eliminando.

El comando es el siguiente:

IMP#clear tcp tcb 637E1AC0

NOTA: Favor estar seguros antes de eliminar la sesión TCP, recuerden que el router puede tener conexiones HTTP, BGP y otras importantes.

Suerte, espero haya sido útil,