[GTER] AS e blocos IP

[Marcus Andree]

On 1/15/08, Diogo Montagner <diogo.montagner at gmail.com> wrote:
> Uma saída para o seu caso seria contratar o serviço de hosting ou colocation
> de algum datacenter no Brasil. A maioria dos datacenters já são sistemas
> autônomos e possuem conexão com pelo menos dois provedores diferentes. Nesse
> caso, o datacenter disponibilizaria para você um range de IPs do bloco dele.

Por enquanto, pensamos que o melhor seja condensar algumas maquinas e
passarmos, nos mesmos, a prover o servico de datacenter com AS. Dai a
necessidade da alocacao ser do tipo ISP.

>
> Utilizar alocação mínima de /24, no meu ponto de vista, não é uma boa idéia
> por dois motivos:
>
> 1- Contribui para o aumento da tabela de roteamento da Internet;
> 2- Nem todos os provedores lá fora aceitam receber prefixos do tamanho /24.
>

Nao creio que exista solucao perfeita para este problema. So continuo
acreditando
que o processo atual, linkando IP com AS e AS com bloco /20, efetivamente,
atrelando novas solicitacoes de IP com um bloco /20, surreal. O proprio lacnic
tem um range para atribuicoes /24.

Se, a partir dai, houver necessidade de roteamento ou propagacao de ASN
especifica para o bloco /24, creio que seja outro problema a parte (apesar
da minha posicao a este respeito ser bastante similar)

> No caso do item (2) tu não terá como fazer um anúncio menos específico para
> resolver este problema, visto que o seu AS somente possuirá um prefixo /24.
> Será fácil garantir de garantir o trânsito nos provedores que estarão
> diretamente conectados a você. Mas e naqueles que estão "longe", por
> exemplo, a quatro ou cinco AS distante de você ? Isto não é um problema
> impossível de resolver, mas com certeza isto gera um incomodo bastante
> grande dependendo da criticidade do seu serviço e do problema causado pela
> filtragem naquele ponto.
>
> []s,
> Diogo
>
> 2008/1/15 Marcus Andree <marcusandree at gmail.com>:
>
> > <snip>
> > >
> > > A solução por DNS atendia a todos os requisitos de disponibilidade dos
> > > sistemas mais críticos dos bancos como Internet Banking; a solução com
> > > DNS+BGP agregava a possibilidade de economia de custos e a proteção de
> > > transações de duração mais longa como EDI. Você pode detalhar em que
> > > cenário a solução baseada em DNS não atende ?
> > >
> >
> > Infelizmente, no momento nao posso detalhar alguns detalhes das operacoes.
> > Basta dizer que economia de custos e' um dos requisitos desejaveis ao
> > envolver o BGP na solucao. Um outro problema e' a falta de controle ao
> > nivel do usuario: em hipotese alguma podemos partir da premissa que todos
> > os pointers aos servicos nao estarao dirigidos diretamente ao IP.
> >
> > >
> > > > Sem duvida nenhuma... Mas, na proxima vez que um grande provedor
> > brasileiro
> > > > cair por varias horas, levando com eles milhares (milhoes?) de redes
> > > > corporativas
> > > > e usuarios domesticos via ADSL, teremos o nosso proprio bloco IP com
> > ASN
> > > > sendo propagado adequadamente pelo outro provedor, que ficou de pe'.
> > >
> > > Veja que um erro da parte desse provedor pode indisponibilizar o
> > > acesso da mesma forma, pois ele pode anunciar sem conseguir de fato
> > > trafegar. Até um erro da parte de um terceiro pode ter o mesmo efeito,
> > > como aconteceu semana passada quando a Impsat derrubou a Embratel sem
> > > que houvesse conexão direta entre as duas.
> > >
> > > BGP é muito bom contra falhas de equipamentos ou enlaces, mas ter um
> > > AS como seu upstream permite que falhas humanas possam tirar o serviço
> > > do ar mesmo com a presença do upstream redundante.
> > >
> >
> > A solucao e' de "melhoria da disponibilidade". Nao e' escopo do projeto
> > garantir 100% de disponibilidade. Sempre estaremos sujeitos a situacoes
> > imprevistas.
> >
> > > Detectado isso é possível suspender a sessão com um upstream, mas até
> > > descobrir... uma das questões interessante do DNS é que ele depende de
> > > uma origem *e* de uma resposta para tentar aquele caminho, o que dá
> > > mais integridade fim-a-fim do que o BGP, que garante apenas ter como
> > > encaminhar tráfego por aquela rota.
> > >
> >
> > Ha uma diferenca entre resolver um nome e conseguir comunicacao com o
> > IP resolvido...
> >
> > > A única vantagem do BGP é fazer com que uma conexão já estabelecida
> > > tenha a maior taxa de sobrevivência, pois mesmo com um chaveamento de
> > > um backbone para outro a conexão se manterá.
> > >
> >
> > Possuimos algumas transacoes caras e "pesadas" (muitos volumes de
> > dados). Esta e' uma das vantagens que estamos buscando.
> >
> > > Em termos de design, uma solução em que a aplicação tenha conexões
> > > short-lived baseadas em DNS acaba tendo a melhor disponibilidade
> > > global. A dúvida de design é: usar BGP para proteger sessões de longa
> > > duração ou mudar a aplicação para usar conexões de menor duração ? A
> > > 2a. tem o melhor resultado, mas impõe alterações que podem ser
> > > custosas.
> > >
> >
> > Nossa questao possui varios "x". Este e' exatamente um dos mais
> > importantes.
> >
> >
> > >
> > > Rubens
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
>
> --
> ./diogo -montagner
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>