MPLS L3VPN Huawei: Como Configurar VRF com BGP VPNv4 no NE8000, NE40 e S6730
MPLS L3VPN Huawei é o serviço em que o PE da operadora mantém uma tabela de rotas separada para cada cliente, a VRF (no VRP ela se chama vpn-instance), e troca essas rotas com os outros PEs por MP-BGP sobre o mesmo backbone MPLS que já carrega a internet.
O modelo está descrito na RFC 4364, e é ele que está por trás do produto que o comercial vende como “VPN IP” ou “rede privada” para a empresa com matriz e várias filiais. Nenhum cliente enxerga o outro, mesmo com endereçamento igual.
Este é o terceiro texto da série de MPLS no VRP. Depois do VPLS no S6730 e do L2VC ponto a ponto, que entregam camada 2, chegou a vez da camada 3.
Tenho NE8000, NE40 e S6730 rodando MPLS e LDP, mas nunca tinha colocado VRF de cliente em nenhum deles, então montei o laboratório do zero. O cenário tem exatamente esses três modelos e duas VRFs com a mesma rede 192.168.10.0/24 no site de São Paulo, de propósito, para provar o isolamento. Escrevi pensando em quem opera provedor e vai ativar o primeiro cliente de MPLS L3VPN Huawei.
O roteiro:
- Entenda o que são VRF, RD, RT e VPNv4 e o que cada um decide.
- Compare L3VPN com L2VC e VPLS para saber quando vender cada serviço.
- Conheça a topologia do laboratório, com os IPs de cada nó e de cada VRF.
- Crie as vpn-instances e coloque as interfaces dos clientes dentro delas.
- Feche o MP-BGP VPNv4 entre as loopbacks dos PEs e ligue os CEs por eBGP ou rota estática.
- Valide o MPLS L3VPN Huawei com os displays do VRP e o ping de ponta a ponta.
Neste tutorial
O que é MPLS L3VPN Huawei: VRF, RD, RT e VPNv4
A VRF é uma tabela de roteamento própria, com interfaces próprias. As rotas aprendidas por uma interface vinculada à vpn-instance ficam na tabela daquela VRF, separadas da global e das de outros clientes. Por isso dois clientes podem usar 192.168.10.0/24 no mesmo PE sem conflito.
O problema aparece quando essas rotas precisam atravessar o backbone. O BGP comum só conhece prefixo IPv4, e dois 192.168.10.0/24 iguais seriam tratados como a mesma rota. O Route Distinguisher resolve isso: são 8 bytes colados na frente do prefixo, e a combinação RD:IPv4 forma uma rota VPNv4 única. O RD só diferencia; ele não decide em qual VRF a rota entra do outro lado.
Quem decide é o Route Target, uma extended community que viaja junto com a rota. Cada VRF exporta suas rotas com um ou mais RTs e importa as rotas que chegam com os RTs listados no import. Se o RT exportado pelo PE-SP não estiver no import da VRF no PE-FILIAL, a rota chega ao PE e é descartada, mesmo com a sessão BGP perfeita.
O transporte dessas rotas é o MP-BGP, a extensão multiprotocolo da RFC 4760, na família VPNv4. Além do prefixo e dos RTs, cada anúncio leva um label de VPN escolhido pelo PE que originou a rota.
No encaminhamento, o pacote do cliente sai do PE com dois labels: o externo é o de transporte, do LSP que o LDP montou até a loopback do PE remoto, e o interno é o de VPN, que diz ao PE de destino em qual VRF entregar.
Cada P intermediário troca o label de transporte; o penúltimo salto o retira (PHP, padrão do LDP na Huawei), e o PE de destino recebe só o label da VPN. Neste lab o P-CORE é o penúltimo salto para os dois PEs.
O P não roda BGP VPNv4 e não tem VRF, e é isso que deixa o MPLS L3VPN Huawei escalável: o núcleo não cresce junto com o número de clientes.
| Pergunta | RD (Route Distinguisher) | RT (Route Target) |
|---|---|---|
| Função | Tornar o prefixo único dentro do BGP (RD:IPv4 vira rota VPNv4) | Decidir quais VRFs exportam e importam cada rota |
| Formato | 8 bytes, escrito como ASN:número ou IP:número (ex.: 64500:101) | Extended community de 8 bytes, no mesmo formato (ex.: 64500:101) |
| Onde aparece | route-distinguisher dentro da ipv4-family da vpn-instance e na frente de cada prefixo VPNv4 | vpn-target com export-extcommunity ou import-extcommunity; viaja como atributo da rota |
| Precisa ser igual nos PEs? | Não. Neste lab é igual por VRF; RD diferente por PE ajuda quando um site tem dois PEs | O RT exportado de um lado precisa estar no import do outro |
| Pode repetir entre VRFs? | Não no mesmo PE: cada vpn-instance tem RD próprio | Pode, e é assim que se monta extranet e serviço compartilhado |
| Erro típico | Achar que RD igual faz as VRFs se enxergarem | Configurar só export ou só import e a rota não entrar na VRF remota |
| Termo | O que é na prática |
|---|---|
| VRF / vpn-instance | Tabela de rotas isolada no PE, com as interfaces do cliente vinculadas a ela |
| PE (Provider Edge) | Roteador da operadora onde o cliente se conecta; guarda as VRFs e roda BGP VPNv4 |
| P (Provider) | Roteador do núcleo; só roda IGP e LDP; troca o label de transporte ou, no penúltimo salto, o retira |
| CE (Customer Edge) | Roteador ou firewall do cliente, ligado ao PE por um link IP |
| RD | Torna a rota única no BGP |
| RT | Controla import e export |
| VPNv4 | Família do MP-BGP que carrega RD, prefixo IPv4, RTs e label de VPN |
| Label de VPN | Label interno anunciado pelo PE de origem; aponta a VRF de destino |
| Label de transporte | Label externo, do LSP LDP até a loopback do PE remoto; sai no penúltimo salto (PHP) |
| PE-CE | Roteamento entre PE e CE dentro da VRF: estática, eBGP, OSPF ou outro IGP |
L3VPN, L2VC ou VPLS: quando usar cada um
| Critério | L3VPN (VRF) | L2VC (VLL) | VPLS (VSI) |
|---|---|---|---|
| Camada entregue | Camada 3: link IP roteado em cada site | Camada 2 ponto a ponto | Camada 2 multiponto |
| Quem roteia | A operadora participa do roteamento do cliente no PE | O cliente, entre os próprios equipamentos | O cliente, sobre uma LAN estendida |
| Topologia | Qualquer site fala com qualquer site; hub-and-spoke por RT | Sempre dois pontos | Vários sites no mesmo domínio de broadcast |
| Escala de sites | Site novo pede a VRF só no PE daquele site | Um circuito por par de sites | Full mesh de PWs entre os PEs da VSI |
| Sobreposição de IP | Entre clientes, sim; dentro da mesma VRF, não | Não importa, a operadora não olha o IP | Não importa, a operadora não olha o IP |
| Protocolos do cliente | IP unicast; multicast exige MVPN à parte | Qualquer ethertype em modo porta | Ethernet, com broadcast e multicast inundados |
| Operação e chamados | A operadora vê as rotas e testa com ping por VRF | Pouco para vigiar; problema de L3 fica com o cliente | Tabela MAC, loops e tempestade de broadcast |
| Caso típico | Empresa com matriz e várias filiais | L2L dedicado entre dois prédios | Mesma VLAN em vários POPs |
Para o provedor, o MPLS L3VPN Huawei resolve mais que a VPN vendida para empresa:
- A VPN corporativa multi-site é o uso óbvio, com cada cliente numa VRF e todas as filiais roteando entre si.
- A gerência dos equipamentos e das CPEs pode ficar numa VRF própria, fora da tabela de internet.
- O CGNAT e os serviços internos, como RADIUS e DNS recursivo, podem ser isolados em VRFs separadas.
- O mesmo acesso pode entregar internet na tabela global e rede privada numa subinterface dentro da VRF.
- Uma extranet deixa vários clientes consumirem um serviço compartilhado sem que um enxergue o outro.
A regra que eu adotaria: cliente com três filiais ou mais que quer roteamento entre elas vai para L3VPN, em vez de costurar circuitos L2 para o cliente montar a malha. Quando o pedido é um cabo entre dois pontos, com o cliente rodando o próprio roteamento, L2VC. O MPLS L3VPN Huawei tende a dar mais trabalho no primeiro cliente e bem menos do segundo em diante, porque o backbone não muda.
Cenário do laboratório: NE8000, NE40 e S6730 com duas VRFs
O backbone é o mais simples que ainda mostra o papel de cada equipamento: dois PEs e um P no meio, AS 64500, OSPF na área 0 e LDP em todos os enlaces. O NE8000 M4 faz o PE de São Paulo, o NE40E fica no núcleo sem nenhuma configuração de cliente, e o S6730-H faz o PE da filial.
Usar switch como PE é comum na borda de operadora regional, e o laboratório deixa à mostra as diferenças de sintaxe entre o VRP8 dos roteadores e o VRP5 do switch.
| Nó | Modelo | VRP | Papel | Loopback0 | Uplinks |
|---|---|---|---|---|---|
| PE-SP | NE8000 M4 | VRP8 | PE dos sites SP das duas VRFs | 10.70.255.1/32 | GigabitEthernet0/1/0 10.70.0.1/30 (BACKBONE-PARA-P-CORE) |
| P-CORE | NE40E | VRP8 | P: só OSPF e LDP, sem VRF e sem BGP | 10.70.255.3/32 | GigabitEthernet0/1/0 10.70.0.2/30 (BACKBONE-PARA-PE-SP) GigabitEthernet0/1/1 10.70.0.5/30 (BACKBONE-PARA-PE-FILIAL) |
| PE-FILIAL | S6730-H | VRP5 | PE dos sites filial das duas VRFs | 10.70.255.2/32 | XGigabitEthernet0/0/24 10.70.0.6/30 (BACKBONE-PARA-P-CORE) |
| VRF | RD | RT (import e export) | Site SP (PE-SP) | Site filial (PE-FILIAL) | PE-CE |
|---|---|---|---|---|---|
| CORP-ALFA | 64500:101 | 64500:101 | GigabitEthernet0/1/2.101: PE 172.31.101.1/30, CE-ALFA-SP 172.31.101.2, AS 65101 LAN 192.168.10.0/24 | Vlanif101: PE 172.31.101.5/30, CE-ALFA-FILIAL 172.31.101.6, AS 65102 LAN 192.168.20.0/24 | eBGP (AS 65101 e 65102 contra o AS 64500) |
| CORP-BETA | 64500:102 | 64500:102 | GigabitEthernet0/1/2.102: PE 172.31.102.1/30, CE-BETA-SP 172.31.102.2 LAN 192.168.10.0/24 | Vlanif102: PE 172.31.102.5/30, CE-BETA-FILIAL 172.31.102.6 LAN 192.168.30.0/24 | Rota estática no PE para a LAN do CE, rota default no CE |
CORP-ALFA e CORP-BETA usam 192.168.10.0/24 no site SP de propósito. Os dois prefixos entram no mesmo PE-SP, cada um na sua VRF, e saem no BGP como rotas VPNv4 diferentes por causa do RD. Qualquer vazamento entre os clientes aparece na hora.
Pré-requisitos e diferenças entre VRP8 e VRP5
- Antes do MPLS L3VPN Huawei, o backbone MPLS precisa estar funcionando, com loopback /32 anunciada no IGP e LSP LDP ativo entre os PEs.
- A versão e a licença de cada PE precisam suportar L3VPN.
- O S6730-H suporta BGP/MPLS IP VPN, mas a versão do VRP e a licença do seu equipamento devem ser checadas na documentação da Huawei.
- A primeira ativação deve acontecer numa janela de manutenção.
O MTU do backbone também entra na conta. Com dois labels, cada pacote do cliente ganha 8 bytes no núcleo, e um enlace com MTU 1500 passa a descartar ou fragmentar pacote cheio. Entre VRP8 e VRP5, a lógica do MPLS L3VPN Huawei é a mesma; muda a forma de aplicar e de montar a interface do cliente.
| Ponto | VRP8 (NE8000, NE40) | VRP5 (S6730-H) |
|---|---|---|
| Aplicar configuração | Nada vale até o commit | Cada comando vale assim que é digitado; não existe commit |
| Gravar para o boot | save depois do commit | save |
| Interface do cliente | Subinterface com vlan-type dot1q | Vlanif ligada à VRF e porta do cliente em trunk |
| Porta física | Já é L3 por padrão | É L2 por padrão; undo portswitch para virar porta roteada |
| Comandos display | display ip vpn-instance, display bgp vpnv4 all peer e afins | Os mesmos, com saída em formato muito parecido |
| Onde conferir licença | display license e display version | display license e display version |
Atenção: se o roteador já roda BGP, entre no AS que já existe e não cole o router-id do exemplo: trocar o router ID reinicia todas as sessões BGP do equipamento, inclusive as de trânsito.
Para os comandos básicos do dia a dia, consulte a lista de comandos para roteadores e switches Huawei.
Passo 1: Backbone MPLS pronto (revisão rápida)
O transporte é o mesmo do tutorial de VPLS no S6730 e do post do L2VC: loopback /32, OSPF na área 0, LDP no core e MTU 9216. Se isso já roda na sua rede, pule para o Passo 2.
No PE-SP (NE8000 M4):
system-view
sysname PE-SP
interface LoopBack0
description LSR-ID-MPLS
ip address 10.70.255.1 255.255.255.255
quit
ospf 1 router-id 10.70.255.1
area 0.0.0.0
quit
quit
interface LoopBack0
ospf enable 1 area 0.0.0.0
quit
mpls lsr-id 10.70.255.1
mpls
quit
mpls ldp
quit
interface GigabitEthernet0/1/0
undo shutdown
description BACKBONE-PARA-P-CORE
mtu 9216
ip address 10.70.0.1 255.255.255.252
ospf network-type p2p
ospf enable 1 area 0.0.0.0
mpls
mpls ldp
quit
commit
No P-CORE (NE40E), único bloco dele:
system-view
sysname P-CORE
interface LoopBack0
description LSR-ID-MPLS
ip address 10.70.255.3 255.255.255.255
quit
ospf 1 router-id 10.70.255.3
area 0.0.0.0
quit
quit
interface LoopBack0
ospf enable 1 area 0.0.0.0
quit
mpls lsr-id 10.70.255.3
mpls
quit
mpls ldp
quit
interface GigabitEthernet0/1/0
undo shutdown
description BACKBONE-PARA-PE-SP
mtu 9216
ip address 10.70.0.2 255.255.255.252
ospf network-type p2p
ospf enable 1 area 0.0.0.0
mpls
mpls ldp
quit
interface GigabitEthernet0/1/1
undo shutdown
description BACKBONE-PARA-PE-FILIAL
mtu 9216
ip address 10.70.0.5 255.255.255.252
ospf network-type p2p
ospf enable 1 area 0.0.0.0
mpls
mpls ldp
quit
commit
No PE-FILIAL (S6730-H, VRP5, sem commit):
system-view
sysname PE-FILIAL
interface LoopBack0
description LSR-ID-MPLS
ip address 10.70.255.2 255.255.255.255
quit
ospf 1 router-id 10.70.255.2
area 0.0.0.0
quit
quit
interface LoopBack0
ospf enable 1 area 0.0.0.0
quit
mpls lsr-id 10.70.255.2
mpls
quit
mpls ldp
quit
interface XGigabitEthernet0/0/24
undo portswitch
description BACKBONE-PARA-P-CORE
mtu 9216
ip address 10.70.0.6 255.255.255.252
ospf network-type p2p
ospf enable 1 area 0.0.0.0
mpls
mpls ldp
jumboframe enable 12288
quit
O P-CORE para aqui: não tem VRF nem BGP. Ele só comuta labels (neste lab, retira o de transporte por PHP). No PE-SP, confira o LSP até a loopback do PE-FILIAL:
display mpls lsp
Tem de aparecer a FEC 10.70.255.2/32 com label de saída. Sem ela, o BGP do Passo 4 sobe, mas as rotas remotas do L3VPN Huawei ficam inválidas por falta de túnel.
Passo 2: Criar a VRF (vpn-instance) no MPLS L3VPN Huawei
No PE-SP:
ip vpn-instance CORP-ALFA
description VPN-L3-CORP-ALFA
ipv4-family
route-distinguisher 64500:101
vpn-target 64500:101 export-extcommunity
vpn-target 64500:101 import-extcommunity
quit
quit
commit
ip vpn-instance CORP-BETA
description VPN-L3-CORP-BETA
ipv4-family
route-distinguisher 64500:102
vpn-target 64500:102 export-extcommunity
vpn-target 64500:102 import-extcommunity
quit
quit
commit
No PE-FILIAL, igual e sem commit:
ip vpn-instance CORP-ALFA
description VPN-L3-CORP-ALFA
ipv4-family
route-distinguisher 64500:101
vpn-target 64500:101 export-extcommunity
vpn-target 64500:101 import-extcommunity
quit
quit
ip vpn-instance CORP-BETA
description VPN-L3-CORP-BETA
ipv4-family
route-distinguisher 64500:102
vpn-target 64500:102 export-extcommunity
vpn-target 64500:102 import-extcommunity
quit
quit
| Linha | O que faz |
|---|---|
ip vpn-instance | Cria a VRF. O nome é local, mas igual nos PEs facilita o suporte. |
description | Cliente e contrato. |
ipv4-family | Família IPv4 da VRF, onde ficam RD e RT. |
route-distinguisher | Torna a rota única no VPNv4. Para trocar, só apagando a família, e isso derruba o cliente. |
vpn-target ... export-extcommunity | RT colado nas rotas exportadas. |
vpn-target ... import-extcommunity | Rotas com esse RT entram na VRF. |
commit | Só no VRP8 (NE8000 e NE40E). Sem ele nada vale. |
Usei o mesmo RD nos dois PEs por legibilidade. No multihoming de um L3VPN Huawei, RD por PE evita que o route reflector veja as duas rotas da mesma LAN como um prefixo só e descarte o backup.
Passo 3: Colocar a interface do cliente dentro da VRF
No NE8000, cada cliente do L3VPN Huawei entra por uma subinterface dot1q: VLAN 101 na CORP-ALFA, 102 na CORP-BETA.
interface GigabitEthernet0/1/2
undo shutdown
description CES-CORPORATIVOS
quit
interface GigabitEthernet0/1/2.101
vlan-type dot1q 101
description CORP-ALFA-SP
ip binding vpn-instance CORP-ALFA
ip address 172.31.101.1 255.255.255.252
quit
commit
interface GigabitEthernet0/1/2.102
vlan-type dot1q 102
description CORP-BETA-SP
ip binding vpn-instance CORP-BETA
ip address 172.31.102.1 255.255.255.252
quit
commit
No S6730, porta trunk com as duas VLANs e uma Vlanif por VRF:
interface XGigabitEthernet0/0/1
description CES-CORPORATIVOS
port link-type trunk
undo port trunk allow-pass vlan 1
port trunk allow-pass vlan 101 102
quit
Se o cliente precisa entregar várias VLANs no mesmo acesso e elas colidem com VLANs que você já usa no switch, a tradução de VLAN do QinQ resolve antes da Vlanif.
vlan batch 101
interface Vlanif101
description CORP-ALFA-FILIAL
ip binding vpn-instance CORP-ALFA
ip address 172.31.101.5 255.255.255.252
quit
vlan batch 102
interface Vlanif102
description CORP-BETA-FILIAL
ip binding vpn-instance CORP-BETA
ip address 172.31.102.5 255.255.255.252
quit
| Linha | O que faz |
|---|---|
vlan-type dot1q | Tag que o CE envia. |
port trunk allow-pass vlan | Porta do S6730 levando as VLANs dos clientes. |
interface Vlanif | Interface L3 da VLAN no S6730. |
ip binding vpn-instance | Move a interface da tabela global para a VRF. |
ip address | IP do PE no /30. Pode repetir em outra VRF. |
Atenção: o ip binding vpn-instance vem antes do ip address. Em interface que já tem IP, o binding apaga o endereço e o protocolo configurados nela.
Passo 4: MP-BGP VPNv4 entre os PEs
Esta sessão é o que transporta as rotas do L3VPN Huawei entre os PEs. No PE-SP:
bgp 64500
router-id 10.70.255.1
undo default ipv4-unicast
peer 10.70.255.2 as-number 64500
peer 10.70.255.2 description PE-FILIAL-VPNV4
peer 10.70.255.2 connect-interface LoopBack0
ipv4-family vpnv4
peer 10.70.255.2 enable
quit
quit
commit
No PE-FILIAL:
bgp 64500
router-id 10.70.255.2
undo default ipv4-unicast
peer 10.70.255.1 as-number 64500
peer 10.70.255.1 description PE-SP-VPNV4
peer 10.70.255.1 connect-interface LoopBack0
ipv4-family vpnv4
peer 10.70.255.1 enable
quit
quit
| Linha | Por que está ali |
|---|---|
undo default ipv4-unicast | Peer novo não entra sozinho na família IPv4 global. |
peer ... as-number 64500 | Mesmo AS: sessão iBGP. |
connect-interface LoopBack0 | Sessão sai da loopback, a FEC do LSP. |
ipv4-family vpnv4 | Carrega rota, RD, RT e label de VPN. |
peer ... enable | Ativa o vizinho no VPNv4. |
Se o roteador já roda BGP, lembre do aviso de router-id nos pré-requisitos.
Loopback porque a origem da sessão vira o next hop das rotas VPNv4, e o LDP só tem label para a /32. Com undo default ipv4-unicast, a sessão carrega só VPNv4.
Com mais de quatro PEs, a malha completa cresce rápido (dez PEs já são 45 sessões) e entra o route reflector. No RR, dentro de ipv4-family vpnv4, cada PE cliente entra com peer <loopback do PE> enable e peer <loopback do PE> reflect-client, e o bloco leva undo policy vpn-target. Sem ela, o RR, que não tem VRF, descarta todas as rotas e o L3VPN Huawei fica mudo.
Passo 5: Roteamento PE-CE com eBGP e rota estática
Cada VRF do laboratório mostra um jeito de ligar o cliente ao L3VPN Huawei: eBGP na CORP-ALFA, rota estática na CORP-BETA. No PE-SP:
ip route-static vpn-instance CORP-BETA 192.168.10.0 255.255.255.0 172.31.102.2
bgp 64500
ipv4-family vpn-instance CORP-ALFA
peer 172.31.101.2 as-number 65101
peer 172.31.101.2 description CE-ALFA-SP
quit
ipv4-family vpn-instance CORP-BETA
import-route direct
import-route static
quit
quit
commit
No PE-FILIAL:
ip route-static vpn-instance CORP-BETA 192.168.30.0 255.255.255.0 172.31.102.6
bgp 64500
ipv4-family vpn-instance CORP-ALFA
peer 172.31.101.6 as-number 65102
peer 172.31.101.6 description CE-ALFA-FILIAL
quit
ipv4-family vpn-instance CORP-BETA
import-route direct
import-route static
quit
quit
Na CORP-ALFA, o que chega do CE por eBGP já vira VPNv4. Na CORP-BETA, import-route static leva a LAN e import-route direct leva o /30 do link PE-CE. Na estática, o vpn-instance logo depois de route-static é obrigatório: sem ele a rota vai para a tabela global e o cliente nunca a enxerga.
Os CEs são roteadores Huawei AR, e nenhum deles sabe que existe um L3VPN Huawei no caminho. Em alguns modelos de AR as portas GE0/0/1 e GE0/0/2 vêm como Layer 2; nesse caso, aplique undo portswitch antes do IP. Os da CORP-ALFA fecham eBGP:
system-view
sysname CE-ALFA-SP
interface GigabitEthernet0/0/1.101
dot1q termination vid 101
arp broadcast enable
description LINK-L3VPN-OPERADORA
ip address 172.31.101.2 255.255.255.252
quit
interface GigabitEthernet0/0/2
description LAN-CE-ALFA-SP
ip address 192.168.10.1 255.255.255.0
quit
bgp 65101
router-id 172.31.101.2
peer 172.31.101.1 as-number 64500
ipv4-family unicast
network 192.168.10.0 255.255.255.0
peer 172.31.101.1 enable
quit
quit
quit
system-view
sysname CE-ALFA-FILIAL
interface GigabitEthernet0/0/1.101
dot1q termination vid 101
arp broadcast enable
description LINK-L3VPN-OPERADORA
ip address 172.31.101.6 255.255.255.252
quit
interface GigabitEthernet0/0/2
description LAN-CE-ALFA-FILIAL
ip address 192.168.20.1 255.255.255.0
quit
bgp 65102
router-id 172.31.101.6
peer 172.31.101.5 as-number 64500
ipv4-family unicast
network 192.168.20.0 255.255.255.0
peer 172.31.101.5 enable
quit
quit
quit
Os da CORP-BETA só têm default para o PE:
system-view
sysname CE-BETA-SP
interface GigabitEthernet0/0/1.102
dot1q termination vid 102
arp broadcast enable
description LINK-L3VPN-OPERADORA
ip address 172.31.102.2 255.255.255.252
quit
interface GigabitEthernet0/0/2
description LAN-CE-BETA-SP
ip address 192.168.10.1 255.255.255.0
quit
ip route-static 0.0.0.0 0.0.0.0 172.31.102.1
quit
system-view
sysname CE-BETA-FILIAL
interface GigabitEthernet0/0/1.102
dot1q termination vid 102
arp broadcast enable
description LINK-L3VPN-OPERADORA
ip address 172.31.102.6 255.255.255.252
quit
interface GigabitEthernet0/0/2
description LAN-CE-BETA-FILIAL
ip address 192.168.30.1 255.255.255.0
quit
ip route-static 0.0.0.0 0.0.0.0 172.31.102.5
quit
| PE-CE | Quando uso | A favor | Contra |
|---|---|---|---|
| Estático | Uma LAN, um link, cliente sem equipe de rede. | Nada para negociar. | Mudou a LAN, abre chamado. Queda do CE passa despercebida sem BFD. |
| eBGP | Várias redes ou dois links. | O cliente anuncia e o PE pode filtrar com peer ... ip-prefix ou route-policy. Failover pelo BGP. | Exige alguém que entenda BGP no cliente. |
| OSPF | Cliente que já roda OSPF. | Sem redistribuição no CE. | Processo OSPF por VRF e sham-link em alguns casos. |
Passo 6: Validar o MPLS L3VPN Huawei de ponta a ponta
Abaixo, na ordem das dependências, a saída esperada no laboratório, no PE-SP.
VRF, RD, RT e interface
display ip vpn-instance verbose CORP-ALFA
VPN-Instance Name and ID : CORP-ALFA, 1 Interfaces : GigabitEthernet0/1/2.101 Address family ipv4 Vrf Status : UP Route Distinguisher : 64500:101 Export VPN Targets : 64500:101 Import VPN Targets : 64500:101 Label Policy : label per route The ttl-mode Information is : pipe Description : VPN-L3-CORP-ALFA
Sessão VPNv4
display bgp vpnv4 all peer
BGP local router ID : 10.70.255.1 Local AS number : 64500 Total number of peers : 2 Peers in established state : 2 Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv 10.70.255.2 4 64500 148 151 0 02:05:41 Established 3 Peer of IPv4-family for vpn instance : VPN-Instance CORP-ALFA, Router ID 10.70.255.1: 172.31.101.2 4 65101 139 142 0 02:03:18 Established 1
Tabela VPNv4 com os dois RDs
display bgp vpnv4 all routing-table
BGP Local router ID is 10.70.255.1
Total number of routes from all PE: 6
Route Distinguisher: 64500:101
Network NextHop MED LocPrf PrefVal Path/Ogn
*> 192.168.10.0/24 172.31.101.2 0 0 65101i
*>i 192.168.20.0/24 10.70.255.2 0 100 0 65102i
Route Distinguisher: 64500:102
Network NextHop MED LocPrf PrefVal Path/Ogn
*> 172.31.102.0/30 0.0.0.0 0 0 ?
*>i 172.31.102.4/30 10.70.255.2 0 100 0 ?
*> 192.168.10.0/24 172.31.102.2 0 0 ?
*>i 192.168.30.0/24 10.70.255.2 0 100 0 ?A 192.168.10.0/24 aparece sob 64500:101 e sob 64500:102: dois clientes, mesma LAN, sem conflito. Quem separa as duas é o RD.
Tabela de cada VRF
display ip routing-table vpn-instance CORP-ALFA
Routing Table : CORP-ALFA
Destinations : 6 Routes : 6
Destination/Mask Proto Pre Cost Flags NextHop Interface
172.31.101.0/30 Direct 0 0 D 172.31.101.1 GigabitEthernet0/1/2.101
172.31.101.1/32 Direct 0 0 D 127.0.0.1 GigabitEthernet0/1/2.101
172.31.101.3/32 Direct 0 0 D 127.0.0.1 GigabitEthernet0/1/2.101
192.168.10.0/24 EBGP 255 0 D 172.31.101.2 GigabitEthernet0/1/2.101
192.168.20.0/24 IBGP 255 0 RD 10.70.255.2 GigabitEthernet0/1/0
255.255.255.255/32 Direct 0 0 D 127.0.0.1 InLoopBack0
display ip routing-table vpn-instance CORP-BETA
Routing Table : CORP-BETA
Destinations : 7 Routes : 7
Destination/Mask Proto Pre Cost Flags NextHop Interface
172.31.102.0/30 Direct 0 0 D 172.31.102.1 GigabitEthernet0/1/2.102
172.31.102.1/32 Direct 0 0 D 127.0.0.1 GigabitEthernet0/1/2.102
172.31.102.3/32 Direct 0 0 D 127.0.0.1 GigabitEthernet0/1/2.102
172.31.102.4/30 IBGP 255 0 RD 10.70.255.2 GigabitEthernet0/1/0
192.168.10.0/24 Static 60 0 RD 172.31.102.2 GigabitEthernet0/1/2.102
192.168.30.0/24 IBGP 255 0 RD 10.70.255.2 GigabitEthernet0/1/0
255.255.255.255/32 Direct 0 0 D 127.0.0.1 InLoopBack0Na ALFA, a 192.168.20.0/24 entra como IBGP via 10.70.255.2, pelo LSP. Na BETA ela não aparece, porque tem RT 64500:101: é o isolamento do L3VPN Huawei.
Labels de VPN
display bgp vpnv4 vpn-instance CORP-ALFA routing-table label
VPN-Instance CORP-ALFA, Router ID 10.70.255.1:
Total Number of Routes: 2
Network NextHop In/Out Label
*> 192.168.10.0 172.31.101.2 32832/NULL
*>i 192.168.20.0 10.70.255.2 NULL/1027O Out label 1027 veio do PE-FILIAL e é o label interno, que diz ao S6730 em qual VRF entregar. O externo é o do LDP, que o P-CORE retira antes de o pacote chegar ao S6730.
Ping e tracert
ping -vpn-instance CORP-ALFA -a 172.31.101.1 172.31.101.2
Sem -vpn-instance o PE busca na tabela global, erro clássico de quem vem do L2VC. Do PE até o site remoto da ALFA o ping falha, e está certo: a ALFA só anuncia LANs, então o CE da filial não tem volta para 172.31.101.1, e o PE-SP não tem rota para 172.31.101.4/30, porque a ALFA não faz import-route direct. O teste que vale é no CE-ALFA-SP, com origem na LAN (192.168.10.1):
ping -c 3 -a 192.168.10.1 192.168.20.1
tracert -a 192.168.10.1 192.168.20.1
PING 192.168.20.1: 56 data bytes, press CTRL_C to break
Reply from 192.168.20.1: bytes=56 Sequence=1 ttl=253 time=3 ms
Reply from 192.168.20.1: bytes=56 Sequence=2 ttl=253 time=2 ms
Reply from 192.168.20.1: bytes=56 Sequence=3 ttl=253 time=2 ms
--- 192.168.20.1 ping statistics ---
3 packet(s) transmitted
3 packet(s) received
0.00% packet loss
traceroute to 192.168.20.1(192.168.20.1), max hops: 30 ,packet length: 40,press CTRL_C to break
1 172.31.101.1 2 ms 1 ms 1 ms
2 172.31.101.5 3 ms 2 ms 2 ms
3 192.168.20.1 3 ms 2 ms 3 msO P-CORE some do tracert e o TTL fica em 253: com ttl-mode pipe o PE de entrada não copia o TTL do IP para o label; o P-CORE não decrementa o TTL do cliente e só os dois PEs aparecem. Do CE-BETA-SP, ping para 192.168.20.1 tem de falhar; se responder, há RT errado em algum PE.
| Comando | O que olhar |
|---|---|
display ip vpn-instance verbose | RD, RTs e a interface do cliente. |
display bgp vpnv4 all peer | Established e PrefRcv acima de zero. |
display bgp vpnv4 all routing-table | Remotas com *>i, separadas por RD. |
display ip routing-table vpn-instance | Remota como IBGP; rota de outra VRF ausente. |
... routing-table label | Out label nas rotas remotas. |
ping -vpn-instance | CE local respondendo. |
ping e tracert no CE | LAN a LAN respondendo, core oculto. |
Recursos avançados: extranet, limite de rotas e sites com o mesmo AS
Extranet: VRF de serviços compartilhada com clientes
No L3VPN Huawei, extranet é uma questão de RT. Exemplo: DNS e monitoramento do provedor numa VRF SERVICOS, liberada só para alguns clientes. O desenho é hub: a SERVICOS exporta 64500:900 e importa 64500:901. Quem pode falar com ela importa 900 e exporta 901, além do RT próprio. No PE-SP, onde ficam os servidores:
ip vpn-instance SERVICOS
description VPN-L3-SERVICOS-COMPARTILHADOS
ipv4-family
route-distinguisher 64500:900
vpn-target 64500:900 export-extcommunity
vpn-target 64500:901 import-extcommunity
quit
quit
interface GigabitEthernet0/1/3
undo shutdown
description DNS-E-MONITORAMENTO
ip binding vpn-instance SERVICOS
ip address 172.20.90.1 255.255.255.0
quit
bgp 64500
ipv4-family vpn-instance SERVICOS
import-route direct
quit
quit
commit
A CORP-ALFA ganha os dois RTs extras nos dois PEs; o 64500:101 continua lá.
ip vpn-instance CORP-ALFA
ipv4-family
vpn-target 64500:900 import-extcommunity
vpn-target 64500:901 export-extcommunity
quit
quit
commit
ip vpn-instance CORP-ALFA
ipv4-family
vpn-target 64500:900 import-extcommunity
vpn-target 64500:901 export-extcommunity
quit
quit
A ALFA passa a receber 172.20.90.0/24 nos dois sites, a SERVICOS recebe as LANs da ALFA, e um cliente continua sem enxergar o outro, porque nenhuma VRF de cliente importa 901.
A CORP-BETA fica de fora porque a LAN dela em SP é 192.168.10.0/24, a mesma da ALFA. Se as duas exportassem 901, a SERVICOS teria dois caminhos para o mesmo prefixo. O BGP escolhe um, e o retorno para o outro cliente vai parar no lugar errado. Para a BETA entrar, renumere a LAN ou faça NAT no CE dela.
Antes de ligar um cliente numa VRF compartilhada, compare os prefixos dele com os que já estão lá. Overlap em extranet não gera alarme: o sintoma é tráfego de um cliente chegando ao outro.
Limite de rotas por VRF
Um CE com BGP mal configurado pode despejar milhares de rotas na VRF. O limite protege a memória do PE:
ip vpn-instance CORP-ALFA
ipv4-family
routing-table limit 1000 80
quit
quit
commit
Com routing-table limit 1000 80, o PE gera alarme quando a VRF atinge 80% (800 rotas). Ao chegar em 1.000, para de aceitar rotas novas; as que já estão na tabela continuam valendo. Com simply-alert no lugar do percentual, ele só avisa. Em L3VPN Huawei com clientes em BGP, ponha limite em todas as VRFs.
Para limitar por cliente, na sessão BGP, use peer 172.31.101.2 route-limit 100 dentro da ipv4-family vpn-instance. E, se o contrato define quais redes o cliente anuncia, filtre com ip ip-prefix aplicado no peer.
Sites do cliente com o mesmo AS
No laboratório os CEs da ALFA usam AS 65101 e 65102, mas muito cliente repete o mesmo AS privado em todos os sites. Se os dois sites usassem 65101, a rota de SP chegaria à filial com AS_PATH 64500 65101 e o CE da filial a descartaria. Duas saídas:
- No PE-FILIAL,
peer 172.31.101.6 substitute-asemipv4-family vpn-instance CORP-ALFAtroca o AS do cliente pelo 64500 ao anunciar para aquele CE. O PE-SP precisa do mesmo comando para o CE dele. - No CE,
peer 172.31.101.5 allow-as-loopfaz o roteador aceitar o próprio AS no caminho.
| Opção | Onde | Prós | Contras |
|---|---|---|---|
substitute-as | PE | O provedor resolve sem depender do cliente. | Esconde loops reais; site com backdoor pede SoO. |
allow-as-loop | CE | Não muda nada no PE. | Depende de quem administra o CE, site a site. |
VRF de gerência
Uma VRF GERENCIA tira o acesso aos CPEs da tabela global: SSH, SNMP e syslog passam por ela. No VRP8 dos NE8000 e NE40 já existe a __LOCAL_OAM_VPN__, VRF de sistema da porta de gerência. Não mexa nela. Dê à GERENCIA um RT próprio (64500:950 no plano abaixo) que nenhuma VRF de cliente importe.
L3VPN Huawei numa rede de provedor com BRAS em AS privado
É o caso de muita rede regional: borda em AS público, BRAS em AS privado com eBGP IPv4 para a borda, todos no mesmo OSPF e LDP. Para ter PE de L3VPN Huawei no BRAS, esbarra-se numa limitação: VPNv4 em iBGP exige o mesmo AS, e o equipamento Huawei roda um único AS no BGP.
A saída com menos mudança é VPNv4 em eBGP multihop entre as loopbacks, com connect-interface LoopBack0 e ebgp-max-hop. O encaminhamento funciona porque o OSPF e o LDP comuns já montam o LSP entre as loopbacks; sem esse LSP a rota VPNv4 chega, mas fica inativa. No BRAS, com AS 65020 de exemplo:
bgp 65020
peer 10.70.255.1 as-number 64500
peer 10.70.255.1 description PE-SP-VPNV4-EBGP
peer 10.70.255.1 connect-interface LoopBack0
peer 10.70.255.1 ebgp-max-hop 10
ipv4-family unicast
undo peer 10.70.255.1 enable
quit
ipv4-family vpnv4
peer 10.70.255.1 enable
quit
quit
commit
No PE-SP entra o espelho: peer para a loopback do BRAS com as-number 65020, o mesmo connect-interface e ebgp-max-hop, e peer enable só em ipv4-family vpnv4.
A sessão nova é só VPNv4. O bloco já traz undo peer 10.70.255.1 enable dentro de ipv4-family unicast, então ela não carrega IPv4 mesmo num BRAS sem undo default ipv4-unicast, e as sessões eBGP IPv4 que já existem entre borda e BRAS seguem como estão.
Com vários PEs, feche a sessão eBGP VPNv4 do BRAS com cada PE ou com o route reflector. Se ela ficar só no PE-SP, ele passa a repassar as rotas do BRAS como um ASBR (troca next hop e label) e precisa de undo policy vpn-target para não descartar RTs que ele não importa.
Se a sessão IPv4 entre borda e BRAS já usa essas mesmas loopbacks, não existe sessão nova: ativar o VPNv4 nesse peer derruba e renegocia a sessão, e o IPv4 dos assinantes cai junto. Nesse caso use outro par de endereços (uma segunda loopback) para a sessão VPNv4, ou faça a mudança na janela.
| Opção | Prós | Contras |
|---|---|---|
| iBGP VPNv4 no mesmo AS | Modelo clássico, igual ao resto deste tutorial. | Só funciona se o BRAS já estiver no AS do backbone. |
| eBGP VPNv4 multihop entre loopbacks | Não mexe nas sessões IPv4 atuais; pouca configuração. | Mais uma sessão por BRAS; depende do LSP entre loopbacks. |
| Confederação | Sub-ASes internos com comportamento próximo do iBGP. | Reconfigura o BGP de todo o backbone para ganhar pouco. |
| Migrar o BRAS para o AS do backbone | Desenho mais limpo no longo prazo. | Mexe em todas as sessões e políticas do BRAS, com risco para os assinantes. |
Não suba VRF nesse desenho sem testar antes em equipamento de reserva ou num ambiente virtual com imagens VRP8 (NE40E virtual), e sem janela de manutenção. Sessão BGP nova em BRAS com assinantes online não é mudança de horário comercial.
Configuração completa do MPLS L3VPN Huawei (para copiar)
Os três nós com backbone, VRFs, circuito, BGP VPNv4 e PE-CE. Extranet e limite ficam de fora. Lembre do aviso de router-id nos pré-requisitos; save pede confirmação [Y/N].
PE-SP (NE8000 M4, VRP8)
system-view
sysname PE-SP
interface LoopBack0
description LSR-ID-MPLS
ip address 10.70.255.1 255.255.255.255
quit
ospf 1 router-id 10.70.255.1
area 0.0.0.0
quit
quit
interface LoopBack0
ospf enable 1 area 0.0.0.0
quit
mpls lsr-id 10.70.255.1
mpls
quit
mpls ldp
quit
interface GigabitEthernet0/1/0
undo shutdown
description BACKBONE-PARA-P-CORE
mtu 9216
ip address 10.70.0.1 255.255.255.252
ospf network-type p2p
ospf enable 1 area 0.0.0.0
mpls
mpls ldp
quit
commit
ip vpn-instance CORP-ALFA
description VPN-L3-CORP-ALFA
ipv4-family
route-distinguisher 64500:101
vpn-target 64500:101 export-extcommunity
vpn-target 64500:101 import-extcommunity
quit
quit
commit
ip vpn-instance CORP-BETA
description VPN-L3-CORP-BETA
ipv4-family
route-distinguisher 64500:102
vpn-target 64500:102 export-extcommunity
vpn-target 64500:102 import-extcommunity
quit
quit
commit
interface GigabitEthernet0/1/2
undo shutdown
description CES-CORPORATIVOS
quit
interface GigabitEthernet0/1/2.101
vlan-type dot1q 101
description CORP-ALFA-SP
ip binding vpn-instance CORP-ALFA
ip address 172.31.101.1 255.255.255.252
quit
commit
interface GigabitEthernet0/1/2.102
vlan-type dot1q 102
description CORP-BETA-SP
ip binding vpn-instance CORP-BETA
ip address 172.31.102.1 255.255.255.252
quit
commit
bgp 64500
router-id 10.70.255.1
undo default ipv4-unicast
peer 10.70.255.2 as-number 64500
peer 10.70.255.2 description PE-FILIAL-VPNV4
peer 10.70.255.2 connect-interface LoopBack0
ipv4-family vpnv4
peer 10.70.255.2 enable
quit
quit
commit
ip route-static vpn-instance CORP-BETA 192.168.10.0 255.255.255.0 172.31.102.2
bgp 64500
ipv4-family vpn-instance CORP-ALFA
peer 172.31.101.2 as-number 65101
peer 172.31.101.2 description CE-ALFA-SP
quit
ipv4-family vpn-instance CORP-BETA
import-route direct
import-route static
quit
quit
commit
return
save
P-CORE (NE40E, VRP8)
system-view
sysname P-CORE
interface LoopBack0
description LSR-ID-MPLS
ip address 10.70.255.3 255.255.255.255
quit
ospf 1 router-id 10.70.255.3
area 0.0.0.0
quit
quit
interface LoopBack0
ospf enable 1 area 0.0.0.0
quit
mpls lsr-id 10.70.255.3
mpls
quit
mpls ldp
quit
interface GigabitEthernet0/1/0
undo shutdown
description BACKBONE-PARA-PE-SP
mtu 9216
ip address 10.70.0.2 255.255.255.252
ospf network-type p2p
ospf enable 1 area 0.0.0.0
mpls
mpls ldp
quit
interface GigabitEthernet0/1/1
undo shutdown
description BACKBONE-PARA-PE-FILIAL
mtu 9216
ip address 10.70.0.5 255.255.255.252
ospf network-type p2p
ospf enable 1 area 0.0.0.0
mpls
mpls ldp
quit
commit
return
save
PE-FILIAL (S6730-H, VRP5)
system-view
sysname PE-FILIAL
interface LoopBack0
description LSR-ID-MPLS
ip address 10.70.255.2 255.255.255.255
quit
ospf 1 router-id 10.70.255.2
area 0.0.0.0
quit
quit
interface LoopBack0
ospf enable 1 area 0.0.0.0
quit
mpls lsr-id 10.70.255.2
mpls
quit
mpls ldp
quit
interface XGigabitEthernet0/0/24
undo portswitch
description BACKBONE-PARA-P-CORE
mtu 9216
ip address 10.70.0.6 255.255.255.252
ospf network-type p2p
ospf enable 1 area 0.0.0.0
mpls
mpls ldp
jumboframe enable 12288
quit
ip vpn-instance CORP-ALFA
description VPN-L3-CORP-ALFA
ipv4-family
route-distinguisher 64500:101
vpn-target 64500:101 export-extcommunity
vpn-target 64500:101 import-extcommunity
quit
quit
ip vpn-instance CORP-BETA
description VPN-L3-CORP-BETA
ipv4-family
route-distinguisher 64500:102
vpn-target 64500:102 export-extcommunity
vpn-target 64500:102 import-extcommunity
quit
quit
interface XGigabitEthernet0/0/1
description CES-CORPORATIVOS
port link-type trunk
undo port trunk allow-pass vlan 1
port trunk allow-pass vlan 101 102
quit
vlan batch 101
interface Vlanif101
description CORP-ALFA-FILIAL
ip binding vpn-instance CORP-ALFA
ip address 172.31.101.5 255.255.255.252
quit
vlan batch 102
interface Vlanif102
description CORP-BETA-FILIAL
ip binding vpn-instance CORP-BETA
ip address 172.31.102.5 255.255.255.252
quit
bgp 64500
router-id 10.70.255.2
undo default ipv4-unicast
peer 10.70.255.1 as-number 64500
peer 10.70.255.1 description PE-SP-VPNV4
peer 10.70.255.1 connect-interface LoopBack0
ipv4-family vpnv4
peer 10.70.255.1 enable
quit
quit
ip route-static vpn-instance CORP-BETA 192.168.30.0 255.255.255.0 172.31.102.6
bgp 64500
ipv4-family vpn-instance CORP-ALFA
peer 172.31.101.6 as-number 65102
peer 172.31.101.6 description CE-ALFA-FILIAL
quit
ipv4-family vpn-instance CORP-BETA
import-route direct
import-route static
quit
quit
return
save
Problemas comuns no L3VPN Huawei e como resolver
| Sintoma | Causa provável | Como resolver |
|---|---|---|
| Peer VPNv4 não sobe | Sem rota para a loopback remota ou sem connect-interface. | Ping entre loopbacks e conferir o connect-interface. |
| Rota não entra na VRF | Export RT de um PE diferente do import RT do outro. | Comparar vpn-target nas duas pontas. |
| Mesmo RD da VRF em PEs diferentes | Não é erro num site com um PE só; em multihoming com route reflector, use RD por PE. | Nada a corrigir, desde que os RTs batam. |
| IP sumiu da interface | ip binding vpn-instance apaga o endereço. | Vincular a VRF antes do IP. |
| Ping falha a partir do PE | Ping na tabela global. | Usar ping -vpn-instance NOME. |
| Rota VPNv4 inativa | Sem LSP até a loopback do PE remoto. | Conferir LDP e o LSP /32. |
| Configuração não aplicada no NE | Faltou commit no VRP8. | Rodar commit. |
| CE BGP sem rotas do outro site | O CE do outro site sem network ou sem a LAN na tabela. | Conferir o network no CE. |
| Extranet leva tráfego ao cliente errado | Prefixo sobreposto entre VRFs. | Renumerar ou fazer NAT. |
| BETA sem rota do link PE-CE remoto | Falta import-route direct. | Adicionar na ipv4-family vpn-instance. |
Se o cliente chegar com dois links no mesmo PE, junte-os num Eth-Trunk e crie a subinterface da VRF sobre ele; o LACP é o mesmo da agregação de link entre OLT e switch Huawei.
Boas práticas: plano de RD, RT e nomes de VRF
Em L3VPN Huawei com dezenas de clientes, a planilha nasce antes do primeiro comando. O plano do laboratório:
| VRF | Cliente | RD | RT | VLAN | Observação |
|---|---|---|---|---|---|
| CORP-ALFA | Cliente Alfa | 64500:101 | 64500:101 (+ 900/901) | 101 | BGP no CE, extranet |
| CORP-BETA | Cliente Beta | 64500:102 | 64500:102 | 102 | Estática, LAN sobreposta |
| SERVICOS | Provedor | 64500:900 | exp 900 / imp 901 | porta física | DNS e monitoramento |
| GERENCIA | Provedor | 64500:950 | 64500:950 | 950 | Acesso a CPEs |
- Use o ID do cliente no sistema de cobrança como número do RD e do RT.
- Escreva o nome da VRF em maiúsculas com o nome do cliente, como CORP-ALFA.
- Coloque
descriptionna VRF, na subinterface e no peer BGP. - Configure
routing-table limitem toda VRF. - Use route reflector com mais de quatro PEs, em vez de full mesh de VPNv4.
- Registre VRF, RD, RT e VLAN no NetBox no dia da ativação.
Perguntas frequentes sobre MPLS L3VPN Huawei
Qual a diferença entre VRF e VRF-lite?
VRF-lite é a tabela separada sem MPLS nem BGP VPNv4: cada VRF precisa de uma VLAN própria em cada enlace. No L3VPN Huawei o RD, o RT e o label levam a VRF pelo backbone sem tocar nos roteadores P.
RD e RT podem ter o mesmo valor?
Podem, e neste tutorial têm; quem decide a importação é o RT. Na extranet a VRF ganha RTs extras, e aí o valor do RD coincide com só um deles.
O roteador P precisa de configuração de VRF?
Não. O P só comuta labels (neste lab, retira o de transporte por PHP) e precisa apenas de OSPF, MPLS e LDP. A configuração do P-CORE acima não tem VRF nem BGP.
Dá para fazer L3VPN no S6730?
Dá. O S6730-H atua como PE, com a VRF vinculada numa Vlanif. Confira licença e limite de VRFs do modelo antes de vender o serviço. O mesmo switch foi PE de VPLS neste outro tutorial.
Como o cliente acessa a internet estando numa VRF?
Três caminhos: uma VRF de internet que exporta a default para a VRF do cliente; uma estática na VRF apontando para a tabela global (leak de default); ou uma sessão separada, em outra VLAN, na tabela global. Para cliente corporativo, a sessão separada é a que eu recomendo, porque deixa cada contrato de banda claro.
Quantas VRFs cabem num PE?
Depende do modelo, da placa e da licença; no S6730 o número é bem menor que no NE8000. O limite prático é memória de rotas: some o routing-table limit das VRFs e compare com a documentação.
Conclusão
Com backbone MPLS e LDP funcionando, o L3VPN Huawei se resume a VRF com RD e RT, vínculo da interface, sessão VPNv4 entre os PEs e o PE-CE de cada cliente. Extranet, limite de rotas e o BRAS em AS privado são variações do mesmo mecanismo. A base está na RFC 4364, o transporte multiprotocolo na RFC 4760 e os limites de cada modelo na documentação da Huawei. Se o cliente precisa de camada 2, o L2VC continua sendo a resposta.
Monte tudo em laboratório antes, principalmente a parte do BRAS. Se você já roda VRF com BRAS em AS privado e escolheu outro caminho, ou travou em algum passo, conte nos comentários com o modelo e a versão do VRP.
3 Comentários
Deixe um comentário
Leia Também
Cisco
BCP38 e uRPF: anti-spoofing no Huawei, Cisco, Juniper e Mikrotik
BCP38 no provedor: onde aplicar anti-spoofing, uRPF strict ou loose, ACL de origem e a sintaxe no Huawei, Cisco, Juniper e Mikrotik, com teste no Spoofer.
GPON
IPv6 na ONU Huawei: WAN PPPoE dual stack e prefixo delegado
IPv6 na ONU Huawei em modo roteador: WAN PPPoE dual stack, prefixo por DHCPv6-PD, LAN com SLAAC, TR-069 no GenieACS e conferência na OLT.
GPON
ONU online sem internet: diagnóstico na OLT Huawei
ONU online sem internet na OLT Huawei: como checar WAN, PPPoE, VLAN da service-port, portas LAN e concentrador, na ordem certa.
[…] você montou a MPLS L3VPN no Huawei, já usou extended communities sem chamar pelo nome: o vpn-target é um route target, e o route […]
[…] O iBGP também é a base das VPNs de camada 3 sobre MPLS. Se esse é o seu próximo passo, veja o guia de L3VPN MPLS no Huawei. […]
[…] e PE1, é de 1G e recebe custo 100, para só carregar tráfego quando o anel quebrar. Os posts de MPLS L3VPN no Huawei e de L2VC no Huawei usam três roteadores em linha com OSPF. Aqui o backbone ganha um quarto […]