Switching Multicapa y SVI

Aquí estamos  de nuevo. Esta vez nos vamos a meter con una característica de los switches multicapa.

Para empezar definiremos qué es esto de los switches multicapa cuando, es posible, que hasta la fecha nos hayan contado que los switches son equipos de Capa 2 dentro del modelo OSI.  En origen, los switches sí que lo eran, pero como todo en esta vida, las cosas cambian y evolucionan. A veces a mejor, a veces a peor, pero en nuestro caso, y como no podía ser de otra manera, a mejor J. Como ya sabemos, los switches en el sentido tradicional de la palabra, efectúan los envíos de tramas considerando las direcciones MAC de los equipos que tiene conectados a cada una de sus bocas, permitiendo así las comunicaciones de la misma red, subred o VLAN. En el momento que queramos hacerlo contra otros fuera de éstas, por ejemplo una granja de servidores, con otro direccionamiento IP y VLAN (es lo suyo), necesitamos, entonces, un equipo de Capa 3 como puede ser un router o un switch multicapa. En un switch multicapa, la principal diferencia con los de Capa 2, es que ahora ya no se va a considerar la dirección MAC del equipo final sino la IP. Es decir, el direccionamiento de Capa 3; o sea, como lo hace un router. Y claro alguien preguntará ¿y en qué más se diferencian un router y un switch multicapa? Una de ellas es el rendimiento. Un switch multicapa está orientado a entornos LAN, pudiendo ofrecer rendimientos a la velocidad del medio que tengan conectado, ya sea 100 Mbps, 1Gbps o 10 Gbps. Esto se consigue gracias a una electrónica especializada denominada ASIC en lugar de un microprocesador que es lo que emplea un router.  Además como buen switch poseen una densidad de puertos mayor pudiendo ser de 12, 24, 48, puertos con medios de transmisión como cable UTP o Fibra Óptica dependiendo de fabricante, gama, modelo, etc. Y ni qué decir que puesto que son equipos que operan en capa 3 también dispondrán de funciones de enrutamiento, tanto estático como dinámico (OSPF, EIGRP, RIP, etc.).

Ahora bien, si tenemos un switch de estas características ¿cómo los echamos a andar? Esta vez tiraré de Packettracer, simulador de redes de Cisco, y tomaré el de capa de capa 3, el 3560.

Aquí tendremos un par de opciones.

Una de ellas es asignar a cada interfaz física del switch una dirección IP. Para ello deberemos configurar dicho puerto como uno de capa 3 en lugar de capa 2 que es como suelen venir por defecto. Para ello:

Switch>enable

Switch#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

Switch(config)#interface fastEthernet 0/1

Switch(config-if)#no switchport

Switch(config-if)#ip address 192.168.1.1 255.255.255.0

Switch(config-if)#exit

Switch(config)#ip routing 

Una vez que entramos en el modo de configuración de la interfaz con “no switchport” indicamos que ese puerto (fastethernet 0/1) no tendrá capacidades L2 (Layer 2, Capa 2) sino L3. Luego con “ip address 192.168.1.1 255.255.255.0” le asignamos la IP y finalmente con “ip routing” habilitamos la capacidad de enrutamiento entre las distintas interfaces que tenga.

Esta es una opción, pero no la única. La otra es definir interfaces virtuales, lo que se denomina como SVI (Switch Virtual Interface). Una SVI es una interfaz definida en el quipo y asociada a una VLAN concreta. Uno de los requisitos es que tiene que haber un puerto activo en esa VLAN para que la SVI correspondiente se habilite. Un enlace troncal también vale. Aunque sea virtual podremos configurar en ella los mismos protocolos y funcionalidades que a una interfaz física como pueden ser HSRP, VRRP, GLBP, ACL´s, etc.

Para ponerlo en funcionamiento, tenemos que definir las VLANs, crear las SVI correspondientes a cada VLAN y asignar una IP, configurar las interfaces físicas bien en modo troncal o de acceso asociada a una VLAN, y habilitar el enrutamiento como en el paso anterior

Esto es:

Entramos en modo configuración:

Switch>ena

Switch>enable

Switch#conf t

Definimos las VLAN 10 y 20:

Switch(config)#vlan 10

Switch(config-vlan)#name VLAN_10

Switch(config-vlan)#exit

Switch(config)#vlan 20

Switch(config-vlan)#name VLAN_20

Switch(config-vlan)#exit

Configuramos las interfaces físicas:

Switch(config)#interface fastEthernet 0/1

Switch(config-if)#switchport mode access

Switch(config-if)#switchport access vlan 10

Switch(config-if)#exit

Switch(config)#interface fastEthernet 0/2

Switch(config-if)#switchport mode access

Switch(config-if)#switchport access vlan 20

Switch(config-if)#exit

Definimos las SVIs:

Switch(config)#interface vlan 10

Switch(config-if)#

Switch(config-if)#ip address 192.168.10.1 255.255.255.0

Switch(config-if)#exit

Switch(config)#interface vlan 20

Switch(config-if)#ip address 192.168.20.1 255.255.255.0

Switch(config-if)#exit

Habilitamos el enrutamiento:

Switch(config)#ip routing

Otra funcionalidad aparte de la comunicación entre redes,  es utilizarlas para la gestión de los propios equipos mediante protocolos como SSH, Telnet, monitorización, etc. para lo cual deberemos definir también una puerta de enlace para la comunicación con otras redes. No nos debemos olvidar que aún en este caso nuestros equipos de red al estar dotados con una IP aunque sea la de gestión, también puede ser objeto de escaneos de red con objeto de recolectar información, y realizar a posteriori algún tipo de explotación contra alguno de los servicios que puedan correr en ellos.

A continuación os dejo una captura de un escaneo sencillo contra un switch Catalyst 6509 dotado con sistema operativo CatOS.

Como se puede ver nmap lo ha detectado sin problemas. Para evitarlo es aconsejable definir algún tipo de ACL donde se permita algún tipo de tráfico desde una estación central de gestión. Pero eso lo dejamos para otro rato, por hoy lo dejamos.

Seguiremos informando…

Asegurando el enrutamiento Parte I

Dentro de las comunicaciones una de las diferencias que podemos establecer es si éstas se producen entre equipos en la misma red, o no. Es decir, si un equipo con IP 192.168.1.10 /24 se quiere comunicar con otro con IP 192.168.1.20 /24. En estos casos los equipos que intervienen son los switches, considerándolos en su sentido tradicional. Para ello el switch elabora una tabla denominada CAM (Content addressable memory) donde asocia el puerto con la MAC del equipo que está conectado a él, entre otra información como la VLAN configurada en el puerto y una marca de tiempo. Cuando una trama ingresa en el puerto el switch mirará la MAC de destino y la buscará en la CAM para saber por qué puerto la tiene que sacar. Si pasado un tiempo un equipo no genera tráfico el switch borrará esa entrada. Este proceso se genera de forma dinámica, pudiendo realizarse también la asignación puerto-MAC de forma estática, o manual.

Sin embargo cuando tenemos dos equipos situados en redes distintas, por ejemplo uno con IP 192.168.1.10 /24 y otro con 10.10.10.10 /24, la cosa cambia. Ahí necesitaremos de equipos que operen en la capa 3,  bien un router o un switch de capa 3. Es decir, ya no se consideran las direcciones MAC para llevar a cabo la comunicación, sino las direcciones IP. Como digo esta operación la puede llevar a cabo tanto un equipo como otro, en lo que a funcionalidad se refiere. Otra cosa distinta es que en función del diseño, arquitectura, rendimiento, etc. sea más adecuado utilizar uno u otro. En síntesis diremos a groso modo, que un switch de capa 3 ofrece más rendimiento y más densidad de puertos lo cual lo hace adecuado en entornos LAN, dónde se utilizan velocidades y flujos de tráfico más elevados que en  entornos WAN donde ahí si se emplean routers.

 En cualquiera de los casos para que un equipo u otro lleven a cabo operaciones de comunicación se deberán configurar de tal manera que sepan manejar el tráfico para llegue a su destino. Para ello se podrán configurar de forma manual o bien de forma automática empleando algún protocolo de enrutamiento.

 Cuando hablamos de enrutamiento manual, hablamos del enrutamiento estático. Esto es, el administrador decide por dónde debe mandarse los paquetes dirigidos a una red concreta, indicando bien la dirección IP de la interfaz de otro equipo o la interfaz por dónde debe mandase ese paquete. En el siguiente ejemplo estaremos diciendo que todo el tráfico dirigido al  red 192.168.1.0 /24 se envíe a la interfaz de otro router con IP 192.168.2.10/24.

 Router(config)# ip route 192.168.1.0 255.255.255.0 192.168.2.10

En el siguiente ejemplo, diremos que todo el tráfico dirigido a la red 192.168.1.0/24 se “saque” por la interfaz fastethernet 0/1.

Router(config)# ip route 192.168.1.0 255.255.255.0 fastEthernet 0/1

 Luego, a partir de estas configuraciones el equipo generará una tabla de enrutamiento donde figurarán las rutas hacia cada destino. Cuando un paquete llegue a  un equipo de capa 3, éste acudirá a su tabla de enrutamiento y buscará a dónde o por dónde enviarlo. Si no se encuentra ninguna coincidencia ese paquete se descarta ya que no se puede determinar una ruta a ese destino. Es conveniente por tanto, definir una ruta por defecto para que en caso de que esto ocurra el paquete no se pierda. El ejemplo que figura a continuación indicaría que todo el tráfico que no coincida con ninguna entrada en la tabla de enrutamiento se envíe a la IP 192.168.10.1

Router(config)# ip route 0.0.0.0 0.0.0.0 192.168.10.1

Esta configuración tiene sus pros y sus contras como todo. Como contra es que requiere una labor administrativa mayor en el sentido que  hay que definir manualmente las rutas que van a seguir los paquetes ya que hay que configurarlo en cada dispositivo, no siendo ni escalable ni viable en muchos casos. Aparte, si por alguna razón algún nodo cae habría, que reconfigurar para que el tráfico se dirija por otro equipo o enlace que esté operativo. A favor tenemos, que todo está más  controlado, se consumen menos recursos hardware y más seguridad en el sentido que todo el tráfico va por los equipos que nosotros definimos.

Al igual que lo anterior tenemos otra alternativa y es el uso de algún protocolo de enrutamiento. Lo que van a hacer estos protocolos es permitir a los routers o switches de capa 3, informarse entre sí sobre las redes a las que tienen acceso bien de forma directa o por medio de otros routers y poder determinar así, de forma automática, la mejor ruta hacia el destino. Existen distintos tipos de ellos RIP, OSPF, EIGRP, etc. La elección sobre cuál elegir dependerá de muchos factores. Por ejemplo, OSPF es un protocolo estándar el cual nos puede servir para entornos con equipos de distintos fabricantes, aunque requiere de una configuración y diseño de la red bien estudiada. A ver, nada se diseña a la ligera, lo que quiero decir es que es un protocolo que escala muy bien y que su configuración puede llegar a ser compleja. Sin embargo podemos elegir EIGRP si nuestra red está compuesta de equipos sólo de Cisco, ya que este protocolo es más sencillo de configurar, pero nos la tenemos que jugar a un solo fabricante. Por hacer una ilustración sobre cómo funciona uno de estos protocolos, veamos el siguiente ejemplo.

Para que el PC con IP 192.168.1.10 se pueda comunicar con el servidor 192.168.2.10, el Router A le dirá tanto al router B como D que tiene acceso a la red 192.168.1.0/24; para que si a alguno de estos dos últimos le llega un paquete para esta red sepan que se lo deben de mandar al Router A. Igualmente el router C tendrá que anunciar al Router B y D que tiene acceso a la red 192.168.2.0/24 y por tanto si reciben algún paquete a esa red deberán eviarselo a C. A partir de la información facilitada entre cada uno de los routers cada uno de ellos generará, una tabla de enrutamiento donde figurarán las mejores rutas hacia los destinos y a la que acudirán para saber por dónde (interfaz) o a quién  (IP del siguiente router) debe mandar los paquetes.

A continuación se muestra  una simulación de un escenario elaborado con la aplicación PacketTracer.

Como protocolo de enrutamiento he elegido OSPF con una configuración de una sola área.

Router A: 

router ospf 1

 log-adjacency-changes

 network 192.168.1.0 0.0.0.255 area 0

 network 10.10.10.0 0.0.0.255 area 0

 network 10.10.13.0 0.0.0.255 area 0

Router B: 

router ospf 1

 log-adjacency-changes

 network 10.10.10.0 0.0.0.255 area 0

 network 10.10.11.0 0.0.0.255 area 0

Router  C:

router ospf 1

 log-adjacency-changes

 network 192.168.2.0 0.0.0.255 area 0

 network 10.10.11.0 0.0.0.255 area 0

 network 10.10.12.0 0.0.0.255 area 0

Router D:

router ospf 1

 log-adjacency-changes

 network 10.10.12.0 0.0.0.255 area 0

 network 10.10.13.0 0.0.0.255 area 0

Y si hacemos “ping” desde el PC:

PC>ping 192.168.2.10 

Pinging 192.168.2.10 with 32 bytes of data: 

Reply from 192.168.2.10: bytes=32 time=22ms TTL=125

Reply from 192.168.2.10: bytes=32 time=26ms TTL=125

Reply from 192.168.2.10: bytes=32 time=23ms TTL=125

Reply from 192.168.2.10: bytes=32 time=25ms TTL=125

Ping statistics for 192.168.2.10:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 22ms, Maximum = 26ms, Average = 24ms

SI hacemos una traza haca el servidor veremos que los paquetes van a través del Router  B. Si el enlace entre el “A” y el “B” cayese, el protocolo sería capaz de ver que se ha perdido el enlace con “B” y comenzaría a mandar todos los paquetes por “D”.

Aparentemente parece sencillo conseguir que esto funcione y comunique pero como siempre hemos de “pulir” nuestra configuración para que sea más segura y evitar que “alguien”, no con muy buenas intenciones, pueda obtener información de nuestra red a través de anuncios de los protocolos, generar paquetes, etc. y poder sufrir por ejemplo un DoS. Pero eso lo dejamos para la segunda entrega.

Seguiremos informando…

Un saludo.