Introdução à arquitetura Spine Leaf e sua importância nos data centers

As tecnologias de virtualização e computação em nuvem vem tomando espaço nos Data Centers e alterando assim a sugestão do modelo tradicional do modelo rede de três camadas Core, Agregação e Acesso.

O modelo tradicional de 3 camadas é eficiente para o tráfego “Norte-Sul”, onde o tráfego percorre o caminho de dentro para fora do Data Center. Este tipo de tráfego é tipicamente utilizado em serviços web, como exemplo, podemos citar o tráfego norte-sul onde há grande volume no modelo de comunicação cliente remoto/servidor.

Esse tipo de arquitetura tradicional é normalmente construído para redundância e resiliência contra falhas em equipamentos ou cabos, organizando portas de bloqueio pelo protocolo Spanning-Tree (STP), a fim de evitar loops de rede.

A arquitetura Spine Leaf é uma maneira inteligente de organizar redes em data centers. Ela é ótima para ambientes que precisam de alto desempenho e baixa latência. As tendências da comunicação entre máquinas nos Data Centers exigem uma arquitetura que sustente as demandas para o tráfego “Leste-Oeste”, ou tráfego de servidor para servidor.

Dependo da configuração lógica do “antigo” modelo tradicional de 3 camadas, o tráfego poderia atravessar todas as camadas para chegar no host de destino entre máquinas no mesmo Data Center, podendo introduzir dessa maneira uma latência imprevisível ou mesmo falta de largura de banda nos uplinks.

A arquitetura leaf-spine é uma topologia de rede escalável e de alta performance, amplamente utilizada em data centers. Ela é composta por duas camadas principais: a camada leaf (folha), que consiste em switches de acesso conectados diretamente aos servidores ou dispositivos finais, e a camada spine (espinha), formada por switches de núcleo que interconectam todos os switches leaf. Cada switch leaf está conectado a todos os switches spine, criando uma malha completa que oferece múltiplos caminhos entre qualquer par de dispositivos na rede. Essa estrutura é projetada para evitar loops naturalmente, já que os switches leaf não se conectam diretamente entre si, nem os switches spine se interligam, eliminando a possibilidade de caminhos redundantes que possam causar loops.

Para gerenciar o encaminhamento de dados e garantir a prevenção de loops, a arquitetura leaf-spine utiliza protocolos de roteamento modernos, como BGP (Border Gateway Protocol) ou OSPF (Open Shortest Path First), em vez de protocolos tradicionais como o Spanning Tree Protocol (STP). Esses protocolos são capazes de calcular os melhores caminhos com base em métricas, evitando loops de forma eficiente. Além disso, a rede aproveita todos os links ativos por meio de técnicas como o Equal-Cost Multi-Path (ECMP), que distribui o tráfego de forma equilibrada entre os múltiplos caminhos disponíveis. Como todos os caminhos entre leaf e spine têm o mesmo custo (geralmente um número fixo de saltos), o ECMP permite que o tráfego seja balanceado, maximizando a utilização da largura de banda e evitando gargalos.

Essa combinação de prevenção de loops e utilização de todos os links ativos traz diversas vantagens, como alta disponibilidade, baixa latência e escalabilidade. A rede se torna mais resiliente a falhas, pois, se um link ou switch falhar, o tráfego pode ser redirecionado instantaneamente por outros caminhos. A latência é mantida baixa, já que o número de saltos entre qualquer par de dispositivos é sempre o mesmo (normalmente dois saltos: leaf → spine → leaf). Além disso, a arquitetura permite a adição de novos switches leaf ou spine sem interromper o funcionamento da rede, tornando-a ideal para ambientes de data center que exigem alta performance, escalabilidade e confiabilidade.

VxLAN e BGP EVPN

A arquitetura leaf-spine também pode ser aprimorada com a integração de tecnologias como VXLAN (Virtual Extensible LAN) e BGP EVPN (Ethernet VPN), que ampliam sua funcionalidade e eficiência em ambientes de data center modernos. O VXLAN permite a criação de redes overlay sobre a infraestrutura física, encapsulando tráfego de camada 2 em pacotes de camada 3, o que possibilita a extensão de redes locais virtuais (VLANs) além dos limites físicos tradicionais. Já o BGP EVPN atua como protocolo de controle, fornecendo uma maneira eficiente de gerenciar a distribuição de informações de rede e a conectividade entre os dispositivos.

A combinação de VXLAN com BGP EVPN traz benefícios significativos, como a simplificação da segmentação de rede, a melhoria da escalabilidade e a facilitação da migração de cargas de trabalho entre diferentes ambientes. Com o BGP EVPN, a rede pode gerenciar de forma dinâmica os endereços MAC e as informações de roteamento, reduzindo a complexidade operacional e permitindo uma melhor utilização dos recursos. Além disso, essa integração suporta cenários de multi-tenancy, onde múltiplos clientes ou aplicações podem compartilhar a mesma infraestrutura física de forma segura e isolada.

Ao adotar VXLAN com BGP EVPN em uma arquitetura leaf-spine, a rede se torna ainda mais robusta e adaptável, capaz de suportar demandas modernas como virtualização, cloud computing e mobilidade de workloads. Essa combinação não apenas mantém as vantagens já existentes da topologia leaf-spine, como prevenção de loops e uso eficiente de links, mas também adiciona camadas de flexibilidade e controle, tornando-a uma solução ideal para data centers de próxima geração.

Vantagens da arquitetura spine leaf em data centers modernos

A arquitetura Spine Leaf é uma opção interessante para data centers modernos, oferecendo várias vantagens. Aqui estão alguns pontos importantes a considerar:

  • Redução de latência: Isso significa que os dados são transferidos mais rapidamente, resultando em uma experiência mais ágil para os usuários.
  • Facilidade de expansão: Você pode adicionar novos dispositivos com facilidade, sem complicações, quando seu negócio cresce.
  • Gerenciamento de tráfego: Essa arquitetura ajuda a evitar sobrecarga nas redes, melhorando a eficiência.
  • Otimização de recursos: Garante que a largura de banda esteja disponível quando você realmente precisa dela.

Automação nas redes spine leaf

Quando falamos sobre automação e segurança em redes, especialmente na Arquitetura leaf-spine, é importante lembrar como essas ferramentas podem facilitar o dia a dia. Imagine ajustar diversas configurações em poucos cliques, ao invés de gastar horas na configuração de cada equipamento. Isso não só economiza tempo, mas também minimiza erros humanos. Além disso, a segurança é fundamental: com o aumento das ameaças digitais, ter camadas de proteção, como segmentação, firewalls e monitoramento constante, é essencial para proteger os dados. Criar zonas seguras dentro da rede ajuda na detecção de comportamentos estranhos.

Gerenciamento de oversubscription e configuração de switches

Gerenciar a oversubscription é fundamental na Arquitetura Spine Leaf. Basicamente, isso significa conectar mais dispositivos do que a largura de banda permite. Isso pode funcionar bem se for planejado corretamente. Aqui estão alguns pontos a considerar:

  • Relação de oversubscription: Defina uma relação adequada com base na sua carga de trabalho. Por exemplo, uma relação de 4:1 pode ser ideal para certos cenários.
  • Configuração dos links: Ajuste bem os links entre os switches spine e leaf para garantir eficiência e reduzir o risco de lentidão.
  • Monitoramento constante: Acompanhe o tráfego para detectar possíveis gargalos antes que eles se tornem problemas sérios.

Antes de projetar uma arquitetura leaf-spine, é importante saber quais são as necessidades futuras e atuais. Por exemplo, se você tem um número de 100 servidores e que poderá  escalar até 500, você precisa ter certeza de o Fabric poderá ser dimensionado para acomodar as necessidades futuras. Há duas variáveis importantes para calcular a sua escalabilidade máxima: o número de uplinks em um switch leaf e o número de portas nos switches spine. O número de uplinks em um switch leaf determina quantos Switches spine você terá no fabric.

Já os equipamentos de WAN  podem ser posicionados em um Switch leaf separado para esse fim, nomeado como border-leaf.

Até a próxima!

Comware 7: Configuração de VXLAN com BGP EVPN

O Ethernet Virtual Private Network (EVPN) é uma tecnologia VPN de Camada 2 VPN que fornece conectividade entre dispositivos tanto em Camada 2 como para Camada 3 através de uma rede IP. A tecnologia EVPN utiliza o MP-BGP como plano de controle (control plane) e o VXLAN como plano de dados/encaminhamento (data plane) de um switch/roteador. A tecnologia é geralmente utilizada em data centers em ambiente multitenant ( com múltiplos clientes e serviços) com grande tráfego leste-oeste.

A configuração do EVPN permite ao MP-BGP automatizar a descoberta de VTEPs, assim como o estabelecimento de tuneis VXLAN de forma dinâmica, a utilização de IRB (Integrated Routing and Bridging) anuncia tanto as informações  de Camada 2 e 3 para acesso ao host, fornecendo a utilização do melhor caminho através do ECMP e minimizando flood do trafego multidestination (BUM: broadcast,unicast unknown e multicast)  .

Em resumo o EVPN possui um address Family que permite que as informações de MAC, IP, VRF e VTEP sejam transportadas sobre o MP-BGP, que assim permitem aos VTEPs aprender informações sobre os hosts (via ARP/ND/DHCP etc.).

O BGP EVPN distribui e fornece essa informação para todos os outros pares BGP-EVPN dentro da rede.

Relembrando o VXLAN

O VXLAN prove uma rede de camada 2 sobreposta (overlay) em uma rede de camada 3 (underlay). Cada rede sobreposta é chamada de segmento VXLAN e é identificada por um ID único de 24 bits chamado VNI – VXLAN Network Identifier ou VXLAN ID.

A identificação de um host vem da combinação do endereço MAC e o VNI.  Os hosts situados em VXLANs diferentes não podem comunicar entre si (sem a utilização de um roteador). O pacote original enviado por um host na camada 2 é encapsulado em um cabeçalho VXLAN que inclui o VNI associado ao segmento VXLAN que aquele host pertence.

Os equipamentos que transportam os tuneis VXLAN são chamados de VTEP (VXLAN tunnel endpoints).

Quando um VXLAN VTEP ou tunnel endpoint comunica-se com outros VXLAN VTEP, um túnel VXLAN é estabelecido. Um túnel é meramente um mecanismo de transporte através de uma rede IP.

Todo o processamento VXLAN é executado nos VTEPs. O VTEP de entrada encapsula o tráfego com cabeçalho VXLAN, mais um cabeçalho UDP externo , mais um cabeçalhos IP externo, e então encaminha o tráfego por meio de túneis VXLAN. O VTEP do destino remove o encapsulamento VXLAN e encaminha o tráfego para o destino.

Os dispositivos da rede IP de transporte encaminham o tráfego VXLAN apenas com base no cabeçalho IP externo dos pacotes VXLAN (eles não precisam ter suporte à tecnologia VXLAN).

Um outro ponto importante é que a tecnologia VXLAN supera as limitações de apenas 4 mil domínios de broadcast fornecido por VLANs para até 16 milhões de domínios de broadcast com VNIs. Já para as limitações do Spanning-Tree que coloca os caminhos redundantes em estado de bloqueio, a tecnologia VXLAN permite a construção de todos os uplinks como parte de um backbone IP (rede underlay), utilizando protocolos de roteamento dinâmico para escolha do melhor caminho ao destino, assim fazendo uso do ECMP (Equal Cost Multipath) em uma topologia Spine-Leaf, por exemplo.

BGP EVPN

O BGP EVPN difere do comportamento “Flood and Learn” executado por tuneis VXLANs em diversas maneiras. Enquanto o tráfego multidestination (BUM: broadcast,unicast unknown e multicast) encaminhado pelo VXLAN sem o BGP EVPN necessita de utilizar grupos multicast, o EVPN permite a replicação da identificação dos dispositivos finais com o MP-BGP , assim como as informações do VTEP que ele está associado. As comunicações ARP para IPv4 também pode ser suprimida, aprimorando assim a eficiência do transporte dos dados.

LAB

No laboratório abaixo utilizamos os roteadores HP VSR no release R0621P18-X64, no EVE-NG.

Ambos os Spines estão configurados como VTEP e encaminharão o tráfego do VXLAN VNI 10. A instancia criada para esse cliente, chamamos de ‘clientea’.

Spine está configurado como BGP Router Reflector fechando peerring com ambos Leafs. Nenhum Leaf fecha peering BGP entre si, somente como Spine.

Configuração SPINE 1

#
 sysname Spine-01
#
interface LoopBack0
description OSPF_UNDERLAY
 ip address 192.168.0.1 255.255.255.255
#
interface LoopBack1
description BGP_EVPN_UNDERLAY
 ip address 192.168.0.11 255.255.255.255
#
interface GigabitEthernet1/0
description CONEXAO_LEAF3
 ip address 192.168.13.1  255.255.255.0
#
interface GigabitEthernet2/0
description CONEXAO_LEAF4
 ip address 192.168.14.1 255.255.255.0
#
ospf 1 router-id 192.168.0.1
 description UNDERLAY_OSPF
 area 0.0.0.0
  network 192.168.0.1 0.0.0.0
  network 192.168.0.11 0.0.0.0
  network 192.168.14.0 0.0.0.255
  network 192.168.13.0 0.0.0.255
#
bgp 65001
 group evpn internal
 peer evpn connect-interface LoopBack1
 peer 192.168.0.33 group evpn
 peer 192.168.0.44 group evpn
 #
 address-family l2vpn evpn
  undo policy vpn-target
  peer evpn enable
  peer evpn reflect-client
#

Configuração LEAF 3

#
 sysname Leaf-03
#
interface LoopBack0
description OSPF_UNDERLAY
 ip address 192.168.0.3 255.255.255.255
#
interface LoopBack1
description BGP_EVPN_UNDERLAY
 ip address 192.168.0.33 255.255.255.255
#
interface GigabitEthernet1/0
description CONEXAO_SPINE1
 ip address 192.168.13.3 255.255.255.0
 ospf network-type p2p
#
ospf 1 router-id 192.168.0.3
 description UNDERLAY_OSPF
 area 0.0.0.0
  network 192.168.0.3 0.0.0.0
  network 192.168.0.33 0.0.0.0
  network 192.168.13.0 0.0.0.255
#
bgp 65001
 peer 192.168.0.11 as-number 65001
 peer 192.168.0.11 connect-interface LoopBack1
 #
 address-family l2vpn evpn
  peer 192.168.0.11 enable
#
 vxlan tunnel mac-learning disable
#
 l2vpn enable
#
vsi clientea
 arp suppression enable
 vxlan 10
 evpn encapsulation vxlan
  route-distinguisher auto
  vpn-target auto export-extcommunity
  vpn-target auto import-extcommunity
  quit
#
interface GigabitEthernet3/0
 xconnect vsi clientea
#

Configuração LEAF 4

#
 sysname Leaf-04
#
interface LoopBack0
description OSPF_UNDERLAY
 ip address 192.168.0.4 255.255.255.255
#
interface LoopBack1
description BGP_EVPN_UNDERLAY
 ip address 192.168.0.44 255.255.255.255
#
interface GigabitEthernet2/0
description CONEXAO_SPINE2
 ip address 192.168.14.4 255.255.255.0
  ospf network-type p2p
#
ospf 1 router-id 192.168.0.4
 area 0.0.0.0
  network 192.168.0.4 0.0.0.0
  network 192.168.0.44 0.0.0.0
  network 192.168.14.0 0.0.0.255
#
bgp 65001
 peer 192.168.0.11 as-number 65001
 peer 192.168.0.11 connect-interface LoopBack1
 #
 address-family l2vpn evpn
  peer 192.168.0.11 enable
#
 vxlan tunnel mac-learning disable
#
 l2vpn enable
#
vsi clientea
 arp suppression enable
 evpn encapsulation vxlan
  route-distinguisher auto
  vpn-target auto export-extcommunity
  vpn-target auto import-extcommunity
  quit
  vxlan 10
  quit
#
interface GigabitEthernet3/0
 xconnect vsi clientea
#

Comandos Display bgp l2vpn evpn

Comando display vxlan tunnel

Referências

R2702-HPE FlexFabric 5940 & 5930 Switch Series EVPN Configuration Guide

KRATTIGER, Lukas; KAPADIA, Shyam; JANSEN, David; Building Data Centers with VXLAN BGP EVPN – A Cisco NX-OS Perspective – 2017 CiscoPress

Comware – Roteamento seletivo entre VRFs com export-map

A utilização de VRFs (Virtual Routing and Forwarding ou vpn-instance na linguagem HP) em Roteadores permite a criação de tabelas de roteamentos virtuais que trabalham de forma independente da tabela de roteamento “normal”, protegendo os processos de roteamento de cada cliente de forma individual.

Como nós explicamos anteriormente no post http://www.comutadores.com.br/roteamento-entre-vrfs-com-mp-bgp-em-roteadores-hp-h3c/ o rotemento entre VRFs (quando necessário) pode ser efetuado com a manipulação do  route-targets (RT) com o processo MP-BGP ativo no Roteador.

Há também cenários em que é necessário a troca seletiva de prefixos de rede entre as tabelas de roteamento virtuais, escolhendo quais redes devem ser exportardas ou não entre as VRFs. Lembrando que os valores vpn-target (route-target) trabalham com as Extended community do BGP para troca de prefixos entre VRFs,  é possível manipular o processo via route-policy (route-map), configurando a “comunidade estendida” para o prefixo e utilizando o comando export dentro da VRF.

Relembrando…

No diagrama abaixo há 2 VRFs já configuradas (com o processo MP-BGP ativo) e com seus respectivos prefixos.

Como os valores para import/export das VRFs não são os mesmos, não há roteamento entre as VRFs (cada VRF tem o seu roteamento isolado).

 comutadores.com.br
# Roteamento Seletivo entre VRFs (1º exemplo)
!
ip vpn-instance Client_A
route-distinguisher 65000:1
vpn-target 65000:1 export-extcommunity
vpn-target 65000:1 import-extcommunity
#
ip vpn-instance Client_B
route-distinguisher 65000:2
vpn-target 65000:2 export-extcommunity
vpn-target 65000:2 import-extcommunity
#
!
interface Loopback1
ip address 1.1.1.1 255.255.255.255
!
bgp 65000
undo synchronization
#
ipv4-family vpn-instance Client_A
network 192.168.1.0
network 192.168.2.0
network 192.168.3.0
#
ipv4-family vpn-instance Client_B
network 172.16.1.0 255.255.255.0
network 172.16.2.0 255.255.255.0
network 172.16.3.0 255.255.255.0
#
#
ip route-static vpn-instance Client_A 192.168.1.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_A 192.168.2.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_A 192.168.3.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.1.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.2.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.3.0 255.255.255.0 NULL0
#
#
[R1]display ip routing-table vpn-instance Client_A
Routing Tables: Client_A
Destinations : 5 Routes : 5

Destination/Mask Proto Pre Cost NextHop Interface

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
192.168.1.0/24 Static 60 0 0.0.0.0 NULL0
192.168.2.0/24 Static 60 0 0.0.0.0 NULL0
192.168.3.0/24 Static 60 0 0.0.0.0 NULL0

[R1]display ip routing-table vpn-instance Client_B
Routing Tables: Client_B
Destinations : 5 Routes : 5

Destination/Mask Proto Pre Cost NextHop Interface

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
172.16.1.0/24 Static 60 0 0.0.0.0 NULL0
172.16.2.0/24 Static 60 0 0.0.0.0 NULL0
172.16.3.0/24 Static 60 0 0.0.0.0 NULL0

No exemplo abaixo, caso manipulassemos o import/export, teríamos as 2 tabelas de roteamento compartilhadas…


# comutadores.com.br
# Roteamento Seletivo entre VRFs (2º exemplo)
!
#
ip vpn-instance Client_A
route-distinguisher 65000:1
vpn-target 65000:1 export-extcommunity
vpn-target 65000:1 65000:2 import-extcommunity
#
ip vpn-instance Client_B
route-distinguisher 65000:2
vpn-target 65000:2 export-extcommunity
vpn-target 65000:2 65000:1 import-extcommunity
#
!
interface Loopback1
ip address 1.1.1.1 255.255.255.255
!
bgp 65000
undo synchronization
#
ipv4-family vpn-instance Client_A
network 192.168.1.0
network 192.168.2.0
network 192.168.3.0
#
ipv4-family vpn-instance Client_B
network 172.16.1.0 255.255.255.0
network 172.16.2.0 255.255.255.0
network 172.16.3.0 255.255.255.0
#
#
ip route-static vpn-instance Client_A 192.168.1.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_A 192.168.2.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_A 192.168.3.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.1.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.2.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.3.0 255.255.255.0 NULL0
#
#
[R1]display ip routing-table vpn-instance Client_A
Routing Tables: Client_A
Destinations : 8 Routes : 8

Destination/Mask Proto Pre Cost NextHop Interface

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
172.16.1.0/24 BGP 130 0 0.0.0.0 NULL0
172.16.2.0/24 BGP 130 0 0.0.0.0 NULL0
172.16.3.0/24 BGP 130 0 0.0.0.0 NULL0
192.168.1.0/24 Static 60 0 0.0.0.0 NULL0
192.168.2.0/24 Static 60 0 0.0.0.0 NULL0
192.168.3.0/24 Static 60 0 0.0.0.0 NULL0

[R1]display ip routing-table vpn-instance Client_B
Routing Tables: Client_B
Destinations : 8 Routes : 8

Destination/Mask Proto Pre Cost NextHop Interface

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
172.16.1.0/24 Static 60 0 0.0.0.0 NULL0
172.16.2.0/24 Static 60 0 0.0.0.0 NULL0
172.16.3.0/24 Static 60 0 0.0.0.0 NULL0
192.168.1.0/24 BGP 130 0 0.0.0.0 NULL0
192.168.2.0/24 BGP 130 0 0.0.0.0 NULL0
192.168.3.0/24 BGP 130 0 0.0.0.0 NULL0

Mas imaginem que a VRF Client_B, por questões de segurança no roteamento, não precissasse ensinar os prefixos 172.16.2.0/24 e 172.16.3.0/24 para a VRF Client_A mas somente o prefixo 172.16.1.0/24…. Nesse caso precisaríamos configurar o roteamento seletivo para que a VRF Client_A aprenda somente os prefixos necessários.

Ja a VRF Client_A exportará todos os prefixos sem filtros para a Client_B

Utilizaremos no exemplo o valor da Extended Community 65000:12 para exportar o prefixo 172.16.1.0/24.

ip ip-prefix Client_B_prefixo index 5 permit 172.16.1.0 24
! Selecionando o prefixo via prefix-list
!
route-policy Client_B_export permit node 10
if-match ip-prefix Client_B_prefixo
apply extcommunity rt 65000:12 additive
#
! Configurando a community estendida via Route-map
!
ip vpn-instance Client_B
export route-policy Client_B_export
quit
! Configurando o export seletivo de prefixo
end
!

#
ip ip-prefix Client_B index 5 permit 172.16.1.0 24
#
route-policy Client_B permit node 10
if-match ip-prefix Client_B
apply extcommunity rt 65000:12 additive
#

ip vpn-instance Client_A
route-distinguisher 65000:1
vpn-target 65000:1 export-extcommunity
vpn-target 65000:1 65000:12 import-extcommunity
#
ip vpn-instance Client_B
route-distinguisher 65000:2
export route-policy Client_B
vpn-target 65000:2 export-extcommunity
vpn-target 65000:2 65000:1 import-extcommunity
#
!
interface Loopback1
ip address 1.1.1.1 255.255.255.255
!
bgp 65000
undo synchronization
#
ipv4-family vpn-instance Client_A
network 192.168.1.0
network 192.168.2.0
network 192.168.3.0
#
ipv4-family vpn-instance Client_B
network 172.16.1.0 255.255.255.0
network 172.16.2.0 255.255.255.0
network 172.16.3.0 255.255.255.0
#
#
ip route-static vpn-instance Client_A 192.168.1.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_A 192.168.2.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_A 192.168.3.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.1.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.2.0 255.255.255.0 NULL0
ip route-static vpn-instance Client_B 172.16.3.0 255.255.255.0 NULL0
#
#
[R1]disp ip routing-table vpn-instance Client_A
Routing Tables: Client_A
Destinations : 6 Routes : 6

Destination/Mask Proto Pre Cost NextHop Interface

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
172.16.1.0/24 BGP 130 0 0.0.0.0 NULL0
192.168.1.0/24 Static 60 0 0.0.0.0 NULL0
192.168.2.0/24 Static 60 0 0.0.0.0 NULL0
192.168.3.0/24 Static 60 0 0.0.0.0 NULL0

[R1]display ip routing-table vpn-instance Client_B
Routing Tables: Client_B
Destinations : 8 Routes : 8

Destination/Mask Proto Pre Cost NextHop Interface

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0
127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0
172.16.1.0/24 Static 60 0 0.0.0.0 NULL0
172.16.2.0/24 Static 60 0 0.0.0.0 NULL0
172.16.3.0/24 Static 60 0 0.0.0.0 NULL0
192.168.1.0/24 BGP 130 0 0.0.0.0 NULL0
192.168.2.0/24 BGP 130 0 0.0.0.0 NULL0
192.168.3.0/24 BGP 130 0 0.0.0.0 NULL0

Obs: O mesmo controle pode ser feito para os prefixos de entrada, utilizando o “import map”

Dúvidas , deixe um comentário

Perguntas e Respostas: VRF x VPN-instance

Pessoal, segue abaixo um pequeno resumo sobre a nomenclatura utilizada nas documentações Cisco x HP sobre o assunto VRF. Acredito que possa ajudar de forma rápida a entender alguns conceitos:

VRF: Virtual Routing and Forwarding
A utilização de VRFs (Virtual Routing and Forwarding) em Roteadores permite a criação de tabelas de roteamentos virtuais que trabalham de forma independente da tabela de roteamento “normal”, protegendo os processos de roteamento de cada cliente de forma individual. Utilizado em cenários MPLS L3VPN com MP-BGP.

VRF Lite
A mesma funcionalidade que a VRF para criação de tabelas de roteamento independentes, mas nomeado para cenários sem MPLS L3VPN. Chamado também de Multi-VRF.

VPN-Instance
Termo utilizado nas documentações HP para VRF no Comware.

MCE (Multi CE)
Termo utilizado nas documentações HP para VRF-Lite.

Dúvidas e colocações, deixe um comentário.