Túnel GRE + IPSec entre Cisco IOS e Huawei NE40
Neste post iremos discutir um cenário muito comum (e pouco documentado), que é utilizar um túnel GRE protegido com IPSec entre um roteador Cisco IOS ASR1002 e um Roteador Huawei NE40. A topologia deste exemplo é descrita abaixo. Ela foi mantida simples para que possamos discutir os detalhes do GRE+IPSEC, sem entrar nos demais pontos da rede. Nela temos o roteador Cisco com endereço IP público 198.51.100.2 e o roteador Huawei NE40 com o IP público 203.0.113.66. Ambos estão conectados à Internet, e com conectividade entre si. Precisamos estabelecer um túnel GRE entre os roteadores e protegê-lo através do IPSec no modo tunnel. O endereçamento do túnel é 172.31.31.0/30. Nas próximas linhas abaixo iremos falar sobre o GRE e IPSec. O objetivo não é detalhar completamente estes protocolos, mas dar um overview e principalmente, uma base para o restante do artigo. Não seja apressado, há informações bem relevantes ali no meio. GRE O Generic Routing Encapsulation (GRE) é um protocolo de tunelamento que consegue encapsular uma variedade de protocolos de rede (ex: ATM, IPX, IPv6 e até mesmo IPv4) dentro de pacotes IPv4. Estes pacotes então podem ser transmitidos através das redes IPv4 comuns (ex Internet). Alguns casos de uso do GRE:interligar redes internas desconectadas entre siinterligar redes IPv6 isoladas por meio de redes IPv4estabelecer comunicação Matriz x Filial pela Internetlinks de mitigação com VPNs quando necessários protocolos de roteamento IPSEC O IPSec é um framework de segurança desenvolvido pelo IETF que busca resolver problemas de segurança que o protocolo IPv4 não conseguiu tratar, como por exemplo encriptação, integridade de dados, validação de origem e anti-replay. Na realidade o IPSec não é um único protocolo, e sim uma combinação de protocolos e algoritmos. Os principais são o IKEv1, IKEv2, ESP e o AH. O IPSec é usado amplamente nas VPNs, sejam elas de remote-access e também nas site-to-site. No ciclo de vida de um túnel, temos 5 etapas bem definidas: Definição do tráfego interessanteO tráfego interessante é o gatilho que faz com que o túnel seja estabelecido. O roteador ou firewall, ao notar um tráfego interessante, inicia as próximas etapas da negociação do IPSec. O tráfego interessante geralmente é configurado na forma de ACLs, ou policies de tráfego. IKE fase 1Na fase 1 o protocolo estabelece um canal seguro de comunicação com o peer remoto. Uma vez estabelecido este canal seguro, as trocas de mensagens da fase 2 são permitidas.É na fase 1 que são protegidos os peers, autenticados, e as policies de ISAKMP são comparadas (e precisam casar). Existem dois modos, main e aggressive. Termos que você vai ver sobre a fase 1: ike, isakmp, DH group, pre-shared-key, integrity, isakmp policy IKE fase 2Nesta fase, já com o túnel seguro protegido estabelecido na fase 1, podemos negociar o que chamamos de IPSec SAs, que nada mais são os “contratos” do tipo de tráfego que serão protegidos pelo túnel IPSec, negociados dinamicamente. Um exemplo pode ser “vou proteger o tráfego da rede 192.168.1.0/24 quando o destino for 192.168.2.0/24 usando o algorítimo de encriptação X e de autenticação Y”, e o peer remoto faz a regra no sentido inverso. Outra função da fase 2 é manter os SAs, assim como expirar as chaves e as sessões caso algum parâmetro seja alcançado (ex: expire os SAs e negocie novos a cada x horas, ou a cada N kilobytes). Termos que vamos ver sobre a fase 2: ipsec, ipsec sa, crypto acl, transform set, mode tunnel, authentication, encryption, ipsec policy Transferência de dadosNesta fase é a transferência de dados em si. Assim que o tráfego interessante chega no roteador, e as fases 1 e 2 são completas, os pacotes são enviados de acordo com os contratos estabelecidos nos IPSec SA, sendo transmitidos até o peer remoto. Encerramento do túnelO encerramento do túnel acontece por processo manual, ou quando algum parâmetro do IPSec expira ou chega ao seu limite. Neste caso, todas as chaves são descartadas, os contratos desfeitos e se o tráfego precisar ser encaminhado, um novo túnel IPSec precisa ser estabelecido. Para mais detalhes do GRE e IPSEC, consulte as referências citadas no final do artigo. As configurações de GRE e IPSEC acordadas entre as partes O exemplo abaixo é de como as informações de VPN são acordadas. Geralmente são formulários que são preenchidos com as informações sobre o túnel. VPN Device Site A VPN Device Site B VPN Device VPN Peer IP Address * 198.51.100.2 203.0.113.66 Device * Cisco ASR 1004 Huawei NE40-M2K Version * V3.0.6 <COLOCAR_VERSAO> Tunnel Properties Site A VPN Device Site B VPN Device Phase 1 Authentication Method <Pre-Shared Key> UmaSenhaBemS3gur@ <Pre-Shared Key> UmaSenhaBemS3gur@ IKE version IKEv2 IKEv2 Diffie-Hellman Group group 14 group 14 Encryption Algorithm * AES 256 AES 256 Hashing Algorithm * SHA-1 SHA-1 Main or Aggressive Mode * Main mode Main mode SA Lifetime * (for renegotiation) with no kbytes rekeying 86400 seconds 86400 seconds Phase 2 Encapsulation * (ESP or AH) ESP ESP Encryption Algorithm * AES 256 AES 256 Authentication Algorithm * SHA-1 SHA-1 Perfect Forward Secrecy for rekeying * Disabled Disabled Diffie-Hellman Group * group 14 group 14 SA Lifetime * (for renegotiation) ) with no kbytes rekeying 3600 seconds 3600 seconds GRE Addressing 172.31.31.1/30 172.31.31.2/30 Keepalives Disabled Disabled MTU 1400 1400 Adjust MSS 1360 1360 Informações importantes sobre licença/módulos Veja com o fabricante dos seus equipamentos se não é necessário algum tipo de placa de serviços, ou licença. No caso dos equipamentos deste laboratório, o roteador NE40-M2K não precisou de módulo físico adicional, apenas a licença de IPSec. No roteador Cisco também não foi necessário licença, pois o IOS dele já estava no ADVIPSERVICES-K9 (que contém toda a base para o Ipsec). *informação útil*: se quiser rodar IKEv1, no roteador Huawei você precisa de um módulo de software para IKEv1 (que você consegue com o fornecedor Huawei). Configurações do Cisco IOS XE Vamos lá então configurar o roteador Cisco para estabelecer a VPN. Não vou entrar em
CDN Netflix, como requisitar?
Agora que você já sabe da importância e benefícios de um cache CDN local (caso ainda não saiba, confira: “O que é, pra que e porquê cache CDN?”Vamos apresentar do que precisamos e como adquirimos o cache CDN NETFLIX, também conhecido como OCA (Open Connect Appliance): Banda mínima! Visto que a Netflix vai precisar investir num hardware caro para você, precisa ser lucrativo a ela também! Hoje no Brasil é necessário que tenham pelo menos 5GB/s de tráfego com a Netflix. Fonte: https://openconnect.netflix.com/deploymentguide.pdf “Recebo diversos outros conteúdos juntos pelo trânsito, como posso ter certeza de quanto tráfego possuo com a Netflix?” Para podermos identificar com exatidão quanto de tráfego temos com a Netflix, precisamos de uma ferramenta que permita a análise minuciosa de origem e destino dos pacotes trafegando por ali. Para isso recomendamos o Made4Flow! Que nos permite visualizar o tráfego dos principais conteúdos. Também há diversos outros meios que possibilitam a visualização de ONDE aprendemos o tráfego: Um campo com mais detalhes sobre o consumo Netflix especificamente: Visualizamos o tráfego originado por servidores Cache CDN (OCA) ou pelo trânsito com a Netflix Quanto o tráfego Netflix representa do total da nossa rede. Por onde recebemos o tráfego com a Netflix e até mesmo se é usado por nós ou algum cliente ASN O Made4flow possui muitas outras aplicações pra dar a melhor visibilidade do seu tráfego. “ACHO que já possuo ou estou próximo do tráfego necessário com a Netflix, quando vão vir aqui em casa oferecer o serviço?” Infelizmente não vão, você que precisa ir atrás deles! E precisa ter certeza de que atende aos requisitos antes de solicitar, senão podem te colocar em espera por alguns meses até a próxima solicitação. Entre em contato com eles por meio do Appliance Request, através do link: https://openconnect.netflix.com/pt_br/deployment-guide/appliance-request/ Preencha o formulário atenção redobrada nos campos das imagens abaixo: Após isso, em alguns dias a Netflix dará sua resposta e mais detalhes sobre a entrega do Hardware, que costuma ser: Servidor de 1u (menor modelo) ou 2u (modelo maior) Com 2 ou 4 portas de 10GB/s(Ópticas) Você pode ver a descrição completa do hardware no link: https://openconnect.netflix.com/pt_br/appliances/ Após fazer o pedido lembre-se de cumprir os requisitos de banda, interconexão, energia e espaço no rack, que podem ser validados no link https://openconnect.zendesk.com/hc/en-us/articles/360034538352 Nos próximos posts teremos mais detalhes sobre como realizar as solicitações de demais caches CDNs e muito mais! Também nos acompanhe nas redes sociais para saber mais sobre a Made4it e o Made4Flow. Em caso de dúvidas sobre a requisição ou sobre o software made4flow entre em contato com nosso time.
Como solicitar o CDN da Microsoft? (MCC)
Olá pessoal, como estão? Nessa postagem vamos explicar um pouco sobre como solicitar o CDN da Microsoft mais conhecido como MCC (Microsoft Connected Caching). Requisitos/ Informações: Banda mínima: 2 Gbps (Seletiva) / 5 Gbps downloads por dispositivos com Win10. (Restritivo) Email: ispnode@microsoft.com Informações: https://peering.azurewebsites.net/Peering/Caching PeeringDB: http://as8075.peeringdb.com/ Vamos para um Overview sobre o MCC O Microsoft Connected Cache (MCC) é uma solução de armazenamento em cache somente de software que oferece conteúdo dentro de redes ISP. O MCC pode ser implementado em quantos servidores bare-metal ou VMs se for necessário e é gerenciado a partir de um portal na nuvem. Os serviços de nuvem da Microsoft lidam com o roteamento de dispositivos de consumidor para o servidor de cache para downloads de conteúdo. O Microsoft Connected Cache é uma solução híbrida (mistura de recursos locais e na nuvem) composta por uma máquina Linux compatível com Docker implementada em seu servidor e um portal de gerenciamento de nuvem. Microsoft escolheu o Azure IoT Edge por ser uma plataforma segura, e mesmo que seu cenário não esteja relacionado à IoT, o Azure IoT Edge nos trará a segurança de infraestrutura de implantação e gerenciamento. Para mais informações sobre o Azure IOT https://docs.microsoft.com/en-us/azure/iot-edge/about-iot-edge O Azure IoT Edge consiste em três componentes que a infraestrutura do Microsoft Connected Cache utilizará: 1. Uma interface baseada em nuvem que permite instalação remota segura, monitoramento e gerenciamento de nós do Microsoft Connected Cache. 2. Um tempo de execução que gerencia com segurança os módulos implantados em cada dispositivo. 3. Módulos/contêineres que executam a funcionalidade Microsoft Connected Cache em seu dispositivo. O que é o MCC? O servidor de caching da Microsoft usa os serviços de IOT Edge da Azure para entregar conteúdo a clientes ISP finais. Ele funciona como um servidor cache dentro da rede do ISP, servindo aos IPs especificados nos anúncios da sessão BGP entre o Servidor e o Roteador. O que vem no conteúdo? A princípio o que viria do CDN deles como atualizações do Windows, Office, jogos do XBOX e arquivos dos sites da Microsoft. Atualmente como é uma implantação nova, nem tudo da Microsoft está disponível através do MCC. Ele é igual o GGC da Google ou OCA da Netflix? Sim, se parece muito, mas a grande diferença dele é que a Microsoft não envia um hardware específico para sua rede, você deve fornecer o hardware, instalar o sistema operacional e fazer a instalação de todos os pacotes necessários para o MCC rodar. Os requisitos são: Devem ser usadas interfaces de rede de pelo menos 10Gbits para entrega do Conteúdo através do Servidor. A Microsoft recomenda fortemente que sejam discos SSD instalados no Servidor. Como funciona o MCC? Segundo o documento da Microsoft, que descreve ele, funciona da seguinte forma: 1. O Portal de Gerenciamento do Azure usado para criar e gerenciar nós de Cache Conectado da Microsoft. 2. O cache do Microsoft Connected Cache implementado e provisionado no servidor. 3. O Portal de Gerenciamento do Azure usado para configurar o Microsoft Delivery Optimization Services para rotear tráfego para o servidor do Microsoft Connected Cache fornecendo duas informações: A – O endereço IPv4 público do servidor que hospeda o Microsoft Connected Cache. b. Os blocos CIDR que representam o espaço de endereço IP do cliente, que deve ser roteado para o node do Microsoft Connected Cache. 4. Os dispositivos de usuário final da Microsoft se conectam periodicamente aos Serviços de Otimização de Entrega da Microsoft, e os serviços correspondem ao endereço IP do cliente com o endereço IP do node de Cache Conectado da Microsoft correspondente. 5. Os dispositivos de usuário final da Microsoft fazem as solicitações de intervalo de conteúdo do node do Microsoft Connected Cache. 6. O node de Cache Conectado da Microsoft extrai o conteúdo da CDN, propaga seu cache local armazenado no disco e entrega o conteúdo ao cliente. 7. As solicitações subsequentes de dispositivos de usuário final para conteúdo agora virão do cache. 8. Se o node do Microsoft Connected Cache não estiver disponível, o cliente extrairá o conteúdo da CDN para garantir um serviço ininterrupto para seus assinantes. Qual o processo para solicitar um MCC Solicitar acesso ao programa, preenchendo o formulário descrito na página Link: https://peering.azurewebsites.net/peering/Caching Abaixo está o resumo das etapas necessárias para implantar o Cache Conectado da Microsoft em seu servidor. 1. Forneça à Microsoft a assinatura do Azure que você usará para o Microsoft Connected Cache 2. Crie o recurso de cache conectado da Microsoft no Azure 3. Crie um node de Cache Conectado da Microsoft a. Informações de aprovação do espaço IP 4. Edite as informações do node de cache 5. Configure um servidor com Ubuntu 20.04 ou uma VM Ubuntu em execução no Windows Server 2019 6. Instale o Microsoft Connected Cache em um servidor ou VM 7. Verifique o funcionamento adequado do Microsoft Connected Cache Server 8. Visualize o Relatório de Resumo do Cache Conectado da Microsoft 9. Problemas comuns. Para qualquer dúvida sobre estas instruções, entre em contato com: msconnectedcache@microsoft.com O portal de gerenciamento do Microsoft Connected Cache Azure é usado para criar e gerenciar nós do Microsoft Connected Cache. Uma ID de Assinatura do Azure é usada para conceder acesso à visualização e para criar o recurso de Cache Conectado da Microsoft nos nodes do Azure e Cache. A instalação: A instalação está muito bem descrita no manual, mas resumidamente: Exemplo de email recebido com a aprovação do MCC Este email foi recebido pela equipe ao ser aprovado o MCC. Nele constam as instruções para dar seguimento a instalação. Observação: É IMPORTANTE ENCAMINHAR O E-MAIL DE SOLICITAÇÃO ANTES PARA A MICROSOFT DO CONTRÁRIO NÃO APARECERÁ A APLICAÇÃO PARA INSTALAÇÃO. No portal escolha Criar um recurso: Digite ” Microsoft Connected Cache” na caixa de pesquisa e certifique-se de pressionar a tecla Enter para mostrar os resultados da pesquisa. • Selecione “Microsoft Connected Cache” e selecione “Create” na próxima tela para iniciar o processo de criação do recurso Microsoft Connected Cache. • Preencha os campos obrigatórios para criar o
Como automatizar processo de provisionamento de clientes!
O provisionamento de clientes é uma tarefa diária de um provedor de internet, tanto na instalação de novos clientes, quanto em manutenções. Neste processo, além do provedor precisar sempre disponibilizar um técnico que faça além da instalação física, a configuração lógica de inserir a VLAN, usuário e senha PPPoE do cliente em sua CPE, temos alguns problemas conhecidos, como: – Demanda de tempo para configuração manual – Abertura para falhas humanas: – Erro de credenciais PPPoE – Erro de Vlan – Erros de usuário e senha – Não cumprir o padrão determinado pelo provedor de configuração – Perda de configurações em resets de CPEs pelos clientes. Diria que esse é o rei dos tickets do suporte de um provedor, onde muitas vezes o cliente em busca de resolver algum problema qualquer em sua casa, reseta o equipamento e não consegue configurar novamente. Neste caso, se o suporte via telefone não for capaz de auxiliar o cliente na configuração, o provedor irá precisar disponibilizar um técnico presencial para o serviço. E se você já leu até aqui, pode estar se perguntando se realmente é possível resolver este problema de forma automática. E a resposta é sim! E inclusive temos uma gama de cenários e possibilidades que nos permitem além de automatizar o processo de provisionamento, torná-lo auto-reconfigurável, para o famoso caso dos resets. Então sem mais delongas, vamos colocar em jogo alguns cenários e suas possíveis implementações: – Cenário exemplo de implementação: Nos casos de equipamentos da rede de acesso que são da mesma fabricante, temos a vantagem deles “falarem a mesma língua”, e isso nos ajuda pois na grande maioria das vezes, conseguimos obter a vantagem de conseguir automatizar a entrega e a permanência das configurações nos equipamentos. Basicamente na OLT, configuramos os parâmetros que serão enviados por OMCI, contendo informações como usuário e senha PPPOE, ativação da WAN, ativação do NAT. Vamos a um exemplo prático de configurações para realizar esse processo: As configurações que serão descritas neste exemplo se aplicam a: – OLT’s Huawei das séries MA56xx e MA58xx. – ONT’s Huawei modo Router. OBS: Note que alguns comandos estão dentro de [chaves] indicando o nome de cada parâmetro, e deve ser alterado para ficar de acordo com o cenário de aplicação. Criação de DBA Profile, line e service profile será normal, de acordo com cada cenário. Recomendamos um profile para cada VLAN, sendo que também recomendamos uma VLAN por PON na OLT. Liberando configuração em modo OMCI: Para ser possível a entrega das configurações para a ONU, precisamos liberar o método de configuração OMCI. Para ativação do NAT na WAN: Para podermos subir a ONT com o NAT ativo, criamos um WAN profile. Adicionando a ONT com user e senha PPPoE: O segredo da implementação está nesta parte, e o comando ont ipconfig será o responsável por entregar o PPPoE para a CPE. interface gpon [FRAME]/[SLOT]ont add [PON] [ONT-ID] sn-auth [SERIAL-NUMBER] omci ont-lineprofile-id [ID] ont-srvprofile-id [ID] desc [DESCRICAO]ont ipconfig [PON] [ONT-ID] pppoe vlan [VLAN] priority 5 user-account username [USER-PPPOE] password [SENHA-PPPOE] Criando WAN: Entrega da Vlan nas portas LAN: Para que dispositivos ethernet que estejam a frente da CPE entendam a Vlan que estamos entregando nas portas, assumimos o modo de vlan nativa: Ativando portas em modo route: Definimos o modo route para as portas para que elas fiquem ativadas para roteamento IP e entrega de DHCP em dispositivos que se conectarem atrás dela. OBS: tanto na entrega da Vlan quanto na ativação do modo route, temos exemplo feito para ONT’s com 4 portas, mas existem casos que isso muda de acordo com a quantidade de portas disponíveis na ONT. Seguindo os passos acima no provisionamento da sua ONT modo route, ela já deverá funcionar. – Como automatizar isso com meu sistema ERP ? O processo acima pode ser realizado manualmente, mas para que se torne mais efetivo, podemos utilizar de scripts de provisionamento do sistema ERP para realizar o processo de provisionamento. Abaixo temos um modelo de script que pode ser utilizado, note que cada variável é separada com #, e isso deve ser verificado com cada sistema, para que eles passem a variável ou ajudem no desenvolvimento do script. interface gpon #subrack#/#slot# ont add #pon# sn-auth #onu_mac# omci ont-lineprofile-id #vlan# ont-srvprofile-id #vlan# desc #nome# ont ipconfig #pon# #onu_numero# pppoe vlan #vlan# priority 5 user-account username #user# password #senha# ont internet-config #pon# #onu_numero# ip-index 0 ont wan-config #pon# #onu_numero# ip-index 0 profile-id [ID-PROFILE-WAN] ont port native-vlan #pon# #onu_numero# eth 1 vlan #vlan# priority ont port route #pon# #onu_numero# eth 1 enable ont port native-vlan #pon# #onu_numero# eth 2 vlan #vlan# priority ont port route #pon# #onu_numero# eth 2 enable ont port native-vlan #pon# #onu_numero# eth 3 vlan #vlan# priority ont port route #pon# #onu_numero# eth 3 enable – Extras: Existem também outras coisas que podemos entregar assim como as credenciais PPPoE, como dados de SIP, ou ativação automática do TR-069. E falando em TR-069, esse modo de configuração trabalha muito bem com ele, já que garante a comunicação IP, e o TR-069 por sua vez garante o management completo da CPE, como wi-fi, senhas, dados de sinal, etc. FAQ: O processo descrito acima foi testado e homologado na OLT Huawei, alguns outros vendors possuem suporte a esse tipo de configuração porém para cada um, o modo de configuração é diferente. Não, o processo acima é homologado apenas em cenários de Huawei com Huawei. Esse artigo foi escrito pelo consultor da Made4it Rafael Henrique. Caso tenha alguma dúvida em relação ao artigo ou como realizar essa configuração em sua rede, fale com nosso time
Funcionalidades e benefícios do TR-069 no Made4Graph
Como vimos em nossos artigos sobre TR-069, o protocolo CWMP, apresenta muitas funcionalidades e vários benefícios, e estes podem ser encontrados na ferramenta Made4Graph, onde esta possui um módulo específico para TR-069. A imagem abaixo mostra o módulo, e o que pode ser acessado na ferramenta. Na primeira opção do módulo, temos a Dashboard TR-069, esta tela mostra relatórios completos do status dos equipamentos que possuem TR-069 habilitado, bem como a porcentagem total dos dispositivos que possuem ou não o TR69 habilitado. É possível ver também os modelos de CPE, os fabricantes e também a quantidade de cada um na base do Provedor, que tenha o TR-069 habilitado. A imagem abaixo mostra como são apresentadas as informações ao utilizador. Na segunda opção do módulo, temos a CPE, nesta aba são encontradas diversas funcionalidades, utilizadas pelo suporte, dentre elas estão: A imagem abaixo exibe as abas presentes dentro da opção CPE do TR-069 Esta tela também pode ser encontrada na aba Gráfico Realtime, quando selecionamos o PPPoE do cliente desejado, vamos em Grafico Realtime. Em seguida vamos na opção de Gestão de Equipamento, ali também podem ser realizadas as configurações da CPE via TR-069, isso permite maior agilidade na hora de configurar a CPE do cliente O Made4Graph conta com mais de 20 templates de Vendors/Fabricantes diferentes, para TR-069, com seus respectivos parâmetros e as configurações específicas, além disso em nossa base de homologação existem mais de 40 modelos de CPEs de diversos fabricantes e modelos de equipamentos que permitem uma flexibilidade na hora de trazer a sua base de CPEs para o TR-069. As imagens abaixo ilustram os templates disponíveis, e também os equipamentos que foram homologados dentro do TR-069. É possível fazer a restauração dos dados da CPE após o reset baseado no template que foi configurado. Existem ainda muitas outras funcionalidades, ao final deste artigo deixarei um link onde você pode acessar gratuitamente a versão demo do made4graph, e TR-069. Você pode assistir um tour pelo tr069 do made4graph nesse vídeo aqui Qualquer dúvida de como funciona nossa ferramenta ou uma apresentação completa da ferramenta, entre em contato conosco que nosso time de especialistas está disponível para você
Como solicitar um CDN do Google?
Olá pessoal!! Aqui é o Luís Dias, consultor na Made4it e hoje iremos falar um pouco sobre CDNs, mais especificamente Google Global Cache (GGC), um tema muito bacana e interessante que já existe em nossas vidas há muito tempo e que facilita muito nosso trabalho em escalabilidade da rede. É um tema bem interessante e que requer um pouco de atenção, então pega um café bem forte e vem comigo. Primeiro que é CDN? Um CDN abreviação de Content delivery network (Rede de Entrega de Conteúdo) é um grupo de servidores distribuídos geograficamente que acelera a entrega de conteúdo da Web, aproximando-o de onde os usuários finais estão. Esse equipamento utiliza o armazenamento em cache, um processo que armazena cópias de arquivos temporariamente, para que você possa acessar o conteúdo da Internet a partir de um dispositivo mais rapidamente por meio de um servidor próximo a você. Os CDNs armazenam todo tipo de conteúdo em cache, como página da Web, imagens e vídeos. Isso permite que você assista a um filme, faça downloads de software, publique nas redes sociais ou faça compras sem ter que esperar pelo carregamento do conteúdo. GGC – Google Global Cache O GGC ou Google Global Cache, são os Servidores do Google espalhados pelos ISPs do Brasil e do mundo afora. Os GGCs são servidores instalados dentro das Redes dos ISPs e Operadoras para melhorar a experiência dos usuários com o conteúdo do google, provendo mais velocidade, latência e experiência destes usuários com os Serviços do Google. O CDN do Google, além de melhorar a experiência dos usuários com a plataforma deles, também é usado para reduzir o congestionamento e redução do tráfego de Trânsito, PTT e Peering para o Google. Assim reduzindo custos para o ISP ou Operadora. Nada mais do que uma troca muito boa, tanto para o Google que seus usuários ficam felizes com a performance e para o ISP fica muito bom pois economiza em quantidade de Link ou Trânsito. Como funciona o GGC: Quando um utilizador solicita um conteúdo – por exemplo, um vídeo, página web, ou uma imagem, o Sistema do Google determina se o conteúdo pode ser servido a partir do Nó GGC. Se o Nó GGC tiver o conteúdo solicitado no seu Servidor Cache, ele irá servir o conteúdo diretamente para o utilizador final, melhorando a rapidez/latência da navegação para o utilizador e otimizando os recursos de banda do ISP. Se o conteúdo não estiver armazenado no Servidor Cache, o Nó GGC vai recuperar esse conteúdo a partir dos servidores da Google e armazena para as futuras solicitações. Como é feita a solicitação do GGC: Para podermos fazer a solicitação do GGC, primeiro precisamos saber quanto temos de tráfego para conteúdo do Google. Pois como todo CDN, temos um requisito de mínimo de banda para conteúdos relacionados ao Google, como Youtube, etc. Hoje a banda mínima é um tráfego maior de 3Gbps – 95 percentil por pelo menos 3 meses. 95 Percentil* – é um cálculo matemático utilizado para avaliar o uso regular e sustentado de links de comunicação de rede. Mas você deve estar se perguntando “Luís, como eu vou saber quanto de tráfego eu tenho para o Google, para solicitar o GGC?” Para esse procedimento podemos utilizar uma ferramenta de Netflow, neste caso aqui estarei utilizando o Made4Flow, a melhor e mais prática ferramenta de Netflow do mercado. Vamos entender como essa mágica funciona: Ao entrarmos nos deparamos com a Dashboard da ferramenta, onde conseguimos especificar o tipo de tráfego que queremos gerar o relatório de consumo, ou podemos escolher a dashboard que queremos, no caso para ver tráfego para o Google, Netflix, Facebook, Akamai. Ao entrarmos na aba Dashboard Google, iremos conseguir ver quanto temos de tráfego total para o Google e verificar se iremos conseguir solicitar o CDN, visto que eles pedem um tráfego percentil mínimo. Após analisarmos, conseguimos dar continuidade na solicitação do GGC Para fazermos a solicitação do GGC (Google Global Cache) é necessário entrarmos no site: https://isp.google.com/partner_request/?data.request_type=Peering E preenchermos o formulário onde vamos colocar os nossos dados como ASN, nome, endereço, etc. Após solicitação caso aprovado, iremos receber um e-mail, informando se fomos aprovados ou não. Caso aprovado, o Google ira nos reportar o passo a passo que devemos seguir e nos passará um prazo de estimativa de quanto tempo levará para o servidor chegar no endereço que fornecemos no formulário. Espero que tenham gostado e compreendido o conteúdo! Caso tenha alguma dúvida entre em contato com nosso time de especialistas.
Controle de banda Seletivo no Roteador Huawei
Olá, meu nome é Gabriel Henrique, sou analista de redes aqui na Made4it e hoje vou mostrar para vocês como configurar o controle de banda seletivo em usuários de camada de acesso nos roteadores da linha NE da Huawei. O controle de banda seletivo abre a possibilidade de novos produtos ou a melhora, incremento ou “charme” na entrega do serviço ao usuário final sendo um diferencial muito interessante, principalmente para ISPs que possuem CDN local. Mas, afinal, do que se trata o controle de banda seletivo ? Normalmente, nas implementações de BNGs/BRAS/PPPoE Server, temos como corriqueiro um controle de banda global (do ponto de vista do usuário) do qual todo e qualquer conteúdo é limitado pelo valor do plano contratado. No controle de banda seletivo, temos a possibilidade de atrelar diferentes bandas para diferentes serviços, onde você pode por exemplo atrelar um controle de banda de valor “X” para o seu conteúdo local de CDN, “y” para o tráfego interno a sua rede e “z” quando a origem ou destino do tráfego é externo (links, transitos, Peering, IX/PTT, PNI, transportes…), podemos dizer que fazemos o QoS seletivo ou que controlamos especificamente quanto de banda por conteúdo ou também poderia ser dito que podemos tirar o controle de banda do CDN ou PBR seletivo. Enfim, chega de conversa, vamos para a parte mais legal 🙂 No nosso cenário de testes, temos: – Cliente com plano de 100Mbps – Necessidade de liberar até 500Mbps quando origem/destino for CDNs locais – Necessidade de manter 100Mbps quando origem/destino não forem CDNs Locais– CDNs locais endereçados com 192.0.2.0/24 e 2001:DB8::/64 Pré-requisitos: – ERP/Radius com suporte ao AVP “Huawei-Policy-Name”– Domain de autenticação dos clientes com um “user-group” declarado (Se não sabe o que é user-group, fique ligado no blog da Made que logo logo tem um post sobre Firewall que vai explicar exatamente do que se trata 😉 Passo 1: Configurar, no system-view, os parâmetros de Radius necessários e ativar a função de “Value Added Service” no roteador. Passo 2: No Radius-group usado para autenticação, ativar o suporte a accounting do value-added-service Passo 3: Configurar as ACLs de acesso delimitando o tráfego de CDN e o tráfego geral Passo 4: Configurar os “classifiers” para classificar o tráfego das ACLs Passo 5: Configurar os “behaviors” que vamos usar para identificar cada um dos classifiers Passo 6: Configurar a traffic-policy que será atrelada globalmente, contendo o classifier e behavior configurados anteriormente, efetivando a classificação diferenciada dos fluxos Passo 7: Aplicar a traffic-policy globalmente. Passo 8: Configurar os qos-profiles que vão delimitar a banda dos respectivos conteúdos Passo 9: Configurar a policy que irá controlar a banda do cliente Pronto. Agora, basta o ERP/Radius entregar para o cliente o AVP Huawei-Policy-Name := 150m que, o cliente terá o controle de banda limitando até 500Mbps quando a origem/destino forem os CDNs locais, e até 100Mbps para as demais origens/destinos. Lembrando que se o ERP/Radius entregar o Huawei-Input-Average-Rate, o BRAS/BNG irá usá-lo preferencialmente e não irá aplicar o Policy name! A traffic-policy permite até 8 “tariff-levels” aonde você pode classificar seu tráfego em até 8 tipos de serviço e aplicar diferentes controles de banda para cada um deles. No caso de exemplo, caso queira configurar o controle de banda diferenciado para outros planos, basta criar novos “qos-profile” e “value-added-service policy” com os valores que deseja aplicar, pois o tráfego de CDN e geral já está classificado em “tariff-levels” distintos. É isso aí, até a próxima! Qualquer dúvida de como implantar essa configuração em sua rede entre em contato e converse com um dos nossos especialistas
Como Funciona o TR-069?
Já vimos um pouco das funcionalidades do TR069, para acessar o conteúdo onde apresentamos o que é o TR069 leia o nosso primeiro artigo, agora veremos como essa “mágica” funciona. TR-069 é baseado em SOAP/HTTP, onde é feita a conexão entre a CPE e o ACS. A comunicação é feita através de chamadas de procedimento remoto (RPC), isso permite a CPE encaminhar os parâmetros, além do seu status atual, bem como gerência de firmware para o ACS. É muito importante lembrar que, quem inicia a conexão é a CPE, vai partir dela o primeiro contato, e também os informes periódicos ao ACS, pois a cada fração de tempo a CPE encaminha ao ACS um inform para que o ACS atualize seu status no servidor. O ACS somente vai iniciar o contato em momentos específicos, como: atualização de firmware, ou ainda uma interação iniciada pelo operador, mas que devem ser aceitas pela CPE para que seja concluída a ação. A imagem acima mostra a comunicação entre a CPE e o ACS, onde a CPE encaminha uma solicitação de conexão para o ACS, perceba que nesta foto, a CPE já é conhecida pelo ACS, do contrário a comunicação teria alguns campos a mais, como o GetParamenterNames request, onde esta solicitação parte do ACS para a CPE, com a intenção de conhecer os parâmetros que podem ser entregues ao ACS. Open connection: a CPE informa que quer falar com o ACS SSL initiation: é adicionado a comunicação um certificado para proteger a troca de mensagens inform request: a CPE diz ao ACS que vai informar seu status atual inform response: o ACS diz que a CPE pode encaminhar os parâmetros a ele HTTP post(empty): a CPE diz OK GetParameterValues request: requisição dos parâmetros da CPE GetParameterValues response: resposta da CPE com os parâmetros para o ACS SetParameterValues request: o ACS informa que agora conhece os parâmetros, e que precisa dos valores dos parâmetros da CPE SetParameterValues response: a CPE informa ao ACS os valores dos parâmetros, requisitados pelo ACS. HTTP response empty: o ACS informa que não existem mais informações para serem trocadas entre eles, e que pode ser finalizada a comunicação. Close connection: A CPE finaliza a conexão. É possível ter essa funcionalidade na sua rede de forma simples, que é através do módulo do TR069 no Made4graph, onde todas as informações necessárias ficam dentro da própria interface do software. Para você conhecer o Made4graph e os benefícios da ferramenta você pode acessar a demo ou então marcar uma demonstração com o time comercial 😁
Adicionar alerta por Telegram no Anti-DDoS
Uma das funcionalidades do Anti-DDoS do Made4flow é a possibilidade de enviar alertas de ataques para o seu celular via telegram. Preparamos um tutorial de como você pode configurar essa ação!
Porque só ter Zabbix não funciona?
Para entender essa pergunta, vamos lembrar como o Zabbix funciona. O Zabbix é um software open-source de monitoramento, com ele conseguimos monitorar nossos ativos de diversas maneiras, com protocolo SNMP, via Zabbix Agent, HTTP/S, com scripts externos, e por aí vai…. Quando instalamos e configuramos o Zabbix, vemos diversos templates prontos para poder monitorar equipamentos de diversas marcas e modelos, com eles temos itens, regras de descoberta, triggers, gráficos todos para já serem aplicados ao host, mas é lógico que sempre podemos melhorar o que já existe e adicionar mais ainda. Porém, mesmo adicionando seu host no Zabbix, selecionando o template correto e iniciando o monitoramento dele, não adianta de nada se não houver alguém para acompanhar esse monitoramento. Precisamos de alguém que esteja sempre de olho nos incidentes, nos gráficos dos hosts, nos dados coletados, para identificar algum possível problema. Imagina só! Durante seu expediente você sempre acompanha os gráficos dos seus links contratados com upstreams, porém após seu expediente, durante um horário de pico, um de seus links começa a bater o máximo contratado e afeta a entrega de internet para seus clientes finais, ou uma porta de um de seus equipamentos chega na capacidade máxima com o crescimento que ocorreu nos últimos meses. Isso poderia ser evitado caso houvesse alguém pronto para agir quando encontrado algum comportamento inesperado no monitoramento. Temos até a possibilidade de criar diversas dashboards também e nelas adicionarmos gráficos, histórico de incidentes e tudo mais para facilitar esse acompanhamento, mas sem alguém de olho no monitoramento quando algo assim ocorrer, se torna inútil. Um de nossos serviços, o Made4NOC, serve para isso. Temos nossa equipe de monitoramento à disposição, ela trabalha 24h por dia, 7 dias por semana e está sempre de olho em cada item no monitoramento dos ativos presentes em nosso Zabbix. Além disso, sempre que ocorre um incidente ou nossa equipe encontra um comportamento não esperado, está preparada para tomar ações, seja acionar nossa consultoria, entrar em contato com o cliente, seja entrar em contato com um fornecedor de link ou equipamento ou o que for necessário para podermos resolver tudo o quanto antes. Quer entender melhor como o NOC da Made4it pode ajudar sua rede? Fale com um dos nossos especialistas e saiba o que e como monitorar! Luiz Felipe | Consultor
