segunda-feira, 28 de novembro de 2011

sexta-feira, 11 de novembro de 2011

Utilizando FIltros BGP no Mikrotik / CISCO / Quagga

Link:

https://docs.google.com/presentation/d/1F4XkpIcUq_T1SZBPeYaQOkvdLCXSssK9LDFM8pFNhJw/present#slide=id.p

Essa apresentação foi baseada em duas palestras em São Paulo no MUM 2011 8/11/2011 (Mikrotik User Meeting) e no IV Encontro Nacional da ANID 9/11/2011 e tem como objetivo facilitar o entendimento da Internet e trocas de tráfego, ajudando os novos sistemas autônomos a adotar boas práticas com relação a manipulação de rotas e anúncios para a internet utilizando as interfaces CLI do RouterOS, CISCO IOS e Quagga.




segunda-feira, 11 de abril de 2011

PNBL - Governo exige mínimo de 1Mb por R$ 35

#Depois de alguns anos isso será lembrado como algo bom para todos os provedores.

"pq algumas pessoas tem o pensamento de apontar um amplicador em cima do enlace do outro quando deveriam estar trocando tráfego" ;-)

Lembro que muleque, era doido para que minha mãe assina-se Um certo provedor A que vou chamar de UOL , minha maior motivação era porque vários amigos meus da escola jogavam Counter-Strike num servidor UOL, e eles sempre me matavam mais rápido por algum motivo que eu não entendia na época, mas sabia que tinha alguma coisa haver com uma coisa haver com uma coisa que tinha lá que a gente chamava de latência, a minha era 180~250... as vezes até mais que isso. A deles eram em torno de 30~40 e era como se eles me vissem antes q eu pudesse ver eles, e algumas vezes eu nao conseguia nem atirar neles. Naquela época eu não tinha a mais pálida chance de compreender pq a minha latência era maior que a deles, mas por outro lado descobri que meu vizinho jogava Couter-Strike tb, mas a gente conseguiu passar um cabo do andar dele para o meu, e depois de uma certa dificuldade descobrimos que nunca funcionaria sem um cabo cross-over. Aquilo era fantástico para meus olhos, uma latência de 10ms para baixo, eu senti uma grande diferença na jogabilidade.

O importante é que por algumas horas nós conseguíamos esquecer que precisávamos da "internet" para fazer a única coisa que fazíamos o dia todo (Jogar Couter-Strike ;-). A pergunta que os provedores tem que fazer hoje para conseguir vender 1Mbps por R$ 35,00 é: "Existem alternativas fora da INTERNET? a Internet está do outro lado das fibras de OI, Embratel, Telefônica, NET, etc. Ainda não temos (pequenos provedores) condições técnicas de abandonar as grandes operadoras, mas podemos precisar delas cada vez menos, de maneira gradativa. A NET é de certa forma dá um exemplo de que isso é possível, de que existem sim alternativas do "lado de ká". Por ter ligação com a Globo, a NET detém muito conteúdo (entretenimento) de interesse de milhões de internautas do brasil e outros países, fazendo com que uma parcela do tráfego total de seus clientes não precise vir da "internet", diminuindo a latência e o preço de link para seus clientes finais. A meta é R$ 35 por 1Mbps? Ouvi algo na televisão falando de R$ 29 por 1Mbs, significa que com meta do Governo ou não, os provedores precisam de novas práticas por causa da CONCORRÊNCIA mesmo.

Então os provedores devem, na minha opinião, enxergar isso como um glorioso alerta salvador, uma espécie de "balde de água" para despertarem de alguma eventual sonolência. A novas práticas não são "artigo de ornamento" =P todos precisam trocar tráfego, e ter em média 40Mbs de Transporte para cada 100 Mbs de link total, ou seja, ao invés de comprar 100Mb de Transito IP, deve-se comprar apenas 60Mb, e os outros 40Mb contrata-se com alguma operadora transporte para os pontos de troca de tráfego. A internet brasileira agradece e o o preço final do seu link vai ficar mais barato algo por volta de R$4.000 para esse exemplo de 100Mbs*

*esses valores podem variar uma margem de 10% para mais ou para menos (mais provamelmente para menos porém alguma sobra é importante, devido em qualquer momento o trafego pelo transporte pode aumentar com a adesão de um novo agregado.

Também não existem restrições de que dois agregados tenham vlans exclusivas entre si nesses pontos de troca o que na prática me possibilita uma nova prática para os provedores pequenos:

Sou provedor A e tenho um cliente empresa querendo interliga-se com sua filial em outro estado. Mas eu apenas presto serviços no meu estado. Essa filial é cliente do provedor B que participa da mesma troca de tráfego que eu. Sendo assim, posso solicitar ao NIC.br uma VLAN para que eles façam um trunk da minha porta/vlan até a porta/vlan do provedor B. Em tese, eu não devo pagar nada para o provedor B nem ele deve me pagar nada, e cobramos o nosso preço de nossos 2 clientes (cada um cobra do seu). O custo desse serviço para cada provedor é algo em torno de R$ 100 por cada Mbs. Valor que ainda pode cair para menos da metade se a distância geográfica entre nós seja menor.

Hoje existem muitas razões técnicas para que todas as grandes "Teles" passem uma fibra de uma para outra diminuindo assim as latência e aumentem a satisfação dos seus clientes. Em contrapartida existem muito mais razões financeiras, burocráticas e outras que fogem da minha compreensão para NÃO PASSAREM cabo algum entre si. Mesmo que pareça absurdo a primeira vista para muitos de nós, existe sim algumas razões fortes para o traceroute de um cliente Globalcrossing denunciar que os pacotes vão até Miami e voltam para o Brasil. Se Globalbrossing, Embratel, Telefônica e outras estão (em comum) em grandes Datacenters, pq não participam das trocas de tráfego do PTT-Metro?


Receio hoje que a internet do brasil "ainda" não é de todos porque continua muito dependente das grandes "Teles" para regular o "preço final" em que cada brasileiro paga hoje (por cada Mega) para ter acesso a Internet.
O volume de TOTAL de tráfego somando todos os pontos de troca organizados pelo NIC.br no Brasil atinge hoje picos de 50Gbps (50 Gigabits por segundo) , o que no final do mês soma algumas unidades de mihões de reais a menos que foram bara o bolso das Teles. As trocas de tráfego tem tanto poder hoje em dia que obrigaram as próprias teles a viabilizar serviços de transporte para os PTT's para clientes de médio e pequeno porte pois se sentem pressionadas a se adaptar a essas mudanças. Depois da adesão até do Google é visível como a internet brasileira está se adaptando a nossa realidade de país em desenvolvimento, é uma questão de anos para que as grandes operadoras vão "precisar" participar das trocas de trafego também para sobreviverem à evolução da internet no Brasil, e chegará o momento que essas grandes teles participarão das trocas de tráfego para viabilizar novos negócios. acredito que será bom para o mercado de internet essa meta "difícil" imposta pelo governo, pois vão surgir novas praticas e novos costumes, novos tipos de serviço, que vão dar uma melhor distribuição do acesso à internet, contribuindo com a inclusão digital nas comunidades sem depender dos preços absurdos impostos pelas grandes Operadoras de Telecom&Cia.



domingo, 20 de março de 2011

Mikrotik RouterOS - Monitorando perdas de pacotes

Essa é uma mandeira mais cômoda de detectar perdas de pacote nos links.


1- Primeiro passo, criar um script com o seguinte código fonte:

# Essa linha cria uma variável e insere o nome do equipamento
:gl equip ([:pick [/sys id get name] 0 3])


#essa linha escreve uma mensagem no LOG para avisar que os 100 pings iniciaram

:log warning "Iniciando ping para meu gateway padrão..."


#essa linha executa 100 pings para o IP do gateway padrão com pacotes de 1500 e com a flag de não fragmentação ligada.
:gl teste [ping 192.168.0.1 size=1500 do-not-fragment count=100]
#note que nesse tipo de comando a variável vai receber a quantidade de pacotes RECEBIDOS


#essa linha avisa que os 100 pings foram terminados
:log warning "Pings para gateway padrao encerrados."


#como informado acima, o valor que a variável $teste vai receber é a quantidade de pacotes recebidos, sendo assim, a linha abaixo vai subtrair o valor total de pacotes recebidos da quantidade total de pacotes enviados (100).
:gl perdas [(100-$teste)]
#agora temos de fato a quantidade de PACOTES PERDIDOS na variável $perdas


#as linhas abaixo descrevem as ações tomadas caso o resultado do teste condicional ($perdas>0) seja positivo. Após o comando "do". É possível executar vários comandos colocando apenas um ponto e vírgula no final de cada. Escolhemos escrever no LOG, e também enviar um email com o nome do equipamento (variavel $equip) e a quantidade de pacotes perdidos.

:if condition=($perdas>0) do=[log warning " $perdas% de perdas"; log warning "Enviando email..." ; /tool e-mail send to=" meu_email@gmail.com" subject=(" ALERTA!! O equipamento - ".$equip." está com ". $perdas."% de Perdas") from=" meu_email@gmail.com"; log warning "Email enviado." ] else=[log warning "teste concluído sem perdas"]

#Caso o resultado do teste condicional ($perdas>0) for negativo, serão executados apenas os comandos depois de "else=" e que nesse caso apenas gera uma mensagem no log avisando que não há perdas de pacotes.


#esse exemplo pode ser melhorado executando ações como mudança de link desabilitando uma sessão BGP com a operadora problemática, e muitas outras opções, dependendo das particularidades de cada rede.

2- Segundo passo, no menu system scheduler você manda executar esse script a cada 5 minutos. (+ ou - caso jugue necessário)

Agradecimento especial para Edilson José que me ajudou a melhorar esse código.