[caiu] PTTs - Fora

[Eduardo Ascenco Reis]

Prezados Clayber e demais membros do AS XY,

Utilizar emails não corporativos (e.g. gmail) ou anônimos em listas como 
a caiu pode ser entendido e válido, porém para que um caso técnico possa 
receber atenção adequada a identificação é fundamental.

Por favor, crie um usuário no portal Meu PTT (https://meu.ptt.br/), faça 
o seu vínculo com o AS28329 e faça as interações por lá.

O sistema do Meu PTT permite controle e formatação das informações 
trocadas e valida se você realmente pode interagir em nome do AS em 
questão, além de outras coisas.

No momento, o seu nome e email não existem na base do Meu PTT o que 
inviabiliza o atendimento do caso.

On 12/27/2014 01:49 PM, Clayber Oliveira wrote:
> Alguém com problemas para os PTTs?
>
> Estamos com o PTT-DF, PTT-CAS, PTT-GYN e PTT-PR parados desde dia 24 já
> abrimos chamados no portal e até agora sem nenhum retorno.
>
> Alguém com o mesmo problema ou alguma ajuda?

Você ou alguém do AS XY chegou a ligar para o NOC do PTT.br para 
solicitar urgência de atendimento?

Em caso afirmativo, por favor nos envie via portal Meu PTT as 
informações de telefone de origem e horários para análise de registros 
de ligações.

Segue alguns fatos:

1. As localidades do PTT.br são isoladas, assim cada uma é um PTT distinto;

2. O PTT.br disponibiliza acesso público via web aos gráficos de tráfego 
agregado e entre os PIX de cada localidade. Problemas na infraestrutura 
do PTT.br ou com grandes participantes (e.g. Google) normalmente 
apresentam mudanças significativas no perfil desses gráficos. No caso 
(últimos dias nas localidades indicadas), nada de anormal foi observado;

Exemplo URL de Agregado Total (Goiânia)
http://ptt.br/trafego/agregado/gyn

3. O PTT.br disponibiliza acesso remoto via telnet para o servidor 
coletor de prefixos (looking glass) de cada localidade. Uma consulta com 
o comando "show ip bgp summary" pode ajudar a mostrar o estado do Acordo 
de Troca de Tráfego (ATM) de cada localidade (e.g. lg.gyn.ptt.br para 
Goiânia).

Uma análise inicial considerando os pontos acima e o que você informou 
identifica como ponto comum do problema o seu próprio AS.

On 12/27/2014 07:28 PM, Clayber Oliveira wrote:
> O problema é exatamente esse de estouro de prefixos, mas já tínhamos feito
> a solicitação para ampliação do número máximo de prefixos anteriormente.
>
> Então quando ultrapassamos o limite, ocorreu a queda de nossas conexões que
> agora restam PTT-CAS e PTT-GYN.
>
> A principio postei na lista, para receber o auxilio de alguém do NIC.br,
> pois com o ticket aberto no portal ainda não havia recebido nenhum contato.

Deixando de lado o fato de você já saber a causa do problema e ter 
enviado uma mensagem inicial com informações genéricas, vou tratar o 
lado técnico do controle de número de prefixos, em particular no PTT.br.

Segue URLs de referência (Cisco):
Configuring the BGP Maximum-Prefix Feature
http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/25160-bgp-maximum-prefix.html
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-3s/irg-xe-3s-book/irg-max-prefix.html

Pessoalmente entendo que os Sistemas Autônomos (AS) deveriam ter 
controle de número de prefixos recebidos em todas as suas sessões eBGP, 
inclusive as de trânsito com tabela completa, além de outras proteções. 
As sessões iBGP não abordarei, mas também são críticas.

No PTT.br, os servidores de rotas (RS) que atendem o ATM de cada 
localidade possuem controle de número de prefixos recebidos de cada 
participante, em IPv4 e IPv6.

O número máximo de prefixos aceitos pelo PTT.br é definido em conjunto 
com o participante e configurado no momento da sua ativação. Alterações 
nesse valor devem ser solicitadas pelo portal Meu PTT como Pedido de 
Prefixos.

Destaco que o participante sabe quantos prefixos anuncia (sua gerência) 
e quantos estão configurados no controle do PTT.br (acordado).

O PTT.br utiliza o parâmetro adicional de restart com 10 minutos de 
intervalo.

Quando o limite de prefixos recebidos (e.g. IPv4) de um roteador de 
participante é ultrapassado, o RS derruba a sessão BGP, envia uma 
mensagem BGP de notificação sobre o ocorrido e aguarda 10 minutos para 
reiniciar automaticamente a sessão BGP. O processo é repetido de forma 
indefinida se o número de prefixos recebidos pelo RS continuar a 
ultrapassar o limite definido e configurado.

Do ponto de vista do participante, quando a condição de estouro do 
número de prefixos é atingida, ele deve observar que o estado das 
sessões BGP com os RS oscila e a análise das mensagens de log BGP no seu 
roteador devem informar a origem do problema.

O participante do PTT.br pode então reduzir o número de prefixos 
anunciados para os RS, aguardar um intervalo de 10 minutos, observar que 
as sessões BGP foram reestabelecidas, assim como o seu tráfego para o 
ATM e então abrir um chamado de Pedido de Prefixos no Meu PTT para 
solicitar a ampliação do número máximo de prefixos aceitos pelo PTT.br.

Como o controle de prefixos anunciados para o PTT.br depende 
exclusivamente do participante, assim como o reestabelecimento das 
sessões quando ocorre a condição de estouro desse limite, o PTT.br 
considera que este tipo de chamado não seja caso de suporte e que 
portanto possui menor prioridade de atendimento.

Atualmente algumas localidades do PTT.br, como São Paulo, possuem grande 
quantidade de pedidos, como apresentado no último PTT Fórum:

http://ptt.br/pttforum/8/doc/02-PTT_Forum8-Estatisticas.pdf

Dessa forma, no momento a demora no atendimento da alteração do número 
de prefixos aceitos pelo ATM em cada localidade do PTT.br deve ser 
considerada pelo participante como altamente provável.

Atenciosamente,

-- 

Eduardo Ascenço Reis


PTT.br - http://ptt.br/
NIC.br - http://nic.br/