[GTER] ASN
Diogo Montagner
diogo.montagner at gmail.com
Tue Aug 26 21:32:24 -03 2008
Esse quantidade fica fácil de administrar manualmente.
As quantidades grandes que eu falo é pelo menos umas 10 conexões de
trânsito. E mesmo assim, dependendo de como elas estão distribuidas ao longo
da tua rede ainda é possível fazer os ajustes sem utilizar full routing. Mas
assim as coisas começam a ficar confusas.
Abaixo estão alguns links da lista do GTER sobre este mesmo tópico e alguns
links da RNP com dicas de configuração.
http://eng.registro.br/pipermail/gter/2007-October/016303.html
http://eng.registro.br/pipermail/gter/2007-October/016306.html
http://eng.registro.br/pipermail/gter/2007-October/016312.html
http://www.rnp.br/newsgen/0101/bgp4-dicas.html
http://www.rnp.br/newsgen/0109/bgp4_dicas2.html
[]s,
./diogo -montagner
2008/8/26 Eduardo Schoedler <eschoedler at viavale.com.br>
> Grande Diogo.
>
> Muito obrigado novamente.
> u
> 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.
>
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
More information about the gter
mailing list