Minha jornada até o CCIE RS — BGP
Continuo esta série de artigos compartilhando todas as minhas anotações acumuladas durante anos de trabalho e estudos até passar no lab de CCIE RS. Foram quase 400 páginas de cadernos acumuladas com informações e observações que considero importantes ao trabalhar com Routing and Switching por quase 15 anos.
Acredito que estas informações possam ajudar mais do que passar em certificações, mas no dia-a-dia de outras pessoas como eu ao lidar com infraestrutura Cisco.
Para quem não leu os artigos anteriores, seguem os links sobre “Switching”, “PPP”, “IP Routing”, “RIP”, “EIGRP”, “OSPF” e “Redistribuição”. Abaixo segue a parte sobre BGP.
Fique a vontade para comentar e entrar em contato comigo no LinkedIn. Se gostou do que leu, incentivo a compartilhar com colegas do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow lá em cima :)
BGP
Protocolo de roteamento Open Standard definido na RFC 4271 “A Border Gateway Protocol 4 (BGP-4)”. A melhor fonte de informação low-level que podemos achar.
- Protocolo path vector classless implementado com foco em política de roteamento.
- Utiliza múltiplos atributos de um prefixo para decisões de roteamento.
- Obviamente suporta VLSM e sumarização.
- Extremamente flexível, onde há dezenas de formas de conseguir o mesmo objetivo.
- BGP é estensível a outros protocolos além de IPv4:
- — Multicast
- — IPv6
- — MPLS
- — etc.
Números dos ASs são alocados pelo Internet Assigned Numbers Authority (IANA).
BGP funciona sobre TCP e portanto depende diretamente de IGP. Na prática, BGP não é um protocolo de roteamento, mas sim uma aplicação com 2 funções: anunciar (1) prefixos e (2) next-hops para estes prefixos.
DOC Cisco:
Sistema de notação 4 bytes
Originalmente usava 2 bytes para AS (0 — 65635)
- AS públicos 1 — 64511
- AS privados 64512 — 65535
Nos últimos anos todos os AS migraram para um sistema de 4 bytes para o campo de AS de acordo com a RFC 4893 “BGP Support for Four-octet AS Number Space”.
Com 4 bytes usa denotação 0.0–65535.65535 (ASdot-notation).
Novos speakers (4 bytes) requerem compatibilidade com antigos speakers (2 bytes) e portanto o novo sistema suporta negociação durante a troca de capacidades.
Speakers antigos que não suportam 4 bytes, codificam todos os ASs de 4 bytes como “23456” (0x5BA0).
BGP Peerings
Principais diferenças do BGP:
- BGP não tem seu próprio protocolo de transporte. Roda sobre TCP e, portanto, depende da conectividade através de IGP.
- BGP tem diferentes tipos de neighbors (iBGP, eBGP, confed, etc).
- Neighbors não são descobertos dinamicamente.
- Neighbors não precisam estar diretamente conectados porque a comunicação é sobre TCP 179.
A declaração do neighbor informa ao processo para escutar conexões na porta TCP 179, além de iniciar sessão para endereço remoto na TCP 179. Em caso de colisão, o router-id mais baixo será o TCP server.
Uma vez estabelecida a adjacência, o BGP se comporta como uma aplicação server-client. O client envia tráfego para TCP 179 utilizando porta TCP randômica como origem, enquanto o server responde para a TCP randômica a partir da TCP 179.
Updates e regras para seleção de caminho mudam dependendo do tipo de peer que uma rota está sendo recebida ou enviada.
Regras de paridade EBGP
Pacotes eBGP usam TTL 1 por default implicando que os neighbors devem estar logicamente diretamente conectados.
Prevenção de loops ocorre através do AS-PATH onde o AS é adicionado ao atributo AS-PATH do prefixo e todos os updates entrantes contendo o AS local são descartados (porque representa a ocorrência de loop).
Atualização EBGP tem next-hop ajustado para o update-source do router local (ex: loopback 0). Este comportamento pode ser alterado através de third party next-hop, geralmente separando o control-plane do data-plane.
Regras de paridade iBGP
Pacotes iBGP usam TTL 255 por default, o que implica que os neighbors não precisam esta diretamente conectados desde que haja conectividade.
Baseado no comportamento “next-hop” do iBGP, há uma desconectividade entre o control-plane e o data-plane, permitindo uma maior flexibilidade na criação das políticas.
Prevenção de loops no iBGP se baseia no fato de que rotas aprendidas via iBGP não são propagadas para outros neighbors iBGP. Este comportamento padrão exige que a topologia iBGP utilize full-mesh (não escala), route reflection ou confederation.
Updates iBGP não modificam o next-hop, independente do tipo de peer iBGP. Na maioria das vezes esse comportamento é uma vantagem para o BGP porque desconectando o control-plane do data-plane permite que o tráfego siga o melhor caminho até o ponto de saída (next-hop EBGP).
BGP Server deve concordar com o endereço na sessão vinda do Client. Por default, o pacote do cliente é originado da interface de saída na tabela de roteamento.
Speakers que não suportam o novo sistema de notação 4 bytes utilizam o valor “23456”, porém a informação original ASdot é preservada no prefixo (mesmo quando propagada por speakers que não suportam… pelo menos speakers Cisco).
OBS: Pode-se testar se o BGP Server está habilitado através de telnet na 179. Se retornar “open” está OK e se retornar “refused” não está habilitado. Debug mostra “ACK RST”.
Por default, neighbors EBGP precisam estar em redes diretamente conectas ou nem enviam SYN packets. Pode-se desabilitar com “disable-connected-check”.
Os timers utilizados no BGP são os timers mais baixos entre os valores negociados entre os neighbors.
OBS: Melhor maneira de configurar BGP é copiando e colando no bloco de notas evitando esquecer qualquer comando.
OBS: Um bom modo de analisar o comportamento do BGP é criar uma ACL bloqueando IGP e permitindo todo o resto (debug ip packet ACL + debug ip bgp).
A sincronização do BGP pode demorar e levar vários minutos.
Next-hop
Não importa como seja, desde que os peers tenham rota para o next-hop. As duas opções são:
- fornecer rota para o next-hop (redistribuindo, IGP, etc) ou
- alterar o next-hop para um endereço conhecido (next-hop-self, route-map)
Uma maneira de adicionar conectividade fim-a-fim ao BGP é criar IP SLA monitorando conectividade ou qualidade da conexão, utilizar este tracking em um placeholder e divulgar este placeholder como next-hop no BGP.
- IP SLA -> Tracking -> Placeholder -> redistribuição static no IGP
- No BGP, route-map “set next-hop placeholder”
OBS: É interessante usar placeholder com um endereço IP link-local (ex: 169.254.0.1) porque eles não são divulgados globalmente.
Larga Escala
A escolha de um cenário em larga-escala usando full-mesh, Route-reflection ou Confederation deve balancear entre o total de informação trocada e a quantidade de caminhos na rede a escolher. Como o BGP só divulga o bestpath, quanto mais filtros, menos inteligente é a decisão.
Route Reflection
Por default, BGP admite full mesh de todos os iBGP peers e a replicação de informação para todos.
Route Reflection minimiza a troca de informações de roteamento admitindo um dispositivo central que conecta com os demais (assim como OSPF DR e IS-IS DIS). Isto elimina a necessidade de full mesh e diminui drasticamente a replicação de informações porque os clients só se comunicam com o route-reflector (RR).
Para prevenção de loop, o route reflector adiciona seu cluster-id no atributo cluster-list ao encaminhar o prefixo para qualquer peer. Obviamente o RR descarta qualquer rota recebida que tenha seu cluster-id na cluster-list. Os demais atributos não são modificados durante a propagação.
RR processa os updates de forma diferente dependendo de quem recebe:
- recebida de EBGP — propaga para EBGP, clients e não clients
- recebida de client — propaga para EBGP, clients e não clients
- recebida de não-client — propaga para EBGP e clients
RR em Larga Escala
Designs em larga escala com BGP não podem ter apenas um RR por questão de redundância (se parar o RR, para tudo). Utilizar múltiplos clusters de RR permite redundância e hierarquia.
O cluster é definido pelos clients que um RR serve e RRs no mesmo cluster usam o mesmo cluster-id.
A comunicação inter-cluster entre RR pode ser client ou não client, dependendo do design da redundância.
Todos os peers de um peer-group compartilham da mesma política de atributos e portanto o router só realiza um processamento antes de replicar aos peers (Isto se torna mais claro quando temos milhões de caminhos na tabela do BGP).
Um cluster é definido pelos clients e pelo Cluster-ID (que os RR estão usando).
DOC: “BGP Case Studies” mostra exemplos complexos de RR.
Confederation
Confederation reduz a necessidade de full-mesh iBGP quebrando o AS em Sub-ASs.
- Dentro de cada Sub-ASs permanece o comportamento iBGP com necessidade de full mesh ou RR.
- Entre os Sub-ASs atua o comportamento EBGP (Confed EBGP peers).
Speakers fora da confederation não tem conhecimento da estrutura interna porque os sub-ASs são retirados dos updates quando estes são propagados para os EBGPS peers fora do AS (fora da confed).
Como a estrutura interna não é propagada para outros ASs, os sub-ASs geralmente usam números privados (64512–65535, últimos 1024). Isto evita que um número de AS real (ex: 100) vaze para outros ASs e estes encaminhem o tráfego destinado para este AS.
- Obviamente se um número privado vaza, ele não deveria ser utilizado.
- Além disso, se um Sub-AS usar um número real, ele irá negar rotas com este AS no AS-PATH.
DOC: “BGP Case Studies” mostra exemplos legais de confed.
Network Layer Reachability Information (NLRI)
NLRI pode ser originada através de :
- Network — declaração da rede requer a match na RIB
- Redistribuição — por default, não redistribui OSPF EX.
- Aggregate — requer pelo menos uma subrede do aggregate na tebela BGP. Possuem diversas opções complementares.
- BGP conditional route injection — é o oposto de aggregate, divulgando subredes (prefixos mais longos) e geralmente utilizado para Traffic Engineering.
Na maioria dos designs é comum os EDGE routers originarem os prefixos no lugar da rede interna, visto que estes routers possuem conectividade interna via IGP.
Novamente, o BGP confia no IGP para realizar recursividade do next-hop e definir a interface de saída.
Declaração network:
- Origina um prefixo com ORIGIN IGP (i)
- Requer um match exato (prefixo e tamanho) na RIB
- É necessário especificar a mask ou assume rede classful por default
Prefixos redistribuídos:
- Utilizam ORIGIN INCOMPLETE (?)
- Rotas OSPF externas não são redistribuídas por default
- Herdam a métrica IGP do prefixo redistribuído (MED é um atributo não transitivo)
OBS: Lembrar que redistribuições são a partir da tabela de roteamento e não da base de dados do protocolo redistribuído.
OBS: Configurações no BGP geralmente são muito repetitivas, por isso é mais fácil aprender a trabalhar no notepad.
Aggregation
Aggregation no BGP é muito mais flexível que nos IGP porque possui muito mais opções e controle.
Pode ser aplicada em qualquer ponto da rede desde que exista pelo menos uma subrede na tabela BGP.
Por default, uma aggregation herda os atributos das subredes, porém se houver subredes com diferentes atributos não há modo de herdar corretamente.
Recebe o atributo ATOMIC-AGGREGATE e o router-id de quem agregou.
Geralmente o objetivo do aggregation é diminuir a tabela BGP, portanto não faz sentido divulgar o resumo + subredes.
Aggregate também gera discard-route.
Alterando Atributos
Ao alterar atributos de um bundle ou filtrar, deve-se escolher a opção para satisfazer o match na menor quantidade (pela lei do menor esforço):
- Se a minoria das rotas deve ser suprimida, usamos o suppress-map
- Se a minoria deve ser propagada, usamos o unsuppress-map
Tanto durante a declaração quanto na propagação (IN ou OUT) podemos alterar os atributos do BGP via route-map ou attribute-map (funcionalidade anterior ao route-map).
Uma situação para alterar atributos diretamente na declaração é alterar communities (ex: ajustar no-export para o prefixo não sair do AS).
OBS: A função do prefix-list é fazer o match (sempre é). Cabe ao route-map realizar o deny ou permit baseado no match. Se o prefix-list dá deny significa que não dá match e não que negou alguma coisa.
Para manipular e alterar parte de um AS-SET devemos usar AS SET + advertise-map para alterá-lo.
Conditional Route Injection
A partir de um prefixo mais curto, origina subredes (prefixo mais longos) com objetivo de realizar Traffic Engineering.
É necessário que um prefixo mais longo esteja na tabela de roteamento (exatamente o oposto do aggregation).
Best Path Selection
É o algoritmo do BGP que decide quais rotas são candidatas a serem instaladas na RIB/FIB e quais serão propagadas para outros peers BGP.
No geral, o algoritmo de path selection é padronizado na RFC 4271 seção 9.1 “Decision Process”, mas cada fornecedor pode implementar particularidades.
OBS: Mesmo com múltiplos caminhos na RIB, o BGP só propaga o best path. Portanto, o algoritmo decide quais saídas os roteadores internos irão conhecer dependendo da topologia utilizada (full mesh, RR ou Confed).
DOC: IP Routing -> Troubleshooting Technotes -> Best Path Selection Algorithm (Isto não ficava disponível para consulta durante o lab).
Requisitos
- O next-hop deve estar na tabela de roteamento, evitando blackholes na topologia por falha de recursividade da rota.
- Sincronização deve ser obedecida ou desabilitada (se trata de um mecanismo antigo de prevenção de black-holes). Antigamente os edge routers se comunicavam via iBGP e redistribuíam as rotas no IGP porque a maior parte dos routers internos não tinha recursos para rodar uma tabela completa de BGP.
- AS-path não pode conter o AS local devido a prevenção de loop.
- Por default, o primeiro AS do AS path deve ser o AS do peer EBGP.
Ordem de Seleção
- Weight
- Local-preference — melhor opção para influenciar tráfego OUT
- Locally originated
- AS-path
- Origin
- MED
- EBGP sobre iBGP
- Métrica IGP para o next-hop
- Tie brakers
- — Oldest
- — Lowest RID
- — Shortest cluster list
- — Lowest neighbor address
BGP foi desenvolvido para trabalhar de forma determinística porém há momentos que ele estabiliza de maneira não determinística, chamado BGP wedgies descritos na RFC 4264.
Manipulando o Bestpath
Política de roteamento outbound afeta o tráfego inbound enquanto política de roteamento inbound afeta tráfego outbound.
- Weight e local-pref são ajustadas inbound para afetar o tráfego outbound.
- AS-path e MED são ajustado outbound para influenciar o tráfego inbound.
Pela própria ordem de prioridade dos atributos, é muito mais fácil manipular o tráfego Outbound do que o Inbound. Muito difícil influenciar ou mesmo prever tráfego Inbound.
OBS: BGP Looking Glass e Route-Servers são os melhores lugares para testar expressões regulares e políticas.
O uso de communities é uma prática comum na Internet para influenciar como o tráfego deve retornar ao AS.
É padrão da indústria os ISP receberem communities ASN:90, 80 ou 70 e ajustarem este valor com o local-pref para este prefixo. Esta prática é muito comum porque Local Pref é o método mais recomendado para controlar tráfego OUT nos ISPs.
MED só é comparado se os caminhos vierem do mesmo AS. Porém os ISPs geralmente não levam em conta o MED (por falta de padrão) e zeram ele na entrada.
MED default é NULL mas cada fabricante define NULL como sendo valor máximo ou mínimo (por isso é interessante ajustar na mão).
Communities
Communities são basicamente tags e são usadas para agrupar prefixos para:
- política de filtros
- política de propagação
- política de seleção de melhor caminho
Community é um atributo transitivo opcional e portanto não é trocado entre os peers por default.
Standard Community usa valor de 4 bytes denotado por decimal (0 — 4294967296) e AA:NN (0:0 — 65535:65535) sendo os mesmos valores binários mudando apenas o formato de visualização.
Well-Know Communities
- No-Export — (0xFFFFFF01) — não propagada para peers EBGP (não incluindo Confed).
- No-Advertise — (0XFFFFFF02) — não propaga para qualquer peer.
- Local-AS — (OxFFFFFF03) — não propaga para qualquer peer EBGP (incluindo Confed) em alguns lugares definidos como NO_EXPORT_SUBCONFED.
OBS: Se não há uso de Confed, No-ex e Local-as funcionam da mesma forma.
Communities são ajustadas diretamente via route-map. Porém o match é realizado indiretamente através de community-lists.
OBS: O route-map faz match no nome da community-list e não no valor da community. Sempre use nomes fáceis de distinguir.
É uma best-practice habilitar o uso de communities. Elas precisam ser habilitadas individualmente para cada peer.
Expressões regulares
Derivadas de expressões regulares open source, as regexp no IOS são utilizadas principalmente para:
- Saídas dos comandos show
- Scripts TCL/EEM
- Listas de Community expanded para BGP
- Listas de acesso AS-path para BGP
DOC: Terminal Services Configuration Guide -> Regular Expressions
OBS: Ao realizar matches com regexp é mais fácil utilizar múltiplas linhas simples do que uma regexp complexa.
BGP Filtering
Filtros de updates do BGP ocorrem por peer através de:
- distribute-list
- filter-list
- prefix-list
- route-map
Durante os filtros, é uma best-practice usar route-maps porque permite controlar a ordem exata das operações, evitando problemas.
Convergência
No BGP são utilizados os menores tempos entre aqueles negociados durante o estabelecimento da adjacência.
Tempo de convergência do BGP é muito lento porque roda sobre TCP. Neste caso o modo mais rápido de detectar uma falha no link é monitorar L2 fim-a-fim, porque em ambiente ehternet a queda de um segmento não é detectada pelos outros.
DOC: Blog INE -> Understanding BGP Convergence
LIVRO: Cisco Press -> Optimal Routing Design
Default Routing
As opções para usar default routing são:
- default-information originate + redistribute — durante processo de redistribuição, rota default só é redistribuída se default-information estiver habilitado.
- network 0.0.0.0 mask 0.0.0.0 — requer uma rota default IGP
- neighbor default-originate — suporta “conditional advertisement”
Comandos Show para BGP
sh bgp sum
sh bgp nei
sh bgp nei x.x.x.x
sh bgp nei x.x.x.x adv
sh bgp nei x.x.x.x routes
sh bgp nei x.x.x.x received-routes
clear ip bgp nei x.x.x.x in|out
clear ip bgp * soft
sh ip bgp peer-group
sh ip bgp update-group
sh ip bgp repl
sh ip bgp rege ^$ (regexp)
sh ip bgp
sh ip bgp x.x.x.x
sh ip route x.x.x.x
sh ip cef x.x.x.x
sh ip cef x.x.x.x internal
sh ip bgp rib
sh ip bgp inject
sh ip bgp dampening parameters
sh ip bgp dampening dampened-paths
Esse artigo sobre BGP te ajudará no dia-a-dia?
Faltou algum ponto importante?
Fala pra gente nos comentários?
Se gostou do conteúdo, peço para compartilhar com outros do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow aí embaixo :)
Sobre o autor:
Giuliano Barros é Network Consultant & Founder da Control Plane — Network Services.
Graduado em Ciência da Computação, certificado CCIE RS pela Cisco Systems e trabalha há 15 anos como Network Engineer em projetos para grandes e médias empresas. linkedin.com/in/giulianobarros
