Troubleshooting de Border Gateway Protocol (BGP)- Webcast FAQ

[toc:faq]


Introdução


   



Leonardo Furtado é Instrutor e Facilitador para o Cisco Learning Services (High-Touch Delivery Learning Services), onde atua pela Cisco lecionando treinamentos avançados de plataformas e arquiteturas Cisco de última geração. Possui formação em Ciência da Computação e 21 anos de experiência como Arquiteto de Soluções e Engenheiro de Redes em diversos segmentos de mercado e verticais tecnológicas, de routing & switching, wireless, segurança a colaboração, até Service Providers e Data Centers, sendo estes dois últimos seus segmentos de maior especialidade e interesse. Atuou por empresas com perfil de missão crítica por alta disponibilidade, resiliência e segurança, incluindo New York Stock Exchange (NYSE/Euronext), instituições financeiras e operadoras de telecomunicações. É um Certified Cisco Systems Instructor (CCSI)
Você pode fazer o download da  apresentação em formato PDF aqui. 




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

Histórico de versão
Revisão #
1 de 1
Última actualização:
‎05-15-2017 09:26 AM
Actualizado por:
 
Etiquetas (1)