BGP - Parte Capítulo 3 (Entendendo Redes TCP/IP com MikroTik - Teoria e prática)

 

Atributos do BGP

Seguindo a RFC 4271, o BGP utiliza atributos como base para escolha do melhor caminho para chegar a uma determinada rede. Os atributos do BGP estão caracterizados na Tabela 3.1:

Tabela 3.1 – Classificação dos atributos utilizados no BGP

Classificação	Significado
Conhecido obrigatório  (Well-know Mandatory)	Todos os fabricantes devem reconhecer e disponibilizar este tipo de atributo dentro de sua implementação BGP. Caso não esteja em uma mensagem UPDATE, será exibida uma mensagem tipo NOTIFICATION para informar o erro.
Conhecido arbitrário  (Well-known Discretionary)	Não é obrigatório mas deve ser reconhecido em todas as implementações de BGP. Por exemplo o LOCAL_PREF como um atributo deste tipo.
Opcional e transitivo  (Optional Transitive)	Não é requisito técnico obrigatório/arbitrário. Assim ele deve ser aceito e repassado aos demais peers BGP.

 

Na Tabela 3.2 apresentamos alguns atributos juntamente com sua categoria e RFC que os descreve:

Tabela 3.2 – Apresentação de atributos utilizados no BGP

Atributo	Tipo	RFC
ORIGIN	Conhecido obrigatório	1771
AS_PATH	Conhecido obrigatório	1771
NEXT_HOP	Conhecido obrigatório	1771
MULTI_EXIT_DISC (MED)	Opcional intransitivo	1771
LOCAL_PREF	Conhecido arbitrário	1771
ATOMIC_AGGREGATE	Conhecido arbitrário	1771
AGGREGATOR	Opcional transitivo	1771
COMMUNITY	Opcional transitivo	1997
ORIGINATOR_ID	Opcional intransitivo	1966
Cluster List	Opcional intransitivo	1966
Multiprotocol Reachable NLRI	Opcional intransitive	2283
Multiprotocol Unreachable NLRI	Opcional intransitive	2283

 

Usaremos a Tabela 3.3 para definir os atributos que mais são usados.

Tabela 3.3 – Definição dos atributos mais utilizados no BGP

Atributo	Definição
ORIGIN	Usado para definir a origem do anúncio, pode ser exibido de três formas: ·         i (iGP): de origem interna;               ·         e (eGP): de origem externa, aprendida via eGP; ·         ? (Incompleto): a origem foi feita pela redistribuição de rotas ou por meios desconhecidos.
AS_PATH	É um mapeamento da sequência de ASs para alcançar um destino. Quando um anuncio transita em um peer, sua informação é incluída junto com seu número.
NEXT_HOP	É o próximo salto. Um roteador ao fazer o anúncio de um prefixo, usa a informação do seu próprio IP (exceto em sessões iBGP) como o NEXT_HOP.
LOCAL_PREF	Sua informação não é repassada (do tipo conhecido arbitrário) a seus vizinhos (peers). É usado para determinar qual o caminho preferencialmente selecionado para a saída (de um AS). Quanto maior seu valor, maior será a preferência.
WEIGHT	Também do tipo conhecido arbitrário. Quanto maior seu valor, maior será a preferência.

 

Funcionamento do algoritmo de decisão

Com os valores dos atributos de cada anúncio, que o processo de decisão do BGP determina qual opção acatar. Muito requisitado em sistemas Multi-home (conexão com mais de um AS, mais adiante veremos detalhadamente), que tem mais de um caminho de saída e entrada de rotas. Normalmente existirão múltiplas rotas para o mesmo destino, por isso surge a necessidade do algoritmo de decisão do protocolo BGP, que tem o objetivo de selecionar o melhor caminho entre todos disponíveis para o destino desejado. Na lista a seguir temos os critérios de decisão exibidos por ordem de prioridade:

·         Maior WEIGHT (default = 0);

·         Maior LOCAL-PREFERENCE (default = 100);

·         Menor AS-Path;

·         Originada localmente por agregação de rota ou por anúncio do próprio BGP;

·         Menor ORIGIN (iGP< eGP< Incomplete);

·         Menor MED (default = 0);

·         Aprendidas por eBGP do que por IBGP;

·         Menor Router ID;

·         Lista de Cluster de refletor de rotas (default = 0), e por último;

·         Que vem do vizinho com menor endereço IP. Se o next-hop não for alcançável, a rota é ignorada.

Assim, os anúncios são incluídos na tabela BGP e, baseado nestes critérios, é escolhido o melhor caminho (registrado na FIB).

Tipos de mensagem BGP

São quatro:

·         OPEN – Estabelece uma relação de vizinhança e troca de parâmetros básicos;

·         KEEPALIVE – Mantém a conexão e verifica se o roteador da outra ponta está funcionando, por padrão são enviadas a cada 60 segundos e se o roteador da outra ponta não responder em no máximo 180 segundos ele é considerado como fora de alcance;

·         UPDATE – Envia informações de roteamento;

·         NOTIFICATION – Utilizada quando ocorre um erro. Anula a relação de vizinhança entre roteadores.

Estados de conexão BGP

Dentro do que é demonstrado na RFC 4271 na seção 8, concluímos que a negociação de uma sessão BGP tem alguns estados até seja estabelecida e iniciada a troca de anúncios entre os vizinhos BGP. Na lista a seguir apresentamos os 6 (seis) estados possíveis, da chamada máquina de estados finitos do BGP:

·         idle – Indica o primeiro estágio. O protocolo está à espera de uma conexão;

·         connect – O BGP aguarda pela conexão TCP na porta 179. Uma mensagem OPEN é recebida assim que a conexão estiver estabelecida, passa-se então ao estado de opensent. O estado é alterado para active caso a conexão TCP não for bem-sucedida. E logo em seguida para connect se o tempo de espera espirar. Retornando para idle caso a tentativa for malsucedida;

·         active – Tentar estabelecer uma comunicação BGP, e for bem-sucedida assume-se o estado opensent. Mas, por expiração do tempo, o estado passa a ser connect. Retornando para idle caso ocorra uma intervenção do administrador;

·         opensent – O BGP está a esperar uma mensagem OPEN. Uma NOTIFICATION será enviada caso seja encontrado algum erro e volta-se ao estado de idle. Sem erros na checagem, inicia-se o envio de mensagens KEEPALIVE. Mas se houver alguma desconexão TCP, o estado passa para active. Retornando para idle caso ocorra uma intervenção do administrador;

·         openconfirm – O BGP espera pela mensagem de KEEPALIVE e, assim que recebida, o estado muda para established e a negociação do peer é finalmente completa. Caso ocorra algum erro, será enviada uma mensagem NOTIFICATION, e retornará para o estado de idle;

·         established – Está tudo em ordem, o BGP já pode trocar as mensagens UPDATE ou KEEPALIVE. Mas ao receber alguma mensagem tipo NOTIFICATION, o estado será alterado para idle.

Na Figura 3.41 trazemos a nossa representação gráfica da máquina de estados finitos. Por intermédio dela é possível entender o estado atual e identificar problemas que possam estar ocorrendo em uma sessão BGP.

Figura 3.41 – Máquina de estados finitos para sessões BGP, RFC 4271.

O estado established, é o estado desejado em uma sessão BGP pois somente estando nele ocorre a troca de anúncios com o roteador vizinho.

Quando existe mudanças do estado de connect e active, normalmente refletem problemas com as conexões TCP.