Mostrando entradas con la etiqueta cisco. Mostrar todas las entradas
Mostrando entradas con la etiqueta cisco. Mostrar todas las entradas

martes, 11 de agosto de 2015

Como monitorear independientemente contadores IPv4 e IPv6 en Cisco (tráfico)

Introduccion
  Hoy en día es muy común ver redes en la modalidad Dual Stack (IPv4 + IPv6) donde ambos protocolos conviven en misma VLAN y/o Bus de red

  En el presente post voy a mostrar como monitorear independientemente el tráfico IPv4 e IPv6 que atraviesa una interfaz de un equipo Cisco.

Que se necesita
  a) Primero es muy importante el soporte de IP::MIB en el IOS del router, muy probablemente ya lo tengas pero vas a necesitar un IOS relativamente novedoso porque existen OID que no estan en versiones viejas.

  Para la realizacion del siguiente documento utilizamos:  c7200-adventerprisek9_sna-mz.152-4.M8.bin

  b) El cliente debe tener el software con el que vayas a monitorear..., eso es todo :-)  El siguiente post brevemente da ejemplos en MRTG, por ello instalamos:

apt-get install snmp
apt-get install snmp-mibs-downloader
apt-get install mrtg

  c) Para un mejor seguimiento de este documento es mejor tener compilado el MIB: IP-MIB de Cisco, muy seguramente quedó instalado luego de ejecutar apt-get install snmp-mibs-downloader.


Topologia utilizada para este post




Pasos

a)  Primero hay que averiguar el índice de la interfaz. Hay dos maneras:
  1) Desde el CLI del equipo Cisco con el comando:

#show snmp mib ifmib ifindex

Obtendremos algo así:

FastEthernet1/1: Ifindex = 3
Loopback0: Ifindex = 5
Null0: Ifindex = 4
FastEthernet1/0: Ifindex = 2
FastEthernet0/0: Ifindex = 1

 Logicamente trabajaremos con las interfaces que nos interecen, recordemos el número de índice que lo necesitaremos más adelante.


  2) Vía SNMP:
  Sabiendo al menos el IPv4 que queremos monitorear (mas adelante podremos monitorear IPv6 también)

Desde el equipo linux hacemos:
#snmpwalk -mALL -v2c -chola3 host1 .1.3.6.1.2.1.4.20.1.2.+DIRIPv4  
Por ejemplo:
#snmpwalk -mALL -v2c -chola3 host1 .1.3.6.1.2.1.4.20.1.2.192.168.1.1

Lo anterior nos devuele el indice de la interfaz que queremos monitorear. Listo!.

Si queremos estar seguro podemos hacer:

#snmpwalk -mALL -v2c -chola3 host1 1.3.6.1.2.1.2.2.1.2.+IntfIndex  
y nos devuelve la interfaz.

Donde:
host1 = host (podemos colocar un IP)
hola3 = la comunidad SNMP


b)  Crear los OID a monitorear
  i) Para obtener el OID de paquetes "INPUT IPv6" haremos lo siguiente:
- Utilizaremos este OID base y la agregaremos el indice de la interfaz al final:
  1.3.6.1.2.1.4.31.3.1.5.2 (IP-MIB::ipIfStatsInOctets.ipv6) + ifIndex = 1.3.6.1.2.1.4.31.3.1.5.2.1

 ii) Para obtener el OID de paquetes "Output IPv6" haremos lo siguiente:
  1.3.6.1.2.1.4.31.3.1.32.2 (IP-MIB::ipIfStatsOutOctets.ipv6) + ifIndex = 1.3.6.1.2.1.4.31.3.1.32.2.1

En MRTG el mrtg.cfg quedaría algo así:

Target[ipv6_f00]:1.3.6.1.2.1.4.31.3.1.5.2.1&1.3.6.1.2.1.4.31.3.1.32.2.1:readonly@192.168.1.1


Ahora bien, también queremos monitorear el tráfico IPv4:

i) Para obtener el OID de paquetes "INPUT IPv4" haremos lo siguiente:
- Utilizaremos este OID base y la agregaremos el indice de la interfaz al final:
  .1.3.6.1.2.1.4.31.3.1.5.1 (IP-MIB::ipIfStatsInOctets.ipv4) + ifIndex (F0/0) = .1.3.6.1.2.1.4.31.3.1.5.1.1

ii) Para obtener el OID de paquetes "Output IPv4" haremos lo siguiente:
  1.3.6.1.2.1.4.31.3.1.32.1 (IP-MIB::ipIfStatsOutOctets.ipv4) + ifIndex (F0/0) = 1.3.6.1.2.1.4.31.3.1.32.1.1


Target[ipv4_f00]:.1.3.6.1.2.1.4.31.3.1.5.1.1&1.3.6.1.2.1.4.31.3.1.32.1.1:readonly@192.168.1.1


  c) Se generó tráfico desde los hosts IPv4 e IPv6 hacia la Loopback del router principal con la aplicación bwping, se cambió el ancho de banda transmitido con el objeto de ver los cambios en la interfaz

    Para generar el tráfico utilicé el siguiente script:

while [ 1] 
do 
  bwping6 -b 256 -s 100 -v 9999 2001:db8:ffff::ffff
done

y

while [ 1] 
do 
  bwping -b 128 -s 100 -v 9999 192.168.255.255
done




Resultados

IPv4:




IPv6:



Total en la interfaz (default en MRTG):






Get Tweaked apps, iOS Emulators and Hack games with iPA Library Browse and download iOS IPA Apps, tweaks and ++ apps for iPhone, iPad and iPod Touch.
Guia do Host: Dicas para Criação e Hospedagem de Sites alphimedia hospedagem de site e revenda de hospdagem mais barata do brasil O Guia do Host é o local ideal para quem quer aprender mais como criar e hospedar um site. Nele você vai encontrar dica melhor hospedagem site brasil No Guia do Host você vai encontrar a melhor hospedagem para seu projeto, acompanhe também nossas promoções e cupons de desconto em parceria com as melhores hospedagens de sites da atualidade.
인스타그램 바로가기
जीबी व्हाट्सएप APK WhatsApp का मॉड वर्जन है जिसमें कई सारे Advance Features मिलते है तो जीबी व्हाट्सएप डाउनलोड करें और पाए Hide Last Seen जैसे बेहतरीन फीचर्स।

miércoles, 6 de mayo de 2015

Demostracion de Secuestro de Prefijos - RPKI - BGP (parte 2/2)


En este segundo video se muestra como manipular Quagga para que tome decisiones en base al estado del prefijo RPKI. Continuacion de: https://blog.acostasite.com/2015/05/demostracion-de-secuestro-de-prefijos.html


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

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,

jueves, 6 de septiembre de 2012

Tunel GRE entre Cisco y Linux + NAT

Introducción:
  En el siguiente escenario se plantean dos oficinas conectadas mediante un tunel GRE. En la oficina "A" existe un router Cisco y en la oficina "B" un servidor Linux.

Objetivo:
  Que la oficina "A" (la red con el router Cisco) salga a Internet (nateada) con el IP de la red de la oficina "B" (red con el servidor Linux)


Topologia:
 
Lado Cisco (Oficina A):
   LAN: 192.168.56.6
   WAN: 98.76.54.32
   TUNNEL 0: 192.168.56.6

Lado Linux (Oficina B):

   LAN: 192.168.1.200/24  (gre_if0)
   WAN: 123.45.67.89 (Interfaz: venet0:0)

Pasos (lado equipo Linux):
1) Levantar el modulo GRE
  #modprobe ip_gre

2) Crear la interfaz del tunel (llamada gre_if0). Puede tener cualquier nombre:
   #ip tunnel add gre_if0 mode gre remote 98.76.54.32 local 123.45.67.89 ttl 255

3) Asignarle un IP a la interfaz recien creada (gre_if0)
   #ip addr add 192.168.1.200/24 dev gre_if0

4) Levantar la interfaz del tunel (por defecto viene shutdown)
   #ip link set gre_if0 up (Levantar la interfaz gre_if0)

5) Enrutar por el tunel aquellas rutas que sean necesarias, por ejemplo: 
   #route add -net 192.168.56.6 netmask 255.255.255.255 dev gre_if0

Pasos (lado Cisco)



!Creación de la interfaz tunel
interface Tunnel0
 ip unnumbered FastEthernet0/0
 tunnel source Vlan1
 tunnel destination 123.45.67.89
 

!Configuración de la interfaz LAN
interface FastEthernet0/0
 description **Conexion LAN**
 ip address 192.168.56.6 255.255.255.252
 duplex auto
 speed auto
 

!La interfaz VLAN1 es la interfaz WAN
interface Vlan1
 description **Conexion WAN**
 ip address 98.76.54.32 255.255.255.248
 

!Hacer las rutas necesarias en el router
!para alcanzar la LAN de la oficina B
ip route 192.168.1.200 255.255.255.255 Tunnel0


PARA EL NAT (LADO LINUX):

1) Permitir routing en el equipo
  # echo 1 > /proc/sys/net/ipv4/ip_forward

2) Que el servidor Linux sepa alcanzar la LAN de Oficina A
   #route add -net 192.168.56.0 netmask 255.255.255.0 dev gre_if0


3) Realizar el NAT
   # iptables -A POSTROUTING -t nat -s 192.168.56.0/24 -j SNAT --to 123.45.67.89





  Notese que hubo que hacer Source NAT (SNAT). La explicación del motivo está indicada en el post: "Linux iptables, solucion al error: Warning: wierd character in interface"

 
Espero te sea útil,


miércoles, 11 de julio de 2012

Script ejemplo en PHP que entra a un equipo Cisco y ejecuta un "show log"

Necesidad:
  Tener un script php que entre en un Router o LAN Switch Cisco y que ejecute ciertos comandos sobre el mismo. Lo cierto es que es un Script muy útil y sencillo.
  Importante: En este ejemplo para ser utilizado desde el shell.

Solución:
   En el presente post solo deseo indicar el script que he utilizado anteriormente 

Script:
  El presente script entra en el host "192.168.1.6" con el usuario "blogale" y la clave "miclave", luego ejecuta el comando "term len 0" (importante si el log tiene varias paginas) y posteriormente ejecuta el comando "sh log"

#!/usr/bin/php

require_once "PHPTelnet.php";

$telnet = new PHPTelnet();
$telnet->show_connect_error=0;

// if the first argument to Connect is blank,
// PHPTelnet will connect to the local host via 127.0.0.1
$result = $telnet->Connect('192.168.1.6','blogale','miclave');

switch ($result) {
  case 0:
  $telnet->DoCommand('term len 0', $result);
  // NOTE: $result may contain newlines
  echo $result;
  $telnet->DoCommand('sh log', $result);
  echo $result;
  // say Disconnect(0); to break the connection without explicitly logging out
  $telnet->Disconnect();
  break;

  case 1:
  echo '[PHP Telnet] Connect failed: Unable to open network connection';
  break;

  case 2:
  echo '[PHP Telnet] Connect failed: Unknown host';
  break;

  case 3:
  echo '[PHP Telnet] Connect failed: Login failed';
  break;

  case 4:
  echo '[PHP Telnet] Connect failed: Your PHP version does not support PHP Telnet';
  break;
}
?>

Ejecutando el script:
  1) Darle permiso de ejecución, por ejemplo:  chmod 755 cisco.php
  2) ./cisco.php

Importante:
 - Debes tener PHPTelnet.php
 - Debes tener php-cli y otras librerias (en Ubuntu puedes instalar la mayoría necesaria con: aptitude  install php5-dev php5-cli php-pear build-essential openssl-dev zlib1g-dev php-pear)

Mas información (y link para bajar phptelnet.php):











 

jueves, 5 de julio de 2012

Linux con soporte CDP

El día de hoy tuve una necesidad donde necesitaba que Linux hablara CDP para realizar unas pruebas con Cisco, en fin, es bastante fácil y por ello lo dejo aquí:

Objetivo:
  Que linux hablé/soporte CDP

Pasos:

1) Bajar el paquete CDP: wget http://gpl.internetconnection.net/files/cdp-tools.tar.gz
2) Compilar el paquete:
   Tuve que bajar cierta cantidad de paquetes para poder compilar el mismo, les dejo lo que tuve que bajar:


  #apt-get install build-essential
  #apt-get install libnet0-dev
  #aptitude install libpcap0.8-dev
  #aptitude install libnet1-dev


3) Ahora si podemos compilar:
  #make

4) Listo!. Ejecutar: ./cdp-send eth0

Revisar que todo funcione:

1) Por ejemplo en un LAN Switch Cisco:

SW1#sh cdp neighbors        
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater


Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
ubuntu           Fas 0/30           127          H        x86_64    eth0



2) SW1-PQC-OESTE#sh cdp neighbors detail 
-------------------------
Device ID: ubuntu
Entry address(es): 
  IP address: 192.N.1X.86
Platform: x86_64,  Capabilities: Host 
Interface: FastEthernet0/30,  Port ID (outgoing port): eth0
Holdtime : 141 sec


Version :
Linux 3.2.0-24-generic


advertisement version: 2
Management address(es): 


También se puede colocar la interfaz a escuchar CDPs:

# ./cdp-listen eth0

# Interface: eth0
# Hostname: SEP0004f2113d06
# Address: 10.0.0.65
#
# TimeToLive: 180
# Capabilities: L3TXRX(host) unknown(00000090)
#
# Networks:


Más información:
- http://openmaniak.com/cdp.php

Espero les sea útil!!


lunes, 28 de mayo de 2012

Inter-VLAN Bridging. Bridge entre dos VLANs. Cisco

Hola,
  El día de hoy tuve la necesidad de unir dos VLANs que me estaban entregando dos proveedores Metroethernet, para esta solución puede ser que exista más de una solución y/o una solución diferente. Les dejo la que me funcionó a mi:

  Escenario:
- Proveedor A: VLAN 10
- Proveedor B: VLAN 25
- Subnet de prueba: 10.22.1.176/29
- Ambas proveedores llegan a un LAN Switch Cisco
- El Inter-VLAN Bridging se hace un router Cisco 7200

  Topología:

  LAN Switch Cisco ---- (vlan 10) Proveedor A
                                  |-- (vlan 25) Proveedor B
                                  | -- (vlan trunk) Cisco Router


  Solución:

a) Paso 1:
   Para al topología planteada -quizás no es necesario en otra topología- es importante manejar Trunking entre el LAN Switch y el Router Cisco. Incluso, el LAN Switch puede manejar correctamente trunking hace el proveedor A y B sin afectar el funcionamiento de esta solución.

Lado del LAN Switch



interface FastEthernet0/3
 description Hacia Router cisco
 switchport mode trunk
end


Lado Router:



interface GigabitEthernet0/1
 no ip address
 media-type rj45
 speed auto
 duplex auto
 negotiation auto
end

interface GigabitEthernet0/1.10
 description  Hacia Proveedor A
 encapsulation dot1Q 10
end

interface GigabitEthernet0/1.25
 description  Hacia Proveedor B
 encapsulation dot1Q 25
end


b) Paso 2:

   Ahora bien, los comandos que hacen "la magia" del Bridging entre las dos VLANs son - SOLO DEL LADO DEL ROUTER -:


!START HERE


bridge irb


interface BVI1

 ip address 10.22.1.179 255.255.255.248
!



interface GigabitEthernet0/1.10
 description  Hacia Proveedor A
 encapsulation dot1Q 10
 bridge-group 1
end

interface GigabitEthernet0/1.25
 description  Hacia Proveedor B
 encapsulation dot1Q 25
 bridge-group 1
end


bridge 1 protocol ieee
bridge 1 route ip


!END HERE


  La única limitante (son en algunos escenarios) que puedo apreciar en la configuración anterior es aquella donde el proveedor no permita configurar alguna dirección IP en el router Cisco. Notese que en el ejemplo existe una interfaz virtual BVI (Bridge Group Virtual Interface) la cual es una subred utilizada dentro de las VLANs (VID 10 y VID 25)


Espero sea de alguna utilidad para alguien,


Más información:
Understanding Issues Related to Inter-VLAN Bridging
Understanding and Configuring VLAN Routing and Bridging on a Router Using the IRB Feature



lunes, 9 de abril de 2012

Router (o LAN Switch) Cisco como servidor NTP

Escenario: 
  Deseo que mi Router Cisco se comporte como un servidor NTP. En realidad es algo SUPER sencillo pero lo deseo colocar aquí como referencia, estoy seguro que más de uno ha tenido esta necesidad.
  Antes de continuar recueden que cualquier servicio que se habilita sobre un dispositivo trae consigo "huecos" de seguridad, dicho esto, en caso de no necesitar levantar el servicio NTP, por favor no lo hagan.

Configuracion del lado del Router (o Switch) _servidor_ :
a) Entrar en modo de configuracion (conf t)
b)  ntp master [stratum]
   ejemplo:
     MIROUTER(config)# ntp master 3



  LISTO!. Posteriormente, a partir de este momento ya el router se convierte en un NTP Server


  Desde otro equipo solo hay que especificar como NTP Server el IP del Router Cisco. Ahora supongamos que el cliente es otro router Cisco, una configuración pudiese ser:

MILANSWITCH(config)#ntp server 192.168.12.1  source loopback 10

  Recomiendo colocar el timezone de la ubicación de uno. Por ejemplo para Venezuela podemos usar:

MILANSWITCH(config)#clock timezone VEN -4 30 quedará precisa

Mas informacion:
http://www.cisco.com/en/US/docs/ios/12_1/configfun/configuration/guide/fcd303.html
Network Time Protocol

martes, 5 de abril de 2011

Convertir archivos Webex a MP4

Introduccion:
Estoy en Linux, tengo un archivo en formato Webex (.arf) y deseo convertirlo a .mp4

Solucion:

1) Bajar el convertidor NBR2MP4 de la siguiente direccion:

http://www.webex.co.uk/support/downloads.html

2) Luego hay que descomprimirlo:

tar -xvf nbr2mp4.tar ./

3) Hacer el instalador ejecutable:

chmod +x ./nbr2mp4.sh

5) Instalarlo en el directorio por default (Home),

./nbr2mp4.sh

6) Entrar en el directorio recien creado

cd nbr2_mp4

7) Para convertir:

./nbr2mp4 SOURCE [MP4_DIRECTORY] [FPS]

Ejemplo:

./nbr2mp4 dns.arf .

lunes, 14 de marzo de 2011

Historico de tablas BGP. ¿Hijack de mi red?

Descripcion:
Si eres un administrador de routers que manejen tablas BGP (probablemente un ISP) quizás publicas tus propios prefijos/subredes a tu upstream provider desde tu Sistema Autonomo (AS).
Ahora bien, debes saber que tu mismo prefijo o uno muy similar (quizás un prefijo más grande o chico) puede ser -por algún error o ataque- publicado desde otro AS en otra parte del mundo. Lamentablemente esto es algo que ocurre y hay que estar preparado.

Problema:
Pienso haber sufrido un hijack de mis prefijos IP (publicadas desde un AS diferente al mio) y necesito verificarlo.
Para este inconveniente te recomiendo utilizar un routeview especificamente la herramienta BGPlay. BGPplay me permito decir que es una herramienta excelente y gratuita realizada en Java que permite buscar un prefijo y el te indicará cualquier cambio en los ultimos 10 días.
Para utilizar BGPPlay:
1) Dirigete a la pagina http://bgplay.routeviews.org/
2) Haz click sobre el boton "Start BGPlay"
3) Luego se cargará el applet de Java, allí indicas cual es tu prefijo un rango de fecha donde deseas consultar
4) Hacer click sobre Ok
5) Analizar los resultados


Recomendación:
Tener Alarmas!; para ello deseo sugerirte el sitio web: http://www.bgpmon.net/ . BGPmon es un sitio gratis dedicado al monitoreo y analisis de tablas BGP. Lo más significativo que tiene es que puedes indicar cuales son tus prefijos, tu AS y en caso de existir algún cambio ellos te envian un correo. Por ejemplo puedes configurar las siguientes alarmas:
- En caso de existir algún otro AS que comienza a publicar algún prefijo tuyo te enviaran un correo
- Redes nuevas
- Cambios significativos de path
- Redes subneteadas
- Retiro/withdraw de redes

Suerte, espero sea de tu utilidad,

martes, 8 de febrero de 2011

Obtener la tabla BGP de un router Cisco por SNMP

Objetivo:
Deseo obtener la tabla BGP de un router Cisco por SNMP

Procedimiento:
El siguiente procedimiento se hizo desde un Laptop con Mandriva y snmp-utils instalado. El router fue un Cisco 7200 con IOS 12.3

- Instalar snmp-utils debido a que es necesario la aplicación snmpwalk
#urpmi net-snmp-utils

- El MIB utilizado es el CISCO-BGP4-MIB, puedes compilarlo en tu equipo o ir directamente al OID.

- El objeto escogido por mi persona es: cbgpRouteBest el cual corresponde el OID 1.3.6.1.4.1.9.9.187.1.1.1.1.18

- El comando para obtener la tabla BGP que puedes utilizar es:
#snmpwalk -v 1 -c MICOMUNIDAD MIROUTER .1.3.6.1.4.1.9.9.187.1.1.1.1.18

La salida del comando es bastante extensa y puede ser hasta engorroso de leer. La salida es algo similar a:

SNMPv2-SMI::enterprises.9.9.187.1.1.1.1.18.1.128.1.4.3.4.5.6.12.0.0.30.228.0.0.0.2.199.60.28.0.24 = INTEGER: 1

El prefijo BGP se encuentra ubicado justo antes del "=" en formato octeto1.octeto2.octeto3.octeto4.mascara

Por ello, para obtener una salida limpia utiliza el siguiente mini-script:

#snmpwalk -v 1 -c MICOMUNIDAD MIROUTER .1.3.6.1.4.1.9.9.187.1.1.1.1.18
| cut -d "=" -f1 | awk -F. '{print $(NF-4) echo "." $(NF-3) echo "." $(NF-2) echo "." $(NF-1) echo "/" $(NF)}'

La salida será algo similar a:
190.124.165.0/24
190.196.224.0/20
192.33.14.0/24
192.58.128.0/24
192.197.157.0/24
193.116.0.0/14
199.60.28.0/24

Más info:
http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/sbgprmib.html
ftp://ftp.cisco.com/pub/mibs/oid/CISCO-BGP4-MIB.oid

sábado, 4 de diciembre de 2010

Como bajar IOS de Cisco (gratis)

Intro: 
 El siguiente post esta basado en el post encontrado en: http://saifulaziz.wordpress.com/2008/08/08/google-hack-for-free-cisco-ios/ llamado: "Google hack for free Cisco IOS" 
Situacion: 
   Deseo bajar IOS de Cisco :) 
Solucion: 
   Conseguiremos los sitios para bajar los IOS gracias al poder de google, en muy sencillo. Por ejemplo para conseguir sitios con un indice de productos Cisco podemos hacer una busqueda que incluya: intitle:index.of ios parent directory bin o haz click aqui Ahora bien, si queremos buscar IOS de alguna plataforma especifica agrega el modelo (familia o modelo exacto) al comienzo de la busqueda, por ejemplo: 2600 intitle:index.of ios parent directory bin o haz click aqui para ver un ejemplo

viernes, 19 de noviembre de 2010

Redistribuir ruta por default con BGP. Cisco

Escenario:
El dia de hoy estuve un cliente que me pidio que por BGP le anunciara una ruta por default. En fin, es algo muy sencillo y espero sea de tu utilidad.

Solucion:
En el router Cisco configurar:

router bgp XXXX
neighbor 10.0.1.5 remote-as NNN
neighbor 10.0.1.5 default-originate

Donde:
XXXX: es tu sistema autonomo
10.0.1.5: Direccion IP del peer con quien estas levantando la sesion BGP
NNN: El sistema autonomo de tu peer
El comando default-originate es quien hace posible la publicacion de una ruta 0.0.0.0 al peer remoto.

Mas informacion:
https://learningnetwork.cisco.com/message/83023
http://blog.ioshints.info/2007/11/bgp-default-route.html

Espero haya sido util,

miércoles, 3 de noviembre de 2010

Tunel GRE entre Cisco y Linux (Debian)

Situación:
Deseo crear un tunel GRE entre en un equipos Linux y un router Cisco

Procedimiento:

a) Del lado del linux:

Lo primero que hay que hacer es levantar el modulo ip_gre del lado del Linux:
#modprobe ip_gre

Luego,necesitamos definir ante todo, el nombre de la interfaz, y la dirección que este va a tener, en mi caso, decidi que la interfaz se llamara "Core2", y usare la dirección IP 7.7.7.0/30 (OJO, esta es una dirección IP PUBLICA!!!!!!, es conveniente usar direcciones IP privadas, ejm: 10.0.0.0/8, en mi caso, esto se monto en un laboratorio).

Ejecutamos los siguientes comandos

ip tunnel add Core2 mode gre local 8.8.8.1 remote 9.9.9.2 dev eth0
ip add ad dev Core2 7.7.7.1/32
ip link set dev Core2 up



Local
hace referencia a la interfaz en nuestro linux (eth0 que tiene el IP 8.8.8.1) por donde sale el trafico, si manejamos una sola interfaz, en este caso usaríamos la dirección IP de la interfaz que tenemos configurado, si manejamos dos interfaces, es conveniente usar la interfaz por donde sabemos que el trafico hacia la otra punta del tunel va a salir. (usar un traceroute)

Remote
hace referencia a la dirección IP del peer, esta tendría que ser la dirección contra la que vamos a levantar el tunnel


Ahora, vemos como queda la configuracion de la interfaz

#ifconfig Core2
Core2 Link encap:UNSPEC HWaddr C8-2F-97-7E-05-08-00-00-00-00-00-00-00-00-00-00
inet addr:7.7.7.1 P-t-P:7.7.7.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MTU:1476 Metric:1
RX packets:134 errors:0 dropped:0 overruns:0 frame:0
TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:11896 (11.6 KiB) TX bytes:3780 (3.6 KiB)


b) Del lado del equipo cisco , es un poco más sencillo,


GRE#conf t
Enter configuration commands, one per line. End with CNTL/Z.
GRE#int tunnel 100
GRE(config-if)#tunnel source 9.9.9.2
GRE(config-if)#tunnel destination 8.8.8.1
GRE(config-if)#ip address 7.7.7.2 255.255.255.252



Listo!!!

Veamos la configuracion

GRE#sh run in tu100
Building configuration...

Current configuration : 128 bytes
!
interface Tunnel100
ip address 7.7.7.2 255.255.255.252
tunnel source 9.9.9.2
tunnel destination 8.8.8.1
end

GRE#


Y listo Sres, ya tenemos nuestro Tunel levantado

GRE#sh int tunnel 100
Tunnel100 is up, line protocol is up
Hardware is Tunnel
Internet address is 7.7.7.2/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 9.9.9.2, destination 8.8.8.1
Tunnel protocol/transport GRE/IP


Cabe destacar que la interfaz tunnel 100, usa por defecto un tunel modo GRE, asi que no hace falta definirlo.

Revisar:

Para probar conexión, un simple Ping podria darnos lo que buscamos


GRE#ping 7.7.7.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.7.7.1, timeout is 2 seconds:
!!!!!


Lab:/home/rollingpaper# tcpdump -i Core2 icmp
tcpdump: WARNING: arptype 778 not supported by libpcap - falling back to cooked socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on Core2, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
11:56:26.704400 IP 7.7.7.2 > 7.7.7.1: ICMP echo request, id 153, seq 0, length 80
11:56:26.708400 IP 7.7.7.2 > 7.7.7.1: ICMP echo request, id 153, seq 1, length 80
11:56:26.710648 IP 7.7.7.2 > 7.7.7.1: ICMP echo request, id 153, seq 2, length 80
11:56:26.712147 IP 7.7.7.2 > 7.7.7.1: ICMP echo request, id 153, seq 3, length 80
11:56:26.713897 IP 7.7.7.2 > 7.7.7.1: ICMP echo request, id 153, seq 4, length 80



Listo Sres, espero que haya sido de ayuda

lunes, 27 de septiembre de 2010

Ejemplos de manipulacion de port forwarding utilizando NAT en routers Cisco

Situacion: 
 Tengo una granja de servidores (ejemplo Web, Mail y SSH) y tengo solo una direccion publica en mi router de borde. 

Escenario: 
    {Internet} --- {RTR con IP publica} ------- {Granja de Servidores} 
IP Publica: 11.12.13.14 
Mail Server: 192.168.1.5 Web Server: 192.168.1.4 
SSH: 192.168.1.6 
IP WAN: 11.12.13.14/30 
IP LAN: 192.168.1.1/24 
  
Solucion: 
 La solucion es configurar en el router Cisco NAT de tal manera de que al momento de recibir un paquete TCP al puerto destino correspondiente sepa a donde enviarlo. En este sentido, es necesario que el router re-envie los paquetes (port forwarding) de la siguiente manera: Paquetes destinados al IP 11.12.13.14 al puerto destino 25 lo envie al Mail Server (192.168.1.5) Paquetes destinados al IP 11.12.13.14 al puerto destino 80 lo envie al Web Server (192.168.1.4) Paquetes destinados al IP 11.12.13.14 al puerto destino 22 lo envie al SSH Server (192.168.1.6) 

Procedimiento: 
 La configuracion del router seria la siguiente: 
  ! ESTA ES LA INTERFAZ QUE DA HACIA LA GRANJA DE SERVIDORES 
interface FastEthernet0 
description Mi granja de servidores 
ip address 192.168.1.1 255.255.255.0 
ip nat inside 
! ! ESTA ES LA INTERFAZ QUE DA HACIA INTERNET 
interface Serial0 
description Hacia Internet 
ip address 11.12.13.14 255.255.255.252 
ip nat outside 
! !En la siguiente linea se indica que todo lo que apunte al IP 11.12.13.14 al puerto 80 lo envie al !servidor web 
ip nat inside source static tcp 192.168.1.4 80 11.12.13.14 80 extendable 
!En la siguiente linea se indica que todo lo que apunte al IP 11.12.13.14 al puerto 25 lo envie al !servidor mail 
ip nat inside source static tcp 192.168.1.5 25 11.12.13.14 25 extendable 
!En la siguiente linea se indica que todo lo que apunte al IP 11.12.13.14 al puerto 22 lo envie al !servidor ssh 
ip nat inside source static tcp 192.168.1.4 22 11.12.13.14 22 extendable 

Tips:
  Un dato muy interesante que es que se puede manipular el puerto. Por ejemplo, supongamos que tenemos un servidor web "escondido" podemos manejarlo con un puerto diferente al 80. Digamos que queremos que la gente desde Internet acceda a nuestro servidor Web utilizando el puerto 61234 podemos hacer lo siguiente: !El usuario desde Internet debe acceder a http://11.12.13.14:61234 ip nat inside source static tcp 192.168.1.4 80 11.12.13.14 61234 extendable Lo anterior es muy util para escoder servicios, ahorrar direcciones IP y darle seguridad a la red. Espero haya sido de tu utilidad, Suerte!

viernes, 24 de septiembre de 2010

Ping utilizando TCL en Cisco

Problema:
  Deseo realizar ping a muchas direcciones IP desde mi router Cisco pero deseo automatizarlo un poco 

  Procedimiento:
  La solución al problema es realizar un pequeño script dentro del router Cisco que recibe como argumento las direcciones IP a las cuales se les desea hacer ping. TCL (Tool Control Languaje) es un lenguaje de scripting utilizado en los IOS "recientes" de Cisco que permiten facilitar parte de la administración 

  Ejemplo del script en TCL:
  foreach address { 192.168.126.10 192.168.126.11 192.168.126.12 192.168.126.13 192.168.126.14 192.168.126.15 192.168.126.16 192.168.126.17 192.168.126.18 192.168.126.19 192.168.126.20 192.168.126.21 192.168.126.22 192.168.126.23 } {ping $i} 

 La salida del comando será la siguiente y lo mejor es que se ejecuta solo hasta hacerle ping a todos los host :) (parte de salida suprimida) Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.126.10, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.126.11, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.126.12, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.126.13, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.126.14, timeout is 2 seconds: !!!!! 

 Espero sea de tu utilidad,

 

Solución a: Error: eth0 interface name is not allowed for R2 node when network mode is not set to none

Problema:   Containerlab devuelve un error similar: Error: eth0 interface name is not allowed for R2 node when network mode is not set to no...