Algo muy común es tener problemas de red y no saber de donde vienen. En este pequeño post os voy a explicar dos pasos para poder determinar si una tarjeta de red o un cable están fallando en una red y por tanto generando errores. Para ello vamos a hacer dos cosas. La primera es poner todos los contadores a cero y la segunda es pedir el estado de errores al cabo de un rato. Cuanto más tiempo pase más estadísticas tendremos. De todas formas si es un problema en un equipo enseguida aparecerán los errores, pero si es en una impresora, por ejemplo, solo aparecerán cuando se utilice.
Bueno, lo primero es borrar los contadores con el comando:
Switch# clear counters
Aparecerá un mesaje de confirmación. Lo aceptamos.
Clear "show interface" counters on all interfaces [confirm]
Ahora esperamos un buen rato y ejecutamos:
Switch#show interface counters errors
Y aparecerá algo parecido a lo siguiente:
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize
Fa0/1 0 0 0 0 0
Fa0/2 0 0 0 0 0
Fa0/3 0 0 0 242 0
Fa0/4 2 26 0 1955 0
Fa0/5 0 0 0 0 0
Fa0/6 0 0 0 0 0
Fa0/7 0 0 0 0 0
Fa0/8 0 1358 0 3593 1772
Fa0/9 0 0 0 0 0
Fa0/10 0 0 0 0 0
Fa0/11 0 701916 0 1040709 313834
Fa0/12 0 125828 0 1847384 0
Fa0/13 0 76416 0 1853476 0
Fa0/14 0 55518 0 515572 0
Fa0/15 0 132 0 9608 0
Fa0/16 0 6529 0 1572869 0
Fa0/17 8759 9423 0 854548 1
Fa0/18 0 825 0 628463 0
Fa0/19 0 58495 0 1061146 0
Fa0/20 0 0 0 0 0
Fa0/21 0 81748 0 1743484 0
Fa0/22 0 23 0 2418 0
Fa0/23 0 0 0 0 0
Fa0/24 0 10147 0 360011 0
Gi0/1 0 0 0 0 0
Gi0/2 0 0 0 0 0
Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants
Fa0/1 0 0 0 0 0 0 0
Fa0/2 0 0 0 0 0 0 0
Fa0/3 0 0 0 0 1 0 0
Fa0/4 0 0 0 0 20 0 0
Fa0/5 0 0 0 0 0 0 0
Fa0/6 0 0 0 0 0 0 0
Fa0/7 0 0 0 0 0 0 0
Fa0/8 0 0 0 0 1 1772 2
Fa0/9 0 0 0 0 0 0 0
Fa0/10 0 0 0 0 9 0 0
Fa0/11 0 0 0 0 0 313834 137
Fa0/12 0 0 0 0 1 0 97
Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants
Fa0/13 0 0 0 0 3 0 27
Fa0/14 0 0 0 0 5 0 61
Fa0/15 0 0 0 0 0 0 0
Fa0/16 0 0 9 0 7 0 10
Fa0/17 0 0 0 0 2 1 0
Fa0/18 0 0 0 0 4 0 1
Fa0/19 0 0 0 0 2 0 55
Fa0/20 0 0 0 0 6 0 0
Fa0/21 0 0 0 0 1 0 80
Fa0/22 0 0 0 0 8 0 0
Fa0/23 0 0 0 0 0 0 0
Fa0/24 0 0 0 0 0 0 41
Gi0/1 0 0 0 0 0 0 0
Gi0/2 0 0 0 0 0 0 0
Con lo que fácilmente podremos averiguar el puerto o puertos con problemas. Para los que no tengan muchas nociones simplemente comentar que si hay muchos errores de CRC suele ser problemas de cableado y si lo que tienes son errores de colisiones probablemente se produzcan por la configuración del duplex.
Para asegurarnos del estado de un interface en concreto (en este caso el 11), podemos ejecutar el siguiente comando:
SWITCH#show interface fa0/11
FastEthernet0/11 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 000f.2444.eb4b (bia 000f.2444.eb4b)
Description: UM
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 100BaseTX
input flow-control is unsupported output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:01, output hang never
Last clearing of "show interface" counters 4w4d
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
42142559 packets input, 2630184855 bytes, 0 no buffer
Received 172385 broadcasts (0 multicast)
313834 runts, 137 giants, 0 throttles
1015887 input errors, 701916 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 102 multicast, 0 pause input
0 input packets with dribble condition detected
46864411 packets output, 2133620851 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
Como podemos observar, tiene la configuración a 100FD y tiene muchos errores de CRC. Esto tiene pintas de que tiene el latiguillo de red mal, lo pisado/machacado o similar. Lo primero que habría que hacer es repasar el cableado desde la tarjeta de red hasta el switch y sustituirlo por nuevos. Se vuelven a borra los contadores y a probar. Si continúan los problemas habría que probar con otra tarjeta de red o con el crimpado del conector de red. En fin, ya es más de la parte de instalación que de configuración.
Un saludo,
Mostrando entradas con la etiqueta Cisco. Mostrar todas las entradas
Mostrando entradas con la etiqueta Cisco. Mostrar todas las entradas
lunes, 25 de octubre de 2010
Como detectar otros dispositivos Cisco conectados a tu electrónica
Normalmente llevo una relación de qué hay conectado en qué puerto muy actualizada, pero en ocasiones me ha pasado que no he actualizado la documentación después de un cambio y he perdido la referencia de los dispositivos conectados en otros puertos. Eso es justo lo que me ha pasado hoy. Me ha parecido interesante publicarlo por si a alguien más le pasa y no es un gurú de Cisco, como para acordarse de todos los comandos. Para solucionarlo tienes dos opciones, una es la de seguir el cable para ver que hay detrás. La otra, si tienes otro dispositivo Cisco conectado en electrónica de dicho fabricante, simplemente le preguntas qué hay detrás. Para ello solo hay que poner en modo ENA el siguiente comando:
Switch>Show CDP neighbors
La salida debe ser algo similar a esto:
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID Local Intrfce Holdtme Capability Platform Port ID
router1 Gig 4/1 158 R S I Cisco 2811 Fas 0/0
switch0 Gig 5/2 160 R S I WS-C4507R Gig 7/1
switch1 Gig 1/3 157 S I WS-C3560G Gig 0/52
switch2 Gig 1/21 151 S I WS-C2950SX Gig 0/2
switch3 Gig 1/4 139 S I WS-C3560G Gig 0/52
switch4 Gig 1/11 131 S I WS-C2950SX Gig 0/1
switch5 Gig 5/1 166 R S I WS-C6506-E Gig 5/1
switch 6 Gig 1/22 178 S I WS-C2960-4 Gig 0/2
Como veréis es sencillo y puede ahorrar bastante trabajo buceando en el cableado.
Un saludo,
Switch>Show CDP neighbors
La salida debe ser algo similar a esto:
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID Local Intrfce Holdtme Capability Platform Port ID
router1 Gig 4/1 158 R S I Cisco 2811 Fas 0/0
switch0 Gig 5/2 160 R S I WS-C4507R Gig 7/1
switch1 Gig 1/3 157 S I WS-C3560G Gig 0/52
switch2 Gig 1/21 151 S I WS-C2950SX Gig 0/2
switch3 Gig 1/4 139 S I WS-C3560G Gig 0/52
switch4 Gig 1/11 131 S I WS-C2950SX Gig 0/1
switch5 Gig 5/1 166 R S I WS-C6506-E Gig 5/1
switch 6 Gig 1/22 178 S I WS-C2960-4 Gig 0/2
Como veréis es sencillo y puede ahorrar bastante trabajo buceando en el cableado.
Un saludo,
lunes, 22 de febrero de 2010
Debuguear con Cisco
Bueno, no es que sea muy experto en debugueo, pero hay veces que lo necesito para ver si hay tráfico en el router o para ver si al menos se conectan ambos lados. En este caso me voy a centrar en un equipo que hace doble NAT y quiero conocer si hay conexión en ambos sentidos. Es importante recordar que el comando debug puede llegar a colgar el router por la cantidad de recursos que necesita. Que cada cual asuma el riesgo de jugar con él o no.
Vamos al lío:
- Lo primero es ver es estado del NAT para comprobar que las direcciones se traducer correctamente. Para ello simplemente hay que usar el 'show':
sh ip nat tr , que traducido es 'Show IP NAT Translation'. Soy muy vago y lo resumo todo al máximo ;-)
Este comando nos mostrará la tabla de NAT, si hay conexión y el puerto utilizado para la misma. Muy útil.
- Si vemos que se crea la conexión, pero no parece que funcione, se puede hacer el debug de la parte NAT:
debug ip nat detailed (no os quejéis que pongo el comando completo). Coño!! no se ve nada. Esto es muy común. Al router tienes que indicarle que lo muestre con term mon.
- Ahora quiero ver todos lo paquetes IP para descartar otros problemas. Creo que lo primero sería desactivar el debug anterior, porque son acumulativos y si pones otro se ejecurarán ambos. Para desactivarlo puedes poner no debug ip nat o simplemente no debug all para parar todos los activos. A continuación ejecutamos:
debug ip packet detail . Ahora empezará a salir una cantidad enorme de información. Mi consejo es almacenarla en algún tipo de fichero para luego analizarla.
- Por fin hemos terminado y queremos parar el debug. podemos usar no debug ip packet o bien no debug all . Además, queremos quitar el monitor del router, con lo que tendremos que ejecutar term no mon
Listo, con esto podéis encontrar el problema o por lo menos orientaros hacia dónde puede estar.
Vamos al lío:
- Lo primero es ver es estado del NAT para comprobar que las direcciones se traducer correctamente. Para ello simplemente hay que usar el 'show':
sh ip nat tr , que traducido es 'Show IP NAT Translation'. Soy muy vago y lo resumo todo al máximo ;-)
Este comando nos mostrará la tabla de NAT, si hay conexión y el puerto utilizado para la misma. Muy útil.
- Si vemos que se crea la conexión, pero no parece que funcione, se puede hacer el debug de la parte NAT:
debug ip nat detailed (no os quejéis que pongo el comando completo). Coño!! no se ve nada. Esto es muy común. Al router tienes que indicarle que lo muestre con term mon.
- Ahora quiero ver todos lo paquetes IP para descartar otros problemas. Creo que lo primero sería desactivar el debug anterior, porque son acumulativos y si pones otro se ejecurarán ambos. Para desactivarlo puedes poner no debug ip nat o simplemente no debug all para parar todos los activos. A continuación ejecutamos:
debug ip packet detail . Ahora empezará a salir una cantidad enorme de información. Mi consejo es almacenarla en algún tipo de fichero para luego analizarla.
- Por fin hemos terminado y queremos parar el debug. podemos usar no debug ip packet o bien no debug all . Además, queremos quitar el monitor del router, con lo que tendremos que ejecutar term no mon
Listo, con esto podéis encontrar el problema o por lo menos orientaros hacia dónde puede estar.
miércoles, 4 de marzo de 2009
Cómo saber dónde está conectado un dispositivo en un switch de Cisco
Pues el título lo dice todo. Me ha pasado más de una vez, que alguien ha tocado el parcheo del rack y me han bailado los puertos y los puntos de datos, con lo que he perdido el control de los dispositivos conectados.
Para solucionarlo de una forma más o menos rápida y eficaz, es siguiendo los siguientes pasos. Posiblemente haya mejores formas de hacerlo, pero a mi me ha funcionado bien hasta ahora.
1.- Con un escaneador de red se buscan las direcciones MAC de los dispositivos a modificar. Yo he probado muchos y el que más me ha gustado por rapidez es el Advanced IP Scanner, que además es gratuido y lo podéis descargar de www.radmin.com.
2.- Te logeas en el switch donde crees que está el dispositivo y escribes:
# show mac-address-table address 0000.1111.2222
Aparecerá un mensaje como este:
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 0000.1111.2222 DYNAMIC Fa0/12
Total Mac Addresses for for this criterion: 1
Ahí se aprecia como en puerto FastEthernet 0/12 está pinchado el dispositivo con la dirección MAC que buscamos.
También podría salir algo como esto:
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 0000.1111.2222 DYNAMIC Gi0/2
Total Mac Addresses for this criterion: 1
Indica casi con toda seguridad, que el dispositivo no está conectado a ese switch, sino a otro que tiene conexión por el puerto GigaEthernet 0/2.
Si tienes pocos switches puedes saber cual está conectado en ese puerto con el comando:
#show cdp neighbor Gi0/2 detail
Donde nos mostrará algo parecido a esto:
Device ID: switch2
Entry address(es):IP address: 1.1.1.2
Platform: cisco WS-C3550-24-PWR, Capabilities: Switch IGMP
Interface: GigabitEthernet0/2, Port ID (outgoing port):
GigabitEthernet0/2
Pues listo, con esto sabrás dónde se encuentran esos dispositivos que quieres cambiar de VLAN.
Para solucionarlo de una forma más o menos rápida y eficaz, es siguiendo los siguientes pasos. Posiblemente haya mejores formas de hacerlo, pero a mi me ha funcionado bien hasta ahora.
1.- Con un escaneador de red se buscan las direcciones MAC de los dispositivos a modificar. Yo he probado muchos y el que más me ha gustado por rapidez es el Advanced IP Scanner, que además es gratuido y lo podéis descargar de www.radmin.com.
2.- Te logeas en el switch donde crees que está el dispositivo y escribes:
# show mac-address-table address 0000.1111.2222
Aparecerá un mensaje como este:
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 0000.1111.2222 DYNAMIC Fa0/12
Total Mac Addresses for for this criterion: 1
Ahí se aprecia como en puerto FastEthernet 0/12 está pinchado el dispositivo con la dirección MAC que buscamos.
También podría salir algo como esto:
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 0000.1111.2222 DYNAMIC Gi0/2
Total Mac Addresses for this criterion: 1
Indica casi con toda seguridad, que el dispositivo no está conectado a ese switch, sino a otro que tiene conexión por el puerto GigaEthernet 0/2.
Si tienes pocos switches puedes saber cual está conectado en ese puerto con el comando:
#show cdp neighbor Gi0/2 detail
Donde nos mostrará algo parecido a esto:
Device ID: switch2
Entry address(es):IP address: 1.1.1.2
Platform: cisco WS-C3550-24-PWR, Capabilities: Switch IGMP
Interface: GigabitEthernet0/2, Port ID (outgoing port):
GigabitEthernet0/2
Pues listo, con esto sabrás dónde se encuentran esos dispositivos que quieres cambiar de VLAN.
Suscribirse a:
Entradas (Atom)