[GTER] RES: BGP / Quagga

[Klaus Schneider]

Bom dia.

Bom, creio que o BGP em si não deva ocupar tanta CPU, e sim um tanto de
memória. Se possível, use DDR3, já que o BGP joga algumas dezenas de
milhares de rotas na memória, e o processador vai precisar acessar elas a
cada fração de segundo.

O consumo de CPU deverá se dar pelo kernel, por causa da grande quantidade
de I/O das placas de rede.

Além disto, tu deves ter cuidado em utilizar placas de qualidade e que os
drivers no SO que será instalado o BGP sejam extremamente estáveis.

Quanto ao servidor com 8 cores, como citou o Patrick, é realmente um
exagero, mais do que isso, é desperdício.

Se está com alguma desconfiança que o sistema não vai agüentar, use 2
servidores, e mantenha 2 em SPARE:

EBGP<->SERVER1<->IBGP<->SERVER2<->EBGP
          |                |
        SPARE1          SPARE2

-----Mensagem original-----
De: gter-bounces at eng.registro.br [mailto:gter-bounces at eng.registro.br] Em
nome de Patrick Tracanelli
Enviada em: quarta-feira, 16 de abril de 2008 18:57
Para: juliano at cyberweb.com.br; Grupo de Trabalho de Engenharia e Operacao de
Redes
Assunto: Re: [GTER] BGP / Quagga

Juliano Primavesi - Cyberweb Networks escreveu:
> Pessoal,
> 
> Estamos implementando BGP com Quagga. Existe algum case na lista com 
> link maior de 500 Mbits em BGP, com esta implementação? Considerando que 
> será balanceado entre 4 roteadores 2x quad-core.

Juliano, 500Mbit/s, nada nem perto. Mas tenho aqui um setup com 
4x34Mbit/s (DM4) (136Mbit/s portanto), em um único servidor (um segundo 
fica de SPARE), com FreeBSD 6.3 + OpenBGP fazendo full com as 4 
operadoras, segue hardware:

FreeBSD 6.3-PRERELEASE #0: Mon Feb 18 14:02:31 BRT 2008
     root at main.bh.freebsdbrasil.com.br:/usr/obj/usr/src/sys/TINYBSD
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) XEON(TM) CPU 2.20GHz (2199.77-MHz 686-class CPU)
   Origin = "GenuineIntel"  Id = 0xf24  Stepping = 4
 
Features=0x3febfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA
,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM>
   Logical CPUs per core: 2
real memory  = 1602420736 (1528 MB)
avail memory =  1545187328 (1473 MB)
ACPI APIC Table: <AMIINT AMIINI09>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
  cpu0 (BSP): APIC ID:  0
  cpu1 (AP): APIC ID:  1

Consumo de memória em 388M, veja o load avg apos um "bgpctl reload":

load averages:  0.57,  0.15,  0.05

Então acho que se esse combo (FreeBSD+OpenBGP) não der conta, nada mais 
deve dar. Sobre quantidade de núcleos a única vantagem será ter 1 
processo por CPU, nada demais, já que o daemon é monothread.

Sobre sua definição de hardware, 4 processadores 2xQuad vc quer dizer 8 
núcleos por servidor em 4 servidores? Se for, é um superdimensionamento. 
Vai sobrar (e muito).

A preocupação primária em um cenário com servers e soluções open source 
substituindo cisco/juniper boxes deve ser na confiabilidade, 
principalmente da disponibilidade (já que commoditie hardware é mais 
sucetível a problemas), e em qualidade de conectividade. Não sei como 
você vai receber esses 500Mbit/s, mas acho que o target da atenção pra 
possível gargalo deve ser essa conectividade.

Posteriormente garantir uma solução de failover, pois seu commoditie 
hardware cedo ou tarde vai falhar. Pra esse caso no meu cenário, temos 
um spare-server com CARP, o que downtime virtualmente nulo.

Então fica a sugestão, avalie o OpenBGP. Seu consumo de recurso é bem 
baixo. No caso que eu citei a mudança veio de cisco pra quagga (pra 
poder fazer full) e depois de quagga pra OpenBGP devido a integração do 
segundo com o restante do SO (firewall por ASN, labeling de rotas por 
AS-path e transito, CARP, etc, coisa que não era possível com quagga sem 
ter que reobter as tabelas rib).


--
Patrick Tracanelli

FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316601 at sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"

--
gter list    https://eng.registro.br/mailman/listinfo/gter