[GTER] OpenBGPd: adicionar peer sem reiniciar

Tue Jan 7 00:01:56 -02 2014

Douglas,

Acho suas colocações muito válidas, mas temos que ver o escopo do ambiente.

Um ambiente com componentes mais familiares aos operadores traz uma
flexibilidade que deve ser considerada. O ambiente de rede já tem uma
complexidade que demanda treinamento, adicionar ainda conhecimento de
sistemas operacionais traz um ônus que nem sempre vale a pena. Mas essa
conta de OPEX nem sempre é ruim para o Open Source.

A questão da atualização de software está desenvolvendo bem. Com o advento
dos DevOps e desenvolvimento colaborativo integrado como o Github está
muito mais fácil instalar ativos e lançar um serviço com um razoável nível
de atualização.

Quanto ao hardware, também depende da análise do ambiente. Do ponto de
vista técnico eu vejo o hardware dedicado como um componente estável. Não
apenas pela qualidade do hardware, que depende de cada fabricante, mas por
eles terem um padrão de fabricação, o que realmente ajuda a ter um sistema
previsível em campo. No entanto, usar bare metal servers pode ser uma
alternativa viável, desde que o projeto se disponha de um padrão que já
tenha sido testado e depurado. Senão corre-se o risco da inserção de
variáveis espúrias e aí não tem projeto de software que dê jeito...
Então não é que o projeto com opensource não funciona, mas sim que muitas
vezes não há um projeto de hardware adequado. Ter opensource não significa
que se usa qualquer componente de hardware e ele funciona, ainda mais
considerando um elemento de convergência da rede como um roteador. Coloque
um padrão de bare metal com os mesmos componentes e você irá replicar o
mesmo roteador várias vezes e terá o mesmo resultado, o cuidado é na hora
da manutenção (tem que usar um hardware compatível) e upgrade (como demora
mais tempo para desenvolver, precisa ser planejado com mais antecedência).

No momento atual minha posição é: depende do que se precisa, do
investimento necessário ou disponível e do tempo que se dispõe. É muito
mais rápido colocar um hardware dedicado e o comportamento dele é em boa
parte previsível, além de poder contar com um suporte padrão. Mas se
pensarmos que existem situações onde o ativo de rede não varia tanto, que
há um tempo disponível para desenvolver o projeto e o ambiente não exige
operações complexas no dia-a-dia, acho que opensource é uma alternativa que
pode trazer vantagens.

Para o futuro, vamos observar. Como sabemos existe um movimente de
separação do control plane do forwarding plane e isso pode levar a uma nova
arquitetura. Certo, ainda está no começo e pessoalmente não acredito em
mudanças bruscas, mas em 1995 o protocolo que dominava o mundo era IPX,
X.25 era absoluto na WAN e olha no que deu hoje...

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
>