BGP no Cisco IOS-XE: route-map, prefix-list e communities

Configurar BGP no Cisco IOS-XE fecha a trilha multi-vendor que o blog vem montando: já passamos pelo sistema de communities no Huawei, pelo BGP no Juniper com policy-statement e pelo BGP no Mikrotik RouterOS v7. A lógica é a mesma nos quatro: vizinhos, o que aceitar, o que anunciar e como marcar as rotas. Muda o vocabulário. No IOS-XE, quem faz esse trabalho são a prefix-list, o route-map e a community-list.

O cenário deste guia é de laboratório: um AS com dois trânsitos e um cliente BGP, em IPv4 e IPv6. Os IPs e ASNs são de documentação (AS64500, 203.0.113.0/24, 2001:db8::/32). Os comandos seguem o BGP Configuration Guide e o BGP Command Reference da Cisco para IOS-XE.

Resposta rápida: o roteiro do BGP no Cisco

1. Declare os vizinhos em router bgp com neighbor ... remote-as e desligue o IPv4 automático com no bgp default ipv4-unicast.
2. Ative cada vizinho na sua address-family (ipv4 unicast ou ipv6 unicast) e anuncie seus blocos com network, ancorados numa rota para Null0.
3. Crie as prefix-list: seus blocos, os blocos do cliente, bogons e prefixos maiores que /24.
4. Monte um route-map de entrada e um de saída por tipo de vizinho, com set local-preference, set community e set as-path prepend.
5. Aplique com neighbor ... route-map ... in/out, limite com maximum-prefix e ligue send-community onde a community precisa sair.
6. Confira com show ip bgp summary e advertised-routes; mudou a política, use clear ip bgp ... soft.

O cenário e a cadeia de políticas

O AS64500 tem o bloco 203.0.113.0/24 e o 2001:db8:100::/40. Recebe a tabela completa de dois trânsitos, prefere sair pelo A, e vende trânsito para um cliente que tem o próprio ASN e um /24.

No BGP no Cisco, cada rota que chega de um vizinho passa pela política de entrada dele antes de entrar na tabela BGP. Depois da escolha do melhor caminho, a rota passa pela política de saída de cada vizinho para o qual seria anunciada. Uma rota sem permit explícito no route-map é descartada, porque o route-map termina com um deny implícito, assim como a prefix-list.

Passo 1: router bgp e os vizinhos

router bgp 64500
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 198.51.100.1 remote-as 64510
 neighbor 198.51.100.1 description TRANSITO-A
 neighbor 198.51.100.5 remote-as 64511
 neighbor 198.51.100.5 description TRANSITO-B
 neighbor 198.51.100.9 remote-as 64501
 neighbor 198.51.100.9 description CLIENTE-AS64501
 neighbor 2001:db8:ffa::1 remote-as 64510
 neighbor 2001:db8:ffa::1 description TRANSITO-A-V6

• bgp log-neighbor-changes registra no log cada vez que uma sessão sobe ou cai. É o que você vai procurar quando o trânsito piscar de madrugada.
• no bgp default ipv4-unicast impede que todo vizinho declarado já troque IPv4. Sem ele, o vizinho IPv6 também tentaria IPv4, e qualquer neighbor novo sobe trocando rotas antes de você colocar o filtro.
• remote-as diferente do seu ASN torna a sessão eBGP. A description não muda nada no protocolo, mas aparece nos logs e evita confundir trânsito com cliente.

Ancorar o anúncio numa rota para Null0

ip route 203.0.113.0 255.255.255.0 Null0
ipv6 route 2001:db8:100::/40 Null0

O comando network do BGP no Cisco só anuncia um prefixo que existe exatamente igual na tabela de roteamento, com a mesma máscara. Como o /24 inteiro raramente está numa interface só, a rota para Null0 garante que ele exista sempre. O tráfego para partes do bloco que estão em uso segue as rotas mais específicas; o que sobra é descartado em vez de voltar para o trânsito em loop.

Passo 2: address-family IPv4 e IPv6

router bgp 64500
 address-family ipv4 unicast
  network 203.0.113.0 mask 255.255.255.0
  neighbor 198.51.100.1 activate
  neighbor 198.51.100.5 activate
  neighbor 198.51.100.9 activate
 exit-address-family

Dentro da address-family ipv4 unicast fica tudo o que é específico do IPv4: o network com mask e o activate de cada vizinho. Um vizinho declarado mas não ativado fica sem trocar rotas nessa família.

router bgp 64500
 address-family ipv6 unicast
  network 2001:db8:100::/40
  neighbor 2001:db8:ffa::1 activate
 exit-address-family

No IPv6 o network usa a notação com barra. O vizinho IPv6 do trânsito A é uma sessão separada da IPv4, com o mesmo ASN remoto. Há quem prefira levar IPv6 dentro da sessão IPv4; manter sessões separadas deixa o diagnóstico mais simples, porque uma família não derruba a outra.

Passo 3: prefix-list no BGP no Cisco

ip prefix-list PL-NOSSOS seq 10 permit 203.0.113.0/24
ip prefix-list PL-NOSSOS-MAIS seq 10 permit 203.0.113.0/24 le 32
ip prefix-list PL-CLIENTE-64501 seq 10 permit 192.0.2.0/24
ip prefix-list PL-BOGONS seq 10 permit 0.0.0.0/0
ip prefix-list PL-BOGONS seq 20 permit 0.0.0.0/8 le 32
ip prefix-list PL-BOGONS seq 30 permit 10.0.0.0/8 le 32
ip prefix-list PL-BOGONS seq 40 permit 100.64.0.0/10 le 32
ip prefix-list PL-BOGONS seq 50 permit 127.0.0.0/8 le 32
ip prefix-list PL-BOGONS seq 60 permit 169.254.0.0/16 le 32
ip prefix-list PL-BOGONS seq 70 permit 172.16.0.0/12 le 32
ip prefix-list PL-BOGONS seq 80 permit 192.168.0.0/16 le 32
ip prefix-list PL-BOGONS seq 90 permit 224.0.0.0/4 le 32
ip prefix-list PL-BOGONS seq 100 permit 240.0.0.0/4 le 32
ip prefix-list PL-BOGONS seq 200 permit 0.0.0.0/0 ge 25

A sintaxe é ip prefix-list NOME seq N permit|deny rede/tamanho [ge N] [le N]. Sem ge e le, só casa o prefixo exato. Com le 32, casa o prefixo e tudo que está dentro dele, até /32.

• PL-NOSSOS: o /24 exato, para o que vamos anunciar.
• PL-NOSSOS-MAIS: o /24 e qualquer pedaço dele, para recusar quem tentar anunciar o nosso bloco de volta para nós.
• PL-CLIENTE-64501: o único prefixo que o cliente pode anunciar. Num cliente com vários blocos, gere a lista a partir do IRR, como no post sobre bgpq4 e IRR.
• PL-BOGONS: a rota default (o 0.0.0.0/0 sem ge/le casa só ela), os blocos privados, CGNAT, loopback, link-local, multicast e reservados, e por fim tudo que é mais específico que /24 (ge 25), que a internet não propaga.

Passo 4: route-map de entrada e de saída no BGP no Cisco

O route-map é a peça central do BGP no Cisco. Cada entrada tem um número de sequência, uma ação (permit ou deny), condições match e ações set. A rota é testada de cima para baixo e para na primeira entrada que casar. Várias condições match na mesma entrada valem como E; entradas diferentes funcionam como OU.

Entrada do cliente

route-map RM-CLIENTE-IN permit 10
 match ip address prefix-list PL-CLIENTE-64501
 set local-preference 200
 set community 64500:100

Só o prefixo da lista entra. Ele ganha local-preference 200, maior que a de qualquer trânsito, porque rota de cliente é a que paga as contas e deve ser a preferida. A community 64500:100 marca a origem; é ela que o route-map de saída vai usar para decidir o que anunciar. O que o cliente mandar fora da lista cai no deny implícito.

Entrada dos trânsitos

route-map RM-TRANSITO-A-IN deny 10
 match ip address prefix-list PL-BOGONS
route-map RM-TRANSITO-A-IN deny 20
 match ip address prefix-list PL-NOSSOS-MAIS
route-map RM-TRANSITO-A-IN permit 30
 set local-preference 100
 set community 64500:200
route-map RM-TRANSITO-B-IN deny 10
 match ip address prefix-list PL-BOGONS
route-map RM-TRANSITO-B-IN deny 20
 match ip address prefix-list PL-NOSSOS-MAIS
route-map RM-TRANSITO-B-IN permit 30
 set local-preference 90
 set community 64500:200

Bogons e o nosso próprio bloco são negados primeiro. O resto entra com community 64500:200 (aprendido de trânsito) e uma local-preference: 100 no A e 90 no B. Como a local-preference maior vence, todo o tráfego de saída prefere o trânsito A, e o B fica de reserva para o mesmo destino.

Saída para os trânsitos

route-map RM-TRANSITO-A-OUT permit 10
 match ip address prefix-list PL-NOSSOS
route-map RM-TRANSITO-A-OUT permit 20
 match community CL-CLIENTES
route-map RM-TRANSITO-B-OUT permit 10
 match ip address prefix-list PL-NOSSOS
 set as-path prepend 64500 64500
route-map RM-TRANSITO-B-OUT permit 20
 match community CL-CLIENTES
 set as-path prepend 64500 64500

Para trânsito vão só duas coisas: o nosso bloco e as rotas marcadas como de cliente. Nada que veio de um trânsito pode sair para o outro, ou o AS64500 vira caminho entre eles: é o vazamento de rotas clássico. No trânsito B, o set as-path prepend repete o nosso ASN duas vezes, deixando o caminho por ele mais longo. Assim, o tráfego de entrada também tende a vir pelo A.

Communities no BGP no Cisco

ip bgp-community new-format
ip community-list standard CL-CLIENTES permit 64500:100

ip bgp-community new-format faz o roteador mostrar e aceitar communities no formato AA:NN (64500:100). Sem ele, algumas versões exibem o valor como um número de 32 bits, o que confunde a leitura. A ip community-list standard nomeada é o equivalente da prefix-list para communities, e é ela que o match community usa.

Substituir ou somar

O set community 64500:100 sem mais nada substitui todas as communities que vieram na rota. Na entrada do cliente isso é o que queremos: o cliente não consegue injetar uma community interna nossa. Se a ideia é manter o que veio e acrescentar a sua, use additive:

route-map RM-CLIENTE-IN permit 10
 set community 64500:100 additive

Esse formato faz sentido quando o cliente usa communities de ação que você documentou, como pedir prepend ou blackhole. O desenho completo de um sistema assim está no post de sistema de communities no Huawei; a lógica vale para o IOS-XE com outro vocabulário. Para blackhole, a prefix-list do cliente também precisa aceitar prefixos mais específicos do bloco dele.

send-community

O guia de configuração do IOS-XE 16.6 diz que, por padrão, o atributo COMMUNITIES não é enviado ao vizinho e que é preciso ligar o neighbor ... send-community. Não conte com o padrão da sua versão: configure de forma explícita onde a community deve sair e confira o que sai com show ip bgp neighbors. No nosso cenário, a marcação só é usada dentro do roteador e não precisa ir para os trânsitos. Para o cliente, ligamos send-community both (padrão e estendida) para ele ver as tags 64500:100 e 64500:200 e poder filtrar a tabela que recebe.

Passo 5: aplicar as políticas e o maximum-prefix

router bgp 64500
 address-family ipv4 unicast
  neighbor 198.51.100.1 route-map RM-TRANSITO-A-IN in
  neighbor 198.51.100.1 route-map RM-TRANSITO-A-OUT out
  neighbor 198.51.100.1 maximum-prefix 1500000 90 warning-only
  neighbor 198.51.100.5 route-map RM-TRANSITO-B-IN in
  neighbor 198.51.100.5 route-map RM-TRANSITO-B-OUT out
  neighbor 198.51.100.5 maximum-prefix 1500000 90 warning-only
  neighbor 198.51.100.9 route-map RM-CLIENTE-IN in
  neighbor 198.51.100.9 send-community both
  neighbor 198.51.100.9 maximum-prefix 10 80 restart 30
 exit-address-family

• route-map ... in e out amarram a política a cada vizinho, dentro da address-family.
• maximum-prefix 10 80 restart 30 no cliente: com 80% do limite, o roteador gera aviso; se passar de 10 prefixos, derruba a sessão e tenta de novo em 30 minutos. Protege contra o cliente que vaza uma tabela inteira para você.
• maximum-prefix 1500000 90 warning-only nos trânsitos: só avisa. Derrubar o trânsito por crescimento natural da tabela seria pior que o problema. Ajuste o número ao tamanho atual da tabela IPv4 com folga.

ipv6 prefix-list PL-NOSSOS-V6 seq 10 permit 2001:db8:100::/40
route-map RM-TRANSITO-A-V6-OUT permit 10
 match ipv6 address prefix-list PL-NOSSOS-V6
router bgp 64500
 address-family ipv6 unicast
  neighbor 2001:db8:ffa::1 route-map RM-TRANSITO-A-V6-OUT out
  neighbor 2001:db8:ffa::1 maximum-prefix 400000 90 warning-only
 exit-address-family

No IPv6, o BGP no Cisco segue a mesma estrutura: ipv6 prefix-list, match ipv6 address prefix-list e as políticas dentro da address-family ipv6 unicast. Para não alongar o exemplo, o bloco acima só mostra a saída. Em produção, o vizinho IPv6 precisa de um route-map de entrada com a mesma lógica da IPv4: negar bogons IPv6, o seu próprio /40 e mais específicos, e prefixos maiores que /48.

Como verificar o BGP no Cisco

show ip bgp summary
show bgp ipv6 unicast summary
show ip bgp neighbors 198.51.100.1 advertised-routes
show ip bgp community 64500:100
show ip bgp prefix-list PL-CLIENTE-64501
clear ip bgp 198.51.100.9 soft in

O resumo mostra o estado de cada sessão. Saída encurtada, com valores de exemplo:

BGP router identifier 203.0.113.1, local AS number 64500
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
198.51.100.1    4 64510  981233    1204   412877    0    0 2d03h  1012440
198.51.100.5    4 64511  975410    1199   412877    0    0 2d03h  1011987
198.51.100.9    4 64501    3301    3410   412877    0    0 2d01h        1

Na coluna State/PfxRcd, um número significa sessão estabelecida e quantos prefixos foram aceitos. Uma palavra (Idle, Active, Connect) significa que a sessão não está de pé. O cliente com 1 prefixo é o esperado.

   Network          Next Hop            Metric LocPrf Weight Path
*> 192.0.2.0        198.51.100.9              0    200      0 64501 i
*> 203.0.113.0      0.0.0.0                  0         32768 i
Total number of prefixes 2

O advertised-routes para o trânsito A é o teste mais importante do BGP no Cisco: devem aparecer só o nosso bloco e o do cliente. Se aparecer um prefixo de outro trânsito, a política de saída tem buraco. O show ip bgp community lista as rotas com aquela tag e o show ip bgp prefix-list mostra o que casa com uma lista.

Aplicar mudanças sem derrubar a sessão

Mudar um route-map não reprocessa as rotas que já estão na tabela. O clear ip bgp 198.51.100.9 soft in pede a tabela de novo ao vizinho (route refresh) e reaplica a política sem fechar a sessão. Se o vizinho não suportar route refresh, o soft-reconfiguration inbound guarda uma cópia do que ele mandou, ao custo de memória. Com o soft-reconfiguration ligado, o soft in usa essa cópia local em vez de pedir a tabela de novo:

router bgp 64500
 address-family ipv4 unicast
  neighbor 198.51.100.9 soft-reconfiguration inbound
 exit-address-family

Em vizinho com tabela completa, prefira o route refresh, que os roteadores atuais costumam suportar, e deixe o soft-reconfiguration para quem realmente precisa.

Erros comuns no BGP no Cisco

Os problemas abaixo aparecem em quase toda implantação, e quase todos se resolvem lendo o advertised-routes antes e depois de cada mudança.

• Route-map sem permit final. Tudo que não casou é negado. Num route-map de entrada de trânsito, esquecer a última entrada permit zera a tabela recebida.
• network sem rota igual na tabela. O prefixo não aparece no advertised-routes. Falta a rota para Null0 ou a máscara está diferente.
• Community setada e não enviada. Sem send-community configurado, o vizinho pode não receber a community, e a ação combinada com ele não acontece.
• Set sem additive apagando communities de ação. Se o cliente manda 64500:666 para blackhole e você faz set community 64500:100 sem additive, a de ação some.
• Mudança de política sem soft clear. A rota antiga continua até a próxima atualização. Parece que a configuração não funcionou.
• Filtro só por prefix-list estática. Combine com IRR e RPKI; o post sobre ROA no Registro.br mostra como proteger o seu próprio bloco.

O mesmo desenho em outros fabricantes

Para quem opera rede mista, a tabela abaixo é um mapa aproximado dos nomes do BGP no Cisco e dos equivalentes nos outros fabricantes. A sintaxe exata está em cada post da trilha e na documentação de cada fabricante.

Perguntas frequentes

Qual a diferença entre prefix-list e route-map no BGP no Cisco?

A prefix-list só descreve prefixos: diz se uma rota casa ou não. O route-map é a política: usa a prefix-list como condição e decide se a rota é aceita, negada ou alterada com local-preference, community ou prepend.

Por que usar no bgp default ipv4-unicast?

Sem ele, todo vizinho declarado passa a trocar IPv4 assim que a sessão sobe, inclusive os vizinhos IPv6. Com ele, cada vizinho só troca rotas nas famílias em que você deu activate, depois de o filtro estar pronto.

O IOS-XE envia communities por padrão?

O guia do IOS-XE 16.6 diz que não: sem neighbor ... send-community, o atributo não sai. Como o comportamento pode variar entre versões, configure send-community (ou both, para padrão e estendida) de forma explícita onde a community precisa sair e confira na sua versão.

Como fazer o tráfego de entrada preferir um trânsito?

O controle mais simples é o prepend no route-map de saída do trânsito que deve ser evitado. Muitos trânsitos também aceitam communities de ação para prepend ou para baixar a preferência; consulte a documentação do seu fornecedor.

Preciso derrubar a sessão depois de mudar um route-map no BGP no Cisco?

Não precisa derrubar. Use clear ip bgp VIZINHO soft in ou soft out para reaplicar a política sem fechar a sessão.

Conclusão

O BGP no Cisco IOS-XE se resume a três camadas: a prefix-list descreve, o route-map decide e a community marca. Com cliente acima de trânsito na local-preference, saída para trânsito só de rotas próprias e de cliente, bogons negados na entrada (em IPv4 e IPv6) e maximum-prefix em todo vizinho, a borda fica previsível.

Para fechar a proteção, gere as listas dos clientes com bgpq4 e IRR e publique ROAs para o seu bloco. Quem opera Huawei, Juniper ou Mikrotik junto com Cisco encontra o mesmo desenho nos outros posts da trilha.