[GTER] Hold Time - BGP

[Douglas Fischer]

Exato!

E ou outro problema que pode acontecer reduzindo excessivamente os
timeoutse o Flap
ing.
Que na minha experiência é a pior coisa que pode acontecer para qualquer
sistema de alta disponibilidade.


- Digamos que você reduza ao máximo o timeout da sessão BGP.
- E aconteça algum problema no caminho de camada 1e2 com o link do seu
upstream, e ele tenha que chavear para um caminho de camada 1e2 secundário.
- Mas os protocolo que ele usou para fazer esse chaveamento não é dos
melhores, e leva muito tempo para chavear.

O que vai acontecer? Tua sessão BGP vai cair(CPU lá no alto), e logo em
seguida tua sessão BGP vai voltar(CPU lá no alto, denovo).


Se me lembro bem, um dos teus Upstreams aí é Embratel, e se não me
enganomais ainda
é Rádio né?
Então esse lance do chaveamento L2 é bem tenso...


Eu sou daqueles que preferem manter esse tipo de configuração no Default.


Em 15 de março de 2013 03:29, Rubens Kuhl <rubensk at gmail.com> escreveu:

> ,
>
> >
> > Recentemente montei uma redundância de rotas usando o BGP e gostaria de
> > saber um pouco da experiência de vocês com relação ao parâmetro Hold
> Time.
> > Não sei se é o mesmo nome para cisco mas no mikrotik este parâmetro
> define
> > a frequência das mensagens de keepalive entre os ASs.
> >
> > Meu objetivo é que caso algum link falhe, o outro torne o 'principal' o
> > mais rápido possível.
> >
>
> Há dois problemas nisso: o primeiro é que diminuindo demais o HoldTime,
> você pode criar situações de falha onde elas não existiam, quando o
> roteador estava encaminhando bem pacotes mas a CPU estava atolada demais
> para manter os keep-alives. O outro é que como isso causa aumento de carga
> na CPU no roteador, além de complicar a gerência da rede como um todo por
> ter um elemento diferente, sua operadora vai ser bem arisca a diminuir isso
> na sua sessão.
>
>
> Rubens
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



-- 
Douglas Fernando Fischer
Engº de Controle e Automação