Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Ciclo de vida da configuração do dispositivo

CUIDADO:

Uma boa compreensão do ciclo de vida da configuração do dispositivo Apstra é essencial. Antes de trabalhar com dispositivos no ambiente Apstra, recomendamos fortemente que você entenda completamente como os dispositivos são configurados desde o momento em que eles são embarcados até o momento em que são desativados.

Terminologia

Os estágios do ciclo de vida da configuração são os seguintes:

Descrição do estágio de configuração
Configuração intocada Quando você instala um agente de dispositivo, a configuração é adicionada à configuração pré-existente no dispositivo. Normalmente, a configuração intocada não muda durante todo o ciclo de vida do dispositivo.
Configuração da Discovery 1 Quando você reconhece um dispositivo, o Apstra adiciona configurações básicas, incluindo a habilitação do LLDP em todas as interfaces.
Configuração pronta (anteriormente conhecida como Discovery 2 Config) Quando você atribui um dispositivo a um blueprint sem implantá-lo (modo de implantação: pronto), o Apstra adiciona configurações básicas, incluindo nomes de host de dispositivos, descrições de interface e configuração de velocidade de porta/breakout.
Configuração de serviço Quando você implanta um dispositivo (modo de implantação: implantação), o Apstra adiciona configuração que é necessária no ambiente Apstra. A configuração de serviço consiste em configuração discovery 1, configuração pronta (Discovery 2) e esta configuração adicional.
Configuração renderizada Configuração completa renderizada pelo Apstra para o dispositivo, de acordo com o Design de referência do Apstra.
Configuração incremental A configuração que será aplicada quando você confirmar alterações feitas por você.
Configuração dourada Quando você confirma mudanças na configuração, o Apstra coleta uma nova configuração em execução chamada Configuração dourada. A configuração dourada serve como Intenção: o Apstra compara continuamente a configuração em execução com a configuração dourada. Quando uma implantação falha, o Apstra descondita o Golden Config.

Estágios de configuração: visão geral

A tabela a seguir descreve os vários eventos de configuração e sua configuração de dispositivo resultante, estado do dispositivo gerenciado pelo Apstra e modo de implantação de blueprints:

de eventos que resulta no Apstra
Configuração de dispositivo resultantemodo de implantação do Apstra Managed Device State
Novo dispositivo Configuração padrão de fábrica N/A N/A
Adicione a configuração pré-Apstra [mgmt] ao dispositivo Fábrica + Pré-Apstra N/A N/A
Instale o agente do sistema de dispositivos Apstra Configuração intocada: Configuração de fábrica + pré-Apstra + instalação de agentes QUARENTENA OOS Não atribuído
Reconhecer dispositivo Descoberta 1: Interfaces plus imaculadas habilitadas PRONTO PARA OOS Não atribuído
Atribua o dispositivo ao blueprint (sem implantação) Pronto (Discovery 2): Discovery 1, mais várias configurações básicas ESTÁ PRONTO PARA Pronto
Implantar dispositivo Configuração do serviço: Configuração pronta (Discovery 2) mais configuração completa renderizada pelo Apstra IS-ACTIVE Implantar
Configuração incremental Add/Commit Delta de mudanças de configuração resultantes de modificações de blueprint IS-ACTIVE Implantar
Dispositivo de drenagem A configuração "Drene" é adicionada ESTÁ PRONTO PARA Drenar
Dispositivo inimplantável A configuração renderizada pelo Apstra é removida ESTÁ PRONTO PARA Inimplantável
Dispositivo unassign A configuração discovery 1 é novamente aplicada PRONTO PARA OOS Não atribuído
CUIDADO:

Quando você instala um agente em um dispositivo, qualquer configuração que já estava lá se torna parte do Pristine Config, o que significa que ele está incluído em todo o ciclo de vida da configuração do dispositivo. Quaisquer correções que você fizer serão impactantes no serviço.

Estágios de configuração: detalhe

Novo dispositivo (padrão de fábrica)

O ciclo de vida de um dispositivo começa com o estágio de configuração padrão de fábrica .

Adicionar configuração pré-Apstra (exigido pelo usuário)

Determinada configuração base mínima é necessária para todo o ciclo de vida da configuração. Isso inclui a configuração para instalação de agentes e conectividade de dispositivos. Você deve configurar a conectividade IP de gerenciamento entre dispositivos e o servidor Apstra fora de banda (OOB). A configuração em banda não é suportada e pode causar problemas de conectividade quando mudanças são feitas no blueprint.

Você pode inicializar essa configuração exigida pelo usuário com o Apstra ZTP ou adicioná-la com scripts (ou outros métodos).

CUIDADO:

Adicione apenas a configuração necessária para conectividade, para a instalação do agente do dispositivo ou que seja conhecida por ser necessária durante todo o ciclo de vida do dispositivo (por exemplo, banners ou endereços IP de servidores NTP/SNMP/syslog). Você pode adicionar configurações necessárias que não são renderizadas pelo Apstra com configurações.

Agente de instalação (Pristine)

Quando você instala um agente de caixa de entrada em um dispositivo (ou um agente offbox no servidor) o dispositivo se conecta e se registra com o Apstra no estado de quarentena . O Apstra aplica configuração parcial à configuração pré-Apstra. Essa configuração é chamada de configuração Pristine. A configuração perfeita é a base para toda a configuração subsequente do dispositivo.

Dispositivo de reconhecimento (Discovery 1 / Pronto)

Quando você reconhece um dispositivo, você está colocando-o no estado pronto . Esse reconhecimento sinaliza sua intenção de que o Apstra gerencie o dispositivo. Para a configuração intocada, o Apstra adiciona uma configuração base mínima essencial para a operação do agente Apstra. Essa configuração é chamada de configuração Discovery 1. A Discovery 1 aplica uma configuração completa (push de configuração completa), sobrescrevendo todas as configurações existentes para garantir a integridade da configuração.

  • Todas as interfaces são renderizadas com velocidades de interface para o perfil do dispositivo atribuído.
  • Todas as interfaces permitem no shutdown que você visualize as informações do vizinho LLDP.
  • Todas as interfaces são movidas para o modo L3 (padrão) para evitar que o dispositivo participe da malha.
Nota:

Os dispositivos que foram reconhecidos não podem simplesmente ser excluídos. Como o dispositivo ainda teria um agente ativo instalado, os dispositivos voltariam a aparecer em segundos. Para remover um dispositivo do gerenciamento do Apstra, veja remover (Descomission) dispositivos gerenciados para obter o fluxo de trabalho completo.

Atribua dispositivo (pronto/ pronto)

Quando você atribui um dispositivo a um blueprint e define seu modo de implantação para pronto, você está colocando-o no estado pronto (Discovery 2 ). O dispositivo foi encenado, mas ainda não foi comprometido (implantado) com o blueprint ativo. A configuração pronta aplica uma configuração completa (push de configuração completa) para garantir a integridade da configuração. A configuração pronta traz interfaces de rede e configura descrições de interface e valida a telemetria, como LLDP, para garantir que ela esteja adequadamente com fio e configurada. Essa configuração não é disruptiva para outros serviços na malha. Os links estão em funcionamento, mas estão configurados no modo L3 para evitar operações de STP/L2.

  • O nome de host está configurado por intenção de blueprint.
  • Todas as descrições da interface são alteradas por intenção de blueprint.
  • As interfaces são renderizadas com velocidades de interface de blueprint.
  • Nenhum roteamento ou BGP está configurado.
  • Nenhuma informação L3 está configurada em interfaces.
  • A MTU de malha é modificada para dispositivos spine para 9050 bytes.

Implantar dispositivo (renderizado/ativo)

CUIDADO:

Na primeira vez que você atribui um dispositivo e o implanta (definir o modo de implantação para implantar e comprometer o blueprint), você está desencadeando um push de configuração completo no dispositivo. Essa ação substitui a configuração completa em execução com a configuração intocada e adiciona a configuração apstra completa. O Apstra descarta qualquer configuração que não seja parte da configuração renderizada pelo Apstra.

Quando você confirma um dispositivo, ele se torna Ativo, e o Apstra implanta a configuração de serviços, movendo o dispositivo para o estágio de configuração renderizado . Os conteúdos de configuração renderizados são derivados da configuração intocada, design/topologia de referência selecionado, NOS e modelo de dispositivo. A primeira configuração renderizada aplica uma configuração completa (removendo todas as configurações existentes do servidor Apstra por Jinja) para garantir a integridade da configuração. Este é o estado final completo do Apstra. Uma configuração completa foi empurrada, todas as interfaces estão sendo executadas e o roteamento dentro da malha de IP está configurado. A renderização completa da configuração, a telemetria baseada em intenção e as operações de serviço padrão ocorrem aqui.

  • O nome de host está configurado por intenção de blueprint.
  • Todas as descrições da interface são alteradas por intenção de blueprint.
  • As interfaces são renderizadas com velocidades de interface de blueprint.
  • VLANs de interface, LAGS, MLAG, VXLAN e assim por diante, são gerenciadas.
  • Todas as informações de L3 são renderizadas.
  • A configuração do BGP é totalmente renderizada para todas as informações de peering BGP.
  • A configuração de DHCP está configurada para quaisquer agentes de transmissão DHCP necessários.
  • O dispositivo é adicionado ao banco de dados de gráficos.

Após a configuração completa ser implantada com sucesso no dispositivo, o Apstra tira um instantâneo da configuração do dispositivo (por exemplo, mostra a configuração em execução) e a armazena como a Configuração Dourada.

CUIDADO:

Se você adicionar a configuração neste momento, você aumentará as anomalias de desvio de configuração. O desvio é a diferença entre a configuração atual e a configuração dourada armazenada. Antes de prosseguir com as tarefas de implantação, você deve corrigir quaisquer anomalias.

Para ver o arquivo de configuração renderizado após o compromisso com o blueprint, selecione o dispositivo no blueprint Ativo e clique em Config (lado direito).

Você pode modificar uma configuração em execução de várias maneiras. Para modificar uma configuração que não faz parte do design de referência, use configurações.

Atualização do dispositivo de estágio (incremental / ativa)

Quando você encena mudanças em um blueprint em execução, você está criando uma configuração incremental .

Confirmar dispositivo novamente (atualizado/ativo)

Quando você confirma uma mudança em um blueprint que afeta a configuração do dispositivo, uma configuração parcial atualiza a configuração renderizada.

Visualizar a configuração do dispositivo a partir do blueprint

Desde o blueprint, navegue até o Staged > Physical para acessar a visão de topologia do blueprint físico.

Clique em um nó na topologia e, em seguida, a partir da guia dispositivo no painel à direita, você pode clicar em links para contexto renderizado, incremental, puro ou dispositivo na seção Config .

O modelo de dispositivo é um diagrama aninhado de variáveis que você pode aproveitar ao criar configurações em blueprints de data center ou modelos de configuração em blueprints Freeform. O contexto do dispositivo inclui informações úteis ao criar configurações em blueprints de data center. Na seção de interface você encontrará tags para tags de interface e intf_tags para tags de link. Na seção principal você encontrará system_tags.

A guia de consulta oferece recursos dinâmicos de pesquisa para pesquisar rapidamente por chaves ou valores e identificar as variáveis de interesse. A sintaxe é sensível ao caso. Por exemplo, uma pesquisa da palavra-chave bgp fornece informações sobre a configuração BGP do switch, bem como as sessões BGP (sessões de protocolo), enquanto uma pesquisa na palavra-chave BGP fornece a lista de mapas de rotas BGP, como "BGP-AOS-Policy". O uso dessas variáveis como conjuntos de propriedades integrados dentro de uma configuração também deve respeitar o atributo sensível ao caso do modelo do dispositivo.

CUIDADO:

Modelos de dispositivos são um modelo de dados interno usado no ambiente Apstra. Eles estão sujeitos a alterações sem aviso prévio ou documentação de alterações no esquema.

Desvios de configuração

Após cada configuração bem-sucedida , a configuração em execução é coletada e armazenada internamente como a configuração áurea . A intenção é a base do produto Apstra. Qualquer diferença entre a configuração em execução real e esta configuração dourada resulta em uma anomalia de desvio de configuração no painel do blueprint. A configuração dourada é atualizada cada vez que a configuração é aplicada com sucesso a um dispositivo.

Alguns pontos importantes para saber:

  • Cada implantação de configuração bem-sucedida resulta em uma Config de Ouro atualizada.
  • Se a implantação da configuração falhar, a Configuração Dourada não será definida. Isso significa que tanto um desvio de configuração quanto uma anomalia de falha de implantação são levantados.
  • A telemetria de configuração em execução é coletada continuamente e combinada com a Configuração dourada. Qualquer diferença resulta em uma anomalia de desvio.
  • As anomalias de configuração podem ser "suprimidas" usando o recurso "Aceitar mudanças". Isso NÃO significa que a mudança seja adicionada à configuração dourada ou intenção.

Veja detalhes sobre anomalias (Serviço ).

Dispositivo offline (indisponível)

Um dispositivo gerenciado (um que foi reconhecido) que não está conectado ao servidor Apstra está no estado indisponível . Um dispositivo pode estar offline se a interface do agente do dispositivo estiver offline, se o serviço não estiver sendo executado ou se ocorrer um erro de conectividade de rede.

Aplicar configuração completa manualmente

As etapas de configuração do Discovery 1 e Deploy Device iniciam pressões completas de configuração. Em casos raros, você pode precisar aplicar manualmente um push completo de configuração. Por exemplo, se a configuração necessária não estiver em vigor para um blueprint com dispositivos NX-OS que exigem esculturas de TCAM, a configuração do dispositivo falhará. O erro de configuração do TCAM deve ser corrigido, seguido por empurrar manualmente uma configuração completa.

Nota:

Execute um push de configuração completo com a máxima cautela, pois é muito provável que afete todos os serviços em execução na caixa. O impacto exato depende das mudanças serem empurradas. Observe também que todas as mudanças fora da banda são sobreescritas após um push completo.

Modos de implantação

Dispositivos gerenciados em blueprints podem ser em um dos vários modos:

Não definir

Estado inicial do dispositivo. O dispositivo não está ativo na malha. Quando você não designa uma ID do sistema de um dispositivo em um blueprint, o modo de implantação muda automaticamente para Not Set (a partir da versão 5.0.0 do Apstra).

Implantar

O dispositivo está ativo na malha.

Pronto

Quando você atribui um dispositivo a um blueprint, ele implanta mudanças de modo no Ready; O Apstra renderiza configurações prontas (Discovery 2) (nomes de host, descrições de interface, velocidade de porta /configuração de separação). O dispositivo não está ativo na malha. Mudar da implantação para pronto remove a configuração renderizada pelo Apstra.

Drenar

A drenagem de um dispositivo para manutenção física permite que ele seja retirado de serviço sem afetar os fluxos TCP existentes. Dependendo do dispositivo ser drenado, o Apstra usa um dos dois métodos:

Para servidores L2

  • Os canais de porta de peer-links MLAG e interfaces de títulos em qualquer NOS não são alterados.
  • Para O Arista EOS e Cisco NX-OS, e Junos OS no Apstra 4.2.1 e superior, todas as interfaces para servidores L2 no blueprint são shutdown.

Para switches L3 de rede

O dispositivo usa declarações de 'negar' mapas de rota de entrada/saída para bloquear quaisquer anúncios a 0.0.0.0/0 le 32. Isso permite que os fluxos TCP L3 existentes continuem sem interrupção. Após um segundo ou dois, as sessões de TCP devem ser restabelecidas pelos dispositivos src/dst, ou devem negociar uma nova porta TCP. A nova porta TCP força os dispositivos a serem hashed em um novo caminho ECMP a partir da lista de links disponíveis. Como não há rotas de ECMP para o destino disponíveis na presença de um mapa de rota, o tráfego não flui pelo dispositivo que está no modo Dreno . O dispositivo é efetivamente drenado do tráfego e pode ser removido da malha (mudando o modo De implantação para Undeploy).

Embora as sessões de TCP drenem (o que pode levar algum tempo, especialmente para os blueprints EVPN), são esperadas anomalias BGP. Quando a implantação da configuração é concluída, as anomalias temporárias são resolvidas.

Quando você altera o modo de implantação para Drenar em um dispositivo, a configuração do dispositivo vizinho também pode ser afetada, não apenas o dispositivo que você está drenando. Por exemplo, quando você drena um dispositivo spine, a configuração em todos os dispositivos leaf conectados muda. Os dispositivos leaf vizinhos usam filtros de rota de entrada/saída (mapas de rota) para bloquear quaisquer anúncios a 0,0.0.0/0 le 32, tanto para EVPN (overlay) quanto para FABRIC (underlay).

Da mesma forma, quando você drena um dispositivo leaf, a configuração em dispositivos spine conectados muda. Os dispositivos spine vizinhos usam filtros de rota de entrada/saída (mapas de rota) "rejeitar (negar)" declarações para bloquear quaisquer anúncios a 0,0,0,0/0 le 32, tanto para EVPN (overlay) quanto para FABRIC (underlay).

No caso de uma topologia baseada em MLAG, além da configuração em dispositivos spine conectados mudando, a configuração no dispositivo leaf pareado também muda.

Inimplantável

A inimplantação de um dispositivo remove a configuração de serviço completa. Se um dispositivo estiver transportando tráfego, é melhor colocá-lo no modo Dreno em primeiro lugar (e confirmar a mudança) antes de nãoimplantar o dispositivo.