Arquitetura de solução

Abordagem de integração de servidor DHCP de nível de não produção de conceito

Nessa abordagem, o servidor DHCP é anexado localmente à função de bloco de serviço da malha. Para redundância, um ESI-LAG está configurado no lado da malha e um LAG normal no lado do servidor. Todas as VLANs 4.000+ possíveis estão configuradas e expostas neste link em direção ao servidor DHCP. A malha em si então não precisa de configuração extra do retransmissão DHCP, pois os domínios de transmissão de Camada 2 de todas as VLANs de acesso são estendidos ao servidor DHCP. Ao configurar sub-interfaces correspondentes para ouvir, o servidor DHCP pode então atribuir leasings ouvindo os pacotes de transmissão MAC que os clientes enviam. Isso funciona à moda antiga, e muitos servidores DHCP (incluindo o Junos OS) podem responder a esse tráfego.

Nota:

Isso claramente não é recomendado em projetos e implantações de nível de produção. Isso pode ajudar a aumentar a rede mais rapidamente, mas existem riscos graves de segurança que vêm com esse design!

A razão para não recomendar isso em designs de nível de produção é que você ignora uma função básica de segurança do design da malha. Normalmente, todos os VRFs de malha são isolados uns dos outros. Isso força todo o tráfego entre VLANs em diferentes VRFs a transitar pelo roteador WAN onde funções de segurança como firewalls podem ser implementadas. Ao colocar todas as VLANs no link para o servidor DHCP no bloco de serviços, ignoramos o roteador WAN e, portanto, a funcionalidade de segurança. Se um invasor encontrar uma falha de segurança, como um login de administrador aberto, ou algo estiver mal configurado, o invasor pode pular entre todas as VLANs e talvez também ignorar qualquer triagem baseada em roteador WAN entre VRFs. Fique ciente dessa troca.

Abordagem recomendada de integração de servidor DHCP de nível de produção

A solução de nível de produção recomendada é seguir uma abordagem baseada em padrões IETF RFC 2131 e RFC 3046 que utiliza o retransmissão DHCP dentro da malha para encaminhar a um servidor DHCP gerenciado pelo cliente.

Em uma malha de campus, o retransmissão DHCP é geralmente localizado onde o GATEWAY VRF de Camada 3 envia tráfego dos switches de acesso conectados em direção às funções vinculadas ao norte. Isso porque esta é a demarcação entre o domínio de broadcast de Camada 2 e o encaminhamento restante da Camada 3 na rede. Um cliente DHCP que solicita um leasing sempre atende ao endereço MAC de transmissão neste domínio de Camada 2, que é FF:FF:FF:FF:FF:FF:FF. Assim que essa mensagem chega ao VRF, ela é encaminhada pela função de retransmissão DHCP da VRF (RFC 2131 chama isso de agente de transmissão BOOTP) como um pacote UDP IP em direção ao servidor DHCP anexado à malha ou fora dele. Juntamente com isso, o encaminhamento de informações adicionais é sempre incorporado no pacote UDP em direção ao servidor DHCP:

• O IP de gateway (RFC 2131 chama isso de "giaddr") é o endereço IP de origem do pacote DHCP. Os servidores DHCP enviam todos os pacotes de resposta de volta a este endereço IP incorporado. Por isso, é importante que este endereço IP seja acessível pelos pacotes de resposta. Este IP de origem relatado pode diferir dependendo do tipo de malha e do método de integração do roteador WAN. Os dois métodos mais populares que são ilustrados neste JVD são:
  • Para malhas pequenas que usam endereçamento de gateway virtual, o endereço IP estático para cada VLAN overlay que é configurado localmente em cada malha VRF é usado como o IP do gateway.
  • Para malhas maiores onde qualquer endereçamentocast está em uso, uma gama adicional de IPs de loopback overlay é usada pelos VRFs distribuídos por toda a malha. Cada VRF em todos os nós onde os VRFs estão configurados nesta malha recebe um endereço IP exclusivo usado como IP do gateway. Assim, você tem uma rede overlay adicional, mas que é compartilhada entre VRFs. É preciso notar que, neste caso, existem dois sabores de uso de endereço IP de loopback:
    • Há sempre os endereços IP de loopback underlay existentes vinculados à interface lo0.0 em cada switch de malha EVPN. Estes são usados para sinalização VXLAN VTEP e EVPN BGP. Eles são tipicamente invisíveis para o transporte overlay.
    • Os novos endereços IP de loopback usados para transmissão DHCP são visíveis nas VLANs overlay. Ao definir esse pool de loopback overlay, tome cuidado para que essa faixa não seja usada em outros lugares pelas VLANs overlay. Além disso, os endereços IP neste pool de loopback overlay só devem estar vinculados a nós da malha EVPN onde os VRFs estão localizados.
• Espera-se que a função de retransmissão DHCP inscreva informações adicionais, como a adicionada pela opção DHCP 82 de acordo com a RFC 3046. Isso ajuda o servidor DHCP a identificar a fonte da solicitação do cliente e a ser capaz de gerenciar melhor a decisão de apostila de locação. Isso é necessário porque o servidor DHCP não será mais capaz de receber solicitações de leasing DHCP de VLANs locais, uma vez que está configurado para ouvir em uma interface de tomada de endereço IP que recebe pacotes UDP. Os possíveis atributos que podem ser incorporados na opção 82 pelo fornecedor de servidor DHCP podem variar e estão sempre sujeitos à integração com a malha.

Como já mencionado, a malha configura a função de retransmissão DHCP onde os VRFs estão localizados em sua malha. Não tente alterar manualmente isso nos switches. Dentro dos campos de configuração da malha, você encontrará opções de configuração de retransmissão DHCP no painel onde você configura as redes e VRFs. O restante será implantado automaticamente pela nuvem Juniper Mist™ nos nós necessários, conforme indicado na figura abaixo:

O	retransmissão DHCP do tipo de malha será configurado em	número de nós suportados
EVPN Multihoming	Switches de núcleo colapsado	Máximo de 4
CRB	Switches de núcleo	Máximo de 4
ERB	Switches de distribuição	muito
IP Clos roteado na borda	Switches de acesso	muito

Malha de gateway virtual versus qualquer malhacast

Dependendo do tipo de malha, as VLANs overlay (onde o tráfego do cliente está localizado), podem precisar de endereços IP adicionais para fins internos, que é o caso de malhas de gateway virtuais. A malha de campus Juniper Mist configura os seguintes tipos de malha:

Malha	virtual de gateway tipo malha		de malha Anycast
EVPN Multihoming		Sim	---
CRB		Sim	---
ERB		---	Sim
Malha IP Clos		---	Sim

Em uma malha de gateway virtual, você normalmente tem uma quantidade muito limitada de VRFs. Eles estão localizados no núcleo ou switches de núcleo colapsados. A quantidade máxima de switches de núcleo ou núcleo colapsados suportados em uma malha de campus da Juniper Mist é de quatro. Isso significa que um certo VRF pode ser duplicado para cada núcleo redundante ou switch de núcleo colapsado no máximo quatro vezes na malha. As malhas Anycast, ao contrário das malhas de gateway virtuais, são apropriadas para designs mais dimensionados. Assim, a localização dos VRFs está nos switches de distribuição (ERB) ou no switch de acesso (malha IP Clos). A natureza das malhas de gateway virtuais é que o sistema requer um endereço IP estático adicional exclusivo por VRF para cada VLAN localizado na malha. Assim, além do endereço IP de gateway compartilhado para cada VLAN, são necessários até quatro endereços IP exclusivos adicionais nessa sub-rede.

Por que tal design? Há benefícios para determinado tráfego na malha, como o retransmissão DHCP. Para o retransmissão DHCP, o sistema usa o endereço IP estático em vez do endereço IP do gateway ao encaminhar as solicitações dos clientes DHCP. Esse comportamento garante que o pacote de resposta DHCP será enviado de volta ao VRF correto, uma vez que o endereço IP estático é exclusivo do switch VLAN/núcleo.

Outra maneira de pensar em uma malha de gateway virtual é se você comparar com os designs tradicionais de failover de gateway de Camada 2, como VRRP. Lá você sempre tem um VIP que flutua entre os gateways (que são nossos VRFs) e cada gateway precisa de um IP estático exclusivo adicional para cada VLAN. Em uma malha de campus da Juniper Mist, o protocolo VRRP não é necessário, pois o plano de controle EVPN assume o controle por ele.

O pequeno sacrifício necessário para esculpir esses endereços IP estáticos adicionais em cada sub-rede é eliminado em malhascast. Isso se deve aos switches de distribuição/acesso mais dimensionados onde os VRFs estão instalados, você teria que planejar bem seu crescimento futuro ao criar VLANs. Serviços de sistema, como o retransmissão DHCP, funcionam em malhascast de forma um pouco diferente e são internamente mais complexos.

Qual endereço IP escolher como endereço IP de gateway relatado?

Normalmente, você deve escolher entre uma das seguintes abordagens para determinar qual endereço IP de gateway está incorporado nos pacotes encaminhados pela função de retransmissão DHCP na malha:

• Para malhas multihoming EVPN, a UI não oferece nenhuma escolha, então você sempre estará usando endereços IP de gateway virtuais para o IP do gateway. Isso permite que o servidor DHCP identifique a VLAN onde a solicitação se origina, analisando apenas o endereço IP do gateway incorporado nos pacotes encaminhados.
• Para malhas CRB, você pode selecionar entre o projeto de endereço IP estático de gateway virtual deixando o campo "Loopback por subnet VRF" vazio ou usando um design com endereços IP de loopback overlay atribuídos a cada VRF na malha ao preencher um prefixo IP na sub-rede "Loopback por VRF" do diálogo da malha do campus.
• Para malhas maiores, como ERB e IP Clos, recomendamos inserir um prefixo IP na sub-rede Loopback por VRF como parte da configuração da malha do campus. Com isso, a malha atribuirá automaticamente IPs de loopback de sobreposição exclusivos dessa faixa de pool a cada VRF na malha. Neste caso, também recomendamos muito aproveitar um protocolo de roteamento, como OSPF ou BGP, para a integração do roteador WAN em direção à malha, pois o uso desses IPs de loopback overlay pode dificultar a previsão de como cada IP de gateway pode ser alcançado a partir do roteador WAN.

Embora seja tecnicamente possível deixar o campo de sub-rede "Loopback por VRF" vazio nessas malhas, não é recomendado. Se deixado em branco, o IP de gateway anycast será o IP de gateway relatado incorporado nos pacotes encaminhados. Isso não causa problemas no caminho para o servidor DHCP. No entanto, quando a resposta do servidor DHCP retorna, porque o IP anycast é compartilhado por vários switches dentro da malha, o pacote de resposta pode ser roteado para um switch que não originou a solicitação e poderia estar em um PoD ou edifício diferente. Se isso acontecer, quando o pacote chegar a um switch que não iniciou a solicitação, a função de retransmissão DHCP descapsulará a resposta e determinará, com base no endereço MAC do cliente, que o pacote deve ser encaminhado para um switch remoto. Para isso, ele usará um túnel VXLAN para reencarnar o pacote leste-oeste para o switch onde o cliente está realmente conectado. Isso cria um design ineficiente.

Onde localizar o servidor DHCP

A abordagem que recomendamos é a integração local como parte da própria malha.

No caso de uma malha de campus, a leaf de serviço é chamada de função de bloco de serviço e, no exemplo a seguir, um par de switches físicos ao norte de onde o servidor DHCP é anexado para ser uma peça integral da malha.

O servidor DHCP também pode gerenciar leasings para clientes que não estão no mesmo VRF que ele mesmo. No entanto, como há sempre o isolamento VRF para VRF dentro da malha, os pacotes terão que ser trocados por um roteador WAN.

Quando essa integração local não é possível, também é possível tentar integrar o servidor DHCP como um elemento externo em direção à malha. Isso é o que você vê no canto superior esquerdo na figura a seguir:

O que precisa ser considerado When usando servidores DHCP externos?

Ao integrar servidores DHCP externos na malha, existem dois pontos críticos a serem mentes para que essa abordagem tenha sucesso:

• Mantenha a latência entre a malha e os servidores DHCP o mais baixo possível. Não considere operar o servidor DHCP em um ambiente de nuvem pública se você não souber o impacto da latência. Alguns clientes DHCP podem ser muito agressivos ao solicitar um leasing, o que pode causar solicitações de locação DHCP sem resposta para empilhar em um ambiente de alta latência, sobrecarregando o servidor DHCP. Como o comportamento do cliente dhcp dificilmente é influenciável no nível da malha, recomendamos testar o design com foco em todos os tempos de latência de ida e volta antes de colocar a malha em produção.
• Nenhuma forma de tradução de endereço de rede (NAT) é suportada entre a malha e o servidor DHCP. A razão para isso é explicada no seguinte trecho do IETF RFC 2131 descrevendo como um servidor DHCP deve responder às solicitações dos clientes. Lembre-se, "giaddr" é o endereço IP de gateway incorporado:

Você pode não estar ciente do que essa descrição da RFC significa, por isso fornecemos um exemplo de tráfego usando um servidor DHCP do Microsoft que não responde às solicitações de DHCP SNATed de acordo com a RFC.

Aqui está o IP de origem original e a porta do switch de acesso criado para o pacote de retransmissão:

Quando o roteador WAN aplica o SNAT à mensagem de descoberta encaminhada, ele altera o IP e a porta de origem da seguinte forma:

A resposta do servidor DHCP, no entanto, responde ao IP de gateway incorporado original na porta 67, que era o IP de origem original dentro da malha antes da aplicação do SNAT:

Este pacote nunca mais chegará ao firewall SNAT.

Otimizações no Junos OS para ajudar seu projeto de retransmissão DHCP

Por meio da configuração do Junos OS, algumas declarações ajudam a otimizar seu projeto. Apresentamos os críticos aqui caso você queira saber por que a malha está configurando-as automaticamente:

Na configuração do Junos OS, é necessária uma declaração "somente para o futuro" para evitar que o dispositivo monitore o tráfego DHCP descontrolado.

Na configuração do Junos OS, a declaração "opção de retransmissão-82 vlan-id-only" sincroniza o comportamento dos switches QFX e EX ao encaminhar a opção 82 tráfego DHCP (por padrão, eles usam atributos diferentes). Além disso, esse atributo não adiciona mais informações de interface indesejadas, como "IRB-irb.1099:ae10.0" ou "IRB-irb.1099:vtep.32769". Com essa configuração adicionada, apenas o ID VLAN é relatado, facilitando a análise de strings neste campo, que aproveitamos para que o servidor DHCP Linux KEA atribua o leasing certo.

A declaração de configuração do Junos OS "override de id de servidor-opção de retransmissão-82" é descrita aqui e é necessária em nosso ambiente. Ele ajuda o servidor DHCP do Microsoft usando a sub-opção 5 para determinar a fonte do pacote e escolher o pool certo para atribuir.

A declaração de configuração do Junos OS "destino de supressão de rota" é necessária ao usar IPs de loopback como IPs de gateway. Ele não é usado para IPs estáticos de endereço de gateway virtual como IPs de gateway.

Na configuração do Junos OS, a malha configura todas as interfaces IRB agora com a opção "no-dhcp-flood". Isso ajuda a limitar a transmissão MAC do cliente para que nem todos os dispositivos de retransmissão DHCP recebam a mesma solicitação do cliente duplicado. Sem essa opção em vigor, como todas as solicitações do cliente são pacotes de transmissão em um VLAN, a solicitação original é duplicada através do VXLAN e enviada a todos os nós de malha que têm esse VRF configurado, que então executam o retransmissão DHCP em direção ao roteador WAN.

Nota:

Caso você use o vJunos-switch como uma instância de switch virtual em um laboratório, é sabido que, embora a opção "no-dhcp-flood" possa ser configurada em um switch virtual, ela não está implementada no momento. Dessa forma, você pode observar inundações e o endereço IP de gateway errado usado. No entanto, isso não deve afetar sua capacidade de testar isso. É apenas uma limitação conhecida do vJunos-switch.