[GTER] ASN

[Mauricio Maehara]

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