barra de menu

martes, 16 de julio de 2019

Capítulo 1: Advanced Ethernet Switching


En este capítulo vemos 4 apartados:

  • VLAN: Asignación de tráfico
  • VLAN: Restricción de tráfico
  • MVRP: Multiple VLAN Registration Protocol
  • Layer 2 Tunneling


ASIGNACIÓN DE TRÁFICO




Por defecto, todos los puertos pertenecen a la VLAN  por defecto. Esta VLAN por defecto la podemos cambiar:


set vlans default vlan-id X


Para configurar un puerto como accesso o como troncal:

  • set interface x.x family ethernet-switching interface-mode access
  • set interface x.x family ethernet-switching interface-mode trunk


Para asignar una VLAN a los puertos:
  • set interface x.x family ethernet-switching vlan members X
  • set interface x.x family ethernet-switching vlan members X members X...

Los puertos de acceso tienen asignada una vlan y los troncales todas aquellas que queremos pasar por ese enlace.


Para asignar VLAN a los troncales podemos decirle que las pase todas o elegir individualmente:
  • set interface x.x family ethernet-switching vlan members all



Juniper permite asignar un puerto de acceso, solo de acceso, directamente en la parte de configuración de vlans. A esto lo llama "port-based". Nos avisará de que si usamos esta configuración, no es compatible con "interface-mode", es decir, la forma de configuración en la interface.


Método Port-Based


Juniper nos ofrece una manera de filtrar en una VLAN. Es lo que llama Filter-Based. El tráfico que recibe el puerto se filtra y se aplican los criterios que configuremos en el filtro.

El filtro asigna al puerto lo que le digamos evaluando la información que le entra, como por ejemplo la ip de origen. Se usan "firewall filters" para determinar la asignación. Este escenario es factible para puertos de switch donde se conectan múltiples dispositivos, como por ejemplo, un hub. Esta opción no se soporta en toda la serie EX.

Nota: Filter-Based Vlan no es compatible es los puertos de acesso con 802.1X


Ejemplo: Tenemos dos PCs conectados a hub. Tienen diferente rango de dirección, por lo que usan una vlan diferente. Sin embargo, el enlace entre el hub y el switch es un puerto de acceso con la VLAN 10, donde por norma se configura una sola vlan. No se puede crear un enlace trunk con un hub.

Vamos a asignarle la vlan 10 y la vlan 20 a las tramas que entren al puerto ge-0/0/0.0 dependiendo de la dirección ip de origen.

 

  • set vlans v10 vlan-id 10
  • set vlans v10 interface ge-0/0/0.0

Lo primero es definir y aplicar el "Firewall filter de Capa 2" (en el nivel de ethernet-switching)
  • set firewall family ethernet-switching filter vlan20-hub term match-subnet from source-address 20.0.0.0/24
  • set firewall family ethernet-switching filter vlan20-hub term match-subnet then vlan v20
  • set firewall family ethernet-switching filter vlan20-hub term resto then accept



Nota: por defecto, un firewall filter descarta todo el tráfico no especificado. Por eso, incluimos otro "term" para aceptar y que asociar con la vlan 10 el resto del tráfico

  • set interfaces ge-0/0/0.0 family ethernet-switching filter input vlan-hub


 Por último, tenemos que asociar la interface ge-0/0/0.0 en la vlan 20 y aplicarle el filtro.

  • set vlans v20 vlan-id 20
  • set vlans v20 interface ge-0/0/0.0 mapping policy



RESTRICCIÓN DE TRÁFICO

En algunos escenarios podemos tener la necesidad de subdividir una vlan para incrementar la seguridad. Podemos encontrarnos una vlan que esté dando servicio a varios departamentos (no es lo común) y que necesitemos restringir tráfico entre usuarios, por ejemplo, entre los usuarios del departamento de Finanzas y el de Ventas. Para ello usaremos las "Private Vlan" (PVLAN).

Podemos crear subdominios de broadcast aislados dentro de un mismo dominio de broadcast global. Esta estructura se divide en Primary Vlans y Secondary Vlans. Se pueden configurar tanto en un switch aislado o en varios conectados y, se se pueden crear múltiples diferentes PVLANs.

Nota: PVLAN y Voice Vlan no pueden ser configuradas en la misma interface a la vez.


Resultado de imagen de primary vlan juniper
Primary Vlan: 100 - Secondary Vlans: 200, 300, 400        

PRIMARY VLAN: es la VLAN principal, la que tiene dentro todas las demás secundarias. Esta VLAN siempre tiene que estar etiquetada con 802.1q

SECONDARY VLAN: solo necesita ser etiquetada con 802.1q si se expande a múltiples switches. Tenemos varios tipos:

  • Community VLAN: transporta tramas entre interfaces que pertenecen a la misma "community" y hacia la Primary Vlan.
  • Isolated Vlan: recibe/envía tramas solo de/hacia la Primary Vlan.
  • Inter-switch Isolated Vlan: tramas entre Isolated Vlan de diferentes swiches (pvlan-trunk)

También tenemos diferentes tipos de puerto:
  • Promiscuous Ports: típicos puertos trunk conectados a un router. Tiene conectividad de capa 2 con todos los otros puertos del resto de los switches, incluídos los Isolated.
  • Community Ports: puertos de acceso que pertenecen a una community. Tienen conectividad con todos los puertos de la misma comunidad y con los puertos promiscuous.
  • Isolated Ports: puertos de acceso que están aislados de los otros puertos del switch Solo tienen conectividad con los promiscuous ports.
  • PVLAN Trunk Ports: puertos troncales que conectan 2 switches que participan en el mismo dominio de PVLAN. Se comunican con todos los puertos excepto con los isolated. También transportan el resto de las vlan, como un trunk normal.
PVLAN Topology Spanning
Multiple Switches

Ejemplo:

Topología


Creamos la "Primary-Vlan" y la "Isolation Vlan". Los puertos de acceso que se configuran dentro de la "primary-vlan" (como el ge-0/0/0 de EX1) se consideran puertos "isolated" y se asocian a la vlan definida como Isolated.


root@EX1> show configuration vlans
PRIMARY-1000 {
    vlan-id 1000;
    interface { 

           ge-0/0/1.0 {
                pvlan-trunk;
           }
           ge-0/0/0.0;
}

no-local-switching;
isolation-id 10;


root@EX2> show configuration vlans
PRIMARY-1000 {
    vlan-id 1000;
    interface { 

           ge-0/0/1.0 {
                pvlan-trunk;
           }
           ge-0/0/0.0;
}

no-local-switching;
isolation-id 10;


Los puertos de PCs se configuran como puertos de acceso normales y le añadimos la "Primary-Vlan" que hemos designado. En este caso elegimos la 1000, por ejemplo. De esta manera vinculamos la vlan primaria.



root@EX1> show configuration vlans
COMERCIALES {
    vlan-id 50;
    interface { 

           ge-0/0/2.0;
    primary-vlan PRIMARY-1000;
}

DIRECTORES {
    vlan-id 40;
    interface { 

           ge-0/0/3.0;
    primary-vlan PRIMARY-1000;
 }


root@EX2> show configuration vlans
COMERCIALES {
    vlan-id 50;
    interface { 

           ge-0/0/2.0;
    primary-vlan PRIMARY-1000; 
}
DIRECTORES {
    vlan-id 40;
    interface { 

           ge-0/0/3.0;
    primary-vlan PRIMARY-1000; 
}



MVRP - Multiple Vlan Registration Protocol (IEEE 802.1ak)

Este protocolo nos facilita la gestión de vlans. Dinámicamente registra las vlans necesarias para la LAN. Esto ayuda a reducir la carga laboral y de la red, ya que es capaz de deshabilitar una vlan si no existe ningún puerto activo en el switch en ese momento para esa vlan. También se puede usar para crear vlans.

MVRP usa PDUs para enviar la información de registro de las vlans. Esta info es usada para comunicar a los otros switches que vlans tiene y que interfaces participan en ella.

Las MVRP PDUs solo se mandan a los otros switches cuando hay un cambio de MVRP. De esta manera se sincroniza la información en toda la planta de switching. Se puede configurar la frecuencia con la que se envían estas PDUs para el tráfico de control. Estos tiempos se configuran por "interface":

  • Join: intervalo para enviar la siguiente MVRP PDU.
  • Leave: periodo de tiempo que una interface espera en estado de "leave" antes de pasar a "unregistered"
  • LeaveAll: frecuencia de mensajes "LeaveAll" que generan los interfaces.

La información de las vlans se distribuye a través del intercambio de mensajes MVRP y puede ser usado para crear una vlan en un switch y propagarla a los otros. La creación dinámica de vlans en MVRP está habilitada por defecto.

MVRP usa MRP para registrar y declarar los diferentes estados y poder comunicar a los otros switches del cambio. Estos mensajes están incluídos en las PDUs:

  • Empty: vlan no declarada ni registrada.
  • In: vlan no declarada pero registrada.
  • JoinEmpty: vlan declarada pero no registrada
  • JoinIn: vlan declarada y registrada
  • Leave: vlan que estaba registrada y ha salido del registro.
  • LeaveAll: todos los registros se desconectan.
  • New: vlan nueva y posiblemente no estaba registrada antes.

Para asegurar que la información es siempre actual, MVRP usas mensajes para eliminar switches e interfaces que no tienen ya las vlanes activas, reduciendo la carga en la red.

MVRP viene deshabilitado por defecto en equipos EX, pero una vez habilitado la configuración dinámica de vlans se habilita también. Solo se puede configurar en puertos "Trunk". MVRP no soporta VSTP.

Ejemplo: Vamos a crear las vlan en EX1 y las propagaremos por MVRP a EX2.

Topología

 La configuración inicial de EX1, EX2 y EX3:





Los puertos de acceso son "port-based" y los trunk "interface-mode".

Con este escenario, ahora es cuando habilitamos MVRP. Solo se habilita en los puertos TRUNK. Una vez habilitado, la información de configuración dinámica de vlans se comparte entre los switches participantes. Se puede deshabilitar la opción dinámica.

  • set protocolos mvrp interface X

Tenemos más opciones para configurar los tiempos


Por defecto, los tiempos de MVRP son 200ms para el Join, 1000ms para el Leave y 10000ms para el Leaveall.

show mvrp - vemos los Joins

Crea las vlans dinámicamente


Con show mvrp dynamic-vlan-memberships podemos ver que en EX2 se han creado vlans que antes no tenía. Fijaos bien en el formato de nombre que les da.

También podemos sacar estadísticas del protocolo.



LAYER 2 TUNNELING

Muchas de las redes de capa 2 de hoy en día necesitan conectividad entre sitios remotos a través de un ISP. Esto hace que los ISP tengan que tener en cuenta varios detalles como la disponibilidad de vlans, el tamaño de las tabla de direcciones mac, los posibles bucles, etc.

Desde el punto de vista del cliente, un EVC (Ethernet Virtual Connection) aparece como un enlace ethernet más, Sin embargo, para el ISP, el etiquetado común del 802.1q no provee de la escalabilidad necesaria para dar este servicio.

Q-in-Q (802.1ad) es la solución que ha surgido para que los ISP puedan ofrecer esta "extensión de su capa 2" entre sus diferentes oficinas. Con esto conseguimos que el cliente vea su WAN como una simple LAN sobre ethernet y, también para el ISP es más fácil, ya que asigna una simple VLAN por cliente.


Azul: C-Tag // Verde: S-Tag


Q-in-Q necesita 2 etiquetas (tag):
  • S-VLAN TAG: Service Vlan (verde)
  • C-VLAN TAG: Customer Vlan (azul)
Para el cliente la S-Tag es transparente, no necesita saber de ella. Con etiquetar su tráfico con la C-Tag es suficiente. Una vez llega la trama al lado del ISP, este le añade la S-Tag. Esta etiqueta usa un único ID (S-Vlan ID) y puede transportar una o todas las 4094 C-Vlans que esté usando el cliente.

El escenario más simple para un ISP es asignar un S-Vlan a cada cliente. Esto da la posibilidad de tener 4094 clientes. Sin embargo, esta solución sigue teniendo que gestionar las tablas mac del tráfico de capa 2 y, eso puede resultar un problema de carga y espacio en los equipos que transportan este tráfico.

Los formatos de las etiquetas para el 802.1ad es el siguiente:

  • S-VLAN Tag:
        • Tag Protocol Identifier (TPID): 16 bits, default 0x88A8
        • Priority: 3 bits, 802.1p
        • Drop Eligibility Indicator (DEI): 1 bit, default 0
        • Unique VLAN Identifier: 12 bits
  • C-VLAN Tag:
        • Tag Protocol Identifier (TPID): 16 bits, default 0x8100
        • Priority: 3 bits, 802.1p
        • Canonical Format Indicator (CFI): 1 bit, default 0 
        • Unique VLAN Identifier: 12 bits

La C-Tag permanece igual a la 802.1q de toda la vida. La S-Tag es muy parecida pero tiene campos diferentes. En la S-Vlan se usa el CFI de 802.1q para el campo DEI que establece la prioridad QoS.

Un puerto trunk estándar entiende perfectamente cuando en la etiqueta de la trama aparece un valor del TPDI  de 0x8100 pero no una que lleve el 0x88A8. Por esta razón, debemos habilitar "dot1q tunneling" en todos los trunks por donde pase la S-VLAN o configurar manualmente el TPID  de las S-VLANs al vlaor 0x8100:

  • set ethernet-switching dot1q-tunneling-ether-type X

La terminología usada en un ISP para este servicio es:

  • Provider Bridge Network: la nube del ISP
  • Provider Bridge: equipos del ISP que participan en el servicio
    • Provider Edge Bridge: equipo frontera (como un PE en MPLS)
    • S-VLAN Bridge: equipo interno (como un P en MPLS)
  • Customer Edge Port: el puerto que enfrenta al equipo del cliente
  • Provider Network Port: puertos internos del ISP por donde pasa este servicio
  • Customer Bridge: equipo frontera del cliente



Proceso de la Trama en Q-in-Q

El cliente usa etiquetas normales de 802.1q (C-VLAN 100) para conectar sus oficinas remotas.
El ISP usa la S-VLAN 200 para transportar las tramas del cliente.




Cuando la trama C-VLAN (ether-type 0x08100) llega al Provider Edge Bridge, este hace una búsqueda (lookup) de la tabla mac de la S-VLAN. Si la encuentra, envía la trama por el puerto asignado (ge-0/0/0.10) y le añade una etiqueta S-VLAN (ether-type 0x88A8). A este proceso de ponerle la etiqueta se le llama PUSH.

Si el Provider Edge Bridge no encuentra la mac en la tabla, inundará (flooding) por los puertos en los que tenga asignada la S-VLAN asociada a ese cliente, excepto por donde el puerto por donde le ha llegado.



Cuando la trama llega al S-VLAN Bridge, esa interface debe ser capaz de procesar las tramas con el ether-type 0x88A8. El S-VLAN Bridge hace una búsqueda de la tabla mac de la S-VLAN 200 asociada al cliente y la envía por interface de salida apropiado (ge-0/0/0.20) la trama sin modificarla.



Cunado la trama llega al Provider Edge Bridge final, este le quita la etiqueta de la S-VLAN. A este proceso se le llama POP. Entonces hace una búsqueda de la mac de destino dentro de la tabla de la C-VLAN.
Finalmente se la envía al Customer Bridge por la interface correspondiente.



Al Customer Bridge (derecha) le llega una trama igual que la que envía el Customer Bridge original (izquierda).


Ejemplo:



root@ISP1> show configuration vlans
v200 {
    vlan-id 200;
    interface xe-0/0/1.0;
    interface xe-0/0/0.0;
    dot1q-tunneling;
}


Con esta configuración en todos los switches del ISP (cada uno con sus correspondientes interfaces) habilitaríamos Q-in-Q en modo "todos en uno". Recoge todo el tráfico de todas las interfaces de acceso y las mapea a la S-VLAN sin importarle la C-VLAN.



El modo "muchos en uno" mapea solo las C-VLANS definidas:


root@ISP1> show configuration vlans
v200 {
    vlan-id 200;
    interface xe-0/0/1.0;
    interface xe-0/0/0.0;
    dot1q-tunneling customer-vlans [ 100 160 245 ];
}




El tercero es el modo "interface". Mapeamos una S-VLAN a una C-VLAN de una específica interface:


root@ISP1> show configuration vlans
v200 {
    vlan-id 200;
    interface xe-0/0/1.0;
    interface xe-0/0/0.0 {
                    mapping {
                           100 {
                                  push;
                           }
                     }
              }
       }
    dot1q-tunneling;
}



Si habilitamos Q-in-Q, tendremos que habilitarlo en todas las vlans de los trunk. Alternativamente podemos configurar:
  •  set ethernet-switching-options dot1q-tunneling ether-type 0x8100


Q-in-Q no tuneliza protocolos de capa 2 como RSTP, MVRP, LLDP, etc. Para ello, podemos habilitar L2PT para transportar esos protocolos de capa 2 a través de Q-in-Q.





L2PT permite enviar PDUs de capa 2 (las encapsula) a través de la red del ISP entre los Customer Bridges de los clientes. L2PT encapsula las PDUs de capa 2 habilitando en el Provider Edge Bridge la capacidad de reescribir la dirección mac de destino de la PDU antes de enviarla. El Provider Edge Bridge de origen trata la PDU encapsulada como un paquete ethernet multicast. El Provider Edge Bridge desencapsula el paquete y reemplaza la dirección mac de destino por la del protocolo que estemos transportando.

Los equipos EX soportan los siguientes protocolo L2PT:
  • 802.1X
  • 802.3ah
  • CDP
  • E-LMI
  • GVRP
  • LACP
  • LLDP
  • MMRP
  • MVRP
  • STP, RSTP, MSTP
  • UDLD
  • VSTP
  • VTP

Para configurar y comprobar el túnel L2PT:
  • set vlans v200 dot1q-tunneling layer2-protocol-tunneling X (stp,cdp,lacp,etc)
  • show ethernet-switching layer2-protocol-tunneling interface


Si un túnel L2PT recibe mucho tráfico, podemos limitar el exceso de PDUs para no tener que deshabilitar la interface:
  • Drop-Threshold: máximo de PDUs recibidas por segundo en una específica vlan
  • Shutdown-Threshold: máximo de PDUs recibidas por segundo en una específica vlan

El límite del shutdown tiene que ser igual o mayor que el del drop.

Para rehabilitar la interface que se ha puesto en shutdown:
  • clear ethernet-switching layer2-protocol-tunneling error

No hay comentarios:

Publicar un comentario