Cuando configuramos un puerto de capa 2 de un switch multilayer y lo convertimos en uno de capa 3 con el comando "no switchport", inmediatamente el equipo asigna la vlan 1006 para uso interno.
Configuramos el puerto:
interface Ethernet0/0
no switchport
Al meter el comando "show vlan internal usage" nos aparece la vlan 1006 asignada al puerto de capa 3 que acabamos de hacer.
Si le asignaramos a ese puerto una dirección ip:
interface Ethernet0/0
no switchport
ip address 10.0.0.1 255.255.255.0
end
sería como si configuraramos en el equipo lo siguiente:
vlan 1006
!
interface vlan 1006
ip address 10.0.0.1 255.255.255.0
!
interface Ethernet0/0
switchport
switchport mode access
switchport access vlan 1006
Parece como si el equipo nos estuviera escondiendo esta información. Hay que tenerla en cuenta, porque si conectaramos otro switch que usa la vlan 1006, nuestro equipo no sería capaz de pasarla porque ahora está asignada para uso interno.
Hay un comando que nos dice la política del equipo respecto al uso interno de las vlans:
- (config)#vlan internal allocation policy ascending
Podemos configurar para que vaya hacia abajo y empezaría en la 4094 :
MLswitch(config)#vlan internal allocation policy descending
MULTILAYER NEXUS
En los Nexus tenemos que comprobar que vlans podemos utilizar, ya que existe un rango amplio que son para uso interno y que nos podría crear problemas a la hora de transportar vlans.
VLANS
Cuando creamos una vlan, automáticamente se crea en la DCAM y la instancia de Spanning Tree para esa vlan.
Como ya sabemos podemos crear de dos maneras las vlans:
- (config)#vlan X
- (config-if)#switchport access vlan X
Hay un caso que no nos dejaría crear la vlan y es cuando el switch está configurado en el modo VTP CLIENT. Hay que tenerlo en cuenta para el troubleshooting.
 |
| No está creada la vlan 50 |
Nota: comando para resetear un interface "(config-if)#default interface X"
Respecto al protocolo DTP, hay que saberse este cuadro:
 |
| En muchos modelos, DTP viene habilitado por decfecto |
Para deshabilitar DTP en un puerto:
- switchport nonegotiate
- switchport mode access
- switchport mode dot1q-tunnel (para transportar varias etiquetas)
NATIVE VLAN 1 MINIMIZATION
Para reducir el riesgo de bucles STP o tormentas, podemos deshabilitar la vlan 1 en cada puerto trunk eliminándola de la lista permitida (allowed list). Cuando la eliminamos de un puerto trunk, el tráfico de gestión que usa la vlan 1, como el CDP, VTP, LACP, STP, UDLD, seguira pasando.
Al remover la vlan 1 de la lista permitida, vemos que sigue siendo la nativa por defecto pero ahora no está permitida para pasar tráfico de datos por el trunk.
Recordad el uso de la vlan nativa. Podemos asignar la vlan que queramos, no tiene porqué ser la 1. Eso sí, si la cambiamos en un puerto trunk, el switch que tengamos al otro lado tendrá que tener en ese puerto la misma vlan nativa porque si no, daría conflicto y las DCAM de cada switch no se rellenarían de forma correcta haciendo imposible la comunicación entre las vlans.
Tenemos dos PC's en la vlan 20 conectados a switches diferentes y, estos conectado por un trunk. La configuración es la básica en ambos switches:
interface Ethernet3/3
switchport trunk encapsulation dot1q
switchport mode trunk
end
interface Ethernet3/0
switchport access vlan 20
switchport mode access
end
Hacemos un ping para comprobar la comunicación entre PC's:
Ambos switches tiene en el trunk la vlan 1 como nativa. Ahora vamos a cambiar la vlan nativa del MLswitchB. Le ponemos la 30, por ejemplo, y les limpiamos la tabla mac para asegurarnos.
MLswitchB(config)#int e3/3
MLswitchB(config-if)#switchport trunk native vlan 30
MLswitchB(config-if)#end
MLswitchB#clear mac address-table dynamic
MLswitchA#clear mac address-table dynamic
Lanzamos el ping y sigue funcionando. Y eso que podemos ver los errores del log que no está avisando de un "mismatch de la vlan nativa". La causa es que la nativa solo se utiliza para enviar tramas sin etiqueta, sin tag de la vlan.
Ahora, si le configuramos al MLswitchB la vlan 20 como nativa, entonces si que deja de haber comunicación para la vlan 20 entre los PC's porque el MLswitchB envía la trama del PC, que entra como vlan 20, por el trunk sin etiqueta al ser esta la nativa. Cuando llega al MLswitchA no tiene donde enviarla porque para mandarla al PC debería llegar con la etiqueta de la vlan 20.
MLswitchB(config)#int e3/3
MLswitchB(config-if)#switchport trunk native vlan 20
COMANDOS PARA TROUBLESHOOTING
show interface status
show vlan
show vlan brief
show interface switchport
show interface trunk
show spanning-tree
show spanning-tree interface
VTP version 3
Con VTP version 3, se reduce el riesgo de que nos suceda una actualización de la base de datos de vlans si un equipo es conectado con un "número de revisión" más alto, ya que en el dominio VTP solo habrá un equipo autorizado (primary server) para actualizar las bases de datos de otros equipos pertenecientes al dominio. Además soporta MST, PVLAN y amplía el rango hasta la vlan 4095 (extended vlans). También nos da la opción de configurarlo globlalmente o por interface.
Para hacer que un switch sea el equipo autorizado:
switch#vtp primary vlan
Los roles siguen siendo los mismos: server, transparent y client. Sin embargo, habrá un "primary server" por rol que será el que pueda hacer los cambios. Esto deja prácticamente a los roles de server y client con la misma capacidad.
 |
| "vtp primary mst" para autorizarlo en MST |
Explorad las opciones del comando, no son muchas.
Para habilitar VTP en un NEXUS, tenemos que habilitar la opción, ya que viene deshabilitado por defecto:
NX-OSv(config)#feature vtp
No hay comentarios:
Publicar un comentario