Introdução
Troubleshooting de Border Gateway Protocol (BGP)
P: O State será sempre zero?
R: O state demostrando o número de prefixos enviados e recebidos está zero pois não foram recebidos e nem anunciados prefixos de rede.
P: Em muitos clientes que ja fiz consultoria os mesmos tem uma dificuldade muito grande para configuração correta dos Filtros de IN-OUT da sessão deles. e muitas vezes nem tem filtros. No seu ponto de vista, qual a melhor forma de realizar esses filtros? Pergunto pois utilizo Route-map / Prefix-list e queria saber se existir uma outra forma, se é melhor/pior ou se depende do cenario mesmo.
R: Dependendo do caso é possível utilizar Community Filters, que habilita políticas de roteamento a serem aplicadas para o destino.Pode-se criar communities de acordo com o tráfego que deseja-se anunciar para os peers ou usar algumas communities.
P: Em alguns casos em que aplicamos as configurações numa prefix-list para divulgar uma rede diretamente conectada. Essa rede só será divulgada para o vizinho após dar um shut e no shut na interface que a rede está conectada. Isso seria um bug?
R: Não necessariamente, pois a interface interna vai responder no dominio interno.
P: Por que o BGP depende de um protocolo de roteamento IGP para o seu correto funcionamento?
R: O BGP, ao contrário dos protocolos de roteamento IGP, não opera diretamente sobre as interfaces do roteador. Enquanto protocolos tais como o EIGRP e o OSPF são ativados exclusivamente sobre as interfaces físicas ou lógicas do roteador, as quais passam então a enviar e receber os PDUs associados ao protocolo para a manutenção de suas diversas funções (ex: Hello para descoberta de vizinhos e estabelecimento de adjacências, Updates para troca de informações sobre os prefixos de redes, etc.) e também fazendo com que as redes definidas nestas interfaces participem do IGP, o BGP por sua vez opera diretamente sobre o módulo de supervisão e controle do roteador (ex: Supervisor em um Cisco Catalyst 6500, RSP em um Cisco ASR 9000...). Sessões Internal Border Gateway Protocol (iBGP) e também External Border Gateway Protocol (eBGP) em cenário eBGP Multihop envolvem vizinhanças entre roteadores que não estejam diretamente conectados ou presentes na mesma subrede, e que o estabelecimento destas sessões deva ocorrer através de uma comunicação unicast usando uma conexão TCP entre os roteadores envolvidos. Sendo assim, a dependência do IGP para o funcionamento do BGP está centrada nos seguintes objetivos:
- O IGP deverá ser usado para transportar as sessões BGP. Ou seja, os roteadores participantes deverão possuir as devidas rotas IGP referentes aos seus respectivos endereços IP usados para o estabelecimento da sessão BGP entre si.
- O IGP deverá ser usado para a resolução do roteamento recursivo, basicamente a questão da conectividade IGP para o atributo NEXT_HOP contido nos anúncios recebidos pelo roteador. Para exemplificar, cada prefixo de rede aprendido por BGP acompanha atributos dentre os quais os do tipo “Conhecido Mandatório” (Well-Known Mandatory), tais como AS_PATH, ORIGIN e NEXT_HOP. Para que um prefixo possa ser considerado como válido na tabela BGP de um roteador, é necessário, dentre algumas exigências, a resolução do roteamento recursivo referente ao atributo NEXT_HOP associado ao prefixo, quando este é recebido e consequentemente instalado na tabela BGP: o roteador deverá possuir uma rota IGP em sua tabela de roteamento que permita a conectividade para o endereço IP especificado pelo atributo NEXT_HOP, sendo que uma rota default (0.0.0.0/0) não pode ser usada para este procedimento, apenas rotas mais específicas que a rota default.
Informação relacionada