[FUG-BR] openbgp travando quando crio uma vlan

[Marcelo Gondim]

Em 11/04/14 22:25, Patrick Tracanelli escreveu:
> On 11/04/2014, at 21:34, Marcelo Gondim <gondim em bsdinfo.com.br> wrote:
>
>> Em 11/04/14 16:48, Luiz Otavio O Souza escreveu:
>>> 2014-04-11 10:32 GMT-03:00 Luiz Otavio O Souza:
>>>> 2014-04-10 15:58 GMT-03:00 Marcelo Gondim:
>>>>
>>>>> rede 192.168.0.0/24 <----> Router Local iBGP <----> Router Público BGP
>>>>> <----> Internet
>>>>>
>>>>> O Router Local anuncia o prefixo 192.168.0.0/24 para o Router Público
>>>>> BGP. Quando eu crio a vlan no Router Público BGP, a rede 192.168.0.0/24
>>>>> não chega e não passa mais pelo Router Público BGP. Mas do Router
>>>>> Público eu pingo o Router Local e vice-versa.
>>>> Gondim,
>>>>
>>>> Meu teste aqui foi o seguinte:
>>>>
>>>> Router teste <---> Router iBGP <---> Router Borda (eBGP)
>>>>
>>>> No seu ambiente e pela sua descrição você podia verificar se os
>>>> anúncios do seu Router Local estão chegando no Router Publico e se as
>>>> rotas necessárias para acesso da rede 192.168.0.0/24 ainda estão na
>>>> fib. Imagino que no seu Router Local tudo funcione.
>>>>
>>>> Não há nenhuma configuração perdida no seu rc.local para essa
>>>> interface ? Quando você cria a vlan ela aparece sem nenhuma
>>>> configuração ? Enquanto ela não esta associada a nenhuma interface
>>>> física seria muito dificil ela gerar algum problema:
>>>>
>>>> # ifconfig vlan666 create
>>>> # ifconfig vlan666
>>>> vlan666: flags=8002<BROADCAST,MULTICAST> metric 0 mtu 1500
>>>> ether 00:00:00:00:00:00
>>>> nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>>>> vlan: 0 parent interface: <none>
>>>>
>>>>
>>>> A tarde vou refazer os testes aqui com lagg.
>>>>
>>> Gondim,
>>>
>>> Sem novidades, mesmo com o lagg consigo criar as vlans aqui sem afetar
>>> o funcionamento do sistema :/
>>>
>> LooS, então eu fico aliviado e agora podemos praticamente ter certeza
>> que o problema está no meu ambiente. To achando que pode ser por causa
>> do problema com mac address com a operadora.
>> Vou continuar testando e aviso à todos.
>>
>> Mas valeu pelo teste!!!!
> Gondim,
>
> Fechei mais um BGP num ambiente pre operacao que deu pra testar muito, e também não reproduzi o erro. Com lagg pra 3 eBGP, sem lagg com 1 iBGP, eBGP sem lag com PTT CAS e PTT SP, taggeado em todas as portas.
>
> Fiz testes simples e sem erro.
>
> Fiz um shell script loopando “ifconfig vlanX create up" e destroy em 10 vlan diferentes das em uso, e nada, so o consumo de CPU do bgpd ficando alto enquanto rodava o shell e o "bgpctl sh int” variando entra valid e invalid conforme as interfaces surgiam, ficavam up e eram destruidas. Sem afetar nenhuma sessao BGP estabelecida, sem gerar perda de pacote, sem consumo excessivo de CPU no Sys ou Interrupt, so mesmo CPU do user com o bgpd sofrendo pra validar as interfaces “highlander” surgindo e sumindo.
>
> Ou seja tem alguma particularidade a mais no seu cenário, voce comentou alguma coisa de mac address o que tem de diferente no mac? Quando voce da vlan create  altera alguma coisa no seu llinfo na sua tabela arp, voce comparou? Seu kernel é generic, esta com debug? Nada estranho no dmesg, debug.log, quando cria essas vlan?
>
> Fogo que é produção ne dificil testar…
>
> Quais as interfaces? em? igb? exgb? ou outra coisa? Aqui foram igb.
>
> Por acaso voce nao tem redundância desse bgp não ne? Com mesmo hardware, pra poder fazer mais testes sem impactar na produção.
>
> Algum tuning diferente?
>
> Antes todos meus testes com FreeBSD 10 tinham sido em ambiente direto no fio, sem vlan e sem lag. Criar vlan n impactava em nada. Mas agora fechando BGP em vlan e em lagg tbm n impacto ou seja n sei… a única coisa que eu fiz foi tirar virtio do kernel, pq apesar de pre-operacao jaja entra em produção e foi customizado alguma coisa.
>
E aí mestre Patrick.  :)

Então, esse lance de mac é o seguinte: de outubro/2013 pra cá nenhum mac 
address passa direito pelo Datacom que está entre eu e a operadora de 
clear channel que me transporta até as cidades que atendo. Olha o que 
acontece com faço um arping:

# arping -i em3 186.xxx.x.149
ARPING 186.xxx.x.149
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
60 bytes from 64:00:f1:75:b7:40 (186.xxx.x.149): index=0 time=609.552 usec
Timeout
60 bytes from 64:00:f1:75:b7:40 (186.xxx.x.149): index=1 time=496.451 usec
Timeout
60 bytes from 64:00:f1:75:b7:40 (186.xxx.x.149): index=2 time=641.974 usec
Timeout
Timeout
Timeout
60 bytes from 64:00:f1:75:b7:40 (186.xxx.x.149): index=3 time=575.442 usec
Timeout
Timeout
Timeout
^C
--- 186.xxx.x.149 statistics ---
22 packets transmitted, 4 packets received,  82% unanswered (0 extra)
rtt min/avg/max/std-dev = 0.496/0.581/0.642/0.054 ms

Essa interface em3 também está ligada nesse Datacom na porta 3. As 
interfaces do lagg estão ligadas nas portas 1 e 2 do Datacom. Todo mundo 
que passa por esse Datacom está fazendo isso. Aí sou obrigado à fixar o 
mac address das interfaces de cada cidade na minha tabela arp do router 
pra que funcione tudo certinho.
Todas as interfaces são em(4) Intel PRO/1000 PT Dual Port PCI-e.
Tentei ver no momento do problema como estavam a fib e a rib no bgp e 
pareciam normais. Nos logs não vi erro.
Tentei rodar o /etc/rc e também o /etc/netstart para ver se voltava à 
funcionar, fiz tanta coisa, matei o serviço e tudo e teve um momento que 
eu reiniciei o ibgp em cada cidade e voltou à funcionar mas não consegui 
reproduzir a façanha. HaHaHaHaHA

Patrick, pode ser aquele problema que você comentou sobre alguns 
chipsets em(4)?

Grande abraço,
Gondim