Entender o DCBX
O protocolo de troca de recursos de ponte de data center (DCBX) é uma extensão do Link Layer Data Protocol (LLDP). Se você desativar o LLDP em uma interface, essa interface não pode executar DCBX. Se você tentar habilitar o DCBX em uma interface na qual o LLDP é desativado, a operação de compromisso de configuração falha. Os dispositivos de ponte de data center (DCB) usam o DCBX para trocar informações de configuração com pares diretamente conectados.
Este tópico descreve:
Noções básicas do DCBX
O DCBX pode:
Descubra os recursos de DCB dos colegas.
Detecte a inconfiguração ou incompatibilidade de recursos de DCB entre pares.
Configure recursos de DCB em pares.
Você pode configurar a operação DCBX para controle de fluxo baseado em prioridade (PFC), aplicativos de Camada 2 e Camada 4, como FCoE e iSCSI, e ETS. O DCBX é habilitado ou desativado por interface.
Os switches QFX5200 e QFX5210 não oferecem suporte a agendamento hierárquico de seleção de transmissão aprimorada (ETS). Use o agendamento de portas para gerenciar a largura de banda nesses switches.
Por padrão, para PFC e ETS, o DCBX negocia automaticamente o estado administrativo e a configuração com os peer conectados de cada interface. Para habilitar a negociação do DCBX para aplicativos, você deve configurar os aplicativos, mapeá-los para pontos de código IEEE 802.1p em um mapa de aplicativos e aplicar o mapa do aplicativo às interfaces.
O aplicativo FCoE só precisa ser incluído em um mapa de aplicativos quando você quiser uma interface para trocar tipo, comprimento e valores (TLVs) para outros aplicativos, além do FCoE. Se o FCoE for o único aplicativo que você deseja uma interface para anunciar, então você não precisa usar um mapa de aplicativos. Para ETS, o DCBX empurra a configuração do switch para os pares se eles estiverem definidos para aprender a configuração do switch (a menos que você desativa o envio da recomendação de ETS TLV em interfaces no modo IEEE DCBX).
Você pode substituir o comportamento padrão para PFC, PARA ETS ou para todos os aplicativos mapeados em uma interface, desativando a automação para forçar uma interface a habilitar ou desativar esse recurso. Você também pode desativar a automação do DCBX para aplicativos em uma interface, excluindo esses aplicativos do mapa de aplicativos que você aplica a essa interface ou excluindo o mapa do aplicativo da interface.
O comportamento padrão de automação para aplicativos mapeados em uma interface é:
O DCBX é habilitado na interface se o dispositivo peer conectado também oferece suporte ao DCBX.
O DCBX é desativado na interface se o dispositivo peer conectado não oferece suporte ao DCBX.
Durante a negociação de recursos, o switch pode empurrar a configuração de PFC para um peer conectado se o peer estiver configurado como "disposto" a aprender a configuração de PFC de outros pares. O switch da Juniper Networks não suporta autoprovisionamento automático e não muda sua configuração durante a automação para combinar com a configuração de peer. (O switch da Juniper não está "disposto" a aprender a configuração de PFC com os pares.)
Quando uma porta com DCBX habilitada começa a trocar entradas de tipo, comprimento e valor (TLV), as TLVs LLDP opcionais nessa porta não são anunciadas aos vizinhos, para que o switch possa interoperar com uma variedade mais ampla de adaptadores de rede convergentes (CNAs) e switches de Camada 2 que oferecem suporte ao DCBX.
Modos DCBX e suporte
Esta seção descreve o suporte ao DCBX:
Modos DCBX (versões)
Os dois modos DCBX mais comuns são suportados:
IEEE DCBX — A mais nova versão DCBX. Diferentes TLVs têm subtipos diferentes (por exemplo, o subtipo para a configuração de ETS TLV é 9); o IEEE DCBX Organizationally Unique Identifier (OUI) é 0x0080c2.
VERSÃO DCBX 1.01 — A versão Converged Enhanced Ethernet (CEE) do DCBX. Ele tem um subtipo de 2 e uma OUI de 0x001b21.
IEEE DCBX e DCBX versão 1.01 diferem principalmente em formato de quadro. A versão 1.01 do DCBX usa uma TLV que inclui todas as informações de atributos DCBX, que são enviadas como sub-TLVs. O IEEE DCBX usa uma TLV única para cada atributo DCB.
O switch não oferece suporte a versões DCBX pré-CEE (pré-DCB). Versões mais antigas sem suporte do DCBX têm um subtipo de 1 e uma OUI de 0x001b21. O switch derruba quadros LLDP que contêm TLVs DCBX pré-CEE.
A Tabela 1 resume as diferenças entre o IEEE DCBX e a versão 1.01 do DCBX, incluindo a saída de comando show:
Característica |
IEEE DCBX |
Versão 1.01 do DCBX |
|---|---|---|
OUI |
0x0080c2 |
0x001b21 |
Formato de quadro |
Envia uma TLV separada e única para cada atributo DCBX. Por exemplo, o IEEE DCBX usa TLVs separadas para ETS, PFC e cada aplicativo. As informações de configuração e recomendação são enviadas em diferentes TLVs |
Envia uma TLV que inclui todas as informações de atributos DCBX organizadas em sub-TLVs. A bit "disposta" determina se uma interface pode ou não mudar sua configuração para combinar com o peer conectado. |
Configuração simétrica/assimétrica com peer |
Assimétrica ou simétrica |
Somente simétrico |
Diferenças no |
|
|
Você pode configurar interfaces para usar os seguintes modos DCBX:
IEEE DCBX — A interface usa IEEE DCBX, independentemente da configuração no peer conectado.
VERSÃO DCBX 1.01 — A interface usa a versão 1.01 do DCBX, independentemente da configuração no peer conectado.
Automação — a interface negocia automaticamente com o peer conectado para determinar a versão DCBX que os pares usam. A automação é o modo DCBX padrão.
Se você configurar um modo DCBX em uma interface, a interface ignora as unidades de dados de protocolo DCBX (PDUs) que recebe do peer conectado se as PDUs não combinarem com a versão DCBX configurada na interface. Por exemplo, se você configurar uma interface para usar o IEEE DCBX e o peer conectado enviar PDUs DCBX versão 1.01 LLDP, a interface ignora as PDUs da versão 1.01. Se você configurar uma interface para usar a versão 1.01 do DCBX e o peer enviar PDUs IEEE DCBX LLDP, a interface ignora as PDUs IEEE DCBX.
Em interfaces que usam o modo IEEE DCBX, o show dcbx neighbors interface interface-name comando operacional não inclui o estado operacional de aplicativo, PFC ou ETS na saída.
Automação
A automação é o modo DCBX padrão. Cada interface negocia automaticamente com seu peer conectado para determinar a versão DCBX que ambas as interfaces usam para trocar informações do DCBX.
Quando uma interface se conecta à sua interface de peer, a interface anuncia TLVs IEEE DCBX para os peer. Se a interface receber uma PDU IEEE DCBX do peer, a interface define o modo DCBX como IEEE DCBX. Se a interface receber três TLVs da versão DCBX 1.01 do peer, a interface define a versão DCBX 1.01 como o modo DCBX.
A automação funciona um pouco diferente em switches autônomos em comparação com sistemas QFabric:
Switches autônomos — Quando uma interface se conecta à sua interface de peer, a interface anuncia TLVs IEEE DCBX para os peer. Se a interface receber um IEEE DCBX TLV do peer, a interface define o IEEE DCBX como o modo DCBX. Se a interface receber três TLVs dcbx consecutivos da versão 1.01 do peer, a interface define a versão DCBX 1.01 como o modo DCBX.
Sistema QFabric — Quando uma interface se conecta à sua interface de peer, a interface anuncia TLVs da versão 1.01 DCBX ao peer. Se a interface receber uma TLVs IEEE DCBX do peer, a interface define o IEEE DCBX como o modo DCBX. Se a interface receber três TLVs dcbx consecutivos da versão 1.01 do peer, a interface mantém a versão DCBX 1.01 como o modo DCBX.
Se o link bater ou o processo LLDP for reiniciado, a interface iniciará o processo de automação novamente. A interface não usa o último modo de comunicação DCBX recebido.
Suporte de CNA para modos DCBX
Diferentes fornecedores de CNA oferecem suporte a diferentes versões e recursos do DCBX. A configuração DCBX que você usa nas interfaces dos switches depende dos recursos DCBX que o CNAs em seu suporte de rede.
Suporte de interface para DCBX
Você pode configurar o DCBX em interfaces Ethernet de 10 Gigabits e em interfaces de grupo de agregação de enlace (LAG) cujas interfaces de membro são todas interfaces Ethernet de 10 Gigabits.
Tipos de atributos DCBX
O DCBX tem três tipos de atributos:
Informações — esses atributos são trocados usando LLDP, mas não afetam o estado ou a operação do DCBX; eles só comunicam informações ao peer. Por exemplo, TLVs de prioridade de aplicativos são TLVs informativas.
Assimétrica — os valores desses tipos de atributos não precisam ser os mesmos nas interfaces de peer conectadas. Os pares trocam atributos assimétricos quando os valores de atributo podem diferir em cada interface de peer. As configurações da interface de peer podem combinar ou podem diferir. Por exemplo, as TLVs de configuração e recomendação de ETS são TLVs assimétricas.
Simétrico — A intenção é que os valores desses tipos de atributos sejam os mesmos em ambas as interfaces de peer conectadas. As interfaces de peer trocam atributos simétricos para garantir a configuração simétrica do DCBX para esses atributos. Por exemplo, TLVs de configuração PFC são TLVs simétricos.
As seções a seguir descrevem atributos assimétricos e simétricos do DCBX:
Atributos assimétricos
O DCBX passa atributos assimétricos entre interfaces de peer conectadas para comunicar informações de parâmetros sobre esses atributos (recursos). A configuração resultante de um atributo pode ser diferente em cada peer, de modo que os parâmetros configurados em uma interface podem não coincidir com os parâmetros na interface de peer conectada.
Existem dois tipos de TLVs de atributos assimétricos:
Configuração TLV — TLVs de configuração comunicam o estado operacional atual e o estado da bit "disposta". A bit "disposta" comunica se a interface está ou não disposta a aceitar e usar a configuração a partir da interface de peer. Se uma interface estiver "disposta", a interface usa a configuração que recebe da interface de peer. (A configuração da interface de peer pode substituir a configuração na interface "disposta".) Se uma interface "não estiver disposta", a configuração na interface não pode ser substituída pela configuração da interface de peer.
Recomendação TLV — TLVs de recomendação comunicam os parâmetros que a interface recomenda que a interface de peer conectada deve usar. Quando uma interface envia uma recomendação TLV, se o peer conectado estiver "disposto", o peer conectado muda sua configuração para combinar com os parâmetros da Recomendação TLV.
Atributos simétricos
O DCBX passa atributos simétricos entre interfaces de peer conectadas para comunicar informações de parâmetros sobre esses atributos (recursos), com o objetivo de que ambas as interfaces usem a mesma configuração. A intenção é que os parâmetros configurados em uma interface correspondam aos parâmetros da interface de peer conectada.
Existe um tipo de atributo simétrico TLV, a Configuração TLV. Como acontece com atributos assimétricos, as TLVs de configuração de atributo simétrico comunicam o estado operacional atual e o estado da bit "disposta". Interfaces "dispostas" usam os valores dos parâmetros da interface de peer para o atributo. (A configuração de atributo do peer substitui a configuração na interface "disposta".)
Troca de TLV de protocolo de aplicativos DCBX
O DCBX anuncia os recursos do switch para aplicativos de Camada 2, como FCoE e aplicativos de Camada 4, como o iSCSI:
- Intercâmbio de TLV de protocolo de aplicativos
- Intercâmbio de TLV de protocolo de aplicativos FCoE
- Desativação do protocolo de aplicativos TLV exchange
Intercâmbio de TLV de protocolo de aplicativos
Para todos os aplicativos, o DCBX anuncia o estado do aplicativo e os pontos de código IEEE 802.1p nas interfaces às quais o aplicativo é mapeado. Se um aplicativo não for mapeado para uma interface, essa interface não anuncia as TLVs do aplicativo. Existe uma exceção para o protocolo de aplicativos FCoE TLV troca quando o FCoE é o único aplicativo que você deseja que o DCBX anuncie em uma interface.
Intercâmbio de TLV de protocolo de aplicativos FCoE
A troca de protocolo TLV para o aplicativo FCoE depende se o FCoE é o único aplicativo que você quer que a interface anuncie ou se você quer que a interface troque outras TLVs de aplicativos, além de TLVs FCoE.
Se o FCoE for o único aplicativo que você deseja que o DCBX anuncie em uma interface, o DCBX troca TLVs de protocolo de aplicativos FCoE por padrão se a interface:
Transporta tráfego FCoE (tráfego mapeado pela configuração de CoS para a classe de encaminhamento FCoE)
Tem um perfil de notificação de congestionamento com PFC habilitado na prioridade do FCoE (ponto de código IEEE 802.1p)
Não tem um mapa de aplicativos
Se nenhuma configuração de CoS para FCoE for mapeada para uma interface, essa interface não troca TLVs de protocolo de aplicativos FCoE.
Se você quiser que o DCBX anuncie fCoE e outros aplicativos em uma interface, você deve especificar todos os aplicativos, incluindo FCoE, em um mapa de aplicativos, e aplicar o mapa de aplicativos nas interfaces desejadas.
Se um mapa de aplicativo for aplicado a uma interface, o aplicativo FCoE deve ser configurado explicitamente no mapa do aplicativo, ou a interface não troca TLVs FCoE.
Quando o DCBX anuncia o aplicativo FCoE, ele anuncia o estado do FCoE e os pontos de código IEEE 802.1p. Se um dispositivo peer conectado a uma interface de switch não oferece suporte a FCoE, o DCBX usa a automação para marcar a interface como "FCoE down", e o FCoE é desativado nessa interface.
Desativação do protocolo de aplicativos TLV exchange
Para desativar a troca de protocolos de aplicativos DCBX para todos os aplicativos em uma interface, emita o set protocols dcbx interface interface-name applications no-auto-negotiation comando.
Você também pode desativar a troca de protocolos de aplicativos DCBX por aplicativos em uma interface excluindo o mapa do aplicativo da interface ou excluindo uma aplicação específica do mapa da aplicação. No entanto, quando você exclui um aplicativo de um mapa de aplicativos, o protocolo do aplicativo não é mais trocado em nenhuma interface que use esse mapa de aplicativos.
DCBX e PFC
Depois de habilitar o PFC em uma interface de switch, o DCBX usa a automação para controlar o estado operacional da funcionalidade PFC.
Se o dispositivo peer conectado à interface oferece suporte a PFC e é provisionado com compatibilidade com o switch, o DCBX define o estado operacional do PFC para habilitado. Se o dispositivo peer conectado à interface não oferece suporte a PFC ou não for provisionado com compatibilidade com o switch, o DCBX define o estado operacional para desabilitado. (PFC deve ser simétrico.)
Se o peer anunciar que está "disposto" a aprender sua configuração de PFC a partir do switch, o DCBX empurra a configuração de PFC do switch para o peer e não verifica o estado administrativo do peer.
Você pode substituir manualmente o controle DCBX do estado operacional do PFC por interface, desativando a automação. Se você desativar a automação em uma interface na qual configurou o PFC, então o PFC é habilitado nessa interface, independentemente da configuração de peer. Para desativar o PFC em uma interface, não configure o PFC nessa interface.
DCBX e ETS
Esta seção descreve:
Anúncio padrão de ETS DCBX
Se você não configurar o ETS em uma interface, o switch cria automaticamente um grupo de prioridade padrão que contém todas as prioridades (classes de encaminhamento, que representam filas de saída) e atribui 100% da largura de banda da saída de porta a esse grupo prioritário. O grupo de prioridade padrão é transparente. Ele não aparece na configuração e é usado para anúncios DCBX. O DCBX anuncia o grupo de prioridade padrão, suas prioridades e a largura de banda atribuída.
Se você configurar o ETS em uma interface, o DCBX anuncia:
Cada grupo prioritário na interface
As prioridades em cada grupo prioritário
As propriedades de largura de banda de cada grupo prioritário e prioridade
Qualquer prioridade nessa interface que não faz parte de um grupo de prioridade explicitamente configurado (conjunto de classe de encaminhamento) é atribuída ao grupo de prioridade padrão gerado automaticamente e não recebe largura de banda. Se você configurar o ETS em uma interface, todas as classes de encaminhamento (prioridade) nessa interface para a qual deseja encaminhar o tráfego devem pertencer a um conjunto de classe de encaminhamento (grupo de prioridade).
Anúncio de ETS e configuração de peer
O DCBX não controla o estado operacional de ETS (agendamento hierárquico) do switch. Se o peer conectado estiver configurado como "disposto", o DCBX empurra a configuração DE ETS do switch para os pares do switch se a recomendação de ETS TLV for habilitada (ela é ativada por padrão). Se o peer não oferece suporte a ETS ou não é provisionado consistentemente com o switch, o DCBX não altera o estado operacional do ETS no switch. O estado operacional do ETS permanece habilitado ou desativado com base apenas na configuração de agendamento hierárquico do switch e é habilitado por padrão.
Quando o ETS é configurado, o DCBX anuncia os grupos prioritários, as prioridades nos grupos prioritários e a configuração de largura de banda para os grupos e prioridades prioritários. Qualquer prioridade (essencialmente uma classe ou fila de encaminhamento) que não faz parte de um grupo prioritário não tem propriedades de agendamento e não recebe largura de banda.
Você pode substituir manualmente se o DCBX anuncia o estado ETS ao peer por interface, desativando a automação. Isso não afeta o estado de ETS no switch ou no peer, mas impede que o switch envie a Recomendação TLV ou a Configuração TLV para o peer conectado. Para desativar o ETS em uma interface, não configure grupos prioritários (conjuntos de classe de encaminhamento) na interface.
TLV de recomendação de ETS
A recomendação do ETS TLV comunica as configurações de ETS que o switch quer que a interface de peer conectada use. Se a interface de peer estiver "disposta", ela mudará sua configuração para combinar com a configuração no TLV de recomendação do ETS. Por padrão, as interfaces do switch enviam a recomendação de ETS TLV para o peer. As configurações comunicadas são as configurações de ETS de saída definidas pela configuração de agendamento hierárquico na interface.
Recomendamos que você use as mesmas configurações de ETS no peer conectado que você usa na interface do switch e que deixe a Recomendação de ETS TLV habilitada. No entanto, em interfaces que usam o IEEE DCBX como o modo DCBX, se você quiser uma configuração assimétrica entre a interface do switch e o peer conectado, você pode desativar a recomendação de ETS TLV incluindo a no-recommendation-tlv declaração no nível de [edit protocols dcbx interface interface-name enhanced-transmission-selection] hierarquia.
Você só pode desativar a recomendação de ETS TLV quando o modo DCBX na interface for IEEE DCBX. Desativar a recomendação de ETS TLV não surtir efeito se o modo DCBX na interface for a versão 1.01 do DCBX. (O IEEE DCBX usa TLVs de atributos de aplicativos separados, mas a versão 1.01 do DCBX envia todos os atributos do aplicativo na mesma TLV e usa sub-TLVs para separar as informações.)
Se você desativar a recomendação de ETS TLV, o switch ainda envia a configuração de ETS TLV para o peer conectado. O resultado é que o peer conectado é informado sobre a configuração do SWITCH DCBX ETS, mas mesmo que o peer esteja "disposto", o peer não muda sua configuração para combinar com a configuração do switch. Esta é uma configuração assimétrica: as duas interfaces podem ter valores de parâmetro diferentes para o atributo ETS.
Por exemplo, se você quiser que um CNA conectado a uma interface de switch tenha alocações de largura de banda diferentes da configuração de ETS do switch, você pode desativar a recomendação de ETS TLV e configurar o CNA para a largura de banda desejada. A interface do switch e os parâmetros de configuração de troca de CNA, mas o CNA não muda sua configuração para combinar com a configuração da interface do switch.