[GTER] Relatório Euro-IX

Eduardo Schoedler listas at esds.com.br
Wed Aug 22 18:53:28 -03 2012


Em 22 de agosto de 2012 15:59, Eduardo Schoedler <listas at esds.com.br>escreveu:

> Em 22 de agosto de 2012 15:49, Henrique de Moraes Holschuh <
> henrique.holschuh at ima.sp.gov.br> escreveu:
>
> On 22-08-2012 14:40, Eduardo Schoedler wrote:
>>
>>> Em 22 de agosto de 2012 14:35, Rubens Kuhl<rubensk at gmail.com>
>>> escreveu:
>>>
>>>> Os dois piores problemas do BIRD na minha experiência:
>>>>>
>>>>> 1. O BIRD é síncrono, mono-threaded e mono-processo.
>>>>>
>>>>
>>>> O pessoal dos IXPs que fez há alguns anos atrás notou isso mas
>>>> comentou que ficaram surpresos com como ele compartilhava bem o
>>>> tempo de resposta entre as diversas demandas, quase que como uma
>>>> boa implementação de multitarefa não preemptiva (como era o Cisco
>>>> IOS, Mac OS Classic etc.). Então esse ponto não é um problema per
>>>> se, mas ele abre alguns cenários que precisam ser investigados de
>>>> algo que conseguisse capturar atenção demais do daemon.
>>>>
>>>>
>>> No Quagga tive problemas com uma regra de as_path com várias linhas,
>>> o filtro chegava a derrubar a sessão. Estou curioso para saber como o
>>> BIRD se sairia.
>>>
>>
>> Segfault e cai a routing engine inteira se é bug no código.  Se é bug no
>> filtro ou se você pede uma operação não implementada, ele solta uma
>> warning no log, e rejeita o prefixo.
>
>
> Não, nenhum erro... só um filtro bem demorado, que fazia dar timeout na
> sessão.
> O máximo que aparece no log é:
> bgpd.log:2012/07/11 23:18:41 BGP: SLOW COMMAND: command took 9543ms (cpu
> time 9332ms): clear ip bgp xxxxx soft
>


Agora que vi, 9332ms (9s) não derrubam nenhuma sessão... mas 112323ms sim!

bgpd.log:2012/07/06 23:11:36 BGP: SLOW COMMAND: command took 112323ms (cpu
time 107966ms): clear ip bgp x.x.x.x soft in


-- 
Eduardo Schoedler



More information about the gter mailing list