Configuração BGP Huawei: como funciona no VRP, para provedores
Configuração BGP Huawei: no VRP, a sessão é um peer dentro do processo bgp, e o que entra e sai dela é decidido por route-policy, que por sua vez consulta listas ip-prefix. Funciona bem enquanto cada política tem nome claro e ordem certa, e vira problema quando alguém esquece um node, o commit ou o save.
Resumo
- No VRP, a política de rotas se chama route-policy e a lista de prefixos se chama ip ip-prefix.
- Cada route-policy é lida por nodes, do menor número para o maior, e o que não casa com nenhum é negado.
- No VRP 8, a mudança só entra em produção depois do commit, e só sobrevive ao reinício depois do save.
- Os comandos display mostram o que o peer recebeu e anunciou, e são a primeira conferência depois de mexer.
O que é a configuração BGP Huawei e onde ela fica
É o conjunto de comandos do VRP, o sistema dos roteadores Huawei, que cria o processo BGP, os vizinhos e as políticas de cada um. Fica espalhada em três lugares: o bloco bgp, as listas ip-prefix e as route-policy.
Quem vem do MikroTik ou do Cisco estranha primeiro os nomes. O que outras marcas chamam de route-map, o VRP chama de route-policy; a prefix-list vira ip ip-prefix; e o show vira display. A lógica do protocolo é a mesma, mas a leitura de uma configuração Huawei exige saber onde cada peça mora.
Na borda de um provedor, essa configuração costuma estar num NetEngine, como os modelos NE8000 ou NE40E. A configuração de BGP para provedores trata o Huawei como qualquer outra marca: primeiro o desenho da política, depois a tradução para a sintaxe do equipamento.
Para a ordem geral do trabalho, que vale em qualquer roteador, o guia de como configurar BGP mostra as sete etapas. Aqui o foco é como o Huawei organiza essas etapas e onde ele surpreende.
VRP 5 ou VRP 8, o que muda na configuração BGP?
A diferença que mais pesa no dia a dia é o momento em que o comando passa a valer. Os comandos de BGP são parecidos nas duas versões, mas o jeito de aplicar e de voltar atrás não é.
| Ponto | VRP 5 | VRP 8 |
|---|---|---|
| Quando o comando vale | Na hora, ao apertar Enter | Só depois do commit |
| Desfazer um lote de mudanças | Comando a comando, com undo | Descartar antes do commit ou voltar a um ponto de commit |
| Gravar para o próximo reinício | save | save, depois do commit |
| Onde costuma aparecer | Modelos mais antigos da linha NE | NE8000 e NE40E com software recente |
Como ip-prefix, route-policy e peer se ligam no Huawei?
A rota passa por uma cadeia: o peer aponta para uma route-policy, a route-policy consulta uma ip-prefix e decide aceitar, negar ou mudar atributos. Entender essa cadeia é o que permite ler qualquer borda Huawei.
Peer
A rota chega pela sessão
O peer com a operadora recebe a rota e consulta a route-policy marcada como import.
Route-policy
Os nodes são lidos em ordem
Cada node tem um número, permit ou deny, e condições if-match; vale o primeiro node que casar.
Ip-prefix
A lista diz se o prefixo casa
A ip ip-prefix compara o destino e o tamanho da máscara com as linhas index, também em ordem.
Tabela BGP
A rota entra ou é descartada
Se o node for permit, os comandos apply mudam atributos e a rota disputa a seleção com as outras.
Na saída o caminho é o mesmo, ao contrário: a route-policy marcada como export decide o que a operadora vai aprender do provedor.
Repare que há duas listas em ordem, uma dentro da outra. Uma linha fora do lugar na ip-prefix ou um node com número errado na route-policy mudam o resultado sem gerar erro nenhum na tela.
Por que a ordem dos nodes importa
Porque a route-policy para no primeiro node que casa. Um node 10 que aceita tudo, colocado antes de um node 20 que nega faixas privadas, deixa o node 20 sem efeito.
Um hábito que ajuda é numerar os nodes de 10 em 10 e reservar os primeiros números para as negações de segurança. Assim, uma regra nova sempre cabe no meio sem renumerar a política inteira.
Exemplo de configuração BGP Huawei com um trânsito
O exemplo cria a rota do bloco, as listas, as duas políticas e o peer com a sessão bloqueada até a revisão. Os endereços e ASNs são de documentação e precisam ser trocados pelos do provedor.
system-view
# Bloco próprio na tabela de rotas
ip route-static 203.0.113.0 24 NULL0
# Listas de prefixos
ip ip-prefix PL-PROPRIOS index 10 permit 203.0.113.0 24
ip ip-prefix PL-ENTRADA index 10 deny 203.0.113.0 24 greater-equal 24 less-equal 32
ip ip-prefix PL-ENTRADA index 20 deny 10.0.0.0 8 greater-equal 8 less-equal 32
ip ip-prefix PL-ENTRADA index 30 deny 192.168.0.0 16 greater-equal 16 less-equal 32
ip ip-prefix PL-ENTRADA index 100 permit 0.0.0.0 0 less-equal 24
# Políticas de entrada e de saída
route-policy RP-TRANSITO-A-IN permit node 10
if-match ip-prefix PL-ENTRADA
apply local-preference 100
route-policy RP-TRANSITO-A-OUT permit node 10
if-match ip-prefix PL-PROPRIOS
# Processo BGP e peer, bloqueado até a revisão
bgp 64500
router-id 192.0.2.1
peer 198.51.100.1 as-number 64496
peer 198.51.100.1 description TRANSITO-A
peer 198.51.100.1 password cipher TROQUE-ESTA-SENHA
peer 198.51.100.1 ignore
ipv4-family unicast
network 203.0.113.0 24
peer 198.51.100.1 route-policy RP-TRANSITO-A-IN import
peer 198.51.100.1 route-policy RP-TRANSITO-A-OUT export
peer 198.51.100.1 route-limit 1200000 90 idle-timeout 15
commit
# Depois de revisar: libera o peer e grava
bgp 64500
undo peer 198.51.100.1 ignore
commit
return
save- Ip route-static para NULL0: deixa o /24 inteiro na tabela, sem o qual o comando network não anuncia nada.
- PL-ENTRADA: nega o próprio bloco e faixas privadas, e aceita o resto até /24 na linha 100.
- Node 10 da política de saída: é o único node; o que não casa com PL-PROPRIOS cai na negação do fim.
- Peer ignore: mantém a sessão parada enquanto as políticas são revisadas, e o undo libera.
- Route-limit: derruba a sessão por um tempo se a operadora mandar rotas demais, protegendo a memória.
Sua borda Huawei precisa de políticas revisadas antes do próximo link?
Na configuração de BGP, um Especialista escreve ip-prefix e route-policy com nomes legíveis, aplica com commit em janela e deixa cada peer documentado.
Quando a configuração BGP Huawei vira problema?
Vira problema quando o comportamento padrão do VRP decide no lugar de quem configurou. Os casos abaixo deixam a sessão estabelecida e só aparecem quando o tráfego vai para onde não deveria.
| O que aconteceu | O que o VRP faz | O que se vê na rede |
|---|---|---|
| Route-policy sem nenhum node que case | Nega a rota | Sessão estabelecida e nada recebido ou anunciado |
| If-match apontando para ip-prefix que não existe | Pode tratar como se tudo casasse [CONFIRMAR na versão do equipamento] | Filtro que parece certo e deixa tudo passar |
| Peer sem route-policy de export | Anuncia as rotas BGP escolhidas ao vizinho | Rotas de uma operadora repassadas à outra |
| Mudança sem commit no VRP 8 | Mantém a configuração antiga | Ajuste que não fez efeito nenhum |
| Commit sem save | Perde a mudança no reinício | Problema antigo que volta depois de queda de energia |
A terceira linha é a mais perigosa num provedor com dois trânsitos. Sem export explícito, a borda pode virar caminho entre as duas operadoras, o que lota os links e costuma terminar com uma delas derrubando a sessão.
Exemplo: o ajuste que sumiu depois de um reinício
Um provedor ajusta a preferência para tirar tráfego de um link lotado, confere com display e vê tudo certo. Duas semanas depois, uma queda de energia reinicia o roteador e o link volta a lotar.
- Sintoma: o tráfego voltou a sair pela operadora antiga sem que ninguém tivesse mexido na borda.
- Causa: o ajuste tinha passado pelo commit, mas ninguém rodou o save, e o roteador subiu com a configuração gravada antes.
- Correção: o ajuste foi aplicado de novo, gravado com save e conferido comparando a configuração atual com a salva.
Desde então, o roteiro de toda janela termina com o save e com o display da configuração salva. Para dividir o tráfego entre links com regra escrita, veja o guia de configuração de communities BGP.
Comandos display para conferir o BGP no Huawei
Quatro comandos respondem quase tudo: o estado dos peers, as rotas recebidas, as anunciadas e o resumo da tabela. Rode os quatro logo depois do commit e de novo no dia seguinte.
# Estado de cada peer, tempo no ar e prefixos recebidos
display bgp peer
# O que a borda anunciou à operadora
display bgp routing-table peer 198.51.100.1 advertised-routes
# O que chegou da operadora e passou pela política de entrada
display bgp routing-table peer 198.51.100.1 received-routes
# Quantidade de rotas na tabela BGP
display bgp routing-table statistics
# Conteúdo da lista e da política usadas pelo peer
display ip ip-prefix PL-PROPRIOS
display route-policy RP-TRANSITO-A-OUT- Estado Established: é o único que indica sessão no ar; Idle, Connect e Active apontam problema antes da política.
- Advertised-routes: a lista precisa ter só os blocos próprios e os de clientes, nada de rota de operadora.
- Received-routes: o número precisa bater com o tipo de tabela combinado com o trânsito.
- Statistics: uma variação grande de um dia para o outro merece investigação antes de virar falta de memória.
Se o peer fica parado em Idle ou Active, a causa está na conexão, e não nas políticas. O guia de sessão BGP que não sobe ajuda a separar endereço, ASN, senha e filtro de porta.
Erros comuns na configuração BGP Huawei
A maioria dos erros nasce de configuração traduzida de outra marca sem conferir o comportamento do VRP. O resto vem de políticas criadas por várias pessoas, cada uma com um padrão de nome.
Evite
- Traduzir uma borda MikroTik linha a linha, sem redesenhar as políticas para o VRP.
- Criar route-policy com nomes como teste1 ou nova, que ninguém sabe para que servem.
- Deixar o peer sem política de export e confiar no comportamento padrão.
- Numerar nodes de 1 em 1 e não ter onde encaixar uma regra nova.
- Encerrar a janela sem o save e sem comparar a configuração salva com a atual.
A troca de marca é o momento em que esses erros mais aparecem. A migração de borda MikroTik para Huawei refaz as políticas no padrão do VRP e testa lado a lado antes da virada.
Quando vale chamar um Especialista para a borda Huawei?
Vale quando a borda tem dois trânsitos ou mais, sessões com o IX.br ou clientes com ASN próprio. Nesses casos, uma política errada afeta outras redes, e não só o provedor.
A Táquion Tech configura BGP em roteadores Huawei com políticas nomeadas, nodes numerados com folga e roteiro de commit e save em cada janela. O suporte Huawei para provedores cobre também a OLT e os switches da mesma marca.
A configuração BGP Huawei exige atenção dobrada à ordem, porque são duas listas lidas em sequência, e ao fechamento da janela, porque commit e save são passos separados.
Perguntas frequentes
Qual a diferença entre route-policy e ip-prefix no Huawei?
A ip ip-prefix só diz se um prefixo casa ou não, comparando destino e tamanho da máscara. A route-policy usa essa resposta para aceitar, negar ou mudar atributos da rota, como a preferência local.
O peer Huawei precisa ser habilitado na família IPv4?
Na família IPv4 unicast, o peer costuma ficar ativo assim que é criado; para IPv6 e outras famílias, é preciso habilitar com o comando enable dentro da família [CONFIRMAR na versão do equipamento].
Como anunciar o bloco IPv6 numa borda Huawei?
Crie o peer IPv6 com os endereços do enlace, uma rota estática do bloco para NULL0 e uma ip ipv6-prefix com o prefixo. Depois, dentro da ipv6-family unicast, habilite o peer, anuncie com network e associe as políticas.
Dá para voltar atrás depois do commit no VRP 8?
Dá, porque o VRP 8 guarda pontos de commit e permite voltar a um deles [CONFIRMAR na versão do equipamento]. Mesmo assim, a cópia da configuração antes da janela continua sendo o caminho de volta mais seguro.
Por que o peer mostra Established e nenhuma rota recebida?
Quase sempre porque a route-policy de import nega tudo, por falta de um node que case ou por uma ip-prefix vazia. Confira com display route-policy e display ip ip-prefix antes de suspeitar da operadora.
Fontes
- Huawei Enterprise, portal de suporte: guias de configuração dos roteadores NetEngine, com BGP, route-policy e ip-prefix no VRP.
- RFC 4271, A Border Gateway Protocol 4 (BGP-4): especificação do protocolo e dos estados da sessão, como Idle, Active e Established.
- RFC 7454, BGP Operations and Security: filtros de prefixo, limite de prefixos e prevenção de vazamento de rotas.