MED aplicado no ASR9000

[julio augusto alcantara araujo]

Caros, bom dia.

Atualmente trabalho com route-policy na execução dos meus BGP, mas estou tendo alguns problemas, sempre que metade desses links caem eu tenho impacto no gráfico de tráfego consolidado, mesmo que os links restantes sejam o suficiente para suportar o tráfego restante.

Minha route-policy é executada da seguinte forma, primeiro chama a prefix de rotas específicas sem MED específico, apenas com os atributos internos, depois eu devo chamar uma regra de rotas sumarizadas com um MED 100, e por último para garantir que mesmo com vários links fora eu não deixe de navegar eu chamo a terceira regra que diz que todos os blocos sumarizados da minha cidade devem navegar, neste eu coloco MED 200, pois em último caso será utilizado, caso caia os links por onde os específicos destes sumarizados navegam.

Assim sendo gostaria de saber primeiramente se existe um erro na aplicação abaixo? Lembrando que a forma que está aplicada na minha infraestrutura é do modo abaixo:

!
route-policy ANNOUNCE-PP-SP-CID-IP-00251
if destination in EBT-PBA-IP-00251 then
set community xxxx:y
pass
endif
if destination in REDES-SUMARIZADAS then
set community xxxx:yz
set med 200
pass
endif
if destination in REDE-SUMARIZADA-COM-PRIORIDADE-LINK-SP-CID-IP-00251 then
set community xxxx:yz
set med 100
pass
endif
end-policy
!

E a forma que eu suspeito estar mais correta que a minha, e ai minha dúvida disso estar gerando um impacto na convergência ou não é a forma abaixo:

!
route-policy ANNOUNCE-PP-SP-CID-IP-00251
if destination in EBT-PBA-IP-00251 then
set community xxxx:y
pass
endif
if destination in REDE-SUMARIZADA-COM-PRIORIDADE-LINK-SP-CID-IP-00251 then
set community xxxx:yz
set med 100
pass
endif
if destination in REDES-SUMARIZADAS then
set community xxxx:yz
set med 200
pass
endif
end-policy
!

Parece ser um erro ou de configuração ou de convergência no ASR9000, poderiam me auxiliar nesta dúvida?

Desde já, obrigado.

[lfurtado]

Olá Julio, tudo bem?

Não sei se você já conseguiu identificar o que estava provocando o cenário de convergência (indesejada), conforme indicado em sua publicação original. Todavia, permita-me fazer algumas observações.

Como você deve saber, políticas de roteamento tem como propostas a resolução de duas macro condições:

- Filtrar o envio ou o recebimento de prefixos para peers EBGP específicos. Ou seja, quais prefixos você quer anunciar para um determinado peer. O mesmo é válido no que tange ao recebimento de rotas (quais prefixos receber e de quais peers).

- Manipular atributos atrelados aos prefixos para influenciar o processo de seleção de rotas; consequentemente distribuir o tráfego de entrada e/ou saída em conformidade com o seu interesse e em função de objetivos específicos (uso de enlaces de trânsito sob determinadas circunstâncias, peering, condição financeira, acordos para troca de tráfego, etc.). Ex: influenciar o tráfego de saída (upload) por meios de WEIGHT (que não é exatamente um atributo), LOCAL_PREF, receber prefixos mais específicos vs. menos específicos; ou influenciar o tráfego de entrada (download) por meios de anúncios de prefixos mais específicos vs. menos específicos, usar o AS_PATH prepending, MED. Ou ainda, em combinação com estes cenários de IN/OUT, incluir communities para facilitar o tratamento destes prefixos no seu AS ou no AS vizinho.

Para que possa ser bem efetiva, a política de roteamento precisa ser desenhada em cumprimento ao que você compreende da sua própria infraestrutura e geralmente após ter confirmado quais conversações são registradas sobre quais enlaces, até mesmo para você compreender e antecipar quais ações seriam necessárias (a elaboração de políticas e suas respectivas regras) para manipular o tráfego da forma desejada. Isto tanto para o tráfego de upload quanto o de download.

Não sei como você projetou esta sua política, por exemplo, com o auxílio de alguma ferramenta de análise e bilhetagem de tráfego? Porque muitas das vezes a configuração da política de roteamento está correta no ponto de vista de sintaxe (CLI), mas ao mesmo tempo potencialmente disforme da matriz de tráfego registrada na sua rede. Estou apenas levantando esta questão, pois o seu post não esclarece os critérios.

Outro ponto é: em qual sentido você aplicou a referida route-policy, no inbound ou outbound?

O MED é utilizado para influenciar o tráfego de entrada, especificamente como o seu AS vizinho deverá encaminhar o tráfego para o seu AS. O MED não é repassado para os ASs além do seu AS vizinho, o que fatalmente em muitos casos afeta os seus planos de distribuição de tráfego entrante.

Caso queira continuar com este diálogo aqui, permita-me saber!

Cordialmente,

Leonardo Furtado

[lfurtado]

Algumas pequenas observações aqui:

- A partir do momento em que você aplica uma ação após o match na condição “if” (por exemplo, set community), o prefixo já passará a ser aceito, sendo dispensável uma segunda ação do tipo “pass”. O “pass” neste caso aí seria considerado redundante, haja vista que o próprio “set” já aceita a rota e realiza a modificação do atributo mencionado.

- Em plataformas IOS, o MED default é zero (o que já significa ser o “melhor”). Exceto se no roteador do AS vizinho houver a configuração de “bgp bestpath med missing-as-worst” onde, neste caso, a ausência de um MED ou um MED zero seria considerado como o "pior" (worst). Em plataformas IOS XR, o MED não é enviado automaticamente. Se no roteador do AS vizinho não houver um “missing-as-worst”, o MED aquele anúncio será considerado o melhor.

- Caso os seus enlaces sejam recebidos por ASs distintos, o MED não será efetivo. Neste caso, seria exigido uma coordenação com estes AS sobre um cenário “bgp always-compare-med”, nada muito trivial em termos de resultados.

- O MED é considerado um atributo um tanto “fraco” na questão de seleção da melhor rota, e só é funcional na prática quando há dois ou mais enlaces para um mesmo AS vizinho, e obviamente com a proposta de influenciar o tráfego entrante no seu próprio AS. O MED não é propagado para fora do seu AS vizinho, ou seja, o seu AS vizinho não faz o repasse automático do MED que você atrelou aos seus prefixos em seus anúncios para outros AS, portanto você influencia de forma muito branda como o tráfego de ASs mais distantes chega até ao seu AS. Usando ferramentas específicas talvez você detecte isto, daí usar uma solução envolvendo alternância de anúncios de prefixos mais específicos/menos específicos sobre os enlaces, caso a caso, seja mais efetivo. Ou então fazer o AS_PATH Prepending, que costuma ser bem mais efetivo que usar o MED para este propósito.

Cordialmente,

Leonardo Furtado