Mikrotik, quem é esta empresa?

Queridos leitores, é com enorme satisfação que aceitei o convite para estar colaborando com artigos, matérias e discussões neste nosso querido blog CCNA (Cloud Campus Networking Academy), abrindo espaço para novos fabricantes e discutindo abertamente novidades do universo das redes, perguntas, dicas e matérias de professores CloudCampus, profissionais do segmento, alunos, ex-alunos e amigos que fizemos ao longo de todos estes anos.

Como matéria inaugural vamos desmistificar um fabricante quem vem ganhando espaço no mercado Brasileiro a passos largos, Mikrotik, a empresa que saiu da congelante Letônia para invadir o mundo dos Provedores de Internet.

MikroTik é uma empresa da Letônia, fabricante de equipamentos para redes de computadores. Vende produtos wireless e roteadores. Foi fundada em 1995, com intenção de venda no mercado emergente de tecnologias wireless.

Seus equipamentos são muito utilizados por provedores de banda larga e empresas dos mais variados segmentos (hotéis, pousadas, universidades, empresas, etc) em todo o mundo, em função de sua conhecida versatilidade.

O principal produto da empresa é o sistema operacional baseado em Linux chamado MikroTik RouterOSEVERYBODY ou apenas RouterOS, que pode ser instalado em suas RouterBoard que é o nome dado a uma série de produtos MikroTik que combina o RouterOS com uma linha de hardware próprio, inicialmente projetados para provedores de pequeno, médios porte e hoje já oferece equipamentos para provedores de grande porte.

Existe também a opção de transformar plataformas x86 em um poderoso roteador, com funções como Servidor PPPoe, DHCP, VPN, Hotspots, Controle de Banda, QoS, Firewall, dentre outras opções que contam com inúmeras ferramentas de análise e monitoramento que variam de acordo com o nível de licença do sistema adquirido.

Com o RouterOS pode-se criar uma rede muito segura, com um firewall eficiente e concatenação de links. Além disso, o sistema conta com o suporte de protocolos de roteamento, entre eles BGP, RIP, OSPF, MPLS, etc.

Para a administração deste ambiente, os seguintes métodos estão disponíveis:

A Mikrotik produz diversos hardwares diferentes, segue outras funções/modos de operação que dependem do modelo do hardware:

Além das Routerboards feita pela própria Mikrotik, existem outros fabricantes de hardware que deixam o RouterOS ainda mais poderoso. Podemos citar as PowerRouter e FireRouter.

A Mikrotik ainda dispões de treinamentos no Brasil em Português para carreira Mikrotik e o site Tiktube com os vídeos das palestras ministradas no evento Mikrotik User Meeting ou apenas MUM, que contempla o Brasil anualmente com treinamento, palestras e lançamentos da Mikrotik.

No site da CloudCampus temos o treinamento de entrada na carreira Mikrotik – MTCNA, onde você pode dar o ponta pé inicial em sua nova carreira.

Bons estudos e até o próximo artigo.

Autor: Lacier Dias
Texto original: http://blog.ccna.com.br/

Google já vê 3% dos usuários em IPv6

A percentagem de usuários que o Google vê usando IPv6 é de 3%. Pode parecer pouco, mas em setembro de 2013 era de apenas 2%. Isso mostra que o uso do protocolo tem se acelerado. O gráfico original pode ser encontrado em:

http://www.google.com/intl/en/ipv6/statistics.html

De onde vem esse crescimento? O Google já está preparado para o IPv6 há algum tempo. O que ele consegue medir é a quantidade de acessos que seus usuários fazem usando IPv6. Mais usuários com IPv6 significa que mais provedores de acesso estão habilitando essa tecnologia.

No Brasil, os maiores provedores ainda não estão usando o novo protocolo, embora alguns estejam fazendo testes localizados. Temos “movimento”, contudo, na área acadêmica e em provedores médios e pequenos. Por exemplo, nas medições em: http://www.worldipv6launch.org/measurements/ vemos a Fundacao Parque Tecnologico Itaipu com quase 80% de sua rede pronta para o IPv6, o POP-BA da RNP com 51,3% e o provedor Maxiweb com 48,76%.

Leslie Daigle, da Internet Society, previu em artigo recente que a adoção de IPv6 chegará a dois dígitos (pelo menos 10%) ainda em 2014. Vendo essa tendência de crescimento, e toda movimentação dos provedores, ela provavelmente tem razão!

Autor: Antonio Moreiras – IPv6.br
Texto original: http://ipv6.br/google-ja-ve-3-dos-usuarios-em-ipv6/

Bloqueio de Sites e Nomes FQDN via ACL/NBAR

Olá Pessoal.
Esse artigo apresenta a solução para um problema comum nas empresas que é o bloqueio de determinados sites na Internet. A maioria das empresas utiliza um proxy para esse fim, o que é recomendado e torna as coisas bem mais fáceis. No entanto, nem sempre esse equipamento está disponível e pode ser interessante utilizar o próprio roteador de borda, responsável por prover acesso à Internet, para realizar esse serviço de filtragem, afinal todo roteador de borda é um firewall natural.
A princípio a escrita de ACLs no roteador de borda para bloquear um determinado site através do seu endereço IP de destino é realmente bastante simples, mas acontece que muitas vezes é necessário escrever regras dessa natureza informando como destino os nomes de domínio FQDN (fully qualified domain name), por exemplo www.labcisco.com.br.
Até então o problema parece continuar bastante simples, afinal basta substituir o endereço de destino pelo nome FQDN e tudo deve funcionar, não é? Não, nem sempre é simples assim… Os sites de serviços providos por grandes empresas, a exemplo da Google e Facebook (e vários outros) não possuem apenas um único endereço de destino, sendo acessíveis através de vários endereços para assegurar a disponibilidade em caso de falha.
Ao utilizar nomes de domínio na escrita de uma ACL, será realizado o processo de resolução de nomes apenas para o primeiro endereço válido e não para todos os endereços possíveis. Ou seja, caso o administrador queira bloquear o YouTube por completo, então seria necessário bloquear todos os endereços vinculados com o domínio youtube.com.
Uma solução para fazer isso seria levantar previamente todos os endereços IP correspondentes ao site que deve ser bloqueado e, posteriormente, escrever regras para cada um desses destinos. O problema dessa solução é que esses endereços não são estáticos e por isso é comum eles mudarem ao longo do tempo, o que torna o trabalho de bloqueio a sites bastante complicado.
Para resolver esse problema esse artigo apresentará um recurso denominado NBAR (Network Based Application Recognitionque será utilizado em conjunto com as ACLs tradicionais. O NBAR é uma ferramenta para implementar QoS que é suportada em todos os equipamentos mais recentes, viabilizando a classificação do tráfego da rede em categorias baseadas nos protocolos e outros parâmetros. O cenário desse laboratório é ilustrado na figura abaixo.
Implementar QoS requer a configuração de (1) classes de tráfego via class-map, (2) de políticas a serem aplicadas nessas classes via policy-map e (3) a inserção das políticas nas interfaces de rede via service-policy. Então utilizaremos class-map, policy-map e service-policy para classificar/marcar todo o tráfego destinado para youtube.com e, na sequência, utilizaremos ACLs para bloquear esse tráfego previamente marcado com a codificação DSCP (Differentiated Services Code Point) comumente utilizada para fins de QoS. Nosso objetivo nesse artigo não é aprofundar a discussão sobre QoS e nem entrar em detalhes da codificação DSCP.
Os comandos necessários para classificar o tráfego e bloqueá-lo são:
!—- Parte 1: Class-Map p/ Identificar o Site
01. Router(config)# class-map match-any Classe-YouTube
02. Router(config-cmap)# match protocol http url “*youtube.com*”
03. Router(config-cmap)# exit
!—- Parte 2: Policy-Map p/ Marcar a Classe de Tráfego
04. Router(config)# policy-map Politica-YouTube
05. Router(config-pmap)# class Classe-YouTube
06. Router(config-pmap-p)# set ip dscp 1
07. Router(config-pmap-p)# exit
08. Router(config-pmap)# exit
!—- Parte 3: Service-Policy p/ Aplicar a Marcação na Rede Local
09. Router(config)# interface f0/0
10. Router(config-if)# description “Rede Local”
11. Router(config-if)# service-policy input Politica-YouTube
12. Router(config-if)# exit
!— Parte 4: ACL p/ Bloquear o Tráfego Marcado
13. Router(config)# ip access-list extended NegaYouTube
14. Router(config-acl-ext)# deny ip any any dscp 1
15. Router(config-acl-ext)# permit ip any any
16. Router(config-acl-ext)# exit
!— Parte 5: Aplicação da ACL na Saída p/ Internet
17. Router(config)# interface f0/1
18. Router(config-if)# description “Internet”
19. Router(config-if)# ip access-group NegaYouTube out
20. Router(config-if)# exit
Observem na primeira parte que foi criada uma class-map para classificar todo tráfego HTTP com a URL desejada, processo realizado através da inspeção dos pacotes. Na segunda parte escrevemos uma policy-map que aplica o código DSCP=1 para todo perfil de tráfego identificado na class-mapanterior. A codificação DSCP tem alguns códigos padronizados, então optamos pelo código 1 porque provavelmente esse código não estará associado com nenhuma aplicação. Na terceira parte aplicamos a política de marcação dos pacotes em todo tráfego entrante na interface do roteador que está conectada na rede interna (gateway da rede interna). Por fim é configurada uma ACL que nega acesso a todo pacote que tenha o campo DSCP=1, cabendo destacar que essa regra deve ser aplicada no sentido sainte da interface conectada à Internet.

Uma observação importante é que essa solução funciona muito bem para tráfego HTTP (80) porque o NBAR consegue fazer a inspeção do cabeçalho dos pacotes, no entanto é impossível fazer a leitura de conteúdo cifrado via HTTPS (443). Por isso o NBAR não irá funcionar para serviços que somente operam através do HTTPS. Nesse caso o jeito é fazer uso das vantagens de um proxy…
Abraço.

Samuel.

Redundância para Cisco WLAN Controllers

Antes da versão 7.3 (Mobility Group)

A redundância de Controladoras, quando usamos software anterior a versão 7.3, é alcançada usando Mobility Group.

Neste tipo de redundância cada AP está associado a uma WLC, e no caso de falha, o access-point se registra em outra WLC que faz parte do Mobility Group. Access-point e cliente perdem o acesso a rede temporariamente.

Esta é uma redundância do tipo N+1, e a “convergência” demora mais do que nos outros métodos.

Por outro lado, todas as controladora suportam este tipo de redundância e podemos configurar um Mobility Group com WLCs de modelos diferentes.

WLC 7.2 HA.jpg

“Um Mobility Group é um conjunto de controladoras, identificadas com o mesmo nome do Mobility Group, que define o âmbito de roaming para clientes sem fio. Ao criar um Mobility Group, você pode ativar várias controladoras em uma rede para compartilhar dinamicamente informações e dados permitindo o roaming inter-controladora ou inter-sub-rede. Controladoras no mesmo Mobility Group podem compartilhar o contexto e o estado dos dispositivos dos clientes, bem como a sua lista de pontos de acesso. Com estas informações, a rede pode suportar roaming inter-controladora e redundância da controladora.”

Observe que neste caso não há sincronização de configuração, sendo cada WLC configurada individualmente.

Mais informações sobre o Mobility Group neste link.

Versão 7.3 e 7.4 (HA – AP SSO)

Na versão 7.3 foi introduzido um novo método de redundância, chamado High Availability – AP SSO. Neste novo método a redundância é do tipo 1:1, com uma WLC ativa e outra em Standby, sendo que os access-points estão associados a WLC ativa e tem ainda “uma conexão backup com a WLC que está em standby”.

Para usarmos o HA – AP SSO precisamos de uma conexão direta entre as duas WLCs (ativa e backup), usando a Redundancy Port.

WLC 7.3 HA.gif

“No HA AP SSO uma WLC estará em estado ativo e a segunda WLC vai estar em Standby Hot, monitorando continuamente a saúde da WLC através da porta redundante. Ambas as WLCs irão compartilhar o mesmo conjunto de configuração, incluindo o endereço IP da interface de gerenciamento. A WLC no estado de espera não precisa ser configurado de forma independente com toda a configuração sendo sincronizada da WLC Ativa para o WLC de espera através da porta redundante. O estado do AP CAPWAP (apenas APs que estão em um estado de execução) também é sincronizado, e uma cópia do banco de dados dos APs é mantida na WLC de espera. Os APs não entram em estado de descoberta quando a WLC ativa falha.”

Este método está disponível para as controladoras 3650, 5500, 5760, 3850, WiSM2, 7500 e 8500.

Mais informações sobre o HA AP SSO nos links abaixo:

Configurando HA – AP SSO

HA (AP SSO) – Deployment Guide

Versão 7.5 (HA – Client SSO)

A partir da versão 7.5 temos a evolução do HA, onde além dos access-points temos também o “Stateful Switch Over” para os clientes.

Ou seja, no caso de falha da controladora primária, os access-points e clientes fazem a transição para a controladora backup de forma transparente.

Neste modelo (também 1:1) além da configuração e informações dos access-points, também é sincronizada a tabela de estado dos clientes.

WLC 7.5 HA.jpg

“A transição transparente de clientes da controladora ativa para o controladora backup também é suportada. Durante o Client SSO, a informação do cliente é sincronizada com a controladora backup quando o cliente está associado com a controladora ativa. Clientes que estão totalmente autenticados, ou seja, os clientes que se encontram no estado de execução, são sincronizados com a controladora backup. A estrutura de dados dos clientes são sincronizadas com base no estado do cliente.”

Este método está disponível para as controladoras 5500, WiSM2, 7500 e 8500.

Mais informações sobre o HA Cliente SSO:

Configurando HA – Software 7.5

Deployment Guide – HA Client SSO – Software 7.5

Bom… esse é um resumo sobre a redundância em WLAN Controllers Cisco.

Até a próxima.

Fonte: Brainwork

O diálogo sobre a transição para o IPv6 no Brasil

O NIC.br tem conduzido há meses uma série de reuniões com diversos participantes para discutir a questão da transição tecnológica do IPv4 para o IPv6 na Internet. Nesta ultima quarta, 12 de fevereiro, aconteceu a mais recente.

A transição é forçada pelo esgotamento mundial dos endereços livres no protocolo antigo, o IPv4 (em uso desde 1983), e vem sendo anunciada amplamente desde o início da década de 1990. Apesar da solução estar disponível há anos,muitas empresas postergaram demasiadamente o início da mudança, levando-nos à situação atual, que é problemática. O esgotamento dos IPs já aconteceu em diversas regiões do mundo, e ocorrerá nas Américas ainda em 2014. Como nem todos estão preparados, será necessário compartilhar os endereços antigos entre diversos usuários, o que leva a problemas de desempenho e segurança. O mais grave é a dificuldade de identificar um criminoso online.

Nas reuniões de coordenação que acontecem na sede do NIC.br, desde 2012, participam associações de provedores, Polícia Federal, Ministério Público, associações de e-commerce, bancos, operadoras de telecomunicações, ANATEL, fabricantes de equipamentos, entre outros, além de um representante do Comitê Gestor da Internet e da própria equipe técnica do NIC.br. Nesse tempo, foi possível aumentar o nível de compreensão de todos os envolvidos sobre o problema e criar um consenso em torno das soluções: é precisoacelerar a implantação do IPv6 e adotar uma medida paliativa na guarda de informações do IPv4 para provedores de conteúdos e serviços na rede, acrescentando a guarda da porta de origem, para quem já faz logs de IPs e instante do acesso.

Na última reunião houve uma proposta polêmica para que o NIC.br tentassse postergar o esgotamento dos endereços IPv4 livres. Isso nos motiva a fazer alguns esclarecimentos em relação à forma como eles são distribuidos.

A distribuição de recursos de numeração na Internet, como blocos de endereços IPv4, segue princípios que são comuns em todo o mundo, sendo realizada por um conjunto de instituições organizadas em uma hierarquia. Os blocos distribuídos pelo NIC.br são repassados a ele pelo LACNIC, que é o Registro Regional para América Latina e Caribe. O LACNIC, por sua vez, recebeu seus endereços da IANA/ICANN. A distribuição dos endereços é sempre feita com base em necessidades justificadas. Funciona dessa forma para o LACNIC e para todos os demais registros regionais (Afrinic, ARIN, APNIC e RIPE NCC). Cabe destacar que os estoques do APNIC e do RIPE NCC teminaram já em 2011 e 2012, respectivamente, devido ao grande volume de alocações nessas regiões, que é conseqüência do crescimento natural da Internet.

Alocações de IPv4 anuais (em milhões de IPs) - fonte: análise de Geoff Huston

Alocações de IPv4 em 2013 (em milhões de IPs) - fonte: análise de Geoff Huston

Em nenhum momento o LACNIC recusou repasses de blocos de endereços IPv4 ao NIC.br e, analogamente, o NIC.br nunca recusou alocações a operadoras ou provedores de acesso, quando justificadas adequadamente. Em 2013, o Brasil foi o segundo país no mundo com mais alocações de endereços IPv4, atrás apenas dos EUA, sendo que o provedor que mais recebeu endereços foi brasileiro, conforme pode ser visto em recente artigo de Geoff Huston [1], cientista chefe do APNIC.

Aventou-se a possibilidade de que o NIC.br fosse buscar endereços junto a empresas norte americanas, que receberam grandes conjuntos de IPs no início da operação da Internet. Contudo, o processo seria complexo, caro, e o número de endereços provavelmente faria uma diferença apenas marginal, dada a velocidade de crescimento da rede no mundo e, em particular, no Brasil. Regras para permitir estas transferências de endereços diretamente entre as empresas já estão em vigor na América do Norte e Asía/Pacífico, desde final de 2012, e o total já transferido foi de pouco mais que 500 mil endereços IPv4. Quantidade bastante pequena considerando o uso desses recursos nos últimos anos.

Nada pôde ser feito pelo APNIC ou pelo RIPE NCC para evitar o esgotamento dos endereços em suas respectivas regiões. Os recursos são finitos, e o crescimento contínuo da Internet é uma realidade. Esse crescimento é visto como algo bom, positivo, e inclusive incentivado por políticas públicas no Brasil e no mundo. Não há nenhuma ação que possa ser feita para mitigar a escassez dos endereços IPv4. Eles realmente se esgotarão nos próximos meses.

O NIC.br tem atuado continuamente para garantir que nenhuma empresa receba blocos maiores de que os que realmente necessita, prejudicando os demais. Nos últimos 4 anos, vale destacar, houve um grande esforço para a recuperação de blocos sem uso, além de enfatizar, junto às grandes operadoras e todas as demais redes, a importância de se investir esforços para garantir o uso eficiente dos recursos. É possível afirmar que hoje não há desperdícios ou estoques de endereços nos provedores e operadoras, além do necessário para sua operação normal.

Em todos os setores, as empresas têm projetos em curso para a implantação do IPv6. Há, contudo, uma dificuldade muito grande para que se comprometam com prazos bem definidos, mesmo considerando a proximidade do esgotamento dos endereços antigos. Um problema bastante sério acontece com os equipamentos utilizados por consumidores domésticos, como smartphones e roteadores wifi: boa parte dos equipamentos vendidos no mercado ainda não suportam IPv6. Durante as reuniões, há algum tempo já se entendeu que o melhor caminho para resolver essa situação seria acrescentar o suporte ao IPv6 nos requisitos da homologação que já é efetuada nesse tipo de equipamento pela ANATEL. A equipe técnica do NIC.br tem colaborado com a Agência Reguladora na definição do conjunto de requisitos e em breve a ANATEL deverá publicar as novas regras.

Outro problema sério é que algumas das operadoras de telecom responsáveis pelo backbone da rede estão atrasadas na implantação do IPv6. Isso atrasa toda a cadeia envolvida no fornecimento de serviços na Internet: pequenos provedores, datacenters e empresas não podem avançar se não houver oferta de trânsito IPv6 por parte das principais operadoras. O caso mais grave é o de uma grande operadora com atuação majoritária na região nordeste do país, que não oferece o serviço nem em caráter experimental ainda. A situação levou o Comitê Gestor da Internet a interpelar formalmente as operadoras, em dezembro de 2013, por meio de ofício. A inação de algumas delas provocou recentemente uma bem vinda reação da ANATEL, que as convocou para uma reunião à portas fechadas na semana passada, anunciando na reunião no NIC.br, no dia 12, que atuaria mais fortemente junto a esse setor para que um cronograma fosse definido nos próximos dias. O representante da superintêndencia de planejamento e regulamentação da Agência afirmou que espera uma resposta muito rápida das operadoras e comprometeu-se a ter o cronograma em mãos para a próxima reunião no NIC.br, prevista para o final de março.

Outros pontos positivos, abordados na última reunião, foram a formação de um grupo de trabalho na FEBRABAN para tratar desse assunto, e ações da Câmara-e.net junto aos sites de comércio eletrônico, visando acelerar a implantação do IPv6.

Uma das ferramentas utilizadas pelo grupo de entidades que se reune no NIC.br é um termo de compromisso: um documento que discute o problema, as soluções e tarefas de cada grupo de empresas. Não é um contrato ou regulamento com cláusulas que estipulam penalidades, mas um acordo de cavalheiros, com compromissos a serem assumidos livremente. O processo de elaboração do documento, em si, ajudou o grupo a compreender melhor a situação e os possíveis caminhos para sua solução. Quando pronto, o documento também será útil para a divulgação das ações necessárias. Por exemplo, o Ministério Público e a Polícia Federal poderão usá-lo internamente para explicar a todos o que mudará quando houver a necessidade de identificar um usuário da Internet junto a um provedor de acesso. Chegou-se muito perto do ponto em que poderia ser assinado, mas após as intervenções da ANATEL e Câmara-e.net na última reunião, todos concordaram que seria melhor fazê-lo apenas quando todos apresentassem cronogramas claros de trabalho.

Acompanhando as ações recentes da ANATEL, da FEBRABAN, da Câmara-e.net, além de notícias sobre a implantação do IPv6 em muitos pequenos provedores, sites e outros serviços, há espaço para um otimismo moderado. Há muito ainda para ser feito, mas parece que estamos no caminho correto.

Por Ricardo Patara e Antonio M. Moreiras

Next Page →