Otimização de tráfego de máquina virtual de entrada

Quando máquinas virtuais e hosts são movidos dentro de um data center ou de um data center para outro, o tráfego de rede pode se tornar ineficiente quando o tráfego não é roteado para o gateway ideal. Isso pode acontecer quando o host for realocado. A tabela de arp nem sempre é lavada e o fluxo de dados para o host é enviado para o gateway configurado, mesmo quando há um gateway mais ideal. O tráfego é "tromboned" e roteado desnecessariamente para o gateway configurado.

A partir do Junos OS Release 18.4R1, o Junos oferece suporte à otimização de tráfego de máquina virtual (VMTO) de entrada. Quando o recurso VMTO de entrada é habilitado, as rotas remotas de host IP são armazenadas na tabela de roteamento e encaminhamento virtual (VRF) L3 e as rotas de dispositivo de tráfego de entrada diretamente de volta para o host que foi realocado.

A Figura 1 ilustra o tráfego enlatado sem VMTO de entrada e tráfego otimizado com VMTO de entrada habilitado. Sem VMTO de entrada, Spine 1 e 2 de DC1 e DC2 anunciam a rota remota de host IP 10.0.0.1 quando a rota de origem é de DC2. O tráfego de entrada pode ser direcionado ao Spine 1 e 2 em DC1. Em seguida, seria roteado para spine 1 e 2 em DC2 onde a rota 10.0.0.1 foi movida. Isso causa o efeito tromboning. Com o VMTO de entrada, podemos alcançar um caminho de encaminhamento ideal configurando uma política para a rota de host IP (10.0.01) a ser anunciada apenas pelo Spine 1 e 2 a partir de DC2, e não de DC1 quando o host IP é transferido para DC2.

A Figura 2 ilustra uma rede EVPN com diferentes elementos. PE1 compartilha um segmento de Ethernet com PE2. O PE3 está em um segmento separado. Quando pe1 aprende sobre novas rotas de host IP a partir do CE1, PE1 adiciona a rota para a tabela VRF, uma vez que é uma rota aprendida localmente. Se o PE2 aprender a rota a partir do peer PE1 remoto (e não do CE1), o PE2 também adicionará a rota na tabela VRF como se a rota também fosse aprendida localmente, já que PE1 e PE2 estão no mesmo Segmento de Ethernet. A Tabela 1 resume a atividade realizada na tabela VRF quando um dispositivo PE aprende sobre novas rotas de host IP a partir de dispositivos PE remotos sob EVPN-VXLAN e não há políticas de roteamento configuradas no dispositivo. A Tabela 2 resume a atividade realizada na tabela VRF quando um dispositivo PE aprende sobre novas rotas de host IP a partir de dispositivos PE remotos em EVPN-MPLS e não há políticas de roteamento configuradas no dispositivo.

Nota:

Você também pode configurar políticas para adicionar seletivamente as rotas que deseja para a tabela VRF.

Nota:

As rotas de host IP que PE1 e PE2 aprenderam entre si são descritas como "A partir de dispositivo remoto que está conectado a um segmento de ethernet compartilhado" e as rotas de host IP que PE3 aprendeu com PE1 ou PE2 são descritas como "De um dispositivo remoto que não está conectado a um Segmento Ethernet compartilhado.

Tabela 1: Atividade na tabela VRF para EVPN-VXLAN

Status de configuração de VMTO de entrada	De um dispositivo remoto conectado a um segmento de ethernet compartilhado	De um dispositivo remoto que não está conectado a um segmento Ethernet compartilhado
Antes do Junos OS Release 18.4R1.	A rota de host IP é criada com a interface IRB como o próximo salto e a rota é adicionada à tabela de instâncias VRF.	A rota de host IP não é adicionada à tabela de instâncias VRF.
VMTO de entrada não configurado	A rota de host IP é criada com a interface IRB como o próximo salto e a rota é adicionada à tabela de instâncias VRF.	A rota de host IP não é adicionada à tabela de instâncias VRF.
VMTO de entrada configurado	A rota de host IP é criada com a interface IRB como o próximo salto e a rota é adicionada à tabela de instâncias VRF.	A rota de host IP é criada com a interface IRB como o próximo salto e a rota é adicionada à tabela de instâncias VRF.

Tabela 2: Atividade na tabela VRF para EVPN-MPLS

Status de configuração de VMTO de entrada	De um dispositivo remoto com um segmento de ethernet compartilhado localmente	De um dispositivo remoto sem um segmento de ethernet compartilhado localmente
Antes do Junos OS Release 18.4 R1 com next hop composto encadeado configurado.	A rota de host IP é criada com o próximo salto composto. A rota não é anunciada para seus pares.	A rota de host IP é criada com o próximo salto composto. A rota não é anunciada para seus pares.
Antes do Junos OS Release 18.4R1 sem um próximo salto composto encadeado.	A rota de host IP não é adicionada à tabela de instâncias VRF.	A rota de host IP não é adicionada à tabela de instâncias VRF.
VMTO de entrada não configurado	A rota de host IP é criada com a interface IRB como o próximo salto e a rota é adicionada à tabela de instâncias VRF.	A rota de host IP não é adicionada à tabela de instâncias VRF.
VMTO de entrada configurado	A rota de host IP é criada com a interface IRB como o próximo salto e a rota é adicionada à tabela de instâncias VRF.	A rota de host IP é criada com a interface IRB como o próximo salto e a rota é adicionada à tabela de instâncias VRF.
VMTO de entrada configurado com next hop composto	A rota de host IP é criada com a interface IRB como o próximo salto e a rota é adicionada à tabela de instâncias VRF.	A rota de host IP é criada com o próximo salto composto e a rota é adicionada à tabela de instâncias VRF.

Para habilitar o VMTO de entrada, configure remote-ip-host-routes no nível de [edit routing-instances routing-instance-name protocols evpn] hierarquia. Ao ativar a rota de host ip remoto, todas as rotas remotas de host IP serão adicionadas à tabela VRF. Você pode especificar quais rotas de host IP remotas serão adicionadas à tabela VRF por meio de políticas, incluindo uma política de importação a ser submetida remote-ip-host routes para filtrar as rotas indesejadas.

Nota:

A Juniper recomenda que você apenas habilite o VMTO de entrada nos dispositivos spine em uma sobreposição de pontes roteada centralmente (CRB) em uma rede EVPN. Isso permite que os dispositivos anunciem rotas aprendidas para outros protocolos de roteamento e anunciem rotas EVPN tipo 5 em diferentes data centers.

Para lidar com a invasão na Figura 1, você definiria as comunidades para data center 1 e data center 2 e configuraria uma política nos dispositivos spine para importar apenas as rotas aprendidas com os membros de sua própria comunidade. Antes da mudança, os dispositivos spine no Data Center 1 anunciam a rota de host IP para o host local. Após a mudança, o host passa a fazer parte da comunidade do Data Center 2 para que os dispositivos spine no Data Center 2 anunciem a rota de host IP. E a tabela de próximo salto no host remoto terá a rota atualizada para o Data Center 2 após a mudança.

A saída a seguir mostra a política de amostra e a configuração da amostra com uma política de importação configurada com remote-ip-host.