[GTER] AS e blocos IP

[Diogo Montagner]

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.

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.

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