Puertos e interfaces en un switch multilayer

Cuando abordamos el estudio de los switches, y particularmente los llamados switches multilayer, es conveniente organizar claramente los conceptos para tener una comprensión adecuada de las diferentes operaciones que se realizan en el dispositivo.

Es por esto que consideré conveniente dedicar atención a las diferentes interfaces y puertos que presentan estos dispositivos.

En primer lugar debemos tener presente que cada puerto tiene su correspondiente interfaz. Estas interfaces pueden ser interfaces capa 2 o interfaces capa 3 según participen de procesos de reenvíos de tramas (capa 2) o de paquetes (capa 3).

Interfaces capa 2

Se trata de interfaces que participan del reenvío de tramas a partir de la dirección MAC de destino de cada trama y tomando en consideración la tabla de direcciones MAC del switch.

Estas interfaces, por ser capa 2, no admiten la configuración de direccionamiento capa 3.

Hay diferentes interfaces capa 2:

• Puertos de acceso.
  Se trata de puertos asociados a una VLAN que está definida como VLAN del puerto.
  Los puertos de acceso pueden participar de una única VLAN y ocasionalmente (cuando el diseño lo requiere) de una VLAN auxiliar o VLAN de voz.
  Su encapsulación es Ethernet.
  Un ejemplo de configuración:
  
  Switch(config)#interface GigabitEthernet 1/0/1
  Switch(config-if)#switchport mode access
  Switch(config-if)#switchport nonegotiate
  Switch(config-if)#swtichport access vlan 10
  
  
• Puertos troncales.
  Son puertos en capacidad de transportar tráfico de múltiples VLANs manteniendo su pertenencia a cada VLAN.
  Para mantener identificada esa pertenencia a cada VLAN de cada trama se utiliza un protocolo de etiquetado de tramas: IEEE 802.1Q.
  Todo puerto troncal que implementa 802.1Q incluye una VLAN que no es etiquetada y que recibe el nombre de VLAN nativa. En el caso de los switches Catalyst la VLAN nativa por defecto es la VLAN 1; esto puede cambiarse por configuración.
  Estos puertos, por defecto, transportan todas las VLANs definidas en el switch y es posible por configuración limitar cuáles son las VLANs transportadas.
  Un ejemplo de configuración:
  
  Switch(config)#interface GigabitEthernet 1/0/10
  Switch(config-if)#switchport mode trunk
  Switch(config-if)#switchport trunk encapsulation dot.1q
  Switch(config-if)#switchport trunk allowed vlan 10, 20
  Switch(config-if)#swtichport trunk native vlan 999

Una VLAN no es una interfaz.

Una VLAN es una red lógica o virtual cuyo tráfico circula de modo independiente (a nivel de capa 2) del de otras VLANs que operan sobre la misma red física.

Las VLANs no tienen necesariamente asociada una interfaz VLAN.

Interfaces capa 3

Son interfaces que participan del reenvío de paquetes IP a partir de la dirección IP de destino de cada paquete y tomando en cuenta las rutas que se encuentran definidas en la tabla de enrutamiento IP.

Estas interfaces por ser capa 3 requieren la configuración de direccionamiento IP, sea IPv4 y/o IPv6.
No admiten la configuración de VLANs de acceso o troncales ya que se trata de interfaces de capa 3, y estos features son features de capa 2.

En los switches multilayer a 2 tipos de interfaces capa 3:

• Interfaces VLAN.
  Se trata de interfaces lógicas que operan como gateway del segmento IP que se identifica que con una VLAN determinada.
  El ID de la interfaz VLAN corresponde al mismo ID de la VLAN.
  Requieren la configuración de una dirección IP que operará como default gateway de las terminales conectadas a los puertos de la misma VLAN.
  Estas interfaces, por ser interfaces lógicas, no requieren que se las habilite administrativamente ya que se encuentran habilitadas por defecto.
  Un ejemplo de configuración:
  
  Switch(config)#ip routing
  Switch(config)#interface vlan 10
  Switch(config-if)#ip address 10.10.10.1 255.255.255.0
  
  
• Interfaces o puertos ruteados.
  Se trata de puertos cuya interfaz se habilita para operar como interfaz de capa 3. Los puertos de los switches Catalyst (independientemente de que sean switches multilayer) tienen asociadas interfaces de capa 2 por defecto, por est
  Estos puertos no pueden ser parte de troncales, participar de VLANs o integrar un link aggregation de capa 2.
  No admiten la configuración de subinterfaces.
  Un ejemplo de configuración:
  
  Switch(config)#ip routing
  Switch(config)#interface GigabitEthernet 1/0/20
  Switch(config-if)#no switchport
  Switch(config-if)#ip address 10.10.10.1 255.255.255.0
  
  

Estás invitado a participar de nuestro grupo en Facebook:

https://www.facebook.com/groups/librosnetworking/

O si preferís redes sociales con mayor control de tu privacidad,
podés participar de nuestro grupo en VKontakte
https://vk.com/libros.networking

o seguir las principales novedades en el grupo de Telegram:
https://t.me/LibrosNetworking

Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en

 el Glosario de Siglas y Términos de Networking

que está disponible en la Librería en Línea de EduBooks.

 

 

 

Gestión de la configuración

Contenido incluido
en el temario de
CCNA 200-301

Se da esta denominación a la práctica de definir el rendimiento, los atributos funcionales y físicos de un producto y luego garantizar la coherencia de la "configuración" del sistema a lo largo de su trayectoria. 

Con este propósito se pueden implementar herramientas de gestión de la configuración (CMT). Estas herramientas se han utilizado tradicionalmente en el ámbito de los sistemas para la implementación de servidores y aplicaciones; ahora se utilizan también como herramientas de automatización de la gestión de la configuración de los dispositivos para mejorar las operaciones de red. Estas herramientas no son nuevas. Lo novedoso es cómo su uso en redes está cambiando la forma en que se gestionan las infraestructuras.

Las herramientas de gestión de la configuración ofrecen algunos beneficios:

• Se automatiza el aprovisionamiento y la implementación de aplicaciones e infraestructura.
• No requieren conocimientos de programación: hay herramientas que implementan un modelo declarativo (intención). No requieren conocimientos de scripting.
• Aprovechan las prácticas comunes en el desarrollo de software para realizar implementaciones, incluyendo las prácticas de control y las pruebas de versiones
• Las herramientas más comunes son: Puppet, Ansible y Chef.

Desde la perspectiva de la gestión de la red es habitual implementar cambios manualmente. Estos cambios tienen diferente gravedad e impacto, puede ser tanto la creación de una nueva VLAN en un centro de datos o campus, como la implementación de cambios diarios en las políticas de firewall para cada una de las nuevas aplicaciones que se implementan. Cuando en la organización se ha definido un flujo de trabajo manual para realizar un conjunto de tareas, se deben usar las herramientas adecuadas para automatizar ese flujo de tareas. No tiene sentido pasar una hora realizando un cambio que puede ejecutarse en solo unos minutos y con menor probabilidad de errores si se utiliza una herramienta diseñada correctamente. Este proceso o flujo de tareas es donde las herramientas de código abierto como Puppet, Chef y Ansible pueden reducir drásticamente la cantidad de interacciones manuales con la red.

• Puppet: https://puppet.com/
• Chef: https://www.chef.io/products/chef-infra
• Ansible: https://www.ansible.com/

Con herramientas para la gestión de la configuración se pueden definir y aplicar configuraciones relacionadas con operaciones a nivel del sistema (por ejemplo, autenticación, registro, imagen), configuración a nivel de interfaz (por ejemplo, VLANs, QoS, seguridad), configuraciones de enrutamiento (por ejemplo, especificaciones OSPF o BGP) y más.

Estas herramientas a menudo se denominan herramientas DevOps. Son más específicamente herramientas de automatización y administración de la configuración y son utilizadas por aquellas organizaciones que han implementado alguna forma de prácticas de DevOps como el control y las pruebas de versiones. Permiten automatizar aplicaciones, infraestructura y redes en alto grado sin la necesidad de realizar programación manual utilizando un lenguaje de programación como Python. No solo reducen el tiempo necesario para realizar determinadas tareas, también ofrecen una mayor previsibilidad.

Una arquitectura habitual de los sistemas CMT consiste en un servidor central, donde se define un estado requerido o previsto del sistema, al que se asocia  una serie de dispositivos de red sobre los que se aplica ese estado y debe hacerse cumplir.

Implementaciones con o sin agente

Para la gestión automatizada de la configuración de los dispositivos hay dos modelos posibles.

1- Modelo basado en la intención

En un servidor central se define el estado requerido o deseado de los sistemas y los agentes implementados en cada sistema o dispositivo se ocupan de plasmar ese estado deseado.

Su despliegue requiere la implementación de un agente en cada dispositivo de la red.

Es el modelo implementado por Puppet y Chef.

La arquitectura es uniforme para todos los dispositivos de destino que admitan el agente:

• Un software de control (Puppet Master o Chef Server) define el objetivo a conseguir en los dispositivos destino.
• En cada dispositivo un agente de software monitorea el estado de la configuración real del dispositivo.
  El agente interactúa con el servidor para informar el estado real y recibir el estado deseado. Si hay diferencia entre ambos estados el agente ejecuta lo necesario para hacer cumplir el objetivo.

2- Modelo basado en CLI y SSH.

Se basa en las técnicas tradicionales a partir de plantillas y grupos de comandos reutilizables para lograr escalabilidad.

No requiere de la instalación de ningún agente o cliente en cada dispositivo de la red.

La operación se realiza a través de un shell remoto al que accede un servidor de gestión o máster que utiliza un modelo push para entregar a través de la red la información a implementar en forma de script.

Es el modelo implementado por Ansible.

En este caso el estado de configuración objetivo se define en los playbooks de Ansible.

Los playbooks son archivos de configuración basados en texto que definen cómo se deben usar los módulos de Ansible. Ansible interpreta el contenido de los playbooks y utiliza los módulos para aprovisionar los dispositivos de destino. Para los dispositivos de Cisco estos comandos se ejecutan a través de CLI.

Su ventaja principal es que no requiere la instalación de un agente; pero es crítica la configuración de seguridad del dispositivo ya que puede limitar la posibilidad de acceder al mismo.

Ambas implementaciones coinciden en la capacidad de utilizar un único conjunto de herramientas para configurar todos los dispositivos de la infraestructura. Esto implica que todo el ciclo de vida de la implementación de una aplicación se puede definir y gestionar desde un solo punto, con una misma herramienta.

Unificar la configuración de todos los elementos de la infraestructura en un único conjunto de herramientas aumenta la eficiencia y la agilidad, al tiempo que reduce los costos.

Estás invitado a participar de nuestro grupo en Facebook:
https://www.facebook.com/groups/librosnetworking/

O si preferís redes sociales con mayor control de tu privacidad,
podés participar de nuestro grupo en VKontakte
https://vk.com/libros.networking

o seguir las principales novedades en el grupo de Telegram:
https://t.me/LibrosNetworking

Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en

 el Glosario de Siglas y Términos de Networking

que está disponible en la Librería en Línea de EduBooks.