Como um fabric EVPN sabe onde está o seu servidor

Uma rede comutada clássica encontra um servidor aos gritos: inunda a frame por todo o lado, vê quem responde, memoriza a porta. Um fabric BGP EVPN encontra-o porque lho dizem. Essa única diferença explica porque é que os fabrics EVPN escalam, fazem failover depressa e podem ser auditados, e vale a pena compreendê-la mesmo que nunca configure um.

O problema do flood and learn

O Layer 2 tradicional aprende endereços MAC a partir do tráfego. Quando um switch não sabe onde vive um destino, inunda a frame por todas as portas da VLAN. O spanning tree bloqueia depois ligações suficientes para impedir que a inundação circule para sempre, o que significa que boa parte da cablagem que pagou fica parada. Estenda essa VLAN por muitos racks e obtém domínios de falha grandes, convergência lenta e uma rede que ninguém consegue descrever por completo, porque o seu estado vive em tabelas que se enchem e expiram sozinhas.

O VXLAN por si só resolve o problema do transporte: embrulha frames Ethernet em UDP para que um segmento Layer 2 possa atravessar um underlay encaminhado com todas as ligações ativas. Mas o VXLAN simples continua a inundar para aprender. O EVPN substitui essa aprendizagem por um control plane.

O que o EVPN anuncia de facto

O EVPN é uma address family do BGP. Cada leaf switch que aloja servidores atua como VXLAN tunnel endpoint (VTEP) e diz aos outros leaves o que sabe, usando um pequeno número de tipos de rota. Três deles fazem a maior parte do trabalho:

• Tipo 2, anúncio de MAC e IP. Quando um servidor envia a sua primeira frame ou ARP, o leaf local aprende a sua MAC (e normalmente o seu IP) e anuncia-a a todos os outros leaves com o seu próprio endereço VTEP como next hop. Todos os leaves passam a saber onde está esse servidor sem uma única inundação.
• Tipo 3, inclusive multicast. Cada leaf anuncia em que segmentos participa. Isto constrói a lista de VTEP que devem receber tráfego broadcast e desconhecido para cada segmento. Com ingress replication, o leaf emissor faz uma cópia unicast para cada um deles, pelo que o underlay não precisa de multicast nenhum.
• Tipo 5, prefixo IP. Sub-redes encaminhadas, por exemplo um bloco de endereços públicos atrás da firewall de um cliente, são anunciadas como prefixos dentro de um VRF de tenant.

Os route targets decidem quem importa o quê. As rotas de um segmento transportam o seu route target, e só os leaves configurados com esse target as importam. É aqui que o isolamento entre tenants é realmente imposto, e é por isso que a numeração de segmentos e route targets merece disciplina a sério (mais sobre isso abaixo).

Anycast gateways: o mesmo router em todo o lado

Num fabric EVPN, cada leaf que transporta um segmento pode ser o seu default gateway, usando o mesmo IP e a mesma MAC virtual. O primeiro salto de um servidor é sempre o switch a que está ligado. Se esse leaf falhar, o bond do servidor faz failover para o outro leaf do par, que já responde no mesmo endereço de gateway e na mesma MAC. Nada muda no servidor, nenhum protocolo de gateway tem de eleger ninguém, e as cargas de trabalho podem mover-se entre racks mantendo o seu gateway.

Em conjunto com pares de leaves a correr virtual port-channels, isto dá a cada host dois switches físicos atrás de um único bond lógico. Em NX-OS, um anycast gateway mínimo tem este aspeto:

fabric forwarding anycast-gateway-mac 0000.2222.3333
interface Vlan210
  vrf member TENANT-A
  ip address 192.0.2.1/26
  fabric forwarding mode anycast-gateway

Localizar um host: os comandos que importam

Quando algo não chega onde devia, estes são os comandos com que começamos em Cisco Nexus, mais ou menos por esta ordem:

show nve peers                         ! are the other VTEPs up?
show nve vni                           ! is the segment up, control plane learning?
show l2route evpn mac all              ! which MACs are local, which are remote, and from which peer
show bgp l2vpn evpn <mac-or-ip>        ! the actual route, its RD, RT and next hop
show ip arp suppression-cache detail   ! is ARP being answered locally?
show vpc consistency-parameters vlans  ! do both leaves of the pair agree?

A história que contam é normalmente curta. Uma MAC que é local num leaf mas nunca aparece no BGP dos outros aponta para a aprendizagem local ou para a configuração do segmento. Uma rota que está presente mas não é importada aponta para os route targets. Um VTEP que falta no show nve peers aponta para o underlay. Ler o estado do fabric assim só é possível porque o EVPN guarda esse estado no BGP, onde é visível e consistente, em vez de em tabelas aprendidas por inundação.

A numeração é um controlo de segurança

Cada segmento precisa de um VXLAN network identifier (VNI) e de route targets, e o fabric aceita qualquer número que escreva. Dois segmentos que partilhem acidentalmente um identificador ficam ligados em bridge, em silêncio, e um VNI mal escrito que por acaso pertença a outro segmento parece perfeitamente legítimo em todos os ecrãs.

A defesa é uma regra e uma máquina que a verifica. Escolha uma derivação fixa, por exemplo VNI igual a um offset fixo mais o número da VLAN local, com os route targets derivados do VNI, e depois verifique-a automaticamente:

• Leia o mapa VLAN para VNI de todos os leaves de forma agendada.
• Confirme que todas as entradas obedecem à regra.
• Confirme que todos os leaves que devem transportar os mesmos segmentos têm mapas idênticos.
• Compare um fingerprint de todo o mapa com uma baseline assinada em controlo de versões, para que uma alteração intencional exija uma nova assinatura deliberada com autor, e uma não intencional chame um engenheiro.

Corremos exatamente esta verificação no nosso fabric todas as horas. Custa alguns segundos de acesso só de leitura e transforma uma classe de erros invisíveis num alarme.

O que perguntar sobre o seu próprio fabric

• Os seus gateways são anycast em todos os leaves, ou são propriedade de um par de switches?
• Todos os hosts estão ligados em dual-homing a um par de leaves, ou só os caros?
• Os hosts com bond fazem hash em layer 3 e layer 4, com o lado do switch a condizer, para que as duas ligações transportem mesmo tráfego?
• Existe uma regra escrita para a numeração de VNI e route targets, e há algo que a imponha?
• Um engenheiro consegue mostrar-lhe, com comandos como os acima, exatamente onde vive o seu servidor e como o seu tráfego sai do rack?

Se quer os seus servidores num fabric construído e verificado desta forma, ou quer ajuda a ler o seu, teremos todo o gosto em ajudar.

CTA

Fale com um engenheiro

Related

Relacionados: Fabric do datacenter: EVPN/VXLAN em Cisco Nexus · Como alteramos as coisas: disciplina de alterações de rede · Mude para nós sem alterar endereços: extensão Layer 2