[GTER] ASN

Tue Aug 26 18:46:10 -03 2008

Grande Diogo.

Muito obrigado novamente.

Estamos falando de quantos eBGPs ?
Aqui terei provavelmente 3, talvez 4.

Abraços!

--------------------------------------------------
From: "Diogo Montagner" <diogo.montagner at gmail.com>
Subject: Re: [GTER] ASN

Mauricio,

Nem sempre é assim para o caso de partial routing. Depende muito de um ISP
para outro. Essa informação é melhor obter direto do seu provedor
perguntando quais as rotas que eles enviam no partial routing e qual o
tamanho médio da tabela parcial deles.

Alguns provedores enviam as rotas de seus peerings na tabela parcial. E aí
eles podem incluir os peering feitos no Brasil e no exterior. Ou até mesmo
peerings feitos no Brasil com empresas do exterior, como por exemplo o
Google. Só que o Google e outros provedores seguem a filosofia do Hot Potato
Routing e, somente anunciará em peerings no Brasil os blocos deles que estão
em uso no Brasil. Então é dificil imaginar (ou adivinhar) quais rotas serão
enviadas no roteamento parcial sem consultar os seus ISPs.

A vantagem de receber um anúncio full ao invés do parcial é que você terá a
visão da tabela de roteamento da Internet. Você poderá, por exemplo, ver
como um prefixo da China chega até você pelo provedor A e pelo provedor B. E
baseado nisto decidir qual rota (pelo provedor A ou B) terá a preferência de
inserção na sua tabela de roteamento. Mas dependendo do tamanho da sua rede
e topologia, não fará diferença em receber parcial ou full. Porque tu poderá
utilizar rotas default e rotas para CIDR específicos quando quiser manipular
o tráfego de saída da sua rede.

Se a sua rede for grande (entenda número de conexões eBGP elevado) é uma
vantagem receber full nos links de trânsito para poder trabalhar com os
anúncios e manipular o tráfego de saída. Mas se a sua rede for pequena, com
poucas conexões eBGP para realizar ajustes de configuração, não vejo porque
"queimar" memória de roteadores para isto.

Uma alternativa é utilizar o quaggua (ou outros similares) em hardware Intel
para poder receber full-routing de ambos os provedores. Na lista já rolou
alguns e-mails sobre isto.

[]s,
./diogo -montagner

2008/8/26 Mauricio Maehara <mauriciomaehara at yahoo.com.br>

> Eduardo a diferença básica é que o partial routing contém somente as rotas
> nacinais mais uma rota default, enguanto o full routing tem todas as rotas
> existentes na internet.
> abraços
> Maehara
>
>
>
> ----- Original Message ----
> From: Eduardo Schoedler <eschoedler at viavale.com.br>
> To: Grupo de Trabalho de Engenharia e Operacao de Redes <
> gter at eng.registro.br>
> Sent: Tuesday, August 26, 2008 3:48:49 PM
> Subject: Re: [GTER] ASN
>
> Olá Diogo!
>
> Muito obrigado pela atenção de todos.
>
> Uma dúvida que sempre me intrigou é a seguinte:
> - Qual a diferença entre ter a tabela FULL Routing ou PARTIAL ?
> - Quais as vantagens que eu tenho com isso ?
>
> Pergunto isso porque estive dando uma olhadinha aqui no nosso router.
> Simplesmente minha saída principal (EBT) está sem *nenhuma* rota!
> Vejam:
>
> #show ip bgp neighbors xxx.xxx.xxx.xxx (EBT) routes
>
> Total number of prefixes 0
>
>
> Eu tenho outro peering, da BRT.
> Ali existe um "route-map BRT-IN in", filtrando os anúncios da BRT às redes
> deles (BRT).
> Ainda não descobri qual foi a idéia por trás desse filtro, mas nesse
> neighbor eu possuo uma tabela.
>
> #show ip bgp neighbors yyy.yyy.yyy.yyy (BRT)
>                                 Sent      Rcvd
>   Prefix activity:              ----      ----
>     Prefixes Current:              3        53 (Consumes 2544 bytes)
>     Prefixes Total:                3        53
>     Implicit Withdraw:              0          0
>     Explicit Withdraw:              0          0
>     Used as bestpath:            n/a        53
>     Used as multipath:            n/a          0
>
>
> Abraços!
> Eduardo.
>
>
> --------------------------------------------------
> From: "Diogo Montagner" <diogo.montagner at gmail.com>
> Subject: Re: [GTER] ASN
>
> Eduardo,
>
> veja as respostas abaixo.
>
> []s
> ./diogo -montagner
>
>
> 2008/8/14 Eduardo Schoedler <eschoedler at viavale.com.br>
>
> > Olá Diogo e Rubens!
> >
> > Primeiramente gostaria de agradecer a atenção de vocês.
> > Sobre as colocações, segue.
> >
> > > 1) backup: particularmente não gosto muito dessas topologias
> > > em que a redundância é offline. Poder tu pode fazer isto, mas
> > > mesmo assim eu modificaria a topologia para tentar manter os
> > > dois roteadores funcionando e quando um deles parasse o outro
> > > assumiria. Até porque se tu manter um offline pode acontecer
> > > de no momento da substituição do roteador defeituoso tu descobrir
> > > que o spare também está ruim (tá eu sei - é muito azar - mas
> > > pode acontecer :-) )
> >
> > Claro, não há problema em manter o spare ativo... eu até prefiro.
> > Alguém já fez isso com Cisco ?
> > Poderia me indicar um link sobre o assunto ?
> >
>
> Dificilmente encontrará um howto (pelo menos eu não conheço nenhum) sobre
> isto. Terás que trabalhar com a sua topologia e protocolos de roteamento
> para atingir este objetivo.
>
>
>
> > > 2) ter o seu próprio ASN e endereços - não vejo problemas nisto,
> > > desde que a utilização dos endereços seja bem justificada;
> >
> > Sem problemas. Hoje já contamos com um bloco /22, dois blocos /23
> > somente nada sede. Contando com as demais localidades, seriam mais
> > três blocos /24.
> >
> >
> > > 3) tu não conseguirá aumentar o bloco /21 para /20 se o bloco /21
> > > seguinte ao seu já foi alocado. Se não estou enganado, a alocação
> > > mínima no Brasil é /20. Nos links http://registro.br/info/cidr.html
> > > e http://registro.br/info/cidr-request.txt tem algumas informações
> > > adicionais sobre este processo.
> >
> > Pelos links eu habia entendido que a alocação mínima seria de um
> > bloco /21. Bom, entendi errado então... rsrsrs. Mas é melhor assim,
> > porque um bloco /21 seria meio "apertado" demais para a nossa infra.
> >
> > Sobre a alocação de um bloco adicional, acredito que seja difícil
> > conseguir um bloco consecutivo ao que já está alocado, totalizando
> > assim um bloco maior. Mas isso não seria problema, pelo menos não
> > vejo ainda nenhum problema.
> >
> >
> > > 4) O bloco sendo seu, tu pode rotear ele da forma que desejar.
> > > Obviamente as redes com as quais tu se conectará estabelecerá
> > > algumas regras para aceitar os seus anúncios. E sempre se
> > > recomenda seguir as melhores práticas nas questões de segmentação
> > > e anúncio de blocos aos parceiros. Na Internet existem vários
> > > discussões sobre esse tema.
> >
> > Justamente sobre isso que eu gostaria de me informar.
> > Quais seriam essas melhores práticas? Onde encontro?
> > Sobre as regras que você comentou, cada peering tem as suas ?
> >
>
> Que eu saiba, também não existe um documento específico sobre isto. Talvez
> algum outro colega saiba informar. Mas posso te indicar alguns links sobre
> o
> assunto de (des)agregação de rotas. O Roque fez uma apresentação sobre 
> este
> assunto no fórum do LACNIC deste ano.
>
>
> http://www.lacnic.net/documentos/lacnicxi/presentaciones/Deaggregation_LACNIC.ppt
> mms://lacnic.net/webcasting/lacnicxi/27_5/lacnog/lacnog-02-roque.wmv
> http://www.ripe.net/ripe/docs/ripe-399.html
> http://thyme.apnic.net/current/
>
>
>
> > >> 5) depende o que tu considera como limitação. Se tu tiver um
> > >> backbone interno, seria possível escoar o tráfego para dois
> > >> pontos distintos, por exemplo. Se tu não tiver backbone interno,
> > >> por exemplo, em cada cidade tu terás um roteador trocando BGP
> > >> com uma operadora (ou mais de uma) mas este roteador não está
> > >> conectado aos demais roteadores das outras cidades. Se tu tiver
> > >> atendendo 10 cidades, precisará desta estrutura nas 10 cidades,
> > >> ou seja, 10 links com as operadoras. Ou tu poderia concentrar
> > >> isto em duas cidades e investir na interligação própria
> > >> (ou de terceiros) entre as cidades. E assim tu terias uma
> > >> topologia de rede bem interessante e seria possível criar
> > >> vários cenários de contingência e melhor escoamento de tráfego.
> >
> > Hoje possuimos roteadores trocando BGP com 1 operadora em
> > cada localidade.
> >
> > Existe uma possiblidade de interligarmos tudo, centralizando no
> > datacenter da sede toda a operação de BGP.
> >
> >
> > > No caso de ASN disjunto, eu recomendo anunciar um bloco mais
> > > abrangente em uma das localidades, e manter túneis IPIP com ajuste de
> > > MSS para as outras localidades. Assim, no caso de algum filtro de
> > > prefixos abater os anúncios mais específicos, o mais abrangente
> > > manterá conectividade. É claro que o melhor é o túnel ficar sem
> > > tráfego, mas assim se ganha tempo para responder ao problema.
> >
> > Exato, a operação do ASN ainda ficaria de forma disjunta.
> > A sua idéia é muito boa!
> > Gostei, MESMO.
> >
> >
> > > 6) Pra terminar, recomendo uma lida no livro do Halabi.
> > > Lá tem vários cenários de utilização do BGP.
> >
> > Já estou atrás desse livro.
> >
> > Muito obrigado à todos !!!
> >
> >
> > Forte Abraço.
> >
> > Sds,
> > Eduardo. 