[GTER] OpenBGPd: adicionar peer sem reiniciar
Alisson
alissongoncalves at bsd.com.br
Tue Jan 7 01:43:21 -02 2014
Boa Noite Senhores,
Utilizo OpenBGPd a 2 anos, nunca tive problemas com ele após colocar em
produção, e mesmo em produção adicionei vários Peers, os quais estão
funcionando perfeitamente até hoje.
Tudo depende do Custo/Benefício, Suporte/Consultoria e etc.
Concordo com o que disse o Marcelo Gondim, tudo é uma questão de escolha.
Não há remendos no OpenBGPd, já é uma ferramenta madura e estável.
Mas vale lembrar que num sistema Open Source, principalmente FreeBSD
deve-se levar em conta Hardware (CPU, Memórias, Placas de Rede, Discos de
Armazenamentos), Software (Versão), Kernel Tuning (Compilação).
Não é normal que um Neighbor/Peer não fique UP após um reload ou um restart
(utilizo só em último caso).
Se suas configurações estão corretas, pode ser que as configurações do
outro lado do Peer não estejam, algum parâmetro de hold time, anúncios
incorretos e etc.
Ai para te ajudar somente ativando o Log do OpenBGPd no /var/log/messages
ou utilizar os comandos acima mencionados pelo Marcelo.
A alguns meses atrás tive problemas com uma sessão no PTT-SP, a sessão
ficava Down e eu tinha que limpar o ARP da interface para subir o Peer.
Depois após tratamento via suporte no PTT-SP foi descoberto que um dos
participantes estava anunciando rota default e anunciando redes incorretas..
Após filtrarem o participante, tudo voltou ao normal.
Creio que estamos aqui pra somar e ajudar uns aos outros.
Ao participante dl.lagg0 at gmail.com, fico a disposição para lhe ajudar com
este problema.
Att.
Alisson F. Gonçalves
Em 6 de janeiro de 2014 10:00, Listas Discussão <dl.lagg0 at gmail.com>escreveu:
> 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
> >
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
More information about the gter
mailing list