Descripción general sobre puentes

Los puentes se utilizan para conectar segmentos de red separados. 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 los puentes y el enrutamiento se pueden utilizar para distribuir información sobre las ubicaciones de los recursos de la red, difieren de varias formas. 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 que está conectado a otro puente en la subred con puentes. Con el tiempo, todos los puentes dentro de la subred 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 también caducan a lo largo 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ápido (RSTP) para puentes, Oracle Solaris admite la mejora de la protección TRILL. 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 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.

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 configurado el establecimiento de puentes. sanfrancisco y sausalito son sistemas que están conectados físicamente 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.

Figura 11-1 Red con puentes simple

Las redes con puentes se pueden formar en anillos que conectan 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 a westminster. Un sistema está conectado físicamente a waterloo. Y un sistema está conectado físicamente a tower. Los puentes están conectados físicamente entre ellos mediante los puertos.

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, 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.

Figura 11-2 Anillo de red con puentes

---

Precaución - No establezca local-mac-address?=false en plataformas SPARC, o los sistemas utilizarán de forma errónea la misma dirección MAC en varios puertos y en la misma red.

---

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

Estas propiedades de enlaces pueden ser mostradas y modificadas por los comandos dladm show-linkprop, 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 deshabilita 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 puentes para especificar el identificador de VLAN de puerto (PVID) 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 está definido como 5 en net0, no puede crear una VLAN con el ID 5 en net0. Para especificar VLAN 5 en esta situación, utilice net0.

No puede establecer default_tag igual al ID de cualquier VLAN existente que se crea en ese enlace. Por ejemplo, el comando siguiente crea 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 etiqueta en net0 no estén asociados con ninguna VLAN. Esta situación evita que los paquetes se reenvíen por un puente configurado.

---

forward

Habilite y deshabilite 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 está deshabilitada, una VLAN asociada con una instancia de enlace no reenvía tráfico por medio del puente. La deshabilitació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

Habilite y deshabilite STP y RSTP. Los valores válidos son 1 (true) y 0 (false). El valor predeterminado es 1, que habilita STP y RSTP. Cuando se define en 0, el enlace no utiliza ningún tipo de protocolo de árbol de expansión 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). Deshabilite 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

Represente 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 Mbps, 19 para 100 Mbps, 4 para 1 Gbps y 2 para 10 Gbps.

stp_edge

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

stp_p2p

Especifique 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 punto a punto y especifique false para forzar el modo multipunto normal.

stp_priority

Defina 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 identificador del puerto. 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 SMF denominada de manera idéntica de svc:/network/bridge. Cada instancia ejecuta una copia del daemon /usr/lib/bridged, que implementa el STP.

El siguiente comando de ejemplo 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 TLL o conteo de saltos en paquetes, cualquiera de dichos bucles son errores fatales para la red.

Cuando sabe que un puerto concreto no está conectado a otro puente (por ejemplo, una conexión punto a punto directa a un sistema host), puede deshabilitar administrativamente el STP de ese puerto. Incluso si todos los puertos de un puente tienen el STP deshabilitado, 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 habilitar o deshabilitar el reenvío en los puertos, según sea necesario.

Cuando un puerto tiene el STP deshabilitado, el daemon bridged escucha BPDU (protección de BPDU). El daemon utiliza syslog para marcar los errores y deshabilita el reenvío en el puerto para indicar un error grave de la configuración de la red. El enlace se habilita 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 deshabilita 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.

El siguiente comando de ejemplo 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 nombra por el nombre de puente y 0 al final.

El nodo de observación está destinado únicamente para su uso con las utilidades snoop y wireshark. Este nodo se comporta 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 utiliza, el nodo de observación realiza una copia única sin modificaciones de cada paquete gestionado por el puente disponible para el usuario. Este comportamiento es similar a un puerto de “supervisión” en un puente tradicional y está sujeto a las reglas del “modo promiscuo” de DLPI habituales. Puede utilizar pfmod o las funciones en las utilidades snoop y wireshark para filtrar por ID de VLAN.

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

---

Precaución - En los casos donde el proceso de puentes agrega, elimina o modifica una etiqueta VLAN, los datos que se muestran describen el estado antes de que este proceso ocurra. Esta situación inusual puede resultar confusa si existen valores default_tag distintos utilizados en diferentes enlaces.

---

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.

Para obtener información sobre nodos de observación, consulte Funciones de observación para la virtualización de redes y el control de recursos.

Otros comportamientos de puentes

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

Para obtener información sobre el comportamiento estándar de los enlaces, consulte Administración de redes de área local virtuales.

Comportamiento de DLPI

A continuación, se describen las diferencias en el comportamiento de enlaces cuando se habilita 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 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 necesitan 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 regulares, como IP, en que brindan información sobre el estado del hardware y no participan en el reenvío.

  • 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 nada 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 todas estén desconectadas.

• 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 VLAN

De manera predeterminada, las VLAN que se configuran en el sistema se reenvían entre todos los puertos en una instancia de puente. Al invocar al comando dladm create-vlan o dladm create-vnic -v, y el enlace subyacente forma parte de un puente, ese comando también permitirá el reenvío de la VLAN especificada en ese enlace de puente.

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

Utilice el comando dladm create-vlan para habilitar 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 este árbol para habilitar y deshabilitar enlaces. Debe configurar los enlaces duplicados que se proporcionan en sus redes, de manera que cuando esos enlaces son deshabilitados 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.

TRILL no necesita seguir 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 es una diferencia importante del STP donde podría reutilizar 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 forma, es posible que pueda implementar otras soluciones, como redes 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 deshabilita el enlace “equivocado”. La pérdida de funcionalidad relativamente pequeña en redes VLAN aisladas está más que compensada por la solidez del modelo de TRILL.

Comportamiento de VLAN

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

• Determinación de VLAN de entrada. Esta tarea empieza cuando se recibe un paquete en un enlace. Cuando se recibe un paquete, se comprueba si tiene una etiqueta de VLAN. Si dicha etiqueta no está presente o si la etiqueta es sólo de prioridad (etiqueta cero), la default_tag configurada en ese enlace (si no se ha definido en cero) se considera como la 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 a default_tag, el paquete también es ignorado. De lo contrario, la etiqueta de entrada se toma como la VLAN de entrada.

• Comprobación de pertenencia de enlace. Si la VLAN de entrada no está configurada como una 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.

• Actualización de etiquetas. Si la VLAN (que no es cero en este punto) es igual a default_tag en el enlace de salida, la etiqueta en el paquete (si hay) se elimina, independientemente de la prioridad. Si la VLAN no es igual a 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.

Ejemplos de configuración 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

• Puede obtener información sobre apodos de TRILL para un puente ejecutando el siguiente comando:

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