[GTER] OpenBGPd: adicionar peer sem reiniciar

Douglas Fischer fischerdouglas at gmail.com
Sun Jan 5 02:49:53 -02 2014 

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

More information about the gter mailing list