Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Hierarquia de configuração do Juniper Mist WAN Assurance

Introdução à hierarquia de configuração

Configuração do Juniper Mist WAN Assurance

Para os administradores de rede, é essencial entender que cada peça do quebra-cabeça cria as políticas, a segurança e a conectividade da sua rede no serviço de nuvem Juniper Mist WAN Assurance. Uma implantação completa da SD-WAN requer que cada parte conclua a conectividade entre os locais. A Mist traduz automaticamente sua intenção de tráfego em configurações para dispositivos WAN Edge usando o modelo de rede baseada em intenção (IBN) da Mist. Cada parte trabalha em conjunto para criar atribuições de interface complexas, segurança, políticas de roteamento e — dependendo da plataforma — zonas de destino. Portanto, entender o modelo de intenção do Mist é crucial à medida que nos aprofundamos na hierarquia de configuração do Juniper Mist WAN Assurance.

Roteamento baseado em intenção

O IBN resolve vários problemas. Por exemplo, considere a necessidade de comunicação segura entre duas redes. Um modelo de intenção afirma que a comunicação segura requer um túnel seguro entre a rede A e a rede B. Nesse cenário, um administrador de rede identifica qual tráfego usa o túnel e descreve outras propriedades gerais desejadas. Mas um operador não especificaria ou mesmo saberia como construir um túnel. Para implementar um túnel, você deve saber quantos dispositivos proteger, como fazer anúncios BGP e quais recursos e parâmetros ativar. Por outro lado, um sistema IBN gera automaticamente uma configuração completa de todos os dispositivos com base na descrição do serviço. Em seguida, ele fornece verificações de garantia contínuas entre o estado desejado e o estado operacional da rede, usando validação de loop fechado para verificar continuamente a exatidão da configuração. O IBN é um modelo de operação de rede declarativo. Ela contrasta com a tradicional rede imperativa, que exige que os engenheiros de rede especifiquem a sequência de ações necessárias em elementos individuais da rede e cria um potencial significativo de erro.

Principais características do modelo baseado em intenção:

  • Não exigem tanta direção explícita quanto os modelos de rede tradicionais exigem.
  • Crie políticas com base em qual rede vai para qual aplicativo.
  • Configure redes e aplicativos do Juniper Mist WAN Assurance em toda a organização.
  • Envie apenas configurações relevantes.
  • Configure apenas os aplicativos que um dispositivo usa. Se um dispositivo não usar um Aplicativo, a rede baseada em intenção não o configurará nesse dispositivo.

Vejamos o exemplo de configuração do DHCP em uma LAN e suponha que a interface já esteja configurada e atribuída a uma zona.

Etapas necessárias na CLI do Junos:

  • Navegue até o nível de serviços do sistema Junos e habilite o DHCP-local-server para sua interface.
  • Navegue até a atribuição de endereços do sistema Junos e crie um pool de endereços especificando a rede de destino, o intervalo de endereços para o pool, o gateway padrão e quaisquer outros atributos DHCP.
  • Navegue até sua zona de segurança e habilite o tráfego de entrada de host para o serviço do sistema DHCP para permitir que a Série SRX processe solicitações DHCP de clientes.

As etapas acima exigem várias linhas de configuração espalhadas por três hierarquias de configuração, no mínimo.

O mesmo fluxo de trabalho é significativamente simplificado no Mist:

  • Primeiro, navegue até a configuração da LAN e abra-a para edição.
  • Em seguida, habilite o botão de opção Servidor DHCP para desbloquear a configuração e preencher os campos obrigatórios (Início do IP, Fim do IP e gateway).
  • Salve a configuração da LAN e, em seguida, salve a configuração do dispositivo.

Elementos da hierarquia de configuração

Elementos de configuração em toda a organização

A parte superior da configuração do Mist é chamada de organização do Mist. Esses elementos afetam toda a sua implantação de rede de longa distância definida por software (SD-WAN). Os diferentes componentes nesse nível de configuração se tornam blocos de construção para origens e destinos em sua implantação. Uma vez identificadas, as solicitações de tráfego associam um remetente e o destino desejado de forma adequada. Os elementos ajudam a construir diferentes componentes de implantação do Juniper Mist WAN Assurance, dependendo da sua plataforma. A identificação da origem e do destino criará túneis IPsec na WAN e nas zonas de segurança associadas no firewall da Juniper® Série SRX. Esses componentes no Session Smart™ Router da Juniper® Networks tornam-se a origem e o destino correspondentes para ajudar a construir a troca de metadados de roteamento de vetor seguro (SVR). As duas plataformas abordam o desafio da SD-WAN de forma única, o que torna importante conhecer sua plataforma Juniper Mist WAN Assurance.

Redes

A rede Juniper Mist WAN Assurance é o "quem" no paradigma orientado por intenção da Mist. As redes são fontes da solicitação em sua rede. As redes permitem que você defina grupos de "Usuários". Depois de criar esse elemento em seu design do Mist, a rede é definida para uso em toda a organização.

Características das redes no roteador Session Smart™ da Juniper® Networks:

  • A Mist Networks cria locatários em segundo plano para SVR.
  • O Session Smart Router identifica os locatários na interface lógica (interface de rede).
  • As configurações de interface de LAN e WAN identificam seu locatário (origem da solicitação).

Características das redes no firewall da Juniper® Série SRX:

  • As redes criam catálogos de endereços usados como fonte para políticas de segurança e políticas de roteamento avançado baseado em políticas (APBR).
  • As configurações serão aplicadas ao dispositivo se uma Política de Aplicativo estiver configurada.
  • Para a LAN, o nome da zona é derivado do nome da rede especificada.
  • Para a WAN, o nome da zona é baseado no nome da WAN.

Anúncio de rota (anunciar via overlay)

O WAN Assurance trata da abstração da rede de transporte para a SD-WAN. Você pode anunciar redes por meio da SD-WAN para controle e acessibilidade com anúncio de rota. Em seguida, as redes estabelecidas em seus segmentos de LAN podem ser anunciadas em toda a sobreposição. A configuração dessas redes gera os endereços de origem para políticas de serviço. A Network Address Translation (NAT) para a origem e o destino pode rotear o tráfego para seus usuários, se necessário.

O objetivo da SD-WAN é a conectividade entre sites. Portanto, as redes podem ser anunciadas por meio de sobreposição para permitir a acessibilidade entre seus dispositivos SD-WAN. Com essa configuração, sua rede compartilhará o endereço pela WAN para que outros dispositivos saibam como alcançá-la. Você pode anunciar para outros spokes ou para hubs de vizinhos de LAN. Para obter mais informações sobre esse recurso, consulte Configurações de rede.

Acesso à Mist Cloud

Mist é uma solução completa. Apenas alguns de seus dispositivos são roteadores WAN Edge ou SD-WAN. Dispositivos específicos desejarão acessar a Mist Cloud para aproveitar outras soluções, como Wireless e Wired Assurance, em APs e switches sem fio. O acesso à Mist Cloud gerará automaticamente regras de firewall/política específicas, permitindo que os dispositivos liguem para casa com a Mist sem a necessidade de uma política explícita de aplicativo. No entanto, você não deseja esse nível de acesso em todos os dispositivos por trás da borda da WAN em uma implantação de SD-WAN porque isso pode representar um desafio de política para os roteadores. Em geral, selecione Acesso à Mist Cloud para APs ou switches, para que você possa monitorar e solucionar problemas desses dispositivos no portal da Mist.

Permitir o acesso à nuvem da Mist garante que qualquer coisa que esteja atrás da borda da WAN possa alcançar a nuvem da Mist sem a necessidade de expressar políticas de conectividade manualmente. As portas e os protocolos para essa configuração incluem o seguinte:

  • TCP/443
  • DNS/53
  • SSH/2200
  • NTP/123
  • Syslog/6514
  • ICMP

Usuários

Não se deixe enganar pelo rótulo. Usuários não representa um único usuário em sua rede. Os usuários são subconjuntos de sub-redes ou sub-redes conectadas indiretamente. Como as redes são "quem", pense nos usuários como uma subdivisão dessa identidade de rede. Muitas vezes, existem regras universais para tratar as redes da mesma forma. Por exemplo, para 99% do seu tráfego, você deseja que as sessões façam a mesma coisa. Mas e quando você está bloqueando o acesso a uma rede corporativa a partir de uma rede de convidados e apenas um IP precisa de acesso à impressora? Nessa situação, adicione um Usuário. Para aqueles familiarizados com a plataforma Session Smart Routing, compare um usuário com um locatário. Você também pode criar Usuários para definir prefixos indiretos na rede.

  • Os usuários podem definir permissões granulares. Por exemplo, seu segmento de LAN pode precisar de acesso à Internet, mas você deve restringi-lo a um dispositivo de rede específico. Então, aqui, você criaria uma política de acesso em torno dessa área de trabalho.
  • Às vezes, você precisa acessar prefixos conectados indiretamente atrás de um roteador no segmento de LAN. Por exemplo, imagine um roteador atrás de um dispositivo que conecta vários dispositivos a um aplicativo externo. Nesse caso, você pode adicionar usuários a uma rede que você configurou especificamente como uma "rede não conectada diretamente". Para obter mais informações, consulte Configurações de rede.

Aplicações

Os aplicativos incluem o "o quê" no paradigma do modelo orientado por intenção da Mist. Os aplicativos são o que sua rede oferece. Os aplicativos representam destinos de tráfego e são nomeados de acordo com o que um cliente acessaria, como um "banco de dados" ou a "Internet". Depois de criar esse elemento em seu design do Mist, o aplicativo é definido para uso em toda a organização.

Características dos aplicativos no roteador Session Smart™ da Juniper® Networks

  • Os aplicativos Mist criam serviços em segundo plano para SVR.
  • Os aplicativos podem ser portas, protocolos, prefixos, domínios personalizados ou nomes de aplicativos da biblioteca AppID integrada.

Portas, protocolos e prefixos são onde toda a política gira.

  • Aplicativos personalizados são um conjunto de portas, protocolos ou prefixos.
  • Os aplicativos são mapeados para a ID do aplicativo da Internet.
  • As categorias de URL são URLs de ponto de força.

Características dos aplicativos no firewall da Juniper® Série SRX

  • Os aplicativos determinam o destino usado em uma política de segurança.
    • Um prefixo de 0.0.0.0/0 com o protocolo "any" é resolvido para any dentro da política do Juniper Mist WAN Assurance. Nenhum catálogo de endereços ou inscrição é necessário.
  • Os aplicativos personalizados no WAN Edge usam o "tipo" de mecanismo on-box da Série SRX e são uma combinação de um catálogo de endereços e aplicativos.
  • Os aplicativos são mapeados para o mecanismo AppID de Camada 7 da Série SRX.
  • As categorias de URL são URLs de ponto de força.

Direcionamento de tráfego

O direcionamento de tráfego é o "como" no paradigma do modelo orientado por intenção da Mist. O direcionamento de tráfego é como você define os diferentes caminhos que o tráfego pode seguir para chegar ao seu destino. Se o tráfego para um aplicativo tiver vários caminhos, você poderá restringir os caminhos a um subconjunto de caminhos e configurar uma ordem de preferência. Você também pode carregar e balancear vários fluxos nos caminhos disponíveis.

Características do direcionamento de tráfego no roteador Session Smart™ da Juniper® Networks:

  • O Juniper® Session Smart Router™ é baseado em sessão e usa técnicas de monitoramento contínuo de caminhos para caminhos underlay e overlay para encontrar o melhor caminho disponível para qualquer aplicação.

  • Existem três estratégias de direção para a série SSR:
    • Ordenado: esse é o padrão — vá na ordem da lista. Os caminhos ativos na parte superior têm prioridade. Se um caminho cair, vá para o próximo caminho ativo na lista. Isso cria uma lista ordenada.

    • Ponderado: Permite que você defina o pedido desejado com base no peso. Por exemplo, dois caminhos ponderados, ambos definidos como 5, resultam em sessões de ECMP nos dois caminhos. Por outro lado, dois caminhos ponderados, com um definido como 5 e outro definido como 10, resultam em direção ordenada, com as sessões seguindo o caminho de menor peso primeiro.

    • ECMP: balanceamento total da carga do tráfego com um algoritmo multipath de custo igual. As sessões serão divididas igualmente em todos os caminhos disponíveis.

  • Ao contrário dos firewalls da Série SRX, o direcionamento de tráfego não é necessário em uma política de aplicativo para o SSR se já houver uma rota para o tráfego em seu RIB. Há situações em que a configuração do direcionamento de tráfego em uma política de aplicativo resultará em um comportamento indesejável. Consulte Backhaul da Internet através do hub para obter mais informações.

  • O SSR oferece suporte a políticas de direcionamento de tráfego que podem direcionar o tráfego de duas maneiras:

    • Em direção à sobreposição com várias opções para direcionar esse tráfego por diferentes caminhos de WAN usando o roteamento de vetor seguro (SVR). Para o direcionamento de tráfego na overlay, o Mist WAN Assurance conta com o BGP para rotear o tráfego entre dispositivos SSR. Você pode aproveitar esse comportamento para trocar e propagar rotas entre sua(s) rede(s) existente(s) e seu(s) dispositivo(s) SSR.

    • Roteado localmente para fora de uma ou mais interfaces específicas, o que é comum para o tráfego de breakout local (underlay). Para clientes que não desejam executar o roteamento dinâmico com o SSR ou clientes sem soluções de roteamento dinâmico existentes, consulte Backhaul da Internet através do Hub para obter detalhes.

  • Para políticas de aplicativo que têm uma ação de bloqueio, não insira nenhum direcionamento de tráfego

  • O SSR emprega um comportamento de negação por padrão. Você não precisa criar políticas de bloqueio, a menos que um objeto de rede específico já tenha acesso a um aplicativo mais amplo e você deseje limitar um intervalo específico dentro desse espaço de endereço.

Características do direcionamento de tráfego no firewall da Juniper® Série SRX:

  • O firewall da Juniper® Série SRX é baseado em zona, e a zona de destino é determinada pelos caminhos configurados em uma política de direcionamento de tráfego .
  • O Traffic Steering configura instâncias de roteamento do tipo encaminhamento e a política de roteamento relevante para importar rotas. Para sua Série SRX, essa instância de roteamento é usada no APBR.
  • Existem várias estratégias de direção para a Série SRX:
    • Ordenado: padrão, vá na ordem da lista. A parte superior tem prioridade e, em seguida, o failover para a próxima. Cria uma lista ordenada.
    • Ponderado: Permite que você defina o pedido desejado com base no peso. Por exemplo, dois caminhos ponderados, ambos definidos como 5, resultam em ECMP nos dois caminhos. Por outro lado, dois caminhos ponderados com um definido como 5 e o outro definido como 10 resultam em direção ordenada com o tráfego tomando o caminho de menor peso primeiro.
    • ECMP: balanceamento total da carga do tráfego com um algoritmo multipath de custo igual. O tráfego será dividido igualmente em todos os caminhos disponíveis.

Política de aplicação

O "quem", "o quê" e "como" vêm juntos com a Política de Aplicativo. O modelo orientado por intenção da Mist simplifica a geração manual de rotas e políticas de segurança por meio do Junos OS na Série SRX com milhares de linhas de código. Ele também simplifica a implantação de um Session Smart Router para aqueles que estão fazendo a transição de uma implantação Session Smart baseada em condutor para o WAN Assurance. Você não precisa mais de permissões explícitas e atribuições de interface para começar a trabalhar. WAN Assurance é zero trust. Esse recurso está implícito e faz parte do modelo orientado por intenção. Você deve conceder explicitamente permissão para permitir que uma Rede acesse um Aplicativo. Caso contrário, ele não será roteado.

A ordem só importa ao sair de sua rede local no roteador Session Smart™ da Juniper® Networks. O Session Smart Router usa as correspondências mais específicas. Como resultado, o direcionamento do tráfego não é necessário para o tráfego local. Além disso, usar um bloqueio em seu direcionamento de tráfego não funciona com o SVR, pois prejudica o processo proprietário. Se você não quiser que um dispositivo, sub-rede ou rede acesse um Aplicativo, não crie direcionamento de tráfego para esse dispositivo.

Características da política de aplicativos no firewall da Juniper® Série SRX:

O caminho de direção determina a zona de destino na série SRX. Certifique-se de que as políticas tenham o direcionamento de tráfego atribuído, pois a ordem das políticas é importante ao trabalhar com a Série SRX. Como um firewall tradicional baseado em zona, ele usa uma lista de regras que geram filtros e políticas. A maioria das regras específicas deve estar no topo da lista de políticas de aplicativos na Série SRX.

Escalando sua rede: Automação na Mist

Modelos de borda de WAN

Uma vez que os elementos básicos de configuração da SD-WAN estejam em vigor, a Mist permite que você implante novos dispositivos de borda de WAN por meio de modelos de borda de WAN. Toda essa configuração anterior pode ser modelada com modelos de borda de WAN. Esses modelos funcionam para um dispositivo Edge autônomo para uma implantação SD-WAN completa com centenas de sites. O processo de automação elimina erros e simplifica a implantação de vários spokes sites e headends.

Os modelos reduzem ou eliminam tarefas comuns de configuração e removem o erro humano ao configurar vários dispositivos. Modelos de borda de WAN:

  • Aplique padrões em uma implantação.
  • Certifique-se de que todos os seus dispositivos de rede apontem para o mesmo DNS (8.8.8.8).
  • Forneça um comportamento previsível porque eles usam o mesmo Network Time Protocol (NTP) para sincronização e registro. (Isso também afeta certificados específicos.)
  • Simplifique a solução de problemas e o gerenciamento.
    Figura 1: Modelo de borda da WAN Edge Template WAN

No entanto, os modelos de borda de WAN fazem mais do que automatizar tarefas. Você pode usar um modelo para padronizar uma configuração que pode ser aplicada de forma consistente em todos os sites, mesmo que você não implante todos os recursos em todos os sites. Por exemplo, talvez você não precise de uma rede de convidados em todos os sites, mas ao incluir a configuração no modelo, você está reservando essa interface. Se os planos futuros exigirem uma rede de convidados, a interface está pronta para ser usada.

Esses modelos também permitem:

  • Pedidos em massa de hardware para portas e grupos de sites por meio de modelos específicos.
  • Casos de uso e fluxos de tráfego específicos.
  • Diferentes redes LAN corporativas.
  • Redes de convidados.

Os modelos de borda de WAN configuram automaticamente informações repetitivas, como IP, gateway ou VLAN. Além disso, os modelos de borda de WAN podem incluir direcionamento de tráfego, políticas de acesso, preferências de roteamento e qualquer configuração adicional que você queira padronizar. Lembre-se de que você precisará de um prefixo, NAT ou outras informações locais para conectividade WAN e LAN.

Perfis de hub

Os perfis de hub funcionam com modelos de borda de WAN. Os hubs não estão na borda e são universalmente exclusivos em toda a sua rede. Os hubs afetam a forma como a Mist cria a rede overlay. Cada filial e escritório remoto cria a comunicação da SD-WAN com o hub. A topologia é determinada por pontos de extremidade de sobreposição que compõem uma única sobreposição. Cada interface WAN de hub cria um endpoint de sobreposição para spokes. As interfaces Spoke WAN mapeiam as interfaces WAN de hub apropriadas, definindo a topologia. Esta é a abstração da rede de transporte. Como as duas plataformas para o WAN Assurance resolvem a abstração de forma diferente, você precisa entender suas nuances ao construir essa rede overlay.

® Firewall da Juniper Série SRX

A SD-WAN overlay Série SRX combina uma roteador virtual para separação de rotas e túneis IPsec para tráfego de trânsito seguro. As configurações de WAN determinam a topologia e criam a rede overlay. Uma coisa a observar é que você pode implementar apenas uma sobreposição por organização. No entanto, você pode ter muitos caminhos dentro dessa sobreposição em vários tipos de transporte e isolar e encaminhar o tráfego com segurança. Para dispositivos da Série SRX, o overlay combina uma zona de segurança, um roteador virtual e túneis IPsec.

® Session Smart™ Router da Juniper Networks

A sobreposição Session Smart SD-WAN é a sua vizinhança, que envolve comunicação proprietária por meio de BFD na porta 1280 para atividade e jitter, latência e perda entre os pares Session Smart. Quando você configura uma interface WAN em um perfil de hub, ela cria um endpoint de hub de sobreposição. No Session Smart Router, o endpoint é a extremidade receptora do SVR.

Algumas coisas acontecem quando você mapeia uma interface de WAN spoke para o endpoint do hub de sobreposição. O spoke estabelecerá conectividade de pares e identificará os bairros e vetores para SVR, que é a abstração Session Smart da rede de transporte.

Uma observação final sobre a sobreposição: Os roteadores da Série SRX e Session Smart não podem existir em uma única sobreposição. Esses dispositivos podem ser emparelhados por meio do BGP no hub, mas suas soluções para criar conectividade entre sites são exclusivas e não podem operar juntas na mesma sobreposição. Se você tiver planos de migração, identifique quais rotas precisam de publicidade e anuncie no hub.

Lembre-se das seguintes considerações de perfil de hub:

  • Os perfis de hub devem ser criados primeiro, para que os modelos spoke saibam onde se conectar.
    • Os hubs devem ter IPs estáticos para pontos de extremidade de sobreposição.
    • A configuração do endpoint de overlay é exposta no modelo spoke do WAN Edge.
  • Não há limite para o número de hubs que você pode incorporar nestas diretrizes:
    • Um hub por datacenter
    • Dois hubs para redundância (clusters de HA)

Os spokes escolhem o hub principal por meio de direcionamento de tráfego e uma política de aplicativos. O provisionamento zero-touch (ZTP) requer DHCP (para implementação física), a menos que o ZTP seja feito e depois migrado para a rede de destino. Você também pode pré-configurar os dispositivos manualmente.

Figura 2: Perfil Hub Profile do hub

Variáveis de local

As variáveis de local são configuradas por site. Ao planejar uma rede de forma holística, você pode criar modelos padrão para bordas de WAN e clusters de borda de WAN específicos. Idealmente, você tem apenas um dispositivo de Borda WAN por site (ou uma única Borda WAN lógica se o dispositivo estiver clusterizado). Como as variáveis podem diferir por site, os administradores as usam em modelos ou na página de configuração do WAN Edge. A transformação acontece quando a configuração é renderizada e enviada para o dispositivo.

Lembre-se das seguintes considerações sobre variáveis de local:

  • A sintaxe das variáveis corresponde a Jinja2 e está contida entre chaves duplas, assim: {{variableName}}
  • A interface do usuário impõe as chaves à esquerda e à direita como parte do nome.
  • Limitações de variáveis de site:
    • Sem espaços na variável.
    • Nenhum caractere especial (exceto sublinhado) no campo variável.
    • As variáveis podem ser usadas apenas em um campo e não podem especificar um prefixo inteiro.

    Por exemplo, 10.88.88.88/24 precisaria de pelo menos duas variáveis, uma para o endereço IP (10.88.88.88) e outra para o comprimento do prefixo (24).

    Figura 3: Variáveis de Site Variables local

    A melhor maneira de usar o verdadeiro poder dos modelos é com variáveis de site. Muitos itens de configuração são necessários para implantar o hardware. Faz sentido combinar os modelos de borda de WAN e as variáveis de site. Considere a seguinte situação em que você pode definir sub-redes IP inteiras dos três primeiros octetos, deixando uma configuração mínima em cada dispositivo:

    Crie modelos padrão e coloque variáveis em interfaces padrão, como sua WAN, de uma destas maneiras:

    • Com uma variável WAN1PFX, digamos {{192.168.170}}, e no campo WAN na página Configuração, seria {{WAN1PFX}}.1 para o IP local e {{WAN1PFX}}.2 para o gateway.
    • Você pode definir um par de variáveis {{WAN1IP}} e {{WAN1_GW}}; no entanto, há locais onde a sub-rede pode ser reutilizada, mas não o IP específico.
      Figura 4: Variáveis de local na configuração Site Variables in WAN Configuration da WAN

      Outro caso de uso robusto é o octeto mágico, em que o terceiro octeto se torna uma variável, e essa variável também pode se aplicar a vários campos. Por exemplo, uma variável {{SITEID}} pode ser usada para o terceiro octeto e uma marca VLAN. Nesse caso, o prefixo de rede pode ser 192.168. {{SITEID}}.1/24 pelo {{SITE_ID}} ID da VLAN. Lembre-se de que, embora os modelos WAN Edge se apliquem apenas ao Edge WAN, as variáveis de site também se aplicam a switches e APs. O objetivo da automação é simplificar as implantações e aumentar a reutilização.

Introdução à aplicação de modelos

Lembre-se de que um site é uma coleção de todos os seus ativos em um único local. Está implícito que haverá apenas uma única borda de WAN. Um recurso essencial do gerenciamento do Mist por meio do Juniper Mist AI é a sua capacidade de usar modelos de configuração para agrupar bordas de WAN e fazer atualizações em massa. Os modelos fornecem uniformidade e conveniência, enquanto a hierarquia fornece escala e granularidade.

Importar e exportar modelos

Nenhuma solução cobre todas as circunstâncias. Você pode ter vários modelos. Para economizar tempo, clone um modelo. Em seguida, personalize a cópia clonada modificando-a conforme necessário.

Figura 5: Exportar ou clonar modelo Export or Clone Template

Modificando a amostra de modelo

Substituindo o modelo

Os modelos se aplicam a sites, que se aplicam a dispositivos. Os modelos são usados para padronizar as configurações, mas sempre existem exceções. Em vez de criar um modelo ligeiramente diferente para um site, você substitui a configuração do modelo no dispositivo.

Figura 6: Substituir configurações Override Template Settings de modelo

Se você precisar substituir o modelo, poderá habilitar a opção Substituir configurações de modelo para os blocos de configuração necessários por dispositivo. A Figura 7 mostra como você pode substituir o DNS e a Diretiva de Aplicativos , mas nenhuma das outras configurações, como WANs, LANs ou servidores NTP.

Figura 7: Política de Application Policy aplicativo

A captura de tela ilustra uma ação de tudo ou nada. Quando você substitui as configurações de modelo, essa configuração herda mais quaisquer políticas de aplicativo do modelo de Borda de WAN.

Você precisa ter uma das seguintes funções atribuídas a você para substituir a configuração:

  • Superusuário
  • Administrador de rede (acesso a todos os sites)
  • Administrador de rede (acesso a grupos de sites ou sites específicos)

Política de aplicativo no nível da organização

Figura 8: Política de aplicativos no nível organizacional

A Figura 8 mostra a opção de configuração de Diretiva de Aplicativos no nível da organização.

Organizational-Level Application Policy

Embora os modelos economizem tempo na implantação de vários dispositivos, você pode ter vários modelos para considerar diferentes modelos de dispositivo ou configurações ligeiramente diferentes. Você pode criar a mesma Diretiva de Aplicativo em cada modelo, mas considere usar uma Diretiva de Aplicativo no nível da organização como um atalho. Com uma política de aplicativo no nível da organização, você pode criar regras de aplicativo importáveis para modelos de borda de WAN e perfis de hub para topologias de rede em grande escala.

Vamos explorar algumas práticas recomendadas e restrições para usar uma Política de Aplicativo no nível organizacional. Dê a cada Política de Aplicativo no nível da organização um nome globalmente exclusivo ou você receberá erros ao salvar a configuração. A política importada tem todos os campos esmaecidos porque não deve ser modificada. Não há direcionamento de tráfego em nível organizacional, o que faz sentido, porque o direcionamento de tráfego se aplica a conexões e intenções locais.

Considere aplicar uma política de aplicativo em nível organizacional a um bloco de LAN ou a uma sub-rede. Se você criar uma "super-rede" de LAN de 10/8, a política permitirá que qualquer coisa proveniente de 10/qualquer chegue à Internet, o que significa que funcionaria para todos os seus sites. É por isso que o planejamento é crucial. Projete sua rede para simplificar a solução de problemas com padrões de tráfego semelhantes, independentemente da implantação. Por exemplo, alguns sites têm LTE e o tráfego deve sair para lá nesse site em vez de em outros. Além disso, alguns sites são independentes e outros são SD-WAN. Uma política universal poderia se aplicar a ambos, informando ao direcionamento de tráfego em sites autônomos para sair da WAN para a underlay, enquanto os sites estão indo para a sobreposição para os spokes SD-WAN.

Em resumo, o caso de uso de uma política no nível da organização é descrever padrões de tráfego em toda a rede, independentemente do site; Como política, você define o que é e o que não é permitido. Então, quando aplicado ao site ou modelo (que se aplica a lugares), você adiciona a parte de direção, fornecendo a peça final do quebra-cabeça.

Considerações de design de WAN

A Figura 9 mostra o fluxo de trabalho para provisionamento de borda de WAN.
Figura 9: Fluxo de trabalho de provisionamento de borda de WAN WAN Edge Provisioning Workflow

A revisão dos blocos que compõem o projeto concluído é essencial para implantar uma SD-WAN, da seguinte forma:

  1. Pense em "quem" (rede) compõe a fonte de solicitações em sua organização.
  2. Considere "quais" destinos (aplicativos) os usuários acessam.
  3. Para onde esses elementos vão em sua organização? Considere os tipos de site.
  4. Por fim, considere "como" (direcionamento de tráfego) esses usuários obtêm e obtêm acesso aos seus destinos de tráfego.
  5. Agora você pode usar o poder da Mist AI, modelos e variáveis para dimensionar.

Provisionamento de SD-WAN

A ordem das operações é importante. Ao se preparar para implementar o provisionamento de SD-WAN, conclua as tarefas nesta ordem:

  1. Primeiro, planeje sua rede com modelos, pensando na implantação de forma holística.
  2. Os perfis de hub devem vir antes dos modelos spoke do WAN Edge.
  3. Projete com seus aplicativos (destinos de tráfego) primeiro e depois com redes (quem).

Você pode analisar aplicativos e se tornar mais granular posteriormente.

  1. Certifique-se de conhecer suas redes (fontes de tráfego).

As redes informam a política e o direcionamento de tráfego.

  • Aplique a Política de Aplicativo apropriada a ambas as extremidades (spokes e hubs).

Esforce-se para alcançar de ponta a ponta ao estabelecer endpoints de sobreposição. Lembre-se de que não é possível conectar um endpoint MPLS isolado a um endpoint da Internet.