VPSs y mas.

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

jueves, 23 de marzo de 2017

BGP: Filtrar por tamaño de la red en BGP, he ahí el dilema

Introducción
 El equipo de I+D del área técnica y WARP redactaron en conjunto el presente artículo basado en algunos incidentes gestionados por el centro de respuestas de LACNIC.
 En el mundo de BGP existen decenas de maneras para filtrar prefijos. El objetivo del presente post mostrar una serie de recomendaciones para tener una red más estable, no perder conectividad con ciertos destino y reducir el número de quejas en nuestro NOC.


Situación identificada
  Muchos ISPs no pueden recibir la full routing table de BGP (para el dia de hoy consta de ~610.000 prefijos IPv4) en sus enrutadores.
  Lo anterior puede deberse a diversas razones:
  • El enrutador no posee suficiente RAM para aprender todos los prefijos (además recordar que es posible que el router tenga varias sesiones BGP)
  • Por ahorro de CPU
  • Porque el upstream provider a su vez no entrega toda la tabla de enrutamiento
  • Por simplicidad y sencillez


 Entendiendo la situación e independientemente de la razón que sea, el enrutador no aprende toda la tabla de enrutamiento.


Problema
  No aprender toda la tabla de enrutamiento puede traer algunos inconvenientes parciales pero que al final trae problemas de conectividad, quejas de los usuarios, inconvenientes de acceso a ciertos sitios, entre otros.


¿Por qué?
  Imaginemos la siguiente situación:
  1. Tengo un router (propiedad de EXAMPLE) en Internet que solo aprende la tabla parcial de enrutamiento
  2. El router propiedad de EXAMPLE quedó configurado solo para aprender redes “más grandes” que /21. Es decir, aprende redes /20, /19, /18, etc.  (evidentemente estamos hablando de IPv4)
  3. Debido a la configuración establecida en el punto “b”, el router no aprenderá prefijos de tamaño /21, /22, /23 ni /24
  4. Mientras tanto en otra parte del mundo, le acaban de secuestrar su red /21 a la empresa ACME (planteamos el caso como un secuestro pero podría ser una mala configuración)
  5. ACME decide realizar anuncios más específicos de su red original /21, es decir, anuncia 8 redes /24
  6. Por causa de los filtros configurados por EXAMPLE, nunca verá dichos anuncios /24 de ACME
  7. EXAMPLE seguirá aprendiendo la red /21 del secuestrador de la red. Lo que puede ocasionar que el tráfico hacia ACME puede ser potencialmente secuestrado (repito, se entiende que esta situación es potencial, no necesariamente el tráfico irá hacia el atacante)


Diagrama:
  El siguiente diagrama representa la hipótesis planteada en el punto anterior de manera gráfica para facilitar su comprensión.
Articulo BPG.png

Recomendación
 Realizaremos la siguiente recomendación en base a algunas experiencias vividas, teniendo en cuenta que solo aplican al caso de cuando no se pueda aprender/recibir la tabla completa de BGP:
  1. No filtrar permitiendo redes menos específicas. Es conveniente aprender redes más chicas, es decir: /24, /23, /22.
  2. Filtrar por AS_PATH de profundidad.
  3. Crear los ROAs respectivos a los prefijos (RPKI).


Algunos ejemplos (Cisco like)
1)  Solo queremos aprender redes entre /22 y /24 (hay otras maneras de hacer esto):

router bgp 65002
neighbor 10.0.0.1 remote-as 65001
neighbor 10.0.0.1 route-map FILTRO-IN in
!
ip prefix-list REDESCHICAS seq 5 permit 0.0.0.0/0 ge 22 le 24
!
route-map FILTRO-IN permit 10
match ip address prefix-list REDESCHICAS
!


2) Solo queremos aprender dos AS de profundidad (hay otras maneras de hacer esto):


router bgp 65001
neighbor 10.0.0.2 remote-as 65002
neighbor 10.0.0.2 route-map ASFILTER-IN in
!
ip as-path access-list 5 permit ^[0-9]+_$
ip as-path access-list 5 permit ^[0-9]+ [0-9]+_$
!
route-map ASFILTER-IN permit 10
match as-path 5
!


Mas información



Autores
- Dario Gomez
- Alejandro Acosta (@ITandNetworking)

domingo, 1 de enero de 2017

Como la navidad puede dañar una red (experiencia real, BTW adoro la navidad)

Hola,
  En este oportunidad voy a contar una experiencia que tuve unos años atrás. Creo que esta vivencia me vino a la cabeza luego de enterarme del Arbol de Navidad controlado por IPv6 [1]

Introducción:
  Alrededor del año 2011 estuve trabajando en una oficina donde ese mismo año se había instalado una red LAN la cual mediante un pequeño enlace DSL llegaba al core de la red de la organización y además se conectaba a Internet.

Sobre el comportamiento general de la red
  Transcurrían los meses desde Junio a Diciembre y la red funcionaba perfectamente, los usuarios satisfechos con el rendimiento, velocidad, aplicaciones entre otros.

Sobre la topología:
  La oficina (ramal) se conectaba mediante un enlace DSL propio (utilizando los mismos pares de cobre de unas lineas telefónicas del edificio), los modems DSL tenían un puerto UTP el cual conectábamos a un LAN Switch Cisco moderno. Como comentario adicional, también manejábamos algunas VLANs para algunos servicios (VoIP).
  La oficina contaba con una cámara de seguridad HD la cual transmitía a un servidor central ubicado en el core de la red (no en la misma oficina).

_______       __________       __________
|Oficina | ---- Enlace DSL   | ---- | Core Office   |
|_____|       |_________ |      |__________|




La llegada de la navidad
  Al igual que en la mayoría de las oficinas y hogares, en la oficina se decidió colocar su respectivo árbol de navidad en la entrada, justo en la puerta principal.
  El árbol fue adornado con sus respectivos ornamentos navideños tales como: bambalinas, micro arbolitos, casitas, cascanueces, estrellas y por supuesto sus luces a lo largo del árbol que titilaban constantemente.


¿Qué ocurrió y como la navidad "dañó" la red?
  Las cámaras mencionabas anteriormente se encontraban apuntando hacia la entrada de la oficina y al igual que muchas otras cámaras y sistemas de CCTV solo transmitían los cambios de la imagen (o lo que es mismo cuando había algún movimiento) al servidor central, es decir, si no habían cambios de pixels en donde apuntaba la cámara, el consumo de ancho de banda era mínimo o casi nulo. Favor recordar que el receptor de la imagen era un servidor central ubicado al otro extremo del enlace DSL y no propiamente en la oficina donde se instaló el árbol.

Para finalizar:
  Entendiendo que un enlace DSL no es de muy alta velocidad y las cámaras son HD el problema puntualmente fue que colocaron el árbol de navidad con sus luces intermitentes junto a la entrada de la oficina, por ende la cámara alcanzaba el mismo haciendo que tuviese que transmitir constantemente al servidor central los cambios de la imagen, es decir, cualquier movimiento en el árbol tal como las luces intermitentes!.

Saludos,

[1] http://ipv6tree.bitnet.be/
[2] Imagen tomada de: http://www.publicdomainpictures.net/pictures/60000/velka/christmas-tree-by-the-fire-place.jpg




martes, 26 de julio de 2016

lunes, 7 de diciembre de 2015

Configurando una red con DHCPv6 Server (Cisco), DHCPv6 relay (Linux - ISC) y como CPE un Router Cisco

Introducción
  Este post es muy similar al encontrado en:  http://blog.acostasite.com/2015/11/configurando-una-red-con-dhcpv6-server.html
  La principal diferencia es que en esta oportunidad tendremos el DHCPv6 Server en Cisco y no en Linux
  En el presente post vamos a explicar e implementar como trabajar con DHCPv6 Server, Relay y Cliente.
  Favor leer la sección: "Explicación de la topología" la cual indica cada función


Topología




Explicación de la topología

En la topología de arriba va a ocurrir lo siguiente:

- El Cisco DHCPv6 Server está entregando prefijos v6
- El DHCPv6 Relay (Debian) va a escuchar por la interfaz ethernet1 (e1) por peticiones DHCPv6 de Prefix Delegation (PD). Las mismas serán reenviadas por la interfaz ethernet0 (e0) al servidor DHCPv6 Server
- El Cisco Router DHCPv6 Client va a hacer solicitudes DHCPv6 PD en su interfaz f1/0, del prefijo recibido va a configurar su interfaz f0/0 y enviar Router Advertisements por dicha interfaz permitiendo a los clientes auto-configurarse. En esta oportunidad también configuraremos otras interfaces pero solo a manera de ejemplo.
- Los clientes conectados a la interfaz f0/0 en el Cisco DHCPv6 Cliente van a autoconfigurarse vía SLAAC utilizando el prefijo recibido por RA

  Nótese que para el Router Cisco DHCPv6 Client le es transparente el DHCPv6 Relay Server


Que necesitamos:

- Del lado del Relay el software Relay de DHCPv6 de ISC (que es diferente al server)
- El Router tiene que ser un enrutador que haga DHCPv6 cliente PD

Instalando
En el Relay Server:
  #sudo apt-get install isc-dhcp-relay

  Durante la instalación del relay se van a realizar varias preguntas. Puedes decidir contestarlas o no. Para este post no es necesario responderlas.


Configuraciones:

Del lado del Cisco DHCPv6 Server:

ipv6 unicast-routing
interface FastEthernet0/0
 ipv6 address 2001:DB8::1/64
 ipv6 dhcp server DHCPv6-SERVER
end

ipv6 dhcp pool DHCPv6-SERVER
 prefix-delegation pool MY-PD-1

ipv6 local pool MY-PD-1 2001:DB8:ABCD::/48 56


Explicando la configuración:
Primero se le indica al equipo que puede enrutar paquetes IPv6. Luego se configura IPs estáticas entre el relay y la interfaz f0/0 (revisar la ethernet0 del relay).
Luego, se le indica que la interfaz sirve como DHCPv6 Server y se le asigna el pool DHCPv6-Server, aquí podemos escribir cualquier nombre.

Dentro del pool DHCPv6-Server se le dice que haga prefix-delegation (se le puede indicar más información pero para nuestro propósito hasta aquí es suficiente) y que utilice un pool local llamado MY-PD-1. Este pool va a utilizar prefijos dentro de 2001:DB8:ABCD::/48 y entregará bloques /56 a sus clientes. Aquí podemos indicar el tamaño de prefijo que queremos.


Del lado del relay:
Red:
  #ifconfig eth0 inet6 add 2001:db8::2/64
  #ifconfig eth1 inet6 add 2001:db8:1::2/64

  No hay configuraciones. El relay es levantado con este comando:
  #dhcrelay -I -l eth1 -u eth0

Explicación del comando para ejecutar el dhcp-relay:
Hay muchas maneras y opciones para dhcrelay, en el comando anterior se esta diciendo: que se utilice el DHCPv6 interface-id option, que escuche peticiones por eth1 y las mismas sean enviadas por eth0


Del lado del Cisco Router DHCPv6 Cliente:

ipv6 unicast-routing
interface FastEthernet1/0
 description Hacia DHCPv6 Relay Server
 ipv6 address 2001:DB8:1::1/64
 ipv6 dhcp client pd IP-FROM-DHCPv6-SERVER
end

interface FastEthernet0/0
 description Hacia LAN
 ipv6 address IP-FROM-DHCPv6-SERVER ::1/64
end

Explicación de la configuración del router Cisco:
Primero se habilita el routing IPv6 en el equipo.
Segundo, en la interfaz F1/0 se le esta diciendo al router que es DHCP cliente para prefijos y le asignamos el nombre: IP-FROM-DHCPv6-SERVER
Tercero, en la interfaz f0/0 le indica al router que utilice el prefijo recibido via DHCPv6 client y asigne el mismo a la interfaz como ::1/64. Es decir, el router toma el /56 del DHCPv6 y el mismo router va a crear una /64 para f0/0 (nota que puedes configurar otras interfaces utilizando el mismo prefijo recibido por el DHCP). 


Para revisar:
Del lado del DHCPv6 Server deberiamos ver algo como:

a) Con el DHCPv6 server corriendo en foreground puedes ver:

DHCP-Server#debug ipv6 dhcp detail

Se veran mensajes como:

*Dec  1 09:55:14.619: IPv6 DHCP: Received RELAY-FORWARD from 2001:DB8::2 on FastEthernet0/0
*Dec  1 09:55:14.623: IPv6 DHCP: detailed packet contents
*Dec  1 09:55:14.623:   src 2001:DB8::2 (FastEthernet0/0)
*Dec  1 09:55:14.627:   dst FF05::1:3
*Dec  1 09:55:14.627:   type RELAY-FORWARD(12), hop 0
*Dec  1 09:55:14.627:   link 2001:DB8:1::2
*Dec  1 09:55:14.631:   peer FE80::C801:24FF:FE20:1C
*Dec  1 09:55:14.631:   option INTERFACE-ID(18), len 4
*Dec  1 09:55:14.635:     0x01000000
*Dec  1 09:55:14.639:   option RELAY-MSG(9), len 50
*Dec  1 09:55:14.639:     type SOLICIT(1), xid 2389101
*Dec  1 09:55:14.643:     option ELAPSED-TIME(8), len 2
*Dec  1 09:55:14.643:       elapsed-time 0
*Dec  1 09:55:14.647:     option CLIENTID(1), len 10
*Dec  1 09:55:14.647:       00030001CA0124200000
*Dec  1 09:55:14.647:     option ORO(6), len 6
*Dec  1 09:55:14.651:       IA-PD,DNS-SERVERS,DOMAIN-LIST
*Dec  1 09:55:14.655:     option IA-PD(25), len 12
*Dec  1 09:55:14.659:
DHCP-Server# IAID 0x00040001, T1 0, T2 0
*Dec  1 09:55:14.663: IPv6 DHCP: Using interface pool DHCPv6-SERVER
*Dec  1 09:55:14.667: IPv6 DHCP: Source Address from SAS 2001:DB8::1


b) DHCP-Server#sh ipv6 dhcp binding
Client: FE80::C801:24FF:FE20:1C
  DUID: 00030001CA0124200000
  Username : unassigned
  Interface : relayed
  IA PD: IA ID 0x00040001, T1 302400, T2 483840
    Prefix: 2001:DB8:ABCD::/56
            preferred lifetime 604800, valid lifetime 2592000
            expires at Dec 31 2015 09:55 AM (2589331 seconds)


Del lado del Cliente DHCPv6 Cisco:
Para revisar si la interfaz f0/0 se autoconfiguró cone l prefijo recibido por el DHCPv6:
a) R1#show ipv6 interface f0/0

Vamos a ver algo como:

R1#sh ipv6 int f0/0
FastEthernet0/0 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::C801:24FF:FE20:0
  No Virtual link-local address(es):
  Description: Hacia LAN
  General-prefix in use for addressing
  Global unicast address(es):
    2001:DB8:ABCD::1, subnet is 2001:DB8:ABCD::/64 [CAL/PRE]


Nótese que 2001:DB8:ABCD::/64 corresponde al prefijo configurado en el DHCPv6 Server que es entregado vía PD


Algo muy importante es el comando:

b) R1#show ipv6 dhcp

El cual muestra el DUID (DHCPv6 Unique ID) del equipo (RFC3315):
This device's DHCPv6 unique identifier(DUID): 00030001CA0124200000


Podemos apreciar que este mismo número es que le llega al DHCPv6 Server


Del lado del cliente:
Depende de tu OS puedes hacer:
c:\ipconfig 

o

#ifconfig


¿Si hay más de una interfaz del lado del cliente?
En el ejemplo anterior el Cisco DHCPv6 Cliente está recibiendo un prefijo /56, esto quiere decir que tenemos hasta 8 redes /64 para crear. Hasta el momento solo hemos utilizado una en la f0/0.

De manera de ejemplo vamos a crear otras redes en las interfaces loopback0 y looback1 del router del lado del cliente.

interface Loopback0
 ipv6 address IP-FROM-DHCPv6-SERVER ::1:0:0:0:1/64
end

interface Loopback1
 ipv6 address IP-FROM-DHCPv6-SERVER ::2:0:0:0:1/64
end


La manera de construir los pseudo IPs (pe. ::1:0:0:0:1/64) colocados en la interfaz es la siguiente:
Imaginamos el prefijo recibido por DHCPv6, sabemos que es un /56. Lo que estamos haciendo es completando el resto del IP. 

Es decir: recibimos por DHCPv6 2001:db8:ABCD::/56. Al decirle a la loopback 1 ::1:0:0:0:1/64 construimos:  2001:db8:ABCD::1:0:0:0:1/64 (Prefijo recibido + la configuracion de la interfaz)


Vamos a revisar que IPs tienen entonces L0 y L1:

R1#sh ipv6 int l0
Loopback0 is up, line protocol is up
  Global unicast address(es):
    2001:DB8:ABCD:1::1, subnet is 2001:DB8:ABCD:1::/64 [CAL/PRE]


R1#sh ipv6 int l1
Loopback1 is up, line protocol is up
  Global unicast address(es):
    2001:DB8:ABCD:2::1, subnet is 2001:DB8:ABCD:2::/64 [CAL/PRE]


Proximos pasos
- Falta la parte de routing, hay muchas maneras de hacerlo, indiscutiblemente la intención es hacerlo con un protocolo de enrutamiento dinámico


Para más información:
https://tools.ietf.org/html/rfc6355
http://www.cisco.com/c/en/us/support/docs/ip/ip-version-6-ipv6/113141-DHCPv6-00.html
http://blog.acostasite.com/2014/04/instalar-isc-dhcp-43-en-linux-ubuntu.html
http://blog.acostasite.com/2014/04/solucion-tres-errores-cuando-queremos.html
http://blog.acostasite.com/2015/11/configurando-una-red-con-dhcpv6-server.html

lunes, 30 de noviembre de 2015

Configurando una red con DHCPv6 Server (ISC), DHCPv6 relay (ISC) y como CPE un Router Cisco

Introducción
  En el presente post vamos a explicar e implementar como trabajar con DHCPv6 Server, Relay y Cliente.
  Favor leer la sección: "Explicación de la topología" la cual indica cada función


Topología








Explicación de la topología

En la topología de arriba va a ocurrir lo siguiente:

- El Ubuntu DHCPv6 Server está entregando prefijos v6
- El DHCPv6 Relay va a escuchar por la interfaz ethernet1 (e1) por peticiones DHCPv6 de Prefix Delegation (PD). Las mismas serán reenviadas por la interfaz ethernet0 (e0) al servidor DHCPv6 Server
- El Cisco Router va a hacer solicitudes DHCPv6 PD en su interfaz f1/0, del prefijo recibido va a configurar su interfaz f0/0 y enviar Router Advertisements por dicha interfaz permitiendo a los clientes auto-configurarse
- El cliente se va a autoconfigurar utilizando el prefijo recibido por RA

  Nótese que para el Router Cisco le es transparente el DHCPv6 Relay Server


Que necesitamos:
- Del lado del server el servidor de ISC DHCPv6
- Del lado del ralay el relay de DHCPv6 de ISC (que es diferente al server)
- El Router tiene que ser un enrutador que haga DHCPv6 cliente PD

Instalando
En el Server Linux:
  #sudo apt-get install isc-dhcp-server
 
En el Relay Server:
  #sudo apt-get install isc-dhcp-relay

  Durante la instalación del relay se van a realizar varias preguntas. Puedes decidir contestarlas o no. Para este post no es necesario responderlas.


Configuraciones:

Del lado del Server:
Red:
#ifconfig eth1 ine6 add 2001:db8::2/64
#route -A inet6 add default gw 2001:db8::1

en /etc/dhcp/dhcpd.conf

default-lease-time 600;
max-lease-time 7200;
log-facility local7;
subnet6 2001:db8::/32 {

  #Prefix range for PD
  prefix6 2001:db8:1:100:: 2001:db8:1:f00 /56;

}


Explicacion de la configuracion dhcpd.conf:
La parte mas importante de la configuracion de arriba es la linea "prefix6" donde se indica el prefijo inicial y final /56 que los clientes van a recibir.

Para levantar el servicio de DHCPv6:
# /usr/sbin/dhcpd -6 -d -cf /etc/dhcp/dhcpd.conf eth0

Del lado del relay:
Red:
  #ifconfig eth0 inet6 add 2001:db8::2/64
  #ifconfig eth1 inet6 add 2001:db8:1::2/64

  No hay configuraciones. El relay es levantado con este comando:
  #dhcrelay -I -l eth1 -u eth0

Explicación del comando para ejecutar el dhcp-relay:
Hay muchas maneras y opciones para dhcrelay, en el comando anterior se esta diciendo: que se utilice el DHCPv6 interface-id option, que escuche peticiones por eth1 y las mismas sean enviadas por eth0


Del lado del Cisco Router:

ipv6 unicast-routing
interface FastEthernet1/0
 description Hacia DHCPv6 Relay Server
 ipv6 address 2001:DB8:1::1/64
 ipv6 dhcp client pd IP-FROM-DHCPv6-SERVER
end

interface FastEthernet0/0
 description Hacia LAN
 ipv6 address IP-FROM-DHCPv6-SERVER ::1/64
end

Explicación de la configuración del router Cisco:
Primero se habilita el routing IPv6 en el equipo.
Segundo, en la interfaz F1/0 se le esta diciendo al router que es DHCP cliente para prefijos y le asignamos el nombre: IP-FROM-DHCPv6-SERVER
Tercero, en la interfaz f0/0 le indica al router que utilice el prefijo recibido via DHCPv6 client y asigne el mismo a la interfaz como ::1/64. Es decir, el router toma el /56 del DHCPv6 y el mismo router va a crear una /64 para f0/0 (nota que puedes configurar otras interfaces utilizando el mismo prefijo recibido por el DHCP). 


Para revisar:
Del lado del DHCPv6 Server deberiamos ver algo como:

a) Con el DHCPv6 server corriendo en foreground puedes ver:

Relay-forward message from 2001:db8::2 port 547, link address 2001:db8:1::2, peer address fe80::c801:24ff:fe20:1c
Picking pool prefix 2001:db8:1:f00::/56
Advertise PD: address 2001:db8:1:f00::/56 to client with duid 00:03:00:01:ca:01:24:20:00:00 iaid = 262145 valid for 600 seconds
Wrote 0 NA, 0 TA, 1 PD leases to lease file.
Sending Relay-reply to 2001:db8::2 port 547
Relay-forward message from 2001:db8::2 port 547, link address 2001:db8:1::2, peer address fe80::c801:24ff:fe20:1c
Reply PD: address 2001:db8:1:f00::/56 to client with duid 00:03:00:01:ca:01:24:20:00:00 iaid = 262145 valid for 600 seconds
Sending Relay-reply to 2001:db8::2 port 547

b) Para revisar los leases:
# more /var/lib/dhcp/dhcpd6.leases


Del lado del router Cisco:
Para revisar si la interfaz f0/0 se autoconfiguró cone l prefijo recibido por el DHCPv6:
a) R1#show ipv6 interface f0/0


Vamos a ver algo como:

R1#sh ipv6 interface f0/0
FastEthernet0/0 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::C801:24FF:FE20:0
  No Virtual link-local address(es):
  Description: Hacia LAN
  General-prefix in use for addressing
  Global unicast address(es):
    2001:DB8:1:F00::1, subnet is 2001:DB8:1:F00::/64 [CAL/PRE]


Nótese que 2001:db8:1:f00/64 corresponde al prefijo configurado en el DHCPv6 Server que es entregado vía PD


Algo muy importante es el comando:

b) R1#show ipv6 dhcp

El cual muestra el DUID (DHCPv6 Unique ID) del equipo (RFC3315):
This device's DHCPv6 unique identifier(DUID): 00030001CA0124200000


Podemos apreciar que este mismo número es que le llega al DHCPv6 Server


Del lado del cliente:
Depende de tu OS puedes hacer:
c:\ipconfig 

o

#ifconfig


Proximos pasos
- Falta la parte de routing, hay muchas maneras de hacerlo, indiscutiblemente la intención es hacerlo con un protocolo de enrutamiento dinámico
- En el próximo Post haremos exactamente lo mismo pero con el DHCPv6 Server que sea una caja Cisco.


Para más información:
- https://tools.ietf.org/html/rfc6355
- http://www.cisco.com/c/en/us/support/docs/ip/ip-version-6-ipv6/113141-DHCPv6-00.html
http://blog.acostasite.com/2014/04/instalar-isc-dhcp-43-en-linux-ubuntu.html
http://blog.acostasite.com/2014/04/solucion-tres-errores-cuando-queremos.html



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):



















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