Ciclo de vida da configuração do dispositivo
É essencial ter uma boa compreensão do ciclo de vida de configuração do dispositivo Apstra. Antes de trabalhar com dispositivos no ambiente do Apstra, recomendamos que você entenda completamente como os dispositivos são configurados desde o momento em que são integrados até o momento em que são desativados.
Terminologia
Os estágios do ciclo de vida da configuração são os seguintes:
| Estágio de configuração | Descrição |
|---|---|
| Configuração cristalina | Quando você instala um agente de dispositivo, a configuração é adicionada à configuração pré-existente no dispositivo. Normalmente, a configuração original não muda ao longo do ciclo de vida do dispositivo. |
| Configuração do Discovery 1 | Quando você reconhece um dispositivo, o Apstra adiciona a configuração básica, incluindo a habilitação do LLDP em todas as interfaces. |
| Ready Config (anteriormente conhecido como Discovery 2 Config) | Quando você atribui um dispositivo a um blueprint sem implantá-lo (modo de implantação: pronto), o Apstra adiciona a configuração básica, incluindo nomes de host de dispositivos, descrições de interface e velocidade de porta/configuração de breakout. |
| Configuração de serviço | Quando você implanta um dispositivo (modo de implantação: implantar), o Apstra adiciona a configuração necessária no ambiente do Apstra. A Configuração de Serviço consiste na configuração da Descoberta 1, na configuração Pronta (Descoberta 2) e nessa configuração adicional. |
| Configuração renderizada | Conclua a configuração 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 as alterações feitas. |
| Configuração dourada | Quando você confirma alterações de configuração, o Apstra coleta uma nova configuração em execução chamada Golden Config. 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 desativa a configuração dourada. |
Estágios de configuração: visão geral
A tabela a seguir descreve os vários eventos de configuração e a configuração do dispositivo resultante, o estado do dispositivo gerenciado pelo Apstra e o modo de implantação do blueprint:
| Evento | Configuração do dispositivo resultante | Estado resultante do dispositivo gerenciado do Apstra | Modo de implantação do blueprint do Apstra |
|---|---|---|---|
| Novo dispositivo | Configuração padrão de fábrica | N/A | N/A |
| Adicionar configuração pré-Apstra [mgmt] ao dispositivo | Fábrica + Pré-Apstra | N/A | N/A |
| Instalar o agente do sistema do dispositivo Apstra | Configuração perfeita: Configuração de instalação de fábrica + pré-Apstra + agente | OOS EM QUARENTENA | Não atribuído |
| Reconhecer dispositivo | Descoberta 1: Puro e com interfaces habilitadas | PRONTO PARA O OOS | Não atribuído |
| Atribuir dispositivo ao blueprint (sem implantação) | Pronto (Discovery 2): Descoberta 1, além de várias configurações básicas | ESTÁ PRONTO | Pronto |
| Implantar dispositivo | Configuração de serviço: Configuração pronta (Discovery 2) mais configuração completa renderizada pelo Apstra | É ATIVO | Implantar |
| Adicionar/confirmar configuração incremental | Delta das alterações de configuração resultantes das modificações do blueprint | É ATIVO | Implantar |
| Dispositivo de drenagem | A configuração "Drenar" é adicionada | ESTÁ PRONTO | Dreno |
| Dispositivo de desimplantação | A configuração renderizada pelo Apstra foi removida | ESTÁ PRONTO | Desimplantar |
| Cancelar atribuição de dispositivo | A configuração do Discovery 1 é reaplicada | PRONTO PARA O OOS | Não atribuído |
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 está incluída em todo o ciclo de vida de configuração do dispositivo. Quaisquer correções que você fizer afetarão o serviço.
Estágios de configuração: detalhe
- Novo dispositivo (padrão de fábrica)
- Adicionar configuração pré-Apstra (exigido pelo usuário)
- Agente de instalação (imaculado)
- Reconhecer dispositivo (Descoberta 1 / Pronto)
- Atribuir dispositivo (pronto / pronto)
- Implantar dispositivo (renderizado/ativo)
- Preparar atualização de dispositivo (incremental / ativo)
- Confirmar dispositivo novamente (Renderizado-Atualizado/Ativo)
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 básica mínima é necessária para todo o ciclo de vida da configuração. Isso inclui configuração para instalação do agente e conectividade do dispositivo. Você deve configurar a conectividade IP de gerenciamento entre os dispositivos e o servidor Apstra fora de banda (OOB). Não há suporte para configurá-lo em banda e pode causar problemas de conectividade quando são feitas alterações 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).
Adicione apenas a configuração necessária para conectividade, para instalar o 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 do servidor NTP/SNMP/syslog). Você pode adicionar a configuração necessária que não é renderizada pelo Apstra com configlets.
Agente de instalação (imaculado)
Quando você instala um agente onbox em um dispositivo (ou um agente offbox no servidor), o dispositivo se conecta e se registra no Apstra no estado em quarentena . O Apstra aplica uma configuração parcial à configuração pré-Apstra. Essa configuração é chamada de configuração original. A configuração impecável é a base para todas as configurações de dispositivos subsequentes.
Reconhecer dispositivo (Descoberta 1 / Pronto)
Quando você reconhece um dispositivo, você o coloca no estado Pronto . Essa confirmação sinaliza sua intenção de fazer com que o Apstra gerencie o dispositivo. Para a configuração original, o Apstra adiciona uma configuração base mínima que é essencial para a operação do agente do Apstra. Essa configuração é chamada de configuração do Discovery 1. A descoberta 1 aplica uma configuração completa (full config push), substituindo 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 de dispositivo atribuído.
- Todas as interfaces devem
no shutdownpermitir 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.
Os dispositivos que foram reconhecidos não podem ser simplesmente excluídos. Como o dispositivo ainda teria um agente ativo instalado, os dispositivos reapareceriam em segundos. Para remover um dispositivo do gerenciamento do Apstra, consulte Remover (desativar) dispositivo de dispositivos gerenciados para obter o fluxo de trabalho completo.
Atribuir dispositivo (pronto / pronto)
Quando você atribui um dispositivo a um blueprint e define seu Modo de Implantação como Pronto, você o coloca no estado Pronto (Descoberta 2). O dispositivo foi preparado, mas ainda não foi confirmado (implantado) no 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 abre interfaces de rede e configura descrições de interface e valida a telemetria, como LLDP, para garantir que ela esteja conectada e configurada corretamente. Essa configuração não interrompe outros serviços na malha. Os links estão ativos, mas estão configurados no modo L3 para evitar operações STP/L2.
- O nome do host é configurado de acordo com a intenção do blueprint.
- Todas as descrições de 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 nas interfaces.
- A MTU da malha é modificada para dispositivos spine para 9050 bytes.
Implantar dispositivo (renderizado/ativo)
Na primeira vez que você atribui um dispositivo e o implanta (define o modo de implantação como Implantar e confirmar o blueprint), você está disparando um push de configuração completo no dispositivo. Essa ação substitui a configuração atual completa pela configuração original e, em seguida, adiciona a configuração completa do Apstra renderizada. O Apstra descarta qualquer configuração que não faça parte da configuração renderizada pelo Apstra.
Quando você confirma um dispositivo, ele se torna ativo, e o Apstra implanta a configuração do serviço, movendo o dispositivo para o estágio de configuração renderizada . O conteúdo da configuração renderizada é derivado da configuração original, do design/topologia de referência selecionados, do NOS e do modelo do 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 enviada, todas as interfaces estão em execução e o roteamento dentro da malha 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 do host é configurado de acordo com a intenção do blueprint.
- Todas as descrições de 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 gerenciados.
- Todas as informações L3 são renderizadas.
- A configuração do BGP é totalmente renderizada para todas as informações de peering BGP.
- A configuração do DHCP é configurada para todos os agentes de transmissão DHCP necessários.
- O dispositivo é adicionado ao banco de dados de gráficos.
Depois que a configuração completa é implantada com sucesso no dispositivo, o Apstra tira um snapshot da configuração do dispositivo (por exemplo, show running-confg) e o armazena como a Golden Configuration.
Se você adicionar a configuração neste ponto, gerará anomalias de desvio de configuração. O desvio é a diferença entre a configuração atual e a configuração Golden armazenada. Antes de prosseguir com as tarefas de implantação, você deve corrigir quaisquer anomalias.
Para ver o arquivo de configuração renderizado depois de confirmar 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 configlets.
Preparar atualização de dispositivo (incremental / ativo)
Ao preparar alterações em um blueprint em execução, você está criando uma configuração incremental .
Confirmar dispositivo novamente (Renderizado-Atualizado/Ativo)
Quando você confirma uma alteração 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 no blueprint
No blueprint, navegue até Preparado > Físico para ir para a exibição Topologia do modelo físico.
Clique em um nó na topologia e, na guia Dispositivo no painel à direita, você pode clicar em links para contexto renderizado, incremental, original ou de dispositivo na seção Config . 
O modelo de dispositivo é um dicionário aninhado de variáveis que você pode aproveitar ao criar configlets em blueprints do Datacenter ou modelos de configuração em blueprints do Freeform. O contexto do dispositivo inclui informações úteis ao criar configlets em blueprints de data center. Na seção de interface, você encontrará tags tags de interface e intf_tags tags de link. Na seção principal, você encontrará system_tags.

A guia de consulta fornece recursos de pesquisa dinâmica para pesquisar rapidamente chaves ou valores e identificar as variáveis de interesse. A sintaxe diferencia maiúsculas de minúsculas. 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 internos dentro de um configlet também deve respeitar o atributo que diferencia maiúsculas de minúsculas do modelo do dispositivo.
Os modelos de dispositivo são um modelo de dados interno usado no ambiente do Apstra. Eles estão sujeitos a alterações sem aviso prévio ou documentação de alterações de esquema.
Desvios de configuração
Após cada implantação de configuração bem-sucedida , a configuração em execução é coletada e armazenada internamente como a configuração Golden . A intenção é a base do produto Apstra. Qualquer diferença entre a configuração em execução real e essa golden config resulta em uma anomalia de desvio de configuração no painel do blueprint. A configuração dourada é atualizada toda vez que a configuração é aplicada com sucesso a um dispositivo.
Alguns pontos importantes a saber:
- Cada implantação de configuração bem-sucedida resulta em uma Golden Config atualizada.
- Se a implantação da configuração falhar, o Golden Config não será definido. Isso significa que um desvio de configuração e uma anomalia de falha de implantação são gerados.
- A telemetria de configuração em execução é continuamente coletada e combinada com a Golden Config. Qualquer diferença resulta em uma anomalia de desvio.
- As anomalias de configuração podem ser "suprimidas" usando o "recurso Aceitar alterações". Isso NÃO significa que a alteração foi adicionada à golden config ou à intenção.
Consulte Anomalias (Serviço) para obter detalhes.
Aplicar manualmente a configuração completa
Os estágios de configuração Discovery 1 e Deploy Device iniciam pushes de configuração completos. Em casos raros, pode ser necessário aplicar manualmente um push de configuração completo. Por exemplo, se a configuração necessária não estiver em vigor para um blueprint com dispositivos NX-OS que exigem a escultura de TCAM, a configuração do dispositivo falhará. O erro de configuração de TCAM deve ser corrigido, seguido por push manual de uma configuração completa.
Execute um push de configuração completo com o máximo cuidado, pois é muito provável que isso afete todos os serviços em execução na caixa. O impacto exato depende das mudanças que estão sendo promovidas. Observe também que todas as alterações fora da banda são substituídas após um push completo.
Modos de implantação
Os dispositivos gerenciados em blueprints podem estar em um dos vários modos:
Não definido
Estado inicial do dispositivo. O dispositivo não está ativo na malha. Quando você cancela a atribuição de um ID do sistema de um dispositivo em um blueprint, o modo de implantação muda automaticamente para Não definido (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 muda para Pronto; O Apstra renderiza a configuração Ready (Discovery 2) (nomes de host, descrições de interface, velocidade da porta/configuração de breakout). O dispositivo não está ativo na malha. Alterar de Implantar para Pronto remove a configuração renderizada pelo Apstra.
Dreno
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 que está sendo drenado, o Apstra usa um destes dois métodos:
Para servidores L2
- MLAG, links pares, canais de porta e interfaces de ligação em qualquer NOS não são alterados.
- Para 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 instruções de 'negação' de mapas de rota de entrada/saída para bloquear qualquer anúncio para 0.0.0.0/0 le 32. Isso permite que os fluxos TCP L3 existentes continuem sem interrupção. Após um ou dois segundos, as sessões TCP devem ser restabelecidas pelos dispositivos src/dst, ou eles devem negociar uma nova porta TCP. A nova porta TCP força os dispositivos a serem hash em um novo caminho ECMP da lista de links disponíveis. Como nenhuma rota ECMP para o destino está disponível na presença de um mapa de rotas, o tráfego não flui pelo dispositivo que está no modo Drenar . O dispositivo é efetivamente drenado de tráfego e pode ser removido da malha (alterando o modo de implantação para Desimplantação).
Embora as sessões de TCP sejam drenadas (o que pode levar algum tempo, especialmente para blueprints de EVPN), são esperadas anomalias de 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) 'reject (deny)' declarações para bloquear qualquer anúncio para 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 nos dispositivos spine conectados muda. Os dispositivos spine vizinhos usam filtros de rota de entrada/saída (mapas de rota) 'reject (deny)' declarações para bloquear qualquer anúncio para 0.0.0.0/0 le 32, tanto para EVPN (overlay) quanto FABRIC (underlay).

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

Desimplantar
A desimplantação de um dispositivo remove a configuração completa do serviço. Se um dispositivo estiver transportando tráfego, é melhor colocá-lo no modo Drenar primeiro (e confirmar a alteração) antes de desimplantar o dispositivo.