[GTER] OpenBGPd: adicionar peer sem reiniciar

[Marcelo Gondim]

Em 05/01/14 02:49, Douglas Fischer 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...

Entendo a sua frustração mas a maior parte do que você colocou eu chamo 
de experiência. Eu costumo dizer que experiência é o somatório dos 
nossos erros e acertos, tudo que fazemos dando certo ou errado. Quando 
você compra um hardware + software + suporte, você compra a experiência, 
know how que aquela empresa adquiriu fazendo isso tudo que você colocou 
acima. Porque eu vejo muito disso acima como tunning, correções e 
escolha de softwares. Acredito que 90% ou mais dos appliances atuais 
utilizam opensource em seu core e tenho certeza que antes de funcionar 
como deveria eles passaram por tudo isso. Depois dá uma lida aqui [1].
Eu aqui na empresa sou partidário de algumas coisas da forma como você 
colocou como por exemplo: nós temos 3 servidores PeerApp que fazem o 
cache não só para diminuir consumo de link em minhas cidades, mas para 
dar mais performance para o assinante e é muito bom. O PeerApp é uma 
solução "Proprietária" roda SuSE Linux como SO. O fato de colocarmos ele 
foram pelos motivos:

1º gerenciar cache dá trabalho e se não for bem feito além do trabalho 
dá problema, pois coisas como Youtube podem mudar.  :)
2º suporte. Deu problema eu passo a mão no telefone e pronto.

Veja, eu abri mão de adquirir experiência nessa área para ter um 
serviço/suporte mantido por terceiros. Mas não posso esquecer que se 
esses equipamentos/sistemas derem problemas estarei na mão de terceiros 
resolverem. Eles não são perfeitos, pode acontecer um problema que 
demore à ser resolvido, vai depender do tamanho e preparo da equipe 
deles. Quando você escolhe como "parceira" uma empresa de nome como: 
Juniper, Cisco, Dell, HP e por aí vai, você confia que elas vão te 
suprir mas posso te dizer que as vezes o problema pode ser tão sério que 
eles batem cabeça e aí nesse momento você senta e espera. Sei que existe 
o SLA mas a realidade pode ser outra. Tem empresas que tem um excelente 
suporte e tem outras que só sabem vender e o suporte é secundário. Os 
aborrecimentos são outros. Teu chefe não vai te cobrar porque a 
compilação deu erro e sim porque o sistema está fora do ar.

Isso que você fez foi uma escolha, escolheu terceirizar. Mas cuidado com 
o que terceiriza e com quem.
Eu já sou do seguinte princípio: prefiro ter controle das minhas coisas 
e terceirizo menos, não gosto de ficar dependendo de outros quando um 
problema surge.
Isso tudo que você colocou acima eu já passei e algumas poucas coisas eu 
passo uma vez ou outra. Quando comecei com opensource em 1996, era 
Slackware Linux e compilação pra todo lado rsrsrs mas eu gostava e 
aprendi bastante com isso. Alias aprendo até hoje só mudei de SO e a 
compilação continua.  :)

Em todo caso ninguém está mais certo ou mais errado, é tudo uma questão 
de escolha. O que não funciona para ti, para mim funciona e vice-versa. 
Muitos aqui escolheram como você mas outros viraram híbridos como eu.

[1] 
http://www.bsdinfo.com.br/2013/11/16/bsd-em-nossas-vidas-vale-apena-relembrar/

Grande abraço,
>
>
>
>
>
> 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.
>>>>>>>> --
>>>>>>>>
>>>>>>>>