You are on page 1of 86

Captulo 1: Layer 2 Switching

En un entorno de switching podemos encontrarnos dos tipos de redes: Shared Lan o Switched Lan

SHARED LAN (Medio Compartido)

En un entorno Ethernet compartido los equipos se comunican a travs de un medio compartido. Todos los
equipos que participan en un medio compartido pertenecen al mismo dominio de colisin. Ethernet usa
(CSMA/CD) para evitar las colisiones. Esta implementacin solo permite un trfico de datos a la vez. Todos los
equipos estn escuchando para saber cuando la lnea est en estado "IDLE". Solo cuando est en IDLE se
puede transmitir. Si varios equipos detectan la lnea en IDLE y empiezan a transmitir, se darn colisiones.
Cuando hay colisiones se enva una seal "JAM" para notificar que existe una colisin en el segmento. Cuando
un equipo detecta una colisin, para de transmitir y espera un tiempo aleatorio para volver a comprobar si est
la lnea en IDLE y, si lo est, vuelve a transmitir.

Cuando en el entorno compartido tenemos un HUB para conectar los equipos, entonces tenemos un nico
dominio de colisin: la informacin de un puerto sale por todos los dems.

Cuando los entornos compartidos empiezan a crecer se dan demasiadas colisiones haciendo ineficaz la red.
Para solucionar este problema, instalamos un switch.
Cada puerto del switch crea un dominio de colisin. Convierte un dominio de colisin grande (HUB) en
mltiples dominios pequeos (switch). Incrementa el rendimiento y minimiza los riesgos de seguridad. Los
switches crean y mantienen una tabla forwarding/bridge que usa para enviar las tramas a los destinos. A este
proceso se le llama "bridging". En esta tabla se almacenan todos los destinos basados en la direccin mac que
entra por el puerto del switch. Esto reduce el trfico innecesario.

Para construir y mantener la tabla, el switch ejecuta 5 pasos: learning, forwarding, flooding, filtering y
aging. Vamos a verlos individualmente.
Cuando un switch arranca, no tiene informacin de los dispositivos que tiene conectados. Learning es el
proceso de aprender todas las direcciones mac de los dispositivos conectados y las almacena en la "bridge
table". El switch inspecciona las tramas y en la cabecera (header) viene la direccin mac que se guarda en la
tabla.

El aprendizaje o learning se puede deshabilitar en los switches Juniper EX:

#set ethernet-switching-options interfaces ge-0/0/0.0 no-mac-learning

Si el switch encuentra una entrada en la tabla bridge, enviar el trfico de destino por ese interfaz.

Si no encuentra una entrada, enviar la trama por todos los puertos (flooding) que pertenezcan a la misma
VLAN (que en realidad tambin es el mismo dominio de broadcast) excepto por el puerto de donde viene el
trfico de origen.
El flooding (inundacin) se usa cuando el switch tiene una direccin mac de destino que no est en su tabla
bridge o si el paquete recibido es un paquete de broadcast/multicast. El switch inundar por todos los puertos
excepto por el puerto donde se recibe (si se origina en el propio switch igualemente inunda por todos los
puertos). Cuando esa direccin mac no conocida responde, el switch aprender y almacenar el puerto por
donde ha entrado y lo asociar en la tabla bridge.

El switch tiene un filtro propio que hace que si en la tabla bridge, la mac del puerto de origen coincide con el
puerto de destino, no se enviar. Un ejemplo claro es cuando tenemos un HUB, ya que estos no diferencian
por VLAN.
El "aging" es un recurso usado por el switch y otros dispositivos de comunicaciones que hace que mantengan
las direcciones mac en la tabla de bridge, pero nicamente las activas. Cuando recibe trfico de esa mac,
establece un tiempo de espera (que se renueva cada vez que recibe trfico). Si pasa el tiempo y no ha recibido
ms trfico, el switch elimina la mac de la tabla. El tiempo por defecto es de 300 segundos. Se puede
configurar en global o incluso por VLAN:

user@switch# set ethernet-switching-options mac-table-aging-time XXX

user@switch# set vlans vlan-name mac-table-aging-time XXX


JERARQUIZACIN DE LAS REDES DE COMUNICACIONES

Los beneficios del diseo de una red jerarquizada son la modularidad y la facilidad para aislar problemas.

Las tpicas capas de la estructura son: acceso, distribucin/agregacin y ncleo.


Cada una de estas capas cumple una funcin especfica

Las funciones bsicas de estas capas seran:

Todas las capas soportan CoS

CONSOLIDACIN DE LAS CAPAS

Debido al rpido crecimiento y complejidad de las redes hoy en da, Juniper ha desarrollado una simplificacin
de la arquitectura para DATA CENTER llamada "3-2-1". Esta arquitectura elimina capas quedndose la
estructura en 2 capas o incluso en 1: Muchos dispositivos fsicos se convierten en un nico equipo lgico.

Juniper ha desarrollado para esto dos tecnologas: Virtual Chassis y Qfabric.


Virtual Chassis crea un nico switch administrable a partir de diferentes switches conectados entre s.

Qfabric habilita administrar todo la capa de switching de un data center como un nico equipo.

EQUIPAMIENTO DE SWITCHING DE JUNIPER

J Series y SRX Series no soportan todas las capacidades de switching


Parque de Switches de Juniper. Actualmente tienen uno nuevo: EX4300

Switches modulares

Donde ubicar los switches Juniper?

EL CORAZN DE JUNIPER
Todas las plataformas de Junos OS usan el mismo cdigo fuente de software que est basado en el sistema
operativo FREEBSD de UNIX.

Una de las claves del buen rendimiento de los equipos que usan Junos OS es que el software est dividido en
mdulos. Cada proceso tiene su propio espacio de memoria protegido y el fallo de un proceso no hace que
falle todo el sistema.

Otro de los aspectos importantes de esta estructura es la separacin tanto de software como de hardware
entre el panel de control (control plane) y la tabla de datos y envo (forwarding plane).

El Internal Link tambin es conocido como SFID.


Routing Engine (RE): es el cerebro del equipo.

Packet Forwarding Engine (PFE): basada en arquitectura ASICS.

CARACTERSTICAS DE LA RE Y LA PFE

ROUTING ENGINE (RE) PACKET FORWADING ENGINE


Basado en arquitectura x86 Basado en arquitectura ASICS

Mantiene Routing Table y Bridging Table Recibe copia L2-L3 de la Forwdarding


Table de la RE
Mantiene Primary Forwarding Table Enva las tramas y paquetes

Conecta con la PFE internamente Implementa Policy y Filters

Provee la administracin cli o web Implementa CoS

Gestiona los problemas del chassis Imlementa Stateless Firewall

Gestiona el EXCEPTION TRAFFIC Gestiona el TRANSIT TRAFFIC

Para establecer la comunicacin entre ellos utiliza una tarjeta interna (internal link) que suele ser la fpx1/bme0,
dependiendo del modelo de Juniper. Estas tarjetas tienen un lmite de trfico configurado por defecto para
evitar ataques DoS que puedan dejar sin gestin al equipo.

Esta arquitectura tambin provee a los equipos la posibilidad de tener ms de una Routing Engine y a travs
de GRES (Graceful Routing Engine Switchover), NSR (Nonstop Active Routing) y ISSUs (Unified In-Service
Sofware Upgrades) podemos actualizar el software y tener redundancia de fallos sin perder servicio.

PROCESAMIENTO DE TRAMAS
Hay un PFE de entrada y otra de salida

La trama no se replica por el puerto que ha entrado

EJEMPLO DE CONFIGURACIN DE SWITCHING


Lo primero que hay que comentar es que con GNS3 no se puede emular el switching con los comandos
de los equipos EX, es decir, el comando "family ethernet-switching". En el mdulo de routing podremos
configurar TRUNKS y VLANS con otro comando sin problemas.

El objetivo es configurar el switching y comprobar que los usuarios tienen conectividad.

Para configurar las interfaces y hacerlas operativas en capa 2, tenemos 2 opciones:

- Definir las interfaces individualmente


Habilitamos la capa 2 de en las interfaces

- Definir un rango de interfaces

Opcin "Member" para incluir individualmente.


Member-range para definir una lista

Tambin podemos combinar ambas opciones en una misma configuracin:


El proceso de Ethernet-Switching que se ejecuta por defecto en todos los EX es: ESWD.

Podemos ver este proceso en la consola de comandos:

Para revisar nuestra configuracin de las interfaces, Juniper nos ensea dos comandos:

- show interfaces terse


- show interfaces extensive

En rojo vemos la configuracin que viene por defecto: auto-auto

Si necesitamos cambiar la configuracin para forzar la negociacin a full duplex y a una velocidad concreta, lo
hacemos de la siguiente manera:

Forzamos a full duplex y a 1 giga de velocidad

Para comprobar la tabla "bridge" del switch escribimos: show ethernet-switching table
Info: VLAN a la que pertenece, Type (Learn o Static)
Age es el tiempo que queda para borrarla de la tabla

Modo "extensive" para ver ms informacin

Si queremos ver la tabla de envo: show route forwarding-table family ethernet-switching

Para limpiar la tabla bridge:

Vemos que el switch est en el proceso de aprender todas las direcciones mac
Tambin podemos asociar direcciones mac a puertos manualmente.

Aadimos manualmente las direcciones mac y vemos en la tabla como "static"

Captulo 2: Virtual Networks

Con Virtual Networks, Juniper se refiere a las redes VLAN (Virtual LAN).

Una VLAN tiene los mismos atributos que una LAN fsica, pero la diferencia es que no necesita que los dispositivos estn
fsicamente en la misma ubicacin. Aportan flexibilidad para el diseo de una red y agrega seguridad.

Los pc's que pertenecen a la misma VLAN tienen conectividad entre ellos

TIPOS DE PUERTOS
Por defecto, en los switch EX vienen todos los puertos en modo acceso
La primera vez que encendemos el switch, todos los puertos pertenecen a la VLAN por defecto, que es la
que transporta las tramas sin etiqueta (tag). En Cisco, esta VLAN es la 1.

Podemos asignarle un nmero de VLAN a la de por defecto:

- #set vlans default vlan-id 100

Los puertos de acceso suelen tener conectados usuarios finales, pc's, servidores, impresoras, telfonos, etc. Suelen
pertenecer a una sola VLAN (hay una excepcin para la voip).

Los puertos troncales (trunks) se conectan a otro switch o a un router. Son los puertos capaces de transportar mltiples
VLANs dividiendo el trfico en base a las etiquetas (tag). Tambin pueden transportar tramas sin etiqueta usando el
atributo native-vlan-id.
Cuando en un switch entra una trama y este puerto no pertenece a ninguna VLAN, lo enviar por los troncales igualmente,
sin etiqueta, siempre que conozca la mac claro, si no, enviar un broadcast.

Cuando el puerto tiene una VLAN asignada, la trama entra al puerto, el switch hace un "lookup" (bsqueda) en la tabla
bridge, encuentra una entrada asociada (mac-puerto) y lo enva por ese puerto de acesso, Si este puerto es un troncal, le
pone la etiqueta de la VLAN, un nmero entre 1-4096 aunque vara en cada modelo de switch. Cuando llega al otro switch
que est conectado por el troncal, este segundo hace un lookup en la tabla y si encuentra una entrada en la tabla, le quita la
etiqueta y lo enva por el puerto de acceso, al usuario final. Si es un troncal por donde conoce la mac, se repite el proceso.

EJEMPLO DE CONFIGURACIN

Los usuarios A-C y B-D se ven entre ellos por las VLAN 10 Y 20 respectivamente.

Primero creamos las VLAN:

- #set vlans v10 vlan-id 10


- #set vlans v20 vlan-id 20

Asignamos puertos de acceso:

- #set interfaces ge-0/0/8 unit 0 family ethernet-switching port-mode access vlan members v10
- #set interfaces ge-0/0/9 unit 0 family ethernet-switching port-mode access vlan members v20

Tambin podemos hacerlo en el apartado de la configuracin de las VLAN:

- #set vlans v10 vlan-id 10 interface ge-0/0/8.0


- #set vlans v20 vlan-id 20 interface ge-0/0/9.0

Asignamos puertos troncales:

#set interfaces ge-0/0/12.0 family ethernet-switching port-mode trunk vlan members [ v10 v20 ]

O tambin podemos asignar todas las VLANs:

#set interfaces ge-0/0/12.0 family ethernet-switching port-mode trunk vlan members all
Comprobamos con el comando "show vlans":

Show vlans ? nos da una serie de filtros para este comando

LA VLAN DE VOZ

Una clsica configuracin en las empresas es conectar el pc al telfono IP y este al puerto de ACCESO del switch. Al
puerto del switch le estarn llegando tramas con dos etiquetas de VLAN (tag) diferentes. Cmo gestionamos esto?

El truco est en configurar la VLAN de VOZ en el puerto del switch. El telfono mandar las tramas de voz con una
etiqueta que configuramos en el propio telfono. El trfico del PC, que lo enva tambin el telfono, pues este tiene un
pequeo switch dentro, ser enviado sin etiqueta.

Se usa conjuntamente con CoS (Class of Sevice) para diferenciar un trfico de otro. CoS no se estudia en el JNCIS, pero
basta saber que se usa para clasificar y priorizar diferentes trficos.

Tambin podemos usar LLDP-MED, que es un estndar (802.1p) para descubrir dispositivos en capa 2. El protocolo de
Cisco que hace esto es el CDP. Con LLDP-MED, el switch y el telfono se comunican entre ellos asignando el switch la
VLAN correspondiente. LLDP-MED tambin est fuera del estudio.
Configuramos el switch:

#set vlans data vlan-id 10


#set vlans voice vlan-id 20

#set interfaces ge-0/0/6.0 family ethernet-switching port-mode access vlan members data
#set interfaces ge-0/0/12.0 family ethernet-switching port-mode trunk vlan members [ data voice ]

#set ethernet-switching-options voip interfaces ge-/0/0/6.0 vlan voice


#set ethernet-switching-options voip interfaces ge-/0/0/6.0 forwarding-class

Vemos como quedan configurados los puertos:


LA VLAN POR DEFECTO

El comportamiento por defecto de un switch EX en los puertos TRONCALES es no dejar pasar el trfico que no tenga
etiqueta.

Para solucionar esto usamos el comando native-vlan-id:

#set interfaces ge-0/0/.12.0 family ethernet-switching port-mode trunk native-vlan-id default

Hay que hacerlo en los dos switches. En Cisco es la 1, hay que tenerlo en cuenta
RVI - ROUTED VLAN INTERFACE

Una RVI es interfaz lgica de capa 3. Facilita el enrutamiento entre VLANS.

Funcionan como puerta de enlace para usuarios finales que tengan asociada la misma VLAN.

En el diseo de la red suelen estar configuradas en las capas de acceso o agregacin/distribucin

UN EJEMPLO DE CONFIGURACIN DE RVI

Configuramos la 172.23.1x.1 como puerta de enlace para las VLAN

Configuramos la RVI:

#set interfaces vlan unit 14 family inet address 172.23.14.1/24


#set interfaces vlan unit 15 family inet address 172.23.15.1/24
#set interfaces vlan unit 16 family inet address 172.23.16.1/24

Asociamos las RVI a una VLAN de capa 2. Es importante recordar que la VLAN de capa 2 debe tener al
menos una interfaz asociada y activa.

#set vlans v14 vlan-id 14


#set vlans v14 interface ge-0/0/6.0
#set vlans v14 interface ge-0/0/7.0
#set vlans v14 l3-interface vlan.14

#set vlans v15 vlan-id 15


#set vlans v15 interface ge-0/0/8.0
#set vlans v15 interface ge-0/0/9.0
#set vlans v15 l3-interface vlan.15

#set vlans v16 vlan-id 16


#set vlans v16 interface ge-0/0/10.0
#set vlans v16 interface ge-0/0/11.0
#set vlans v16 l3-interface vlan.16

Comprobamos:

Comprobamos la tabla de enrutamiento y hacemos prueba de conectividad:


Captulo 3: Spanning Tree

Como ya sabemos, cuando un switch recibe una trama con una mac de destino desconocida, enviar el trfico
por todos los puertos excepto por el que ha recibido la trama.

Si esto nos sucede en una red con enlaces redundantes se puede producir un bucle (loop) y que los switches
no paren de inundar la red.

Estos bucles pueden empeorar drsticamente el rendimiento de la red. Para evitar estos bucles se cre el
protocolo Spanning-Tree (IEEE 802.1D)

Spanning-Tree (STP) es un protocolo que previene los bucles y calcula la mejor ruta en topologas con enlaces
redundados. Cuando hay un cambio en la topologa, el STP recalcula la ruta.

Spanning-Tree ha evolucionado a lo largo del tiempo. Ahora tenemos:

RSTP: Rapid Spanning-Tree


VSTP: VLAN Spanning-Tree

MSTP: Multiple Spanning-Tree

CONCEPTOS Y DEFINICIONES

Todos los switches que participan en el rbol STP tienen un nico "Bridge ID".

Bridge ID: identificador nico. Es una combinacin de la mac y la prioridad STP que configuramos.

Root Bridge: Switch que tenga el "Bridge ID" ms bajo.

Root Port: El puerto de cada switch que est ms cerca del Root Bridge.

Root Path Cost: Es el coste para llegar al Root Bridge.

Port Cost: Cada interfaz tiene un coste asignado predefinido: El valor por defecto en una interfaz que sea
de 1 Gigabit Ethernet es de 20000. Este es un valor configurable (1-200000000).

Una vez que el Root Bridge ha sido determinado, el resto de switches que no son Root, calculan el coste hasta
el Root Bridge. El puerto con menos coste en estos switches ser el root port.

Designated Bridge: Es un switch que representa el segmento LAN.

Port ID: Un identificador nico para cada puerto del switch.

Designated Port: El puerto designado para enviar las BPDU'S en la parte LAN.

Bridge Protocol Data Unit (BPDU): son paquetes usados entre switches para el protocolo STP.
Cuando hay varios switches en un segmento LAN, el que tenga menor coste hacia el Root Bridge ser el
designated bridge. Si existieran dos switches con el mismo coste para llegar al root, el switch que tenga el
Bridge ID ms bajo ser el designated bridge. Si tambin coinciden en el bridge id, ser el ID del puerto por
donde se llega al root.

ESTADO DE LOS PUERTOS

Hay 4 estados de puerto:

Blocking (bloqueando): el puerto descarta todos los paquetes y solo oye para BPDU's. No est activo en la
topologa.

Listening (escuchando): el puerto descarta todos los paquetes y solo oye para BPDU's. El puerto est
cambiando de estado y ser activo.

Learning (aprendiendo): el puerto descarta todos los paquetes y solo oye para BPDU's. El puerto est
cambiando de estado y el switch empieza a aprender direcciones mac.

Forwarding (enviando): el puerto enva y recibe datos y BPDU's. El puerto se queda en este estado hasta
que haya un cambio en la topologa y continua aprendiendo direcciones mac.

Tambin podemos deshabilitar el puerto para el protocolo STP. Este puerto no participa en el rbol STP
aunque enve trfico si se recibe por otro puerto no deshabilitado y que pertenezca a la misma vlan.

TIPOS DE BPDU

Tenemos 2 tipos de BPDU:

- Configuracin BDPU (TCN ACK): determina el rbol topolgico del STP. Lleva la info del root bridge
elegido, el root port de cada switch, los "designated port" de cada segmento fsico y el bloqueo de los enlaces
redundantes.

- TCN BPDU: informa de un cambio en la topologa STP.


Cuando STP inicia en una red, los dispositivos empiezan a mandar BPDU's por todos los puertos para indicar
a los dems switches o bridges que quieren ser candidatos a ser el root. Cada dispositivo usa las BPDU's para
formar el rbol y asignar los roles a los puertos. Una vez convergido el rbol, el root bridge enviar las
"configuracin BDPU" peridicamente (por defecto es cada 2 segundos).

INTERCAMBIO DE BPDU'S

Los equipos estn constantemente intercambiando bdpu's. Cada bridge construye su propia configuracin
basndose en las BPDU's que le llegan.

Eleccin del Root Bridge:

La eleccin del Root Bridge se hace en base al Bridge ID (BID), que es un nmero que combina la direccin
mac con una prioridad configurable del puerto. El switch mira primero a la prioridad y el que la tenga ms baja
ser el Root. Si coincide con algn o algunos equipos de la red, entra en juego la mac siendo elegida las ms
baja.

Roles de Puerto y Estado:

Una vez elegido el Root Bridge, aquellos equipos que no son el Root empiezan a calcular el coste para llegar a
este. Esto determina el rol del puerto. Y el rol del puerto determina su estado.

Todos los puertos del Root tendrn el rol de Designated y el estado de Forwarding.

En los equipos que no son el Root Bridge, el puerto con menor coste hacia el Root Bridge, tendr el rol de "root
port" y el estado de "Forwarding". Si un equipo tiene uno o varios puertos con el mismo coste, el "root port"
ser el que tenga un ID de puerto ms bajo, es decir, se prefiere el ge-0/0 al ge-0/1.
Coste de los enlaces

Luego el STP asiginar el rol de "Designated" al puerto con menos coste (despus del root port). Si hay
empate se resuelve igual que con el root port. Este puerto tambin estar el estado de "Forwarding".

Los dems puertos que no son ni root ni designated estarn en blocking. En el estado de bloqueo, los
puertos no envan BPDU's, pero si las reciben.

Una vez asignados los roles y los puertos, el rbol STP converge.

STP usa tiempos especficos cuando cambian de estado los puertos. La convergencia de STP dura entre 30 y
50 segundos: 2x Forwarding Delay (15x2=30) + Max Age Timer (20)

Cuando hay un fallo en la red, STP recalcula y vuelve a converger:


Una vez que los switches que no son el root bridge han cambiado el tiempo de espera de la mac (age timer)
por el tiempo ms corto de espera (15 segundos por defecto), borra todas las entradas de la tabla mac para las
que no haya recibido un "update". Todas estas entradas debern ser asociadas otra vez siguiendo el proceso
normal de aprendizaje de macs.

La solucin, cuando hay un cambio de topologa, no es eficiente, pues si tarda en converger 50 segundos,
habr muchos servicios que dejen de funcionar. Por ello, con el tiempo se hizo una mejora del protocolo
creando uno nuevo: RSTP.

RSTP (RAPID SPANNING-TREE)

Este protocolo est definido en la IEEE 802.1w e incorporado a la 802.1D en 2004. Introduce una serie de
mejoras sobre el STP.

El tiempo de convergencia es menor. RSTP identifica los enlaces Point-To-Point y cuando caen, no ejecuta los
tiempos de espera sino que transita al link alternativo inmediatamente.

ROLES DE PUERTO

A parte del root port y el designated port que ya tena STP, aade 3 ms RSTP:

Edge Port: Es un puerto que conecta a la LAN sin ningn switch conectado. Siempre en Forwarding.

Alternate Port: provee un camino alternativo hacia el root bridge. Es como un root port de backup. Bloquea el
trfico mientras reciba BDPU's superiores de un switch vecino. Est siempre en "discarding" pero recibe las
BPDU's.

Backup Port: Provee un camino alternativo hacia un segmento de red (solo en switches designated). Bloquea
el trfico siempre que tenga un "alternate" funcionando. Es una especie de backup del puerto alternate.
ESTADO DE PUERTOS EN RSTP

Cuando una interfaz est "deshabilitada" administrativamente en RSTP, esta no participa ni en STP y RSTP
pero inunda las BPDU's que reciba y que pertenezcan a la misma vlan y hace funciones bsicas de bridging
como asociar direcciones mac en la tabla bridge.

RSTP utiliza menos estados de puerto que STP pero cumpliendo las mismas funciones como podemos ver en
el cuadro.

BPDU's en RSTP

Utiliza las BPDU's igual que STP pero le aade una caracterstica a las BPDU de configuracin (TCNA) y es
que cumplen la funcin de "keepalive" monitorizando a los vecinos. De esta manera se da cuenta de un
cambio en la topologa antes que STP. Si no recibe una BPDU en 3 intervalos de tiempo de "hello" (por defecto
son cada 2 segundos), asume que ha perdido conectividad y actualiza el rbol.
La diferencia es que seran 6 segundos (2x3) y en STP puede llevar hasta 50 segundos.

Las interfaces ethernet trabajando en "full duplex" se consideran enlaces Punto-a-Punto (P2P) y por eso
transitan a forwarding sin esperar el intervalo de tiempo.

Las interfaces ethernet trabajando en "half duplex" se consideran enlaces de medio compartido (shared LAN) y
estas tienen que esperar el intervalo de tiempo.

RSTP es totalmente compatible con STP. Si RSTP recibe una BPDU del tipo STP la trata en modo STP. Si un
switch STP recibe una RSTP BPDU, la descarta.

Una de las grandes diferencias entre ellos es que los puertos root y edge de RSTP transitan inmediatamente a
forwarding sin tener que esperar los 30 segundos de STP hasta que llega al estado de forwarding (15'' listening
+ 15'' learning).

Cuando un puerto est en transicin en STP, esto causa un cambio de topologa. Sin embargo, en RSTP se
reduce el nmero de cambios de topologa ya que solo enva TCN's cuando cambia el estado en un puerto
"non-edge" a forwarding, que normalmente son los puertos que conectan con otro switch.

Cuando un puerto transita hacia el estado de "discarding" no se generan en los TCN's que llevaran a un
cambio de topologa y reclculo de esta.

Cuando hay un cambio en la topologa, el dispositivo que inicia el cambio enva TCN's por todos los puertos
que tenga en "designated" y por el root port tambin. Como el resto de switches reciben los TCN's no tienen
que esperar los intervalos de tiempo y directamente hacen un "flush" de las direcciones mac de la tabla bridge
(borra las entradas y empieza a aprender otra vez las direcciones). Hay dos excepciones: no hace flush de las
direcciones mac que haya aprendido por los puertos "edge" y tampoco hace flush de las direcciones del puerto
por donde recibe los TCN's.

El fallo se mira desde la perspectiva del switch 3

El fallo se mira desde la perspectiva del switch 3

CONFIGURACIN RSTP Y COMPROBACIN


Para comprobar el protocolo:

Si quisieramos algo ms detallado habilitamos un traceoption (debug para Cisco)

set protocols rstp traceoptions file name X


set protocols rstp traceoptions flag all

PROTECCIN DE BPDU's

Si en nuestra red alguien conecta un switch (rogue switch) a un puerto de alguno de estos switches, este
podra participar en el rbol STP y cambiar nuestra topologa llegando a crear bcles.

Para protegernos de esto, aseguramos las interfaces para que si reciben una BPDU, directamente se
deshabilita el puerto y deja de enviar bdpus. El puerto se queda en estado de "blocking". Hay veces que no
podemos deshabilitar esa interfaz y, como solucin, configuraremos la opcin "drop" que descartar las bpdus
pero seguir enviando trfico. Estas interfaces no tienen que tener habilitada ninguna opcin de STP para
poder configurar "drop".
Para comprobar STP:

show spanning-tree interface

Tambin podemos comprobarlo en el log del equipo:

PROTECCIN DEL ROOT BRIDGE


Todos los puertos del root bridge tienen que estar en estado "designated". Si alguno de los puertos cambia a
"root port", es decir, ha recibido una BPDU superior y nuestra topologa se puede ver afectada.

Para protegernos de esto y que nuestra eleccin de root bridge no se vea afectada, podemos habilitar la
proteccin del root en los puertos:

Si el puerto recibe una BPDU superior, el switch pasar este puerto al estado de "blocking". De esta manera
prevenimos que otro switch se quiera coger el rol de "root bridge". Una vez que deja de recibir BPDU's
superiores, el puerto vuelve a pasar por los estados de listening, learning, forwarding.

En el ejemplo vemos que tambin aseguramos puertos en el switch2 para que no sean un root port.

Cuando el "root protection" es habilitado en una interfaz, este es aplicado a todas las instancias STP que haya
en ese puerto.

Es importante saber que el "bdpu protection" y el "root protection" no pueden configurarse en la


misma interfaz.

Para comprobar STP:


Captulo 4: Port Security

Por defecto, todas las interfaces de los switches EX son interfaces de capa 2 y no tienen nmero mximo de
direcciones mac que pueden aprender por cada puerto. Esto puede crearnos problemas de seguridad como un
rogue switch (switch que nos conectan a un puerto del nuestro y negocia con BPDU's), un dispositivo wireless
conectado tambin a un puerto del switch para negociar o un problema de "mac spoofing/flooding", que es un
intruso que cambia la direccin mac fsica o que est conectado al puerto y que puede hacer que el switch
limpie la tabla y vuelva a inundar por todos los puertos.

Se puede configurar cuntas y cules direcciones mac son permitidas para que entren en el puerto y se
aadan a la tabla mac.

Cuando limitamos el nmero mximo de macs que puede recibir por ese puerto, si se supera este lmite, el
trfico de esa mac que ya supera el lmite ser descartado. Esto se hace para evitar el flooding o ataque por
inundacin. Dependiendo del entorno, nos interesar limintar un nmero u otro. Por ejemplo, en entornos
donde hay VoIP tendremos que limitar a dos direcciones mac por puerto.

El otro mtodo es configurar manualmente las direcciones mac que son permitidas. Esto deshabilita el
aprendizaje dinmico. Deniega todo el trfico que no tenga esa fuente de origen.
Tambin se puede monitorizar la mac y decirle el nmero de veces que esa direccin mac se ha movido de un
puerto a otro en la misma vlan. Esto tambin previene el "mac spoofing" y los bucles.
Sin embargo, aqu se configura por VLAN y no por interfaz. Una vez habilitado, el switch comprueba las veces
que se ha movido la mac a una interfaz nueva y, si el nmero de veces en un segundo es superior a lo
configurado, llevar a cabo la accin que nosotros definamos.

Tenemos 4 acciones a la hora de aplicar cualquier tipo de proteccin:

None: no hace nada.

Drop: descarta las tramas y genera una alarma, un log o un aviso SNMP. Es la opcin por defecto.

Log: no descarta la trama pero genera un log.

Shutdown: deshabilita el puerto, bloquea el trfico y genera un log.

AUTORECOVERY

Cuando un puerto se queda en "port-error-disable" por una accin de seguridad, ese puerto no volver a estar
activo a no ser que limpiemos el error.

Para hacerlo manualmente:

#clear ethernet-switching port-error interface X

Tambin tenemos la opcin para que nos limpie el error pasado un intervalo de tiempo configurable. Esto es el
"Autorecovery". Est deshabilitado por defecto. El intervalo de tiempo que podemos configurar va de 10 a 3600
segundos.
Para que el switch lo haga automticamente:

#set ethernet-switching-options port-error-disable disable-timeout X

CONFIGURACIN DEL LMITE DE MACS

Podemos usar la opcin "none" para habilitar interfaces individuales cuando hemos aplicado la configuracin
para todas las interfaces (interface all):

Juniper siempre va a dar preferencia a la configuracin de las interfaces individuales sobre las configuraciones
globales cuando haya conflicto.

Para comprobar y limpiar:


Tambin podemos usar la opcin "Persistent Mac Learning". Se trata de configurar un nmero mximo de
direcciones mac que vamos a permitir que enven y reciban trfico desde el momento que conectamos el o los
dispositivos en el puerto del switch. Una vez llegado al nmero mximo que hemos configurado, el switch no
aprender ms direcciones mac por ese puerto.

Esta opcin viene deshabilitada por defecto.

Incluso si reiniciamos el switch o deshabilitamos la interfaz, las direcciones aprendidas se quedan grabadas.

Si queremos conectar otro dispositivo o si desconectamos el que tenemos y lo conectamos a otro puerto,
tendremos que hacer una limpieza de la tabla mac porque si no, no nos dara conectividad.

#clear ethernet-switching table persistent-mac

Existen una serie de reglas para configurar esta opcin:

1. Las interfaces tienen que estar en modo acceso


2. No se puede habilitar en interfaces que pertenezcan a un troncal redundante
3. No se puede habilitar en interfaces que tengan configurado autenticacin 802.1x
4. No se puede habilitar en interfaces que tengan habilitado el "no-mac-learning"
Para configurarlo:

#set ethernet-switching-options secure-access-port interface X persistent-learning

Comprobamos la tabla:

Aprendizaje Esttico de Direcciones Mac (static learning o sticky)

Otra manera de aportar seguridad a travs de las direcciones mac es configurar manualmente la direccin o
direcciones mac que vamos a permitir que enven y reciban trfico en ese puerto del switch.

Antes de configurarlo debemos asegurarnos que la VLAN est creada:

#set ethernet-switching-options static vlan X mac X next-hop interface X

DHCP (DYNAMIC HOST CONFIGURATION PROTOCOL)

Este protocolo asigna direcciones ip (y se le pueden aadir ms campos como DNS, Puerta de Enlace, etc) a
los clientes que lo soliciten, normalmente pc's.

El proceso de comunicacin del protocolo es el siguiente:


Como vemos son 4 pasos que siempre inicia el cliente.

DHCP expone nuestra red a riesgos de seguridad puesto que si alguien conecta un servidor DHCP a nuestra
red, podra reemplazar al corporativo y tomar el control de las asignaciones o lanzar ataques DoS. A este
equipo se le llamara "Rogue DHCP".

Para evitar este compromiso de la red utilizamos "DHCP Snooping". Con esta opcin lo que hacemos es
mantener una base de datos de las asignaciones que ha hecho el servidor (mac-direccin ip-vlan). Tambin
inspecciona los paquetes que vienen de los "puertos no confiables", es decir, los puertos de acceso. A los
troncales no les inspecciona. Esto es el comportamiento por defecto.

Cuando un cliente enva un DHCPRELEASE, el servidor DHCP desasocia la ip, la mac y la vlan de las
asignaciones. Tambin el servidor controla los intervalos de tiempo de la concesin de la direccin ip, la purga
y la caducidad de las entradas. El snooping solo ocurre cuando hay entradas asociadas a la interfaz. Si no hay
asociacin no se ejecuta, al igual que si el dispositivo tiene una ip fija configurada.

OPCIN 82 DEL DHCP

El dhcp snooping tambin incluye soporte a la opcin 82, el "Relay Agent". Esta caracterstica ayuda a evitar
ataques de "spoofing" y de "exhaustion" (cuando se llena la base de datos de entradas y tiene que forzar una
limpia).
Cuando un cliente est conectado a un puerto no confiable (untrusted), el switch reenva el "dhcprequest" con
informacin del cliente insertada en la cabecera. Cuando la peticin llega al Servidor DHCP, usa estos datos de
la opcin 82 para asignar y devuelve la trama con la misma opcin 82. Cuando llega al switch, este quita la
opcin 82 y le enva la trama al cliente. Se puede configurar para vlan, interfaces normales y tambin para
RVI's (Vlan Interfaces).

Hay que asegurarse que el Servidor DHCP soporta la opcin 82. Si no, el servidor no la usar y cuando vuelve
la peticin desde el servidor DHCP al switch, este ltimo la descartara.

En los equipos EX la implementacin de la opcin 82 aade 3 campos:

Circuit-Id
Remote-Id
Vendor-Id

Con el Relay Agent los flujos cambian un poco

Para configurar DHCP Snooping:


Cuando reiniciamos el switch se pierden las asociaciones (binding) que tenga. Si queremos que no suceda
esto, hay que configurarlo:

#set ethernet-switching-options secure-access-port dhcp-snooping-file location /.....

#set ethernet-switching-options secure-access-port dhcp-snooping-file write-interval X

Monitorizamos:

Para ver las asociaciones:

> show dhcp snooping binding

Para limpiar las asociaciones:

> clear dhcp snooping binding - limpia todas las entradas

> clear dhcp snooping binding vlan X - limpia todas las entradas para la Vlan que sea

> clear dhcp snooping binding vlan X mac X - limpia una entrada especfica
Vemos como desaparece la entrada de la base de datos

Cuando aadimos una entrada esttica y comprobamos la tabla

ARP - ADDRESS RESOLUTION PROTOCOL

Este protocolo hace asociaciones entre direcciones ip y direcciones mac, por lo tanto, es un protocolo de capa
3. Los equipos de comunicaciones mantienen una tabla de estas asociaciones, la tabla ARP.

"show arp" para mostrar la tabla

ARP Spoofing:

Tambin llamado ARP Poisoning. Este ataque de seguridad es usado por "the man in the middle" (el hombre
de en medio). El atacante sustituye la direccin mac de un dispositivo de comunicaciones como un Gateway
(Puerta de enlace) o un servidor. El resultado es que el trfico se dirige hacia el equipo del atacante que ha
sustituido la mac.
El trfico es desviado hacia el atacante

DAI - Dynamic ARP Inspection:

Sirve para protegernos de ataques ARP Spoofing. El DAI inspecciona todos los paquetes que entren en un
puerto no confiable (untrusted port) y los valida comparando con la base de datos del DHCP Snooping. Si no
existe la asociacin mac-ip en la base de datos o si la direccin ip no coincide, el equipo descartar los
paquetes.

Al depender de la base de datos del DHCP Snooping, este hay tenerlo habilitado.

Los puertos de acceso son no confiables por defecto. Los trunk son confiables y el DAI no inspecciona en los
puertos confiables (trusted ports).

Para hacer un puerto confiable:

#set ethernet-switching-options secure-access-port interface ge-0/0/0.0 dhcp-trusted

En los switches EX, el DAI viene deshabilitado por defecto. Para habilitar DAI, lo hacemos por VLAN y no por
puertos.

Los paquetes a inspeccionar son enviados a la RE, por lo que para prevenir una sobrecarga de la CPU, JunOS
limita el nmero de paquetes destinados a la RE.

Para configurar DAI:


DAI se configura por VLAN. En el ejemplo todos los puertos estn en la de por defecto

Si quisiramos habilitar DAI para dispositivos que no soportan DHCP, tenemos que definir una entrada esttica
en la base de datos del DHCP Snooping. Por ejemplo:

Para monitorizar el DAI:

IP ADDRESS SPOOFING
Un usuario puede cambiar su ip y crear problemas de seguridad. Es difcil encontrar al atacante. Para ello
tenemos una opcin de seguridad en los switches que podemos habilitar:

Ip Source Guard:

Cuando tenemos habilitado el "ip source guard", el switch inspecciona los paquetes y si no coincide con la
informacin de la base de datos del DHCP Snooping, descartar los paquetes.

Ip Source Guard construye su porpia tabla y la compara con la de la base de datos del DHCP Snooping.

Para configurarlo:

Ip Source Guard se configura por VLAN

Si quisiramos habilitar Ip Source Guard para dispositivos que no soportan DHCP, tenemos que definir una
entrada esttica en la base de datos del DHCP Snooping. Por ejemplo:
Usar "no-ip-source-guard" y "no-examine-dhcp" para deshabilitarlo

Para monitorizar:

Captulo 5: Device Security and Firewall Filters


TORMENTAS DE TRFICO

Cierto tipo de trfico como broadcast, multicast y unknown unicast pueden crear tormentas al generar un nivel de trfico
que pueda afectar a la red negativamente. Para reconocer una tormenta de trfico debemos saber si el trfico ha llegado a
una carga no normal para nuestra red, debemos saber cul es el tiempo de respuesta normal para detectar posibles
tormentas.

Para evitar esto habilitamos "storm control" en el equipo y este monitorizar los niveles de trfico y descartar paquetes
cuando alcance el nivel que hayamos configurado. Por defecto est configurado al 80% en todas las interfaces.
Para configurarlo:

#set ethernet-switching-options storm-control interface all bandwidth X

Vemos las opciones que nos da.


Tambin se puede configurar para interfaces individuales. Algo a tener en cuenta siempre es que si aplicamos el "storm
control" a un Agregado (dos interfaces unidas en una, lo que en Cisco es un Etherchannel), se configurar el bandwidth
para cada interfaz, es decir, si tenemos la ge-0/0/0.0 y la ge-0/0/1.0 y configuramos 15000 kpbs, sern 15000 para cada
interfaz haciendo un total de 30000 kpbs.

A esta configuracin le siguen las acciones, es decir, qu hace el equipo con la interfaz afectada por una
tormenta cuando supera el umbral. La opcin por defecto es descartar los paquetes (dropping), pero podemos
configurarlo para que deshabilite el interfaz (action-shutdown).

Para recuperar el interfaz cuando ha habido una violacin y se ha deshabilitado:

clear ethernet-switching port-error interface X


Tambin tenemos la opcin de que se recupere automticamente cuando deshabilita un interfaz pasado un
tiempo que nosotros configuramos.

por-error-disable y disable timeout para recuperar automticamente

Para monitorizar:

FIREWALL FILTERS

Firewall Filter es lo que Cisco llama access list (ACL). Estos filtros se tienen que poner tanto en entrada como
en salida (stateless), ya que no trazan las sesiones tcp, sino que examinan los paquetes individualmente. Los
firewall "statefull" trazan las sesiones y se pueden aplicar filtros y acciones para todo el flujo: se permite la
conexin inicial y, automticamente, se permite el flujo bidireccional.

Se suelen usar para permitir o denegar trfico e incluso monitorizar.


Los switches EX no soportan esta caracterstica de statefull, son todos "stateless". pero el chequeo de los
paquetes y los filtros se hace siempre sobre el hardware (PFE+TCAM), hacindolo ms eficiente, no como
Cisco.

Tipos de Filtro:

Est claro que en los filtros de capa 2 no podrn configurarse opciones para filtrar trfico en base a capas
superiores. Los filtros de capa 3 (routed-based) pueden ponerse en interfaces fsicas, loopbacks, agregados y
RVI's. Cuando los EX aplican un filtro a una loopback, la interfaz de gestin (me0) no se ve afectada si pasa
trfico por ella (esto pasaba en otros Junos).

Solo se puede configurar un filtro por VLAN, puerto o interface enrutable y en una direccin.

La clave en los filtros de firewall son los "term". Dentro de un term podemos tener ningno o varios "from"
(condiciones) y una o ms acciones (then). Si todos los "from" se cumplen, se toma la accin o acciones
especficas de dentro del "term". Si no hay ningn "from" configurado, todo el trfico estar sujeto a la accin
que hayamos definido.

Los filtros de firewall tienen por defecto un "term" que descarta los paquetes no especficamente permitidos (es
como un deny any any de Cisco).

Para crear un filtro al menos debe tener un "term".


Podemos usar en el "from" muchos campos de la cabecera (header) del paquete. Se suelen dividir en 3
categoras: rango numrico, direccin y el campo "bit". Por ejemplo, para filtro en puertos de capa 2 y VLAN:

Ya sabemos que el "from" es donde configuramos la condicin y es en el "then" donde configuramos la accin
a tomar:

Las acciones terminativas pueden llegar a parar la evaluacin de la poltica.

Accept: acepta el paquete y continua procesndolo.

Discard: descarta el paquete silenciosamente, sin mandar un ICMP de vuelta al origen para avisar.

Reject: descarta el paquete y avisa mandando un ICMP de vuelta al origen.

Se pueden modificar las acciones terminativas con los modificadores de accin. Pueden configurarse uno o
ms modificadores dentro de una misma accin terminativa. Si configuramos un modificador pero no se
especifica accin terminativa, el switch aplicar un "accept":
Count: conteo de nmero de paquetes que han pasado por el filtro

Policer: llama a una poltica de trfico

Analyzer: el switch duplica los paquetes para un posterior anlisis.

Forwardin-class y loss-priority son modificadores de CoS.

Como ya hemos dicho en un filtro de firewall la accin por defecto si un paquete no coincide con
ninguno de los criterios que hemos configurado se encontrar un "discard".

Sin embargo, en las polticas de enrutamiento si no coincide ser un "accept".

Ejemplo de configuracin de filtros:

1. Implementar filtros en los puertos de acceso para que solo deje pasar la mac del PC, descartar y contar las
tramas que no cumplan la condicin.

2. Tambin hay que implementar un filtro en las dos VLAN's para que no deje pasar las tramas que tengan una
mac de destino 01:80:c2:00:00:00 (Multicast para LLD). Descartar y contar tambin las tramas que no cumplan
el criterio.

Configuramos los filtros:

Configuramos el punto 1
Configuramos el punto 2

Aplicamos los filtros:

Para monitorizar:
Captulo 6: Virtual Chassis
Virtual chassis nos ofrece la posibilidad de conectar dos o ms switches EX para administrarlos como si fuera
una sola unidad. El nmero mximo de dispositivos que podemos interconectar depende de los modelos de
switch y la combinacin entre ellos.

XRE: Re Externa

Cuando aadimos la XRE es est la encargada del proceso del Virtual Chassis. Si tenemos dos XRE, el
master y el backup se elegir a la que ms tiempo lleve levantada (uptime).

En muchos entornos al agregar switches en Virtual Chassis se unen la capa de acceso y distribucin.

Cuando montamos un Virtual Chassis, uno de los switches representa el rol de "Master RE" y un segundo
switch como "Backup RE". Si tenemos redundancia de RE, podemos habilitar lo servicios NSR (nonstop active
routing) y NSB (nonstop active bridging), que nos permite una conmutacin transparente de master a backup y
al revs, sin que se reinicien protocolos de capa 2.

RE: Routing Engine; LC: Line Card

Cuando conectamos switches en Virtual Chassis, las PFEs estn conectadas a travs de los VCP (Virtual
Chassis Port), bien a travs de una conexin interna o, cuando conectamos a travs de los "uplink"
(normalmente de 10 Gb). Las conexiones internas se habilitan por defecto, es decir, cuando conectamos en
Virtual Chassis se crea el Virtual Chassis Backplane automticamente.
Si queremos usar los uplink, tenemos que configurar en el equipo:

user@Switch-1> request virtual-chassis vc-port set pic-slot 1 port 0

El interfaz xe-0/1/0 se convierte a vcp-255/1/0

CABLEADO EN VIRTUAL CHASSIS

Mtodo Daisy-Chained Ring

Mximo 5 metros de distancia del cable

Mtodo Braided-Chained Ring


Mximo 22,5 metros de dsitancia del cable

Mtodo Extended Ring

Mximo 100 km usando 1GBE o 10GBE

Otro factor importante a tener en cuenta es el lugar donde queda la RE en un Virtual Chassis. En caso de fallo
no queremos que se produzca una interrupcin en los servicios que comparten todos los switches. Para ello, el
emplazamiento de la RE debera ser:
ELECCIN DE MASTER

1. El miembro con la prioridad configurada ms alta (de 1 a 255, por defecto es 128)
2. El miembro que antes del reinicio funcionaba como master
3. El miembro que lleve ms tiempo levantado (la diferencia debe ser de ms de 1 min.)
4. El miembro con la direccin mac ms baja (se usa para desempatar la eleccin)
5. El segundo miembro elegido por el rbol de Virtual Chassis ser el miembro de backup. Los otros
miembros son los llamados "line cards", es decir, solo miembros planos que se convertirn en backup
si falla el master o el backup de ese momento.

El ID sirve tambin para identificar los nmeros de los slots de los puertos

El nmero del miembro cuenta para la nomenclatura de las interfaces

A todos los miembros del Virtual Chassis se les asigna un ID del 0 al 9. Se puede asignar manualmente y dejar
al Virtual Chassis que los elija, escogiendo siempre al 0 como master, que suele ser el primer switch que se
enciende, y asigna los ID segn vayan integrndose los miembros al Virtual Chassis. Hay que tener en cuenta
que el ID se conserva incluso si se reinicia el switch.

Si queremos configurar manualmente:

> request virtual-chassis renumber member-id 0 new-member-id 5

Si queremos apagar un miembro en concreto:

> request system halt member 0-9


Si queremos acceder a un miembro individual:

> request session member 0-9

Cuando tenemos que sustituir un switch miembro del Virtual Chassis, el ID de este no se libera ni lo hereda el
nuevo switch que instalemos. Los pasos recomendados por Juniper a la hora de reemplazar un switch
miembro de un Virtual Chassis. Vamos al "master" y:

1. Reciclamos o liberamos el ID del equipo que quitamos


2. Aadimos el nuevo switch y automticamente el nuevo coge el ID y la config del antiguo

Para ello:

> request virtual-chassis recycle member-id X

Cuando sustituimos un switch, el nuevo tiene que tener la misma versin de software. Si no la tiene, el master
le asignar un ID, generar un mensaje de Syslog y lo dejar en estado inactivo. Si este es el caso, habra que
actualizar el software antes de poder integrarlo en el Virtual Chassis.

Para la administracin del Virtual Chassis tenemos una interfaz de administracin (me0) y una direccin ip
dedicadas. Esta interfaz est asociada a la "interface vlan vme".

Los switches en Virtual Chassis dan conectividad al master por la interfaz me0 fsica de cualquiera de los
miembros. Siempre nos podremos conectar a los switches del chassis individualmente a travs de conexiones
vty con el comando: request session member X

ACTUALIZACIN DEL SOFTWARE

Se puede actualizar el software de todo el Virtual Chassis o de uno de los miembros. Siempre se har desde el
master:

> request system software add - para todo el chassis


> request system software add member X - para un miembro en concreto

El switch se puede actualizar manualmente, es decir, entramos en el switch y lo actualizamos o, podemos


hacerlo automticamente haciendo que el nuevo switch coja el software de los equipos miembros que ya
forman el Virtual Chassis y de esta manera se integre inmediatamente en el chassis. A esto le llama Juniper
el NSSU (nonstop software upgrade)

El NNSU tiene la capacidad de actualizar el software en el Virtual Chassis con una menor interrupcin del
servicio. Para poder habilitar NSSU el Virtual Chassis tiene que cumplir los siguientes requerimientos:

Los miembros tienen que estar conectados en anillo (ring)


Master y backup deben ser equipos adyacentes para asegurar la sincronizacin
Mismo software en todos los miembros
NSR y GRES (graceful routing engine switchover) estarn habilitados
Los line cards deben haber sido provisionados (configurados explcitamente)
Opcionalmente podemos habilitar NSB
Podemos hacer un backup previo de la config: request system snapshot

Cuando actualicemos 2 miembros de un Virtual Chassis usaremos la opcin "no-split-detection" para evitar que
los separe del Chassis.

Proceso para actualizar usando NSSU:

Bajamos el paquete de software


Copiamos el software en el switch master. Recomendado guardarlo en: /var/tmp
Entrar en el switch por consola o por la vme.
Iniciar el proceso NSSU que consiste en:

1. request system software nonstop-upgrade /var/tm/paquetedesoftware.tgz


2. Si tenemos un entorno mixto con diferentes modelos:

request system software nonstop-upgrade set [ /var/tm/paquete1.tgz /var/tm/paquete2.tgz]

Descubrimiento de la Topologa

Virtual Chassis usa VCCP (Virtual Chassis Control Protocol) para descubrir la topologa y asegurar que no
haya bucles. Cada miembro del chassis enva LSA, mensajes de descubrimiento entre las PFE
interconectadas. En base a estos mensajes se construye la topologa de PFE's para determinar el mejor
camino de comunicacin entre las PFE.
Una vez creada la topologa se ejecuta individualmente en cada PFE el algoritmo SPF. Este algoritmo se basa
en el nmero de saltos y el ancho de banda. Al final cada PFE tendr una tabla para llegar a las otras PFEs.

Para prevenir bucles se crea un ID fuente de salida para cada PFE

Ejemplo de descubrimiento de la topologa. Es un proceso automtico.


Flujo de intercambio de paquetes

Los paquetes escogen siempre el camino ms corto a travs de los miembros del Virtual Chassis.
Para configurar un Virtual Chassis:

#set virtual chassis...

Opciones de Virtual Chassis


Tambin podemos configurar el GRES (graceful routing engine switchover):

#set chassis redundancy switch-over

Configuracin dinmica:

1. Instalamos el switch que queremos que sea Master. Lo encendemos el primero, coge el ID 0 y le
configuramos una prioridad de 255 (0-255, 128 es la de por defecto).
2. Instalamos el switch que queramos como backup. Conectamos los cables VC, lo encendemos, coge el
ID 1 y le asignamos una prioridad de 255. As nos aseguramos que cualquier otro switch que
aadamos al VC, no tomar ni el rol de master ni el de backup.
3. Aadimos un Line Card Switch (switch que pertence al VC pero que no es master ni backup).
Conectamos los cables VC. Dinmicamente se le asignar el ID 2
4. Repetimos el paso 3 hasta que instalamos el ltimo LC Switch y conectamos los cables VC (uno
cerrar el anillo y tendr que conectarse con el master)

#set virtual-chassis member mastership-priority X

Tambin podemos hacer una preprovisin, es decir, configuramos los roles de los switches antes de formar un
Virtual Chassis. Para ello, configuramos el switch que queramos que tome el rol de master y le configuramos
los roles de los switches que posteriormente encenderemos y aadiremos:

Para monitorizar el VC:

show virtual-chassis ?

sh virtual-chassis vc-port
sh configuration virtual-chassis; show virtual-chassis status

Para habilitar los VC Ports:

> request virtual-chassis vc-port set pic-slot X port X local - para asignar

> request virtual-chassis vc-port delete pic-slot X port X local - para borrar

Disable = los hemos tirado nosotros; Down = cable no conectado/fallo otro extremo

Captulo 7: High Availability Features

Captulo 7: High Availability Features


Con High Availability (alta disponibilidad) Juniper nos habla de la capacidad para asegurar la continuidad de los
servicios.
Para maximizar la disponibilidad de los recursos tendremos que tomar algunas consideraciones a la hora de
hacer el diseo de la red:

Estn las funcionalidades bsicas del hardware y software protegidas?


Cuando ocurre un fallo, cmo reacciona la red y qu nivel de recuperacin presenta?

Para proteger bien un red tendremos que redundar el hardware y tambin usar protocolos para redundar o
recuperar servicios. Por ejemplo, los switches EX disponen de una serie de caractersticas para incrementar la
disponibilidad de la red. Destacamos las siguientes:

Link Aggregation Groups (LAGS) - Combina mltiples interfaces ethernet en una sola. Est definido en el
802.3ad.
Redundant Trunk Groups (RTG) - Redundancia de enlaces de capa 2
Greaceful Routing Engine Switchover (GRES) - Controla la comunicaciones entre las RE master y backup
Nonstop Active Routing (NSR) - Habilita un cambio de RE sin prdidas de servicio
Nonstop Bridging (NSB) - Igual que NSR pero con protocolos de capa 2

LINK AGGREGATION GROUPS - LAGS

Cuando se implementa LAGS se hace en conexiones P2P entre dos dispositivos. Dependiendo del nmero de
interfaces que participen, incrementar proporicionalmente el ancho de banda del LAG y adems aumenta
tambin la disponibilidad para transportar trfico si se cae un interfaz.

Para crear un LAG hay que tener en cuenta que:

La configuracin del Duplex tiene que ser igual en ambos equipos


Un mximo de 8 interfaces para formar un LAG
Los miembros no tienen por qu estar conectados por puertos contiguos y pueden ser miembros de diferentes
Virtual Chassis.

Consideraciones sobre el procesamiento del trfico cuando hemos configurado un LAG:


Todo trfico generador por la RE que atraviese el LAG usar el miembro ms bajo
El algoritmo de balanceo de "trfico IP" usa criterios de capa 2, 3 y 4. No se necesita configurar nada para
habilitar el balanceo de carga.
El algoritmo de balanceo de "trfico NO IP" usa las direcciones mac de origen y destino

El protocolo que usa Junos es LACP - Link Aggregation Control Protocol (802.3ad). Se usa para unir dos o ms
interfaces fsicas en una lgica, para interfaces Tagged (Troncal) o Untagged (de acceso).

El modo de los equipos puede ser activo o pasivo. Siempre tendr que haber uno activo para formarse. Al
equipo local se le llama "actor" y al remoto se le llama "partner". Se intercambian siempre PDU's a travs de
todos los enlaces fsicos para asegurarse de que estn funcionando todos los enlaces correctamente.

Para crear un LAG:

#set chassis aggregated-device ethernet device-count X - siendo X el nmero de LAGS que creamos

Cuando creamos LAGS empieza la nmeracin con ae0

Y despus configuramos las interfaces ethernet:


Configuracin de un Aggregated de capa 2

Por defecto, los equipos mandan paquetes LACP cada segundo. Este intervalo se puede modificar:

#set interfaces ae0 aggregated-ether-options lacp periodic fast/slow

Si configuramos fast el intervalo es cada segundo. Slow es cada 30. Se puede incluso configurar a diferente
intervalo cada equipo.

Para monitorizar LACP:

Tambin podemos usar: show lacp interfaces o show interfaces lacp statistics

Para monitorizar a travs de un traceoption, tenemos que hacerlo desde "protocols lacp".
REDUNDANT TRUNK GROUPS - RTG

Es un simple mecanismo de redundancia de capa 2. Se puede usar en sustitucin de STP en enlaces entre
switches.

Cuando el activo falla, entra el backup. Tiempo de respuesta de menos de 1 segundo

Junos solo manda trfico por el activo y descarta los del backup. Estos descartes se pueden ver en las
estadsticas del interface. Sin embargo, el trfico de control s lo permite, como el LACP o el LLDP. Solo
descarta el trfico de datos.

Algunas consideraciones:

RTG se suele configurar en switches de acceso


RTG y STP no pueden coexistir en el mismo puerto
RTG descarta las BPDU de STP
STP se suele configurar en switches de distribucin (aggregation)
Si se configura RTG como TRUNK, deben compartir las mismas vlans
Mximo de 16 RTG por switch

Un ejemplo de configuracin:

Configurar RTG en el switch 3 y asegurarse de que el trfico se enva por el ae0.0 siempre que est operativo.
En el switch 3:

#set ethernet-switching-options redundant-trunk-group group rtg-1 interface ae0.0 primary

#set ethernet-switching-options redundant-trunk-group group rtg-1 interface ge-0/0/10.0

Si no ponemos el "primary", elegir la interface ms alta en nmero

Para monitorizar el RTG:

show redundant-trunk-group

GRACEFUL ROUTING ENGINE SWITCHOVER - GRES

GRES habilita a un switch con dos RE o que est participando en un Virtual Chassis la capacidad de continuar
enviando paquetes con la menor interrupcin de trfico posible cuando la RE master ha fallado. GRES
mantiene la informacin de las interfaces y el kernel asegurando que no se interrumpe trfico. Sin embargo, no
conserva el plano de control, por lo que procesos como el de routing (rpd) se deben ejecutar otra vez y
aprender las rutas (a no ser que tengamos configurado NSR). Todos los cambios de las RE master se
actualizan en la de backup.

Sin GRES, la PFE se reinicia, reiniciara todos los procesos y descubrira la RE de backup.

Con GRES, la PFE no se reinicia. Esto reduce considerablemente el tiempo del "switchover".

GRES est deshabilitado por defecto.

Proceso del GRES

1. Una vez configurado GRES, las RE's se sincronizan e intercambian paquetes "keepalive".
2. Si la RE de backup no recibe un keepalive en 2 segundos (por defecto), determina que la RE principal
ha fallado y toma el rol de Master.
3. La PFE se desconecta de la RE principal y se conecta a la de backup. La PFE no se reinicia y sigue
enviando trfico en base a las entradas de la tabla de "forwarding".
4. La nueva RE master y la PFE se sincronizan y la RE manda "updates" a la PFE.

Si quisiramos hacer un cambio de RE manualmente, tendramos que usar:

>request chassis routing-engine master switch

Para configurar GRES:

#set chassis redundancy graceful-switchover

Para monitorizar GRES:


show system switchover - solo en la RE de backup

La RE master replica su estado a la RE de backup y a la PFE. Hay 3 estados importantes a copiar:

Configuration database: se replica cuando hacemos "commit synchronize"


Kernel y entradas relacionadas: se inicia un proceso llamado "ksyncd" que es el responsable de la
replicacin de varios de los componentes hardware.
Estado de la PFE: el proceso "chassisd" hace un reinicio suave para preguntar por el hardware cuando hay un
cambio del rol de la RE

NONSTOP ACTIVE ROUTING - NSR

NSR habilita al equipo con dos RE o en Virtual Chassis la capacidad de cambiar del primario al backup sin
alertar a los nodos. NSR usa la misma infraestructura de GRES. NSR guarda la informacin del proceso de
routing "rpd" en el backup, manteniendo rutas y protocolos en activo.

Las RE tienen que tener la misma versin de Junos. No soporta todos los protocolos ni se puede configurar en
todos los equipos EX.

Para configurar NSR:

#set routing-options nonstop-routing

#commit synchronize

Es importante recordar que para configurar NSR se necesita configurar tambin GRES.

Para monitorizar NSR:


show task replication - se pueden ver tambin protocolos

NONSTOP BRIDGING ROUTING - NSB

NSB habilita al equipo con dos RE o en Virtual Chassis la capacidad de cambiar del primario al backup sin
alertar a los nodos. NSB usa la misma infraestructura de GRES. tambin salva la informacin de capa 2
usando el proceso "eswd" en el equipo de backup. NSB hace lo mismo que NSR pero con los protocolos de
capa 2 en vez de los de capa 3.

Las RE tienen que tener la misma versin de Junos. No soporta todos los protocolos de capa 2 ni se puede
configurar en todos los equipos EX.

Para configurar NSB:

#set ethernet-switching-options nonstop-bridging

#commit synchronize

Es importante recordar que para configurar NSB se necesita configurar tambin GRES.

No hay ninguna tabla especfica para comprobar si NSB est funcionando correctamente. Tendremos que ir al
equipo de backup y ver que la capa 2 est todo bien.

>show spanning-tree bridge

Si nos apareciera el siguiente mensaje, querra decir que no est configurado en el equipo:

error: the ethernet-switching subsystem is not running


Captulo 8: Ethernet Ring Protection Switching
ERPS se define en el estndar ITU-T G.8032. Es un protocolo que provee estabilidad y un entorno libre de
bucles. Es una solucin para anillos ethernet que puede proporcionar un tiempo de respuesta por debajo de
los 50ms. Se puede usar en sustitucin del STP. El mnimo para montar un anillo son 3 nodos y, se recomienda
no superar los 16 nodos.

ERPS no es soportado por todos los modelos de EX

La idea es que uno de los enlaces se use para proteger el anillo. Este enlace es el RPL (Ring Protection Link).
El que controla este enlace es el RPL Owner y mientras estn todos los dems enlaces levantados, el RPL
permancer en estado de "blocking". Cuando falle uno, har los clculos necesarios para habilitar el anillo.
Solo habr un RPL Owner por anillo.

El RPL Owner enva mensajes peridicos del tipo R-APS (Ring Automatic Protection Switching) para notificar a
los otros nodos el estado del RPL. Escucha y enva mensajes. Sin embargo, cuando el fallo es en un equipo
normal, los propios equipos locales mandarn mensajes APS para notificar a los dems la cada del enlace.

El Protocolo APS

APS necesita un canal dedicado para enviar y recibir los mensajes R-APS, que ser una VLAN.

Usa CFM (Connectivity Fault Management) para el formato de las tramas. Para diferenciar los mensajes APS
de otros mensajes tipo CFM, APS usa como direccin de destino 01-19-A7-00-00-01, con un Upcode de 40 y
el Flag en 0.
Request/State: 4 bits. Valores: 0000 - no hay fallos; 1011 - seal de fallo
Reserved 1: 4 bits. Valor: siempre 0000
RPL Blocked: 1 bit. Solo el Owner puede ponerlo en este estado.
Do not flush: 1 bit. Valores. 1 para no hacer flush; 0 para hacer un flush.
Status Reserved: 6 bits. Valor: siempre 0000
Node ID: 6 octetos. Direccin mac nica
Reserved 2: 24 octetos. Valor: todo a 0000

Cuando el anillo est funcionando correctamente, todos los nodos estn en estado IDLE. Durante este estado
es el Owner quien pone en estado de blocking al RPL. El Owner enva peridicamente mensajes R-APS cada
5 segundos sealizando que no hay problemas en el anillo.

Cuando hay un fallo se lanza una "seal de fallo":

Switch 2 y 3:

Esperan a que pase el intervalo de tiempo de espera (por defecto 0)


Cambian de estado IDLE al estado de PROTECTION
Bloquean los puertos que han fallado y limpia las tablas mac (flush)
Envan 3 mensajes en los 10ms primeros seguidos por uno cada 5 segundos hasta que las condiciones de la
cada se recuperan.

En el resto de los switches que participan:


Cambian de estado IDLE al estado de PROTECTION
Limpian las mac y paran de enviar mensajes R-APS

RPL Owner:

Desbloquea el RPL
Escucha los mensajes R-APS de los switches 2 y 3

Se desbloquea el RPL y volvemos a tener el anillo

Cuando se recupera de un "fallo de enlace":

Cuando el enlace entre switch2 y 3 se recupera, empiezan a mandar R-APS (request/state=no request) para
decir que el fallo no est ya presente y que no limpien la tabla de direcciones mac (do not flush=1). Mantienen
los puertos en bloqueo hasta que llegan los R-APS hasta el RPL Owner.

Una vez que el RPL Owner recibe los mensajes R-APS:

El Owner espera un tiempo de recuperacin (5 minutos por defecto)


Bloquea el RPL y enva R-APS (request/state=no request;RPLBlocked=1;Do not flush=0)
Los dems switches desbloquean puertos y limpian sus tablas de direcciones mac
Todos los switches cambian del estado de PROTECTION al estado de IDLE.
CONFIGURACIN DE ERPS

Opciones de configuracin

Siempre hay que configurar una interfaz ESTE y otra OESTE

Guard Interval: deshabilitado por defecto. Configura intervalos de 10ms hasta los 2000ms. Se usa para
prevenir la recepcin de mensajes R-APS caducados, descartando los mensajes que lleguen durante este
tiempo. Cuando llega un R-APS correcto, este intervalo se pone a 0.

Restore Interval: especifica el nmero de minutos que el nodo espera antes de procesar las PDU's de ERP

CONFIGURACIN DEL RPL OWNER


Configurar las dos interfaces del switch 1
Vlan de datos: 101
Vlan de control: 100
En modo trunk hay que especificar las vlans que pasan

Configuramos el PROTECTION GROUP como Owner en el switch 1


Una interface ESTE y otra OESTE

CONFIGURACIN DE UN NODO NORMAL


Para monitorizar:

show protection-group ethernet-ring

Al tener el RPL bloqueado y el Originator en "yes", sabemos que es el Owner

Para ver las interfaces que participan en el anillo:

Cuando el "admin state" est en "ready", el canal de control est habilitado para enviar R-APS
Para ver los detalles del nodo local:

Para ver estadsticas del nodo:

Para limpiar estadsticas: clear protection-group ethernet-ring group-name X

Captulo 9: Multiple Spanning Tree Protocol


MSTP provee una extensin del RSTP. Permite crear mltiples instancias (MSTI) para balancear trfico de todos los
enlaces fsicos disponibles.

Cada instancia MSTP, es decir, cada MSTI crea una topologa de STP que podemos mapear a una o varias vlans. As
podemos redundar y balancear el trfico de capa 2.
En MSTP un puerto puede pertenecer a varias vlans y puede ser dinmicamente bloqueado en una instancia y permitido en
otra. Esto reduce el consumo de recursos de la red y mantiene las CPU a un nivel ptimo. Tambin provee el tiempo de
reconvergencia de RSTP.

MSTP permite agrupar switches en una "Regin MST", donde comparten nombre del grupo de la regin, nivel de
revisin y los mapeos de las instancias con las vlan. Cada regin soporta hasta 64 MSTI.

MSTP reduce el nmero de BPDU's en la LAN incluyendo la informacin de spanning-tree para todas las MSTI en una
nica BPDU.

MSTP elige un "root bridge" regional para cada MSTI, que se calcula en base a la prioridad.

MSTP es compatible con STP y RSTP gracias a CST, que permite interconectar mltiples regiones MST o conectar una
MST con un switch donde se ejecuta solo STP.

CST: Common Spanning Tree

Los 13 primeros campos aseguran la compatibilidad

Todos los entornos MSTP contienen un CST. Todos los bridges en CST eligen un nico root bridge, que es el responsable
de calcular el camino para el CST. Los bridges fuera de la regin tratan a cada regin como si fuera un Virtual Bridge,
independientemente del nmero de dispositivos que participen en cada regin MST.

El CIST (Common and Internal Spanning Tree) es una topologa que conecta todos los switches RSTP y MSTP
a travs de una topologa ACTIVA. Crea un nico rbol de spanning tree calculado por RSTP.

Luego cada regin MST tiene su propio rbol de spanning tree, al que se le llama Spanning Tree Interno, que
se conforma gracias a los campos de BPDU que quedan libres. Todos los switches que pertenezcan a la
misma regin debern tener el mismo "Configuration ID". Una vez que el rbol interno est constituido, por
defecto, todas las vlans seguirn este rbol.

Si no configuramos MSTI, todas las vlan irn por el mismo spanning tree interno. La informacin que tienen los
mensajes MSTI permite la eleccin del root bridge, root ports, designated ports, etc. Cada MSTI puede tener
una o varias vlans asociadas. Sin embargo, una vlan no puede pertenecer a ms de una MSTI. La MSTI no
lleva ninguna informacin de la VLAN ID. El mapeo de la VLAN con el MSTI se hace localmente en los
switches, por lo que habr que configurarlos iguales en todos los que queramos que participen.

CONFIGURACIN DE MST

Las vlan que no estn mapeadas se asocian directamente a la MSTI 0 (CST)

EJEMPLO DE CONFIGURACIN
Configurar MSTP de manera que DS-1 y DS-2 acten como Root Bridge para sus respectivas instancias
Si DS-1 o DS-2 fallan, hay que asegurarse que el otro switch asume el rol de Root Bridge

Los switches AS tendrn la prioridad del bridge por defecto, es decir, 32768

Para monitorizar MSTP: