Descripción general sobre puentes

Los puentes se utilizan para conectar segmentos de red independientes y actúan como rutas entre dos nodos. Cuando están conectados por un puente, los segmentos de red se comunican como si fueran un solo segmento de red. Los puentes se implementan en la capa de enlace de datos (L2) de la pila de red. Los puentes utilizan un mecanismo de reenvío de paquetes para conectar subredes.

Si bien tanto los puentes como el enrutamiento pueden utilizarse para distribuir información sobre las ubicaciones de los recursos de la red, difieren en varios aspectos. El enrutamiento se implementa en la capa IP (L3) y utiliza protocolos de enrutamiento. No se utilizan protocolos de enrutamiento en la capa de enlace de datos. En cambio, los destinos de los paquetes reenviados se determinan mediante el análisis del tráfico de red que se recibe en los enlaces conectados al puente.

Cuando se recibe un paquete, se analiza su dirección de origen. La dirección de origen del paquete asocia el nodo desde el que el paquete se envió con el enlace en el que se recibe. A partir de ese momento, cuando un paquete recibido utiliza la misma dirección como la dirección de destino, el puente reenvía el paquete por el enlace a dicha dirección.

El enlace asociado con una dirección de origen puede ser un enlace intermedio conectado a otro puente en la red con puentes. Con el tiempo, todos los puentes dentro de la red con puentes "aprenden" qué enlace envía un paquete hacia un nodo determinado. Por lo tanto, la dirección de destino del paquete se utiliza para dirigir el paquete a su destino final por medio de puentes salto a salto.

Una notificación local de “enlace inactivo” indica que todos los nodos de un enlace determinado ya no son accesibles. En esta situación, el reenvío de paquetes al enlace se detiene, y todas las entradas de reenvío por el enlace se vacían. Las entradas de reenvío anteriores también se van vaciando con el paso del tiempo. Cuando un enlace se restaura, los paquetes recibidos por medio del enlace se tratan como nuevos. El proceso de “aprendizaje” basado en la dirección de origen de un paquete comienza de nuevo. Este proceso permite que el puente reenvíe correctamente paquetes por medio de dicho enlace cuando la dirección se utiliza como la dirección de destino.

Para reenviar paquetes a sus destinos, los puentes deben escuchar en modo promiscuo en cada enlace que está conectado al puente. La escucha en modo promiscuo hace que los puentes se vuelvan vulnerables a la aparición de bucles de reenvío, en los cuales los paquetes circulan continuamente a máxima velocidad. Por lo tanto, los puentes utilizan el mecanismo de protocolo de árbol de expansión (STP) para evitar bucles de red que harían que las subredes se vuelvan inutilizables.

Además de utilizar el protocolo de árbol de expansión (STP) y el protocolo de árbol de expansión rápida (RSTP, Rapid Spanning Tree Protocol) para puentes, Oracle Solaris admite la mejora de protección de interconexión transparente de muchos enlaces (TRILL, Transparent Interconnection of Lots of Links). El STP se utiliza de manera predeterminada; pero usted puede utilizar TRILL especificando la opción -P trill para los comandos de puentes.

El uso de una configuración de puentes simplifica la administración de los distintos nodos en la red conectándolos en una única red. Gracias a la conexión de estos segmentos por medio de un puente, todos los nodos comparten una única red de difusión. Por lo tanto, cada nodo puede acceder a los otros mediante protocolos de red, como el protocolo IP, en lugar de hacerlo mediante enrutadores, para reenviar tráfico por segmentos de red. Si no utiliza un puente, debe configurar el enrutamiento IP para permitir el reenvío de tráfico IP entre nodos.

Figura 4-1 Red con puentes simple

En la siguiente figura, se muestra una configuración de red con puentes sencilla. El puente, goldengate, es un sistema de Oracle Solaris que tiene puentes configurados. Los sistemas sanfrancisco y sausalito están físicamente conectados al puente. La red A utiliza un concentrador que está conectado físicamente al puente en un lado y a los sistemas informáticos en el otro lado. Los puertos del puente son enlaces, como bge0, bge1 y bge2.

Las redes con puentes se pueden estructurar en forma de anillos que conecten físicamente varios puentes juntos. Estas configuraciones son comunes en las redes. Este tipo de configuración podría causar problemas con paquetes antiguos que saturan los enlaces de red generando bucles constantes alrededor del anillo. Para protegerse contra tales condiciones de generación de bucles, los puentes de Oracle Solaris implementan los protocolos STP y TRILL. Recuerde que la mayoría de los puentes de hardware también implementan la protección contra bucles STP.

En la siguiente figura, se muestra una red con puentes configurada en un anillo. La configuración muestra tres puentes. Dos sistemas están conectados físicamente al puente westminster. Un sistema está conectado físicamente al puente waterloo. Un sistema está conectado físicamente al puente tower. Los puentes están conectados físicamente entre ellos mediante los puertos de puente.

Figura 4-2 Anillo de red con puentes

Cuando se utiliza STP o RSTP para la protección contra bucles, el bucle físico se mitiga evitando que una de las conexiones en el bucle reenvíe paquetes. En la Figura 4-2, se muestra que el enlace físico entre los puentes westminster y tower no se utiliza para reenviar paquetes.

Tenga en cuenta que mediante el cierre de enlaces físicos utilizables para realizar la protección contra bucles, STP y RSTP consumen ancho de banda.

A diferencia de STP y RSTP, TRILL no cierra enlaces físicos para evitar bucles. En cambio, TRILL calcula la información de la ruta más corta para cada nodo TRILL de la red y utiliza dicha información para reenviar paquetes a destinos individuales.

Como resultado, TRILL permite que el sistema deje todos los enlaces en uso en todo momento. Los bucles no son un problema, ya que se manejan de forma similar a la forma en que IP maneja los bucles. Es decir, TRILL crea rutas cuando son necesarias y utiliza límites de salto de reenvío para evitar problemas causados por estados de bucles momentáneos.

---

Precaución - No establezca el valor local-mac-address?=false en las plataformas SPARC. Si lo hace, los sistemas utilizaran de manera errante la misma dirección MAC en varios puertos y en la misma red.

---

---

Precaución - No configure un enlace en un puente cuando se requieren los mayores niveles posibles de rendimiento. El establecimiento de puentes requiere que las interfaces subyacentes se encuentren en modo promiscuo, lo que desactiva una cantidad de optimizaciones importantes que están en el hardware, el controlador y las demás capas del sistema. La desactivación de estas mejoras de rendimiento es una consecuencia inevitable del mecanismo de puentes. Puede utilizar un puente en un sistema donde algunos de los enlaces del sistema no están conectados y, por lo tanto, no están sujetos a dichas restricciones. Estos problemas de rendimiento sólo afectan a esos enlaces que están configurados para formar parte de un puente.

---

Para obtener información sobre STP, consulte IEEE 802.1D-1998. Para obtener información sobre RSTP, consulte IEEE 820.1Q-2004. Para obtener información sobre TRILL, consulte Internet Engineering Task Force (IETF) TRILL draft documents.

Propiedades de enlaces

Las siguientes propiedades de enlace pueden ser vistas por el comando dladm show-linkprop y modificadas por los comandos dladm set-linkprop y reset-linkprop:

default_tag

Defina el ID de la red de área local virtual (VLAN) predeterminado para paquetes sin etiqueta que se envían al enlace y desde él. Los valores válidos van de 0 a 4094. El valor predeterminado es 1. Sólo los enlaces de tipo de tarjeta de la interfaz de red (VNIC) no virtual y no VLAN tienen esta propiedad. La configuración de este valor en 0 desactiva el reenvío de paquetes sin etiqueta hacia el puerto y desde él. (Esta es una propiedad MAC).

---

Nota - Esta propiedad también se utiliza fuera del ámbito de los puentes para especificar el identificador de VLAN de puerto (PVID, port VLAN identifier) de IEEE para el enlace. Cuando default_tag no es cero, no puede crear una VLAN que tiene ese mismo ID en el enlace, porque el enlace base representa automáticamente el PVID por sí mismo.

Por ejemplo, si el PVID se establece en 5, en net0, no puede crear una VLAN con ID 5 en net0. Para especificar la VLAN 5 en esta situación, use net1.

No puede establecer default_tag igual al ID de cualquier VLAN existente que se crea en ese enlace. Por ejemplo, el comando siguiente crea la VLAN 22 en net0:

# dladm create-vlan -l net0 -v 22 myvlan0

En esta situación, no puede establecer default_tag en 22, ya que haría que net0 y myvlan0 representen la misma VLAN.

Si establece default_tag en 0, permite que los paquetes sin etiquetas en net0 no estén asociados con ninguna VLAN. Esta situación evita que los paquetes se reenvíen por un puente configurado.

---

forward

Activa y desactiva el reenvío de tráfico por medio del puente. Esta propiedad existe en todos los enlaces, excepto para los enlaces VNIC. Los valores válidos son 1 (true) y 0 (false). El valor predeterminado es 1. Cuando el reenvío de tráfico está desactivado, una VLAN asociada con una instancia de enlace no reenviará tráfico por medio del puente. La desactivación del reenvío es equivalente a la eliminación de la VLAN del “conjunto permitido” para un puente tradicional. Esto significa que la E/S basada en VLAN al enlace subyacente de clientes locales continúa, pero no se realiza ningún reenvío basado en puentes.

stp

Activa y desactiva STP y RSTP. Los valores válidos son 1 (true) y 0 (false). El valor predeterminado es 1, que activa STP y RSTP. Si esta propiedad se establece en 0, el enlace no utiliza STP o RSTP, y se coloca en modo de reenvío en todo momento. El modo de reenvío utiliza la protección de unidad de datos de protocolo de puente (BPDU). Desactive STP y RSTP cuando desee configurar enlaces punto a punto que estén conectados a nodos finales. Sólo enlaces de tipo no VLAN y no VNIC tienen esta propiedad.

stp_cost

Representa valores de costo de STP y RSTP para usar el enlace. Los valores válidos van de 1 a 65535. El valor predeterminado es 0, que se usa para señalar que el costo se calcula automáticamente por tipo de enlace. Los siguientes valores representan el costo de varios tipos de enlace: 100 para 10 mbit/segundo, 19 para 100 mbit/segundo, 4 para 1 gbit/s y 2 para 10 gbit/s.

stp_edge

Especifica si el puerto está conectado a otros puentes. Los valores válidos son 1 (true) y 0 (false). El valor predeterminado es 1. Si esta propiedad se establece en 0, el daemon asume que el puerto está conectado a otros puentes, incluso si no se detectan BPDU de ningún tipo.

stp_p2p

Especifica el tipo de modo de conexión. Los valores válidos son true, false y auto. El valor predeterminado es auto, que detecta automáticamente conexiones punto a punto. Especifique true para forzar el modo de punto a punto. Especifique false para forzar el modo de varios puntos normal.

stp_priority

Define el valor de prioridad de puerto de STP y RSTP. Los valores válidos van de 0 a 255. El valor predeterminado es 128. El valor de prioridad de puerto de STP y RSTP se utiliza para determinar el puerto raíz preferido de un puente anteponiendo el valor al PVID. Cuanto más bajo sea el valor numérico, más alta será la prioridad.

Daemon de STP

Cada puente que crea usando el comando dladm create-bridge se representa como una instancia de la utilidad de gestión de servicios (SMF, Service Management Facility) denominada de manera idéntica de svc:/network/bridge. Cada instancia ejecuta una copia del daemon /usr/lib/bridged, que implementa el STP.

Por ejemplo, el siguiente comando crea un puente denominado pontevecchio:

# dladm create-bridge pontevecchio

El sistema crea un servicio SMF denominado svc:/network/bridge:pontevecchio y un nodo de observación denominado /dev/net/pontevecchio0.

Por motivos de seguridad, todos los puertos ejecutan el STP estándar de manera predeterminada. Un puente que no ejecuta alguna forma de protocolo de puentes, como STP, puede formar bucles de reenvío duraderos en la red. Debido a que Ethernet no tiene recuento de saltos ni lógica de transistor a transistor (TTL, Transistor-to-Transistor Logic) en paquetes, cualquiera de esos bucles son críticos para la red.

Cuando sabe que un puerto concreto no está conectado a otro puente (por ejemplo, porque tiene una conexión punto a punto directa a un sistema host), puede desactivar administrativamente el STP de ese puerto. Incluso si todos los puertos de un puente tienen el STP desactivado, el daemon de STP se sigue ejecutando. El daemon se sigue ejecutando por los siguientes motivos:

• Para poder manejar los nuevos puertos que se agregan.

• Para implementar la protección de BPDU.

• Para activar o desactivar el reenvío en los puertos, según sea necesario.

Cuando un puerto tiene el STP desactivado, el daemon bridged escucha BPDU (protección de BPDU). El daemon utiliza syslog para marcar los errores y desactiva el reenvío en el puerto para indicar un error grave de la configuración de la red. El enlace se activa nuevamente cuando el estado del enlace se desactiva y se vuelve a activar, o cuando usted elimina manualmente el enlace y lo vuelve a agregar.

Si desactiva la instancia del servicio SMF de un puente, el reenvío de puentes se detiene en dichos puertos porque el daemon de STP se detiene. Si la instancia se reinicia, el STP comienza desde su estado inicial.

Daemon de TRILL

Cada puente que crea usando el comando dladm create-bridge -P trill se representa como una instancia de SMF idénticamente denominada de svc:/network/bridge y svc:/network/routing/trill. Cada instancia de svc:/network/routing/trill ejecuta una copia del daemon /usr/lib/trilld, que implementa el protocolo TRILL.

Por ejemplo, el siguiente comando crea un puente denominado bridgeofsighs :

# dladm create-bridge -P trill bridgeofsighs

El sistema crea dos servicios SMF denominados svc:/network/bridge:bridgeofsighs y svc:/network/routing/trill:bridgeofsighs. Además, el sistema crea un nodo de observación denominado /dev/net/bridgeofsighs0.

Depuración de puentes

A cada instancia de puente se le asigna un nodo de observación que aparece en el directorio /dev/net/ y se la denomina por el nombre de puente seguido de 0.

El nodo de observación está destinado únicamente para su uso con las utilidades snoop y wireshark. Este nodo funciona como una interfaz Ethernet estándar, excepto para la transmisión de paquetes, que se sueltan de manera silenciosa. No puede asociar una IP además de un nodo de observación y no puede realizar solicitudes de enlace (DL_BIND_REQ), a menos que utilice la opción pasiva.

Cuando se lo utiliza, el nodo de observación realiza una copia única sin modificaciones de cada paquete gestionado por el puente disponible para el usuario para efectuar la supervisión y la depuración. Este comportamiento es similar al de un puerto de supervisión en un puente tradicional y está sujeto a las reglas habituales del “modo promiscuo” de la interfaz de proveedor de enlace de datos (DLPI, Data Link Provider Interface). Puede utilizar el comando pfmod o las funciones de las utilidades snoop y wireshark para filtrar paquetes en función del ID de la VLAN.

Los paquetes entregados representan los datos que son recibidos por el puente.

Para ver los paquetes que se transmiten y se reciben en un enlace concreto (después de que el proceso de puentes se completa), ejecute snoop en los enlaces individuales, en lugar de ejecutarlo en el nodo de observación del puente.

También puede obtener estadísticas sobre cómo los paquetes de red usan los recursos de red en enlaces mediante el comando dlstat. Para obtener más información, consulte Capítulo 4, Supervisión del tráfico de red y el uso de recursos en Oracle Solaris de Uso de redes virtuales en Oracle Solaris 11.1.

Cómo se modifica el comportamiento de los enlaces cuando se usan puentes

En las siguientes secciones, se describe cómo se modifica el comportamiento de los enlaces cuando se usan puentes en la configuración de red.

Para obtener información sobre el comportamiento estándar de los enlaces, consulte Implementación de VLAN: descripción general.

Comportamiento de DLPI

A continuación, se describen las diferencias en el comportamiento de enlaces cuando se activa un puente:

• Las notificaciones de enlace activo (DL_NOTE_LINK_UP) y enlace inactivo (DL_NOTE_LINK_DOWN) se envían en el agregado. Esto significa que cuando todos los enlaces externos muestran el estado de enlace inactivo, los clientes de nivel superior que están utilizando las capas MAC también ven eventos de enlaces inactivos. Cuando cualquier enlace externo en el puente muestra el estado de enlace activo, todos los clientes de nivel superior ven eventos de enlaces activos.

  Este informe de enlaces activos y enlaces inactivos del agregado se realiza por los siguientes motivos:

  • Cuando se ve el estado de enlace inactivo, los nodos en el enlace ya no son accesibles. Esto no es así cuando el código de puentes aún puede enviar y recibir paquetes mediante otro enlace. Las aplicaciones administrativas que requieren el estado real de los enlaces pueden utilizar las estadísticas del núcleo de la capa MAC para revelar el estado. Estas aplicaciones difieren de los clientes comunes, como IP, en que brindan información sobre el estado del hardware y no participan en el reenvío de paquetes.

  • Cuando todos los enlaces externos están inactivos, el estado aparece como si el puente estuviera cerrado. En este caso particular, el sistema reconoce que ningún nodo podría ser accesible. La compensación es que los puentes no se pueden utilizar para permitir la comunicación sólo local en el caso de que todas las interfaces sean "reales" (no virtuales) y todos los enlaces estén desconectados.

• Todas las funciones específicas de enlaces se vuelven genéricas. Los enlaces que admiten funciones especiales de aceleración de hardware no pueden usar esas funciones porque la determinación real de enlaces de salida no es realizada totalmente por el cliente. La función de reenvío de puentes debe elegir un enlace de salida en función de la dirección MAC de destino, y dicho enlace de salida puede ser cualquier enlace en el puente.

Administración de las VLAN en redes con puentes

De manera predeterminada, las VLAN que están configuradas en el sistema reenvían paquetes a todos los puertos de una instancia del bridge. Cuando se invocan los comandos dladm create-vlan o dladm create-vnic -v, y si el enlace subyacente es parte de un puente, los comandos también permitirán el reenvío de la VLAN especificada en el enlace de puente.

Para configurar una VLAN en un enlace y desactivar el reenvío hacia otros enlaces o desde ellos en el puente, debe desactivar el reenvío estableciendo la propiedad forward con el comando dladm set-linkprop.

Utilice el comando dladm create-vlan para activar automáticamente la VLAN para el establecimiento de puentes cuando el enlace subyacente se configura como parte de un puente.

Las VLAN se ignoran en el STP que cumple con los estándares. El protocolo de puentes calcula sólo una topología sin bucles mediante mensajes de BPDU sin etiquetas y utiliza esta topología de árbol para activar y desactivar enlaces. Debe configurar los enlaces duplicados que se proporcionan en sus redes, de manera que cuando esos enlaces son desactivados de forma automática por el STP, las VLAN configuradas no se desconectan. Esto significa que debe ejecutar todas las VLAN en todas partes de la red principal con puentes o examinar con cuidado todos los enlaces redundantes.

El protocolo TRILL no sigue las reglas STP complejas. En cambio, TRILL encapsula automáticamente los paquetes que tienen la etiqueta de VLAN intacta y los transfiere por la red. Esto significa que TRILL enlaza VLAN aisladas donde el mismo ID de VLAN se ha reutilizado en una única red con puentes.

Ésta diferencia importante del STP implica que se podrían reutilizar las etiquetas de VLAN en secciones aisladas de la red para gestionar conjuntos de VLAN que superan el límite de 4094. Si bien no puede utilizar TRILL para gestionar redes de esta manera, es posible que pueda implementar otras soluciones, como las VLAN basadas en proveedor.

En una red de STP con VLAN, puede resultar difícil configurar las características de conmutación por error para evitar la partición de VLAN cuando STP desactiva el enlace “equivocado”. La pérdida de funcionalidad relativamente pequeña en las VLAN aisladas no es significativa en comparación con la solidez del modelo de TRILL.

Comportamiento de VLAN

El puente realiza reenvíos de paquetes mediante el análisis del conjunto permitido de VLAN y la propiedad default_tag de cada enlace. El proceso general es el siguiente:

1. Determinación de VLAN de entrada. Este proceso comienza cuando un paquete entrante se recibe en el sistema en un enlace. Cuando se recibe un paquete, se comprueba si tiene una etiqueta de VLAN. Si la etiqueta no está presente o si la etiqueta es sólo de prioridad (establecida en cero), el valor de propiedad default_tag configurada en ese enlace (si no se ha establecido en cero) se la considera etiqueta de VLAN interna. Si la etiqueta no está presente o está definida en cero, y default_tag es cero, el paquete se ignora. No se realizan reenvíos sin etiquetas. Si la etiqueta está presente y es igual que el valor default_tag, el paquete también se omite. De lo contrario, la etiqueta se establece como la VLAN de paquetes entrantes.

2. Comprobación de pertenencia de enlaces. Si la VLAN de entrada no está configurada como VLAN permitida en este enlace, el paquete se ignora. El reenvío se calcula, y la misma comprobación se realiza para el enlace de salida.

3. Actualización de etiqueta. Si la etiqueta de VLAN (que no sea cero en este punto) es igual que el valor default_tag en el enlace de salida, la etiqueta en el paquete (si hay) se elimina, independientemente de la prioridad. Si la etiqueta de la VLAN no es igual a la valor default_tag en el enlace de salida, una etiqueta se agrega si no está presente en ese momento, y la etiqueta se define para el paquete de salida, con la prioridad actual copiada en el paquete.

Visualización de configuraciones de puentes

En los siguientes ejemplos, se muestra cómo ver información sobre configuraciones de puentes y servicios de puentes:

• Puede obtener información sobre puentes ejecutando el siguiente comando:

  # dladm show-bridge
  BRIDGE      PROTECT ADDRESS            PRIORITY DESROOT
  tonowhere   trill   32768/66:ca:b0:39:31:5d 32768 32768/66:ca:b0:39:31:5d
  sanluisrey  stp     32768/ee:2:63:ed:41:94 32768 32768/ee:2:63:ed:41:94
  pontoon     trill   32768/56:db:46:be:b9:62 32768 32768/56:db:46:be:b9:62

• Para obtener información sobre apodos de TRILL para un puente, ejecute el siguiente comando:

  # dladm show-bridge -t tonowhere
  NICK FLAGS LINK        NEXTHOP
  38628 --   simblue2    56:db:46:be:b9:62
  58753 L    --          --