Entendendo 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 o DCBX. Se você tentar habilitar o DCBX em uma interface na qual o LLDP está desativado, a operação de confirmação de configuração falha. Os dispositivos de ponte de data center (DCB) usam DCBX para trocar informações de configuração com peers diretamente conectados.
Este tópico descreve:
Noções básicas do DCBX
O DCBX pode:
Descubra os recursos de DCB dos peers.
Detecte a configuração incorreta de recursos de DCB ou incompatibilidades entre pares.
Configure os recursos de DCB em peers.
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.
QFX5200 e switches 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 e a configuração administrativas com os peer conectados de cada interface. Para permitir 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 em interfaces.
O aplicativo FCoE só precisa ser incluído em um mapa de aplicativos quando você deseja 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 que uma interface anuncie, 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ê desabile 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 desabilitar esse recurso. Você também pode desabilitar a autonegotiação DCBX para aplicativos em uma interface, excluindo esses aplicativos do mapa do aplicativo que você aplica a essa interface ou excluindo o mapa do aplicativo da interface.
O comportamento padrão de autonegotiaçã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 do 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 oferece suporte à autoprovisionamento e não altera sua configuração durante a automação para combinar com a configuração dos pares. (O switch da Juniper não está "disposto" a aprender a configuração de PFC dos 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 para vizinhos, de modo 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 e suporte DCBX
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. TLVs diferentes 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 no formato de quadro. A versão 1.01 do DCBX usa um TLV que inclui todas as informações de atributos DCBX, que são enviadas como sub-TLVs. O IEEE DCBX usa um TLV exclusivo para cada atributo DCB.
O switch não oferece suporte a versões DE 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 de show:
Característica |
IEEE DCBX |
Versão 1.01 do DCBX |
|---|---|---|
OUI |
0x0080c2 |
0x001b21 |
Formato de quadro |
Envia um TLV exclusivo e separado 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 um TLV que inclui todas as informações de atributos DCBX organizadas em sub-TLVs. A bit "disposto" 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 |
Apenas 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.
Autonegotiação — a interface negocia automaticamente com o peer conectado para determinar a versão DCBX que os pares usam. A autonegotiaçã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 corresponderem à 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 versão 1.01. Se você configurar uma interface para usar a versão DCBX 1.01 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.
Autonegotiação
A autonegotiaçã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 peer, a interface anuncia TLVs IEEE DCBX para o 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 dcbx versão 1.01 do peer, a interface define DCBX versão 1.01 como o modo DCBX.
A automação funciona um pouco diferente em switches autônomos em comparação com os sistemas QFabric:
Switches autônomos — Quando uma interface se conecta à sua interface de peer, a interface anuncia TLVs IEEE DCBX para o 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 DCBX versão 1.01 para o 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 consecutivas 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 o flaps ou o processo LLDP for reiniciado, a interface iniciará o processo de autonegotiaçã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 do DCBX que você usa em interfaces de switch depende dos recursos dcbx que os 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 enlaces (LAG) cujas interfaces de membro são todas interfaces Ethernet de 10 Gigabit.
Tipos de atributos do DCBX
O DCBX tem três tipos de atributos:
Informativos — esses atributos são trocados usando LLDP, mas não afetam o estado ou a operação do DCBX; apenas comunicam informações ao peer. Por exemplo, as TLVs de prioridade de aplicativos são TLVs informativas.
Assimétrica — os valores para esses tipos de atributos não precisam ser os mesmos nas interfaces de peer conectadas. Os pares trocam atributos assimétricos quando os valores dos atributos podem diferir em cada interface de peer. As configurações da interface de peer podem ser compatíveis 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 para esses 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, as TLVs de configuração de PFC são TLVs simétricas.
As seções a seguir descrevem atributos DCBX assimétricos e simétricos:
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 corresponder aos parâmetros na interface de peer conectada.
Existem dois tipos de TLVs de atributos assimétricos:
Configuração TLV — As TLVs de configuração comunicam o estado operacional atual e o estado do bit "disposto". A bit "disposto" comunica se a interface está ou não disposto a aceitar e usar a configuração a partir da interface de peer. Se uma interface estiver "pronta", 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 "disposto".) Se uma interface "não estiver pronta", a configuração na interface não pode ser anulada 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 no TLV de recomendação.
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 devem usar a mesma configuração. A intenção é que os parâmetros configurados em uma interface correspondam aos parâmetros da interface de peer conectada.
Há um tipo de atributo simétrico TLV, o TLV de configuração. 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 "disposto". As interfaces "dispostos" usam os valores de parâmetro da interface peer para o atributo. (A configuração de atributo do peer substitui a configuração na interface "disposto".)
TLV Exchange 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 iSCSI:
- Intercâmbio TLV de protocolo de aplicativos
- TLV Exchange de protocolo de aplicativos FCoE
- Desativação do protocolo de aplicativos TLV Exchange
Intercâmbio 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 para as quais o aplicativo é mapeado. Se um aplicativo não for mapeado em uma interface, essa interface não anuncia as TLVs do aplicativo. Há uma exceção para a troca de TLV de protocolo de aplicativos FCoE quando o FCoE é o único aplicativo que você deseja que o DCBX anuncie em uma interface.
TLV Exchange de protocolo de aplicativos FCoE
A troca de protocolo TLV para o aplicativo FCoE depende se o FCoE é o único aplicativo que você deseja que a interface anuncie ou se você deseja 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 para a prioridade do FCoE (ponto de código IEEE 802.1p)
Não tem um mapa de aplicativo
Se nenhuma configuração de CoS para FCoE for mapeada em uma interface, essa interface não troca TLVs de protocolo de aplicativos FCoE.
Se você deseja 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 do aplicativo 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 desativado", e o FCoE é desativado nessa interface.
Desativação do protocolo de aplicativos TLV Exchange
Para desativar a troca de protocolo 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 protocolo de aplicativos DCBX para aplicativos em uma interface, excluindo o mapa do aplicativo da interface, ou excluindo um aplicativo específico do mapa do aplicativo. No entanto, quando você exclui um aplicativo de um mapa de aplicativo, o protocolo do aplicativo não é mais trocado em nenhuma interface que use esse mapa do aplicativo.
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 ao 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 ao PFC ou não é provisionado de forma compatível com o switch, o DCBX define o estado operacional para desativado. (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 do 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 autonegotição. Se você desabilitar a autonegotiação em uma interface na qual você configurou o PFC, então o PFC será 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 do DCBX ETS
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 de 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úncio DCBX. O DCBX anuncia o grupo de prioridade padrão, suas prioridades e a largura de banda atribuída.
Se você configurar 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 faça 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 você deseja encaminhar tráfego devem pertencer a um conjunto de classes de encaminhamento (grupo prioritário).
Configuração de anúncio e peer do ETS
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 o TLV de recomendação de ETS estiver habilitado (ele é habilitado por padrão). Se o peer não oferece suporte ao 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 prioritários e prioridades. 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 para o peer em uma base por interface, desativando a autonegotição. Isso não afeta o estado de ETS no switch ou no peer, mas impede que o switch envie o TLV de recomendação ou o TLV de configuração para o peer conectado. Para desativar o ETS em uma interface, não configure grupos prioritários (encaminhamento de conjuntos de classes) na interface.
TLV de recomendação de ETS
O TLV de recomendação de ETS comunica as configurações de ETS que o switch quer que a interface de peer conectada use. Se a interface de peer estiver "pronta", ela muda sua configuração para combinar com a configuração no TLV de recomendação do ETS. Por padrão, as interfaces do switch enviam o TLV de recomendação de ETS 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 o TLV de recomendação de ETS habilitado. No entanto, em interfaces que usam o IEEE DCBX como modo DCBX, se você quiser uma configuração assimétrica entre a interface do switch e o peer conectado, você pode desabilitar o ETS Recommendation 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 desabilitar o TLV de recomendação de ETS quando o modo DCBX na interface for IEEE DCBX. A desativação da recomendação de ETS TLV não surtiu efeito se o modo DCBX na interface for a versão 1.01 do DCBX. (O IEEE DCBX usa TLVs de atributo de aplicativo separados, mas a versão 1.01 do DCBX envia todos os atributos de aplicativo no mesmo TLV e usa sub-TLVs para separar as informações.)
Se você desativar o TLV de recomendação de ETS, o switch ainda envia o TLV de configuração de ETS para o peer conectado. O resultado é que o peer conectado é informado sobre a configuração de ETS DCBX do switch, 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 desabilitar o TLV de recomendação de ETS 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 altera sua configuração para combinar com a configuração da interface do switch.