[GTER] OpenBGPd: adicionar peer sem reiniciar

Listas Discussão dl.lagg0 at gmail.com
Mon Jan 6 10:00:40 -02 2014


Bom dia pessoal,

Só para esclarecer, a configuração está OK. Como falei ao reiniciar o
OpenBGP a sessão sobe normalmente. Descobri que o problema está acontecendo
por que a sessão dos novos peers foi feita em cima de vlans novas, nesses
casos não está subindo. Se for em cima de uma interface já existente
funciona.



Quanto as questões levantadas pelo Douglas, concordo que pelo fato de usar
OpenSource em alguns casos nos traz um leque muito grande de opções. Ao nos
depararmos com um problema, encontrar a origem/solução é mais árduo.

Nesses momentos que temos que realizar uma boa avaliação do melhor custo X
benefício. Meu caso desse router, está passando 1.72Gb num Port Channel com
2 interfaces em horários de pico e 350K pps, gastamos em torno de R$
15.000,00 e acredito que podemos chegar tranquilo em 4Gb, talvez tenhamos
que fazer alguns ajustes de CPU affinity. Não estou muito por dentro dos
valores, mas se fosse comprar um router Cisco novo gastaria mais de R$
100.000,00 e um Juniper uns R$ 40.000,00. A 1 ano atrás isso pesou muito na
escolha, hoje as coisas mudaram um pouco e possívelmente teríamos pegado
outro caminho.


Desculpe, mas vou parando por aqui, não quero que essa thread se torne uma
daquelas discussões sem fim do ovo e da galinha.



Em 5 de janeiro de 2014 02:49, Douglas Fischer
<fischerdouglas at gmail.com>escreveu:

> Entendo isso Marcelo.
>
> E sou fã da monstruosidade que pode-se fazer na relação custo_X_performance
> usando por exemplo o openbgpd(entre outros).
>
> Mas tem um ditado que aprendi já tem um tempinho numa empresa que
> trabalhei:
> "Faz certo que dá certo!"
> O problema é com opensource, o leque de coisas a serem feitas certas, e a
> métrica para considerar certo ou errado é muito aberto.
>
> Apenas para exemplificar:
> (Nem percam tempo lendo o texto, só conte o numero de linhas)
>
>  - Começa pela escolha do hardware:  NICs vs Northbridge, Clock, nº
> threads, Ram, etc...
>  - Aí vai p/ o S.O.: BSD, Linux, etc...
>  - Aí vai p/ o tipo de distro que vai se usar: Mais pelas que tens que
> começar compliando o boot sector, ou mais confortáveis que tem tudo
> pré-compilado?
>         (Aqui eu penso igual a um colega de missiva
>          Ficar nessa punheteação de compila e recompila
>          é igual a Tosar porco! É muito grito p/ pouca lã)
>  - E os pacotes, vão ser os do repositório oficial?:
>    Aí o que tá no repositório oficial quase sempre é muito desatualizado.
>  - Vão pegar direto do desenvolvedor:
>    Só disponibiliza o source, ou se tem pré-compilado não bate com algum
> parâmetro do seu ambiente.
>  - Baixa o source e aquela quinquilharia toda para compilar
>  - Compila, ajusta configuração...
> Até aqui... tá foi chatinho, mas não matou ninguém
>  - Põe para rodar, e e e e e e ? ? ? ?
>       - Não funciona
>       - ou funciona meia boca
>       - ou não faz uma coisa como deveria fazer
>       - ou simplesmente dá crash do nada
>
> E é aqui que vem o martírio
>  - Será que é alguma incompatibilidade da NIC, pode ser só o firmware.
>  - Talvez atualizando a UEFI
>  - E a memória? Será que tinha que ser ECC?
>  - E o S.O.? Será que fiz alguma coisa errada?
>     (Exs. de tortura)
>       - Putz fiz RAID via software, será que é isso que tá afetando?
>       - Bah, será que tá dando pau por causa do locale,
>         eu sabia que devia ter deixado tudo em inglês.
>       - Putz eram só 2 GB e usei 32Bits
>       - Putz eram só 4 GB e usei Kernel PAE
>       - Putz usei 64, porque eram 16GB,
>         mas me disseram que roda bem com 32Bits
> E as pitacas alheias torturantes?
>  - Se usou do repositório: "É por isso, devia ter baixado a última versão"
>  - Se usou pré-compilado atualizado: "É por isso, devia ter compilado"
>  - Se compilou: É por isso, não instale NADA que não seja do repositório
> oficial.
>         (Os mais xiitas desse ramo:
>          "E se for usar, compile, gere o pacote,
>           coloque ele na lista de repositórios e instale
>           a partir desse mesmo pacote previamente compilado.")
>  - Qual foi mesmo a versão do MAKE que você usou?
>  - E o kernel headers? tava certo?
> Aí subindo mais o nível:
>  - E o IRQ Balance? Você fez?
>         (P.S.: Má poooorrrra...
>          Tenho que meter a mão lá embaixo nas IRQs?
>          Só me falta que daqui a pouco alguém vai me
>          falar que vou ter que jumpear essa merda.)
>  - E depois de tudo isso é que você vai começar a pensar nas configs
>    - Será que estão certas?
>       - "O cara confere aqui para mim..."
>       - "Acho que está tudo certo."
>       - "O Outro cara, dá uma bisoiada aqui, tá tenso o clima."
>       - "Você complilou com --alguma-coisa=true"
>       - "Não"
>       - "aaaa então é isso. tá vendo essa opção aqui? só com
> --alguma-coisa"
>
>
>
> É aí que vem o diferencial de cair para marcas consagradas.
> Tua parte tá bem feita? Vejamos... Qual é tua parte?
>
> - Medir a demanda do cliente, e propor um coeficiente
>   de crescimento e aplicá-lo pelo tempo estipulado.
> - Validar com o cliente quais são as features que ele
>   precisa.
> - Encontrar a linha e modelo de equipamento que vai guentar
>   as pontas do cliente pelo tempo especificado.
> - Fixá-lo no rack
> - Fazer o teu serviço(teu core-business) BEM FEITO.
>   configurar a porra toda.
> - Fazer a ativação ou virada, e ficar no rescaldo.
>   - Deu merda?
>     Confere teu serviço.
>   - Continuou dando merda
>     Pede para o colega conferir suas configs,
>     e na sequencia demais variáveis do ambiente.
>   - Continuou dando merda
>     Liga pro suporte, e já em paralelo informa o CEO/CIO
>     que estamos aguardando retorno do fabricante.
>     - Indiano te liga em até 2h.
>
>    - Putz é um bug
>  de versão? E qual é o workaround?
>       A Faz o downgrade de versão?
>     - Fez, testou, OK...
>
>
>
>
>
>
> Em 5 de janeiro de 2014 00:05, Marcelo Gondim <gondim at bsdinfo.com.br
> >escreveu:
>
> > Em 04/01/14 13:10, Douglas Fischer escreveu:
> >
> >  (Ciente de que vou tomar várias pedradas)
> >> Sinceramente, é por isso que não sou fã de usar ferramentas como
> >> openbgpd...
> >>
> >> "Putz, não funcionou..."
> >> - Tenta o reload.
> >> "Não funcionou..."
> >> - Tenta o restart.
> >> "Não funcionou..."
> >> - Tenta o tenta o kill.
> >> "Não funcionou..."
> >> - Tenta o tenta o no processo pai e deixa subir com whatch-dog.
> >> "Não funcionou..."
> >> - Tenta usar uma meia verde e outra azul, e restart.
> >> "Não funcionou..."
> >> - Inverte as meia e restart denovo.
> >> "Não funcionou..."
> >> - Recompila o kernel com a opção --tãdã=off e restart denovo.
> >>
> > Douglas,
> >
> > Sem dar nenhuma pedrada.  :)   O caso dele deve ser algo com alguma
> > configuração que não está correta em alguma ponta ou algum outro problema
> > desconhecido. Ele queria uma maneira de fechar o peering sem ter que
> > re-iniciar todo o serviço bgp. Eu sugeri à ele primeiro testar se existe
> > algum erro de syntax e na pior das hipóteses o clear foi feito pra isso
> > mesmo, reiniciar uma conexão sem ter que derrubar todo o serviço.
> > Eu uso FreeBSD + OpenBGP tem mais de 2 anos e nunca tive esse problema
> que
> > ele relatou. Tenho 5 sessões eBGP e 9 sessões iBGP sendo IPv4 e agora
> > iniciando IPv6 e não tenho nenhum problema de ter que reiniciar um
> serviço
> > quando crio uma nova sessão bgp. Simplesmente faço:
> >
> > # bgpd -n
> > # bgpctl reload
> >
> > Checo se a sessão levantou tudo bem com:
> >
> > # bgpctl s s
> >
> > Caso não tenha fechado e se eu quiser resetar apenas aquele neighbor eu
> > mando:
> >
> > # bgpctl nei nome_neighbor clear
> >
> > Não tem nada de errado nisso. Não é nada maceteado, ou algum bug
> > contornado, são apenas comandos úteis.
> >
> > Respeito a sua opinião em não querer usar a ferramenta ou querer usar
> algo
> > proprietário. Eu, sinceramente, não tenho o que reclamar pois essa
> solução
> > segura +20mil assinantes distribuídos em 4 cidades e até hoje não me
> deixou
> > na mão.
> >
> > Isso não foi pedrada, apenas um relato que alias já tiveram vários aqui.
> >  :)
> >
> >
> >
> >>
> >>
> >>
> >>
> >> Em 3 de janeiro de 2014 18:00, Listas Discussão <dl.lagg0 at gmail.com
> >> >escreveu:
> >>
> >>  Alisson, ontem quando adicionei o novo peer, fiz exatamente o que você
> >>> sugeriu, efetuei as configurações no arquivo bgpd.conf e após conferir
> >>> executei o comando "bgpctl reload". Após isso com o comando "bgpctl
> show
> >>> sum" o novo peer constava no resultado, porém sempre como "Idle" tentei
> >>> dar
> >>> up e down e nada, executei o comando "/usr/local/etc/rc.d/openbgpd
> >>> reload"
> >>> para dar um reload no daemon e também não tive resultado.
> >>>
> >>> A última alternativa foi "/usr/local/etc/rc.d/openbgpd restart", subiu
> de
> >>> primeira, porém nesse caso as outras sessões foram reiniciadas também.
> >>> Foi
> >>> tudo muito rápido, mas alguns clientes mais chatos já perceberam e
> >>> reclamaram.
> >>>
> >>> Hoje precisei adicionar 2 novos peers, estou aguardando os clientes
> >>> configurarem no lado deles, mas estou com receio de não subir
> novamente.
> >>>
> >>>
> >>>
> >>> Em 3 de janeiro de 2014 17:11, Alisson <alissongoncalves at bsd.com.br
> >>>
> >>>> escreveu:
> >>>> Se o Peer não está subindo, há algo de errado em suas configurações.
> >>>>
> >>>> pode ser algum dos parâmetros em conflito.
> >>>>
> >>>>
> >>>> Em 3 de janeiro de 2014 16:10, Alisson <alissongoncalves at bsd.com.br
> >>>>
> >>>>> escreveu:
> >>>>> Após fazer todas configurações no arquivo bgpd.conf
> >>>>>
> >>>>> execute o comando:
> >>>>>
> >>>>> bgpctl reload
> >>>>>
> >>>>> ele não irá reiniciar o daemon, vai checar mudanças no bgpd.conf e
> >>>>>
> >>>> subirá
> >>>
> >>>> o novo peer se estiver configurado corretamente,
> >>>>>
> >>>>> se haver erros, seu BGP não irá parar.
> >>>>>
> >>>>>
> >>>>> Em 3 de janeiro de 2014 15:50, Leonardo Mauricio Portela <
> >>>>> leonardo.gestec at corp.globo.com> escreveu:
> >>>>>
> >>>>> Tenta um kill -HUP $ID no id do processo da aplicação, na teoria
> >>>>>
> >>>> resolve.
> >>>
> >>>>
> >>>>>> Em 3 de janeiro de 2014 15:58, Listas Discussão <dl.lagg0 at gmail.com
> >>>>>>
> >>>>>>> escreveu:
> >>>>>>> Boa tarde pessoal.
> >>>>>>>
> >>>>>>> Gostaria de saber se é possível adicionar um novo peer no OpenBGPd
> e
> >>>>>>>
> >>>>>> subir
> >>>>>>
> >>>>>>> a sessão sem ser necessário um restart no daemon, em caso positivo
> >>>>>>>
> >>>>>> como?
> >>>>
> >>>>>
> >>>>>>> Já fiz a configuração no arquivo bgpd.conf, após dar um reload o
> >>>>>>>
> >>>>>> novo
> >>>
> >>>> peer
> >>>>>>
> >>>>>>> aparece como ativo na saída do comando "bgpct show sum" mas a
> sessão
> >>>>>>>
> >>>>>> não
> >>>>
> >>>>> fica UP, somente após um restart.
> >>>>>>> --
> >>>>>>>
> >>>>>>
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



More information about the gter mailing list