[GTER] PTT-SP - Prazos

Eduardo Schoedler listas at esds.com.br
Wed Sep 2 00:57:19 -03 2015


Roberto,

Meu foco é vlan bilateral.

Filtro atual: IPv4, IPv6 e ARP.
Sugiro, ao menos, liberar MPLS (8847).

Tenho casos aqui em que contratamos circuitos de transporte de outros
ASes a partir do PTT.
Não consigo estender a rede mpls do core da nossa rede para a
localidade que quero, por exemplo.
Com todas as limitações que tem, perco muita flexibilidade.
Sem falar nos filtros de MAC... se preciso trocar o roteador
problemático no meio da madrugada, sou obrigado a clonar mac.
Acredito que também pode existir gente que queira usar PPPoE tb (BRAS
centralizado -- hardware especializado e caro).
E porque não liberar QinQ?

Para todos esses itens, basta usar VPWS.
No PTT-SP, acredito que isso não será problema, pois já foi comentado
que a infra de lá é MPLS.

Meus 2 cents.

--
Eduardo Schoedler

Em 2 de setembro de 2015 00:37, Roberto Bertó
<roberto.berto at gmail.com> escreveu:
> quais ethertypes que voce considera que deveria ser liberado e porque?
>
> Em terça-feira, 1 de setembro de 2015, Eduardo Schoedler <listas at esds.com.br>
> escreveu:
>
>> +1 para inovações técnicas
>>
>> Alguns:
>> - MTU maior;
>> - relaxamento de filtro de ethertypes;
>> - em casos de vlan bilateral, fazê-lo por VPWS, para não haver limitações
>> entre os participantes.
>>
>>
>>
>> Em terça-feira, 1 de setembro de 2015, Douglas Fischer <
>> fischerdouglas at gmail.com <javascript:;>> escreveu:
>>
>> > Congrats Moreiras!
>> >
>> > Ajuda de peso para o Ascenço, que por sinal estava precisando.
>> > (1- Não é um trocadilho com a massa corporal.
>> >  2- Mesmo que fosse, minha massa é de 110Kg. hahaha.)
>> >
>> > Dúvida
>> > Alguma mudança no escopo técnico surgindo?
>> > Pergunto isso pois é sabido que além dos chamados enfileirados, existem
>> > demandas de inovação técnica que também acabam caindo para segundo plano.
>> >
>> > Me refiro por exemplo a implementação de communities.
>> > Tarefa que deve ser de alta complexidade de implementação, mas que
>> > eliminaria uma boa parte dos chamados do meu.ptt.
>> >
>> >
>> >
>> > Em 1 de setembro de 2015 20:51, Antonio M. Moreiras <moreiras at nic.br
>> <javascript:;>
>> > <javascript:;>>
>> > escreveu:
>> >
>> > > Olá gente.
>> > >
>> > > Temos ciência de que os prazos de atendimento do IX.br nem sempre estão
>> > > dentro de valores esperados e, sim, estamos tomando ações internas para
>> > > melhorar. Entre elas, minha equipe está assumindo parte das tarefas
>> > > relacionadas ao atendimento das novas portas e ativações. Isso
>> significa
>> > > na prática mais gente trabalhando no IX.br, além da equipe do Eduardo
>> > > que continua cuidando da engenharia e operação em geral. Também
>> > > significa que vamos buscar mudanças na forma de atender aos
>> > > participantes. Peço um pouco de paciência porque estamos em uma fase de
>> > > transição e também porque a quantidade de chamados acumulada é bastante
>> > > grande, além de que devemos estar atentos à segurança e à estabilidade
>> > > do sistema como um todo. Não espero que haja novos resultados antes de
>> > > algumas semanas de trabalho.
>> > >
>> > > Sobre os testes de MAC, notem que seu roteador no IX.br troca tráfego
>> > > diretamente com todos os roteadores dos demais participantes e deles
>> > > deve aprender os MACs. Se não me falha a memória, temos em torno de 800
>> > > MACs no IX.br de São Paulo atualmente, e novos participantes entram a
>> > > cada dia. O teste de 1000 MACs visa garantir não só que seu roteador ja
>> > > está preparado para isso, mas principalmente que o transporte
>> contratado
>> > > e outros equipamentos no meio do caminho, como switches, também
>> estejam.
>> > > Em redes metro-ethernet, por exemplo, é comum haver limitações. Um
>> > > transporte com limitação na quantidade de MACs pode gerar problemas
>> > > intermitentes na produção, bem difíceis de diagnosticar. Na quarentena
>> > > são realizados também testes para verificar se a rede suporta um MTU de
>> > > 1500, a existência indevida de um proxy arp, protocolos de
>> gerenciamento
>> > > tipo MNDP ou CDP indevidamente ativados, RA IPv6, anúncios BGP sem os
>> > > filtros devidos, entre outros pequenos erros de configuração que
>> > > poderiam interferir no bom funcionamento se o participante os
>> mantivesse
>> > > na rede de produção.
>> > >
>> > > Atenciosamente,
>> > > Antonio M. Moreiras.
>> > > Gerente de Projetos e Desenvolvimento
>> > > Centro de Estudos e Pesquisas em Tec. de Redes e Operações (Ceptro.br)
>> > > Núcleo de Informação e Coordenação do Ponto BR (NIC.br)
>> > >
>> > >
>> > > Em 01/09/15 16:05, Jefferson Gondek escreveu:
>> > > > Boa tarde,
>> > > >
>> > > >   Teste com os MACs já é realizado a um bom tempo já....não é uma
>> coisa
>> > > TÃO recente...
>> > > >
>> > > >   No caso da Vlan Bilateral, se os dois lados responderem rápido, não
>> > > demora tanto......mas claro que esses atendimentos são de lua, tem de
>> > > torcer para estarem todos de bom humor.....
>> > > >
>> > > >   Realmente o caso de tempo em chamados para ativação, filtragem e
>> tudo
>> > > mais com a NIC.br está bem mais lento, levando em conta que a estrutura
>> > > deles aumentou consideravelmente nos últimos tempos...mas esperava um
>> > pouco
>> > > mais de uma organização de tempo, levando em conta a estrutura que a
>> NIC
>> > > tem. Já muito se discutiu com a interconexão dos PTTs, mas isso é uma
>> > longa
>> > > e velha thread....
>> > > >
>> > > >   O que podemos fazer, por mais frio e louco que se pareça, é
>> esperar e
>> > > ver se com as adequações que esperamos estarem acontecendo, esse tempo
>> > > milenar nos chamados se torne apenas algumas horas.
>> > > >
>> > > >
>> > > >
>> > > > ----- Mensagem original -----
>> > > > De: "Marcos Diego" <marcos at turbonetbr.com.br <javascript:;>
>> <javascript:;>>
>> > > > Para: "Grupo de Trabalho de Engenharia e Operacao de Redes" <
>> > > gter at eng.registro.br <javascript:;> <javascript:;>>
>> > > > Enviadas: Terça-feira, 1 de setembro de 2015 15:28:22
>> > > > Assunto: [GTER] RES:  PTT-SP - Prazos
>> > > >
>> > > > Rubens MTU é uma boa pedida
>> > > >
>> > > > Marcos
>> > > >
>> > > > -----Mensagem original-----
>> > > > De: gter [mailto:gter-bounces at eng.registro.br <javascript:;>
>> <javascript:;>] Em nome
>> > de Rubens Kuhl
>> > > > Enviada em: terça-feira, 1 de setembro de 2015 15:23
>> > > > Para: Grupo de Trabalho de Engenharia e Operacao de Redes
>> > > > Assunto: Re: [GTER] PTT-SP - Prazos
>> > > >
>> > > > 2015-09-01 14:52 GMT-03:00 Chadi Chakra <chadi at ubnt.com
>> <javascript:;> <javascript:;>
>> > >:
>> > > >
>> > > >> Eles estão fazendo um novo teste, agora exigem que o router
>> responda a
>> > > 1000
>> > > >> macs que são gerados simultaneamente, diversos colegas estão com o
>> > mesmo
>> > > >> problema, antigamente era somente checagem de perca de pacotes.
>> > > >>
>> > > >
>> > > > MTU também é testado agora, não ?
>> > > >
>> > > > Rubens
>> > > > --
>> > > --
>> > > gter list    https://eng.registro.br/mailman/listinfo/gter
>> > >
>> >
>> >
>> >
>> > --
>> > Douglas Fernando Fischer
>> > Engº de Controle e Automação
>> > --
>> > gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>>
>>
>> --
>> Eduardo Schoedler
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter



-- 
Eduardo Schoedler



More information about the gter mailing list