[GTER] AS e blocos IP

[Marcus Andree]

On 1/14/08, Rubens Kuhl Jr. <rubensk at gmail.com> wrote:
> > Justificar a alocacao nao seria, de forma alguma, um problema...
>
> Eu me referia a justifcar a alocação com informações reais, e não com
> informações que justifiquem a alocação só por justificar.
>

E eu me refiro exatamente a isto: justificar com informacoes reais,
que podem, a qualquer momento, ser confirmadas por quem quer
que seja.

Como disse antes e repito: JUSTIFICAR A ALOCACAO NAO SERIA
UM PROBLEMA.

Se algumas pessoas estao, com esta frase, comecando a pensar que
as justificativas seriam fraudulentas, sugiro que estas pessoas parem
de pensar.

> > Apenas gostaria de confirmar a seguinte premissa:
> >
> >  - para o registro.br, dado um bloco cidr, se houver a alocacao
> > de apenas um IP a terceiros (sejam eles clientes, fornecedores,
> > parceiros, etc), sera necessario preencher a requisicao como
> > sendo do tipo ISP.
>
> Eu acho que não. Um ISP é caracterizado por operação aberta, ou seja,
> se um cliente bater à porta e queira contratar um serviço que esteja
> dentro do seu portifólio e área de cobertura, ele deve conseguir.
> Ceder um IP a terceiro dentro de uma organização não-ISP é muito
> comum, e não caracteriza um ISP.
>

Como disse, nao esta clara a distincao entre um ISP e um nao ISP no
formulario do registro.br. Do jeito que esta escrito, qualquer IP que va
parar em um "terceiro", merece ser justificado como um ISP. So preciso
saber se este sera o nosso caso ou nao.

>
> > Bom, os "servicos criticos" sao varios. Um dos mais criticos
> > trata-se, basicamente, de uma serie de webservices envolvendo,
> > em um dado momento, transacoes quase financeiras.
>
> Os bancos, maiores representantes do sistema financeiro, por muito
> tempo só utilizaram conexões sem BGP, e ainda hoje mesmo com BGP
> utilizam outras formas de redundância. No caso dos bancos a mais usada
> é o produto LinkProof da Radware, mas você pode mimetizar o mecanismo
> que ele implementa usando DNS de TTL zero e controle das respostas de
> DNS conforme disponibilidade dos enlaces; a disponibilidade pode ser
> checada por métodos do tipo fim-a-fim para que sejam detectados
> inclusives casos de link-up entre você e a operadora mas down em algum
> ponto dali pra frente.
>

Em nenhum momento acreditamos que o BGP sera a solucao para todos
os problemas. Temos uma solucao baseada em DNS, mas ela nao atende
a todos os pre-requisitos essenciais. Possivelmente esta e' a mesma razao
pela qual os bancos estao utilizando BGP e algumas outras coisas adicionais
na solucao de disponibilidade deles.
>
> > Gostariamos de manter uma certa independencia dos nossos
> > provedores, ja que eles nao estao fazendo um bom trabalho...
>
> Nenhuma solução de confiabilidade, BGP ou o que for, vai resolver isso...
>

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'.

>
> > Apenas acho "engracado" que, pelo visto, terei de solicitar
> > um bloco /20, quando um /24 seria suficiente... De jeito nenhum
> > considero isso uma solucao "sensata".
>
> Não é só engraçado, é um mal uso de recursos escassos, que eu espero
> que seja detectado e evitado pelo CANIP.
>

Seria "mal uso" se nao fosse justificavel. Mas, como o e', considero engracada
e insensata a alocacao de um bloco /20 quando um /24 serviria, sem milagres,
e sem gambiarras: apenas trabalhando com proxy reversos, firewalls e mantendo
os verdadeiros servidores em uma rede DMZ com IPs privados.

>
> Rubens
>
>
> >
> >
> > On 1/14/08, Rubens Kuhl Jr. <rubensk at gmail.com> wrote:
> > > 2008/1/12 Marcus Andree <marcusandree at gmail.com>:
> > > > Prezados,
> > > >
> > > > Estou com a tarefa de implementar um AS para
> > > > melhorar a disponibilidade de alguns servicos criticos,
> > > > visto que ja temos duas conexoes independentes a
> > > > provedores distintos...
> > >
> > > Acho que a premissa aqui deve ser revista. A tarefa é melhorar a
> > > disponibilidade; implementar um AS não é factível no cenário que você
> > > descreveu pois ele não justifica alocação, mas há muitas alternativas
> > > de disponibilização de serviços críticos que não envolvem BGP e AS.
> > > Você poderia detalhar quais são os serviços críticos para que se possa
> > > sugerir alternativas para esse cada serviço em particular ?
> > >
> > >
> > > Rubens
> >
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>