SRv6 – Um sucessor do MPLS ? 

Nós aqui na Made4it somos apaixonados por evolução e o SRv6 tem sido motivo de muita euforia e discussão com os nossos times e a comunidade.  Um protocolo que tenta bater de frente com o MPLS com certeza precisa ser olhado com muito carinho.  Vamos conhecer um pouco mais sobre ele, em uma série de artigos sobre o assunto.  Nos últimos anos, a evolução das redes vem sendo impulsionada por demandas crescentes de escalabilidade, flexibilidade e eficiência. Nesse cenário dinâmico, tecnologias como MPLS (Multiprotocol Label Switching) surgiram como soluções dominantes para atender necessidades complexas de roteamento e encaminhamento de tráfego. No entanto, com o avanço das aplicações e serviços digitais, surgiram desafios que o MPLS tradicional não conseguia resolver de maneira eficiente. As necessidades constantes das redes, alinhadas a novas tecnologias como o 5G, IoT, carros autônomos e todo um ecossistema crescendo de forma exponencial EXIGEM que as redes de comunicação estejam alinhadas a novas demandas e necessidades. É aqui que o Segment Routing over IPv6 (SRv6) entra em cena como uma alternativa inovadora atendendo esses requisitos com simplicidade e elegância.   MPLS: A Tecnologia Legada  MPLS foi introduzido no final dos anos 1990 e rapidamente ganhou popularidade devido à sua capacidade de fornecer encaminhamento de pacotes baseado em rótulos (as famosas labels), permitindo maior controle sobre o fluxo de tráfego e melhor qualidade de serviço (QoS).  Nos anos 2000, o MPLS tornou-se a escolha preferida para provedores de serviços e empresas que buscavam soluções robustas para redes de grande escala, data centers e interconexões entre redes. Para os provedores de serviço, a escalabilidade e facilidade que o MPLS entregava tornou inevitável implementá-lo em suas redes. Isso permitiu os provedores de serviço desenvolverem e comercializarem novos produtos, o que culminou em empresas conectando suas matrizes e filiais de forma transparente, operadoras de telefonia móvel conseguindo expandir suas redes de forma massiva, dentre inúmeras outras inovações que aconteceram com o tempo enquanto a internet deixava de ser das grandes corporações e passava a ser das pessoas.   Necessidades e Limitações do MPLS:   Toda e qualquer tecnologia tem pontos positivos e negativos e são moldadas e concebidas para atender uma ou mais necessidades de um determinado ponto no tempo. Conforme o tempo passa, redes crescem e continuam a evoluir, isso implica em necessidades novas que surgem constantemente e talvez não sejam atendidas por tais tecnologias. No caso do MPLS não foi diferente, conforme as redes continuaram no seu crescimento e evolução, algumas limitações do MPLS começaram a se tornar muito aparentes.  Complexidade Operacional: A gestão e configuração de redes MPLS, dependendo de seu tamanho e “features” que são necessárias para a rede, pode ser complexa e exigir expertise altamente especializado.  Escalabilidade: À medida que as redes crescem, torna-se desafiador escalar infraestruturas MPLS sem aumentar significativamente os custos e a complexidade da rede. Existem técnicas e boas práticas para tais implementações, mas assim como toda e qualquer tecnologia o MPLS também tem suas limitações de escalabilidade.   Em muitos casos, o preço da escalabilidade de uma rede MPLS é o uso cada vez mais alto de processamento em equipamentos de rede, tabelas de roteamento cada vez mais extensas, ambientes de rede cada vez mais delicados. Isso invariavelmente aumenta o CAPEX e OPEX da operação, chegando em pontos de tornar completamente inviável manter tal tecnologia em operação na rede e buscar arquiteturas de rede alternativas para manter o ambiente operável.   Flexibilidade Limitada: MPLS foi projetado para cenários específicos e pode não ser facilmente adaptável às novas demandas de tráfego e serviços emergentes.  Com novas tecnologias surgindo como o 5G e as novas necessidades que o IoT e inovações tecnológicas no campo de carros autônomos e telemedicina demandam, se faz necessário ter alternativas para segregação de rede a nível de topologia (Slicing) além segmentação do tráfego seguindo priorizações como caminhos de baixa latência e alto tráfego, baixa latência e baixo tráfego, alto tráfego sem se importar com latência e assim por diante.  O MPLS, hoje, não é capaz de entregar essas demandas emergentes com seus mecanismos legados.  SRv6: A Inovação em Segment Routing  O Segment Routing over IPv6 (SRv6) é uma tecnologia de nova geração que combina o Segment Routing (SR) e o IPv6, aproveitando dos mecanismos de encaminhamento já existentes no IPv6.  Com o uso de uma extensão do cabeçalho IPv6 como meio para identificação e encaminhamento de informações dentro de uma rede, o SRv6 traz benefícios no plano de controle e plano de dados de equipamentos de rede onerando menos e entregando mais. O SRv6 foi concebido desde o início tendo em vista as necessidades constantes dos dias atuais e do futuro, sendo altamente programável e totalmente flexível para escalar redes legadas como também novos ambientes de rede.   Com o conceito de “programabilidade” enraizado, o SRv6 traz a capacidade de uma rede de codificar instruções individuais para os pacotes diretamente em seu cabeçalho.  No “SR-MPLS” (Segment Routing MPLS) essas instruções são transportadas em rótulos (labels) MPLS, no SRv6, tais instruções são transportadas nativamente no cabeçalho IPv6 com adição de uma extensão chamada de SRH, ou Segment Routing Header.  Características e Benefícios do SRv6.  Comparação com Tecnologias Legadas  Ao comparar o SRv6 com tecnologias legadas como MPLS, é evidente que o SRv6 oferece uma abordagem mais simplificada, flexível e adaptável às necessidades atuais de redes de comunicação. Enquanto o MPLS continua sendo uma solução viável para muitos cenários, o SRv6 está emergindo como a escolha preferida para provedores de serviço que buscam inovação e eficiência em suas infraestruturas de rede, principalmente quando nessas redes as demandas “do futuro” se tornam cada vez mais evidentes.   Conclusão  O Segment Routing over IPv6 (SRv6) representa uma evolução significativa no campo das redes de comunicação, oferecendo uma abordagem mais simples, flexível e escalável em comparação com tecnologias legadas como MPLS. Com a crescente demanda por serviços digitais e infraestruturas de rede mais eficientes, é provável que o SRv6 continue ganhando destaque e se tornando uma parte integrante das futuras arquiteturas de rede. A crescente demanda e necessidades que o

Novo método de importação de VM’s do VMware para ProxMox

Olá pessoal, Bryam da Made4it aqui! Como sabem, estamos sempre de olho nas novidades que podem revolucionar a forma como trabalhamos, e hoje estamos super animados para compartilhar algo que vai facilitar a vida de todos nós que lidamos com infraestrutura e virtualização. Diariamente realizamos diversas migrações para todos os tipo de empresas e essa novidade facilitará muito o nosso processo.  Vocês pediram e a tecnologia atendeu: a migração de VMs do VMware para ProxMox acaba de ficar muito mais simples e intuitiva! Esqueçam os comandos complicados e as linhas de código que pareciam não ter fim. Agora, com apenas alguns cliques, vocês podem realizar todo o processo diretamente pela Web GUI.  Fiquem ligados que vamos detalhar tudo sobre essa inovação que promete ser um divisor de águas no nosso dia a dia. Vem com a gente nessa jornada tecnológica!  Introdução  Até então a migração de VMware para ProxMox era um processo totalmente via CLI, tínhamos que baixar um binário específico, realizar a comunicação com o VMware de destino, baixar o disco, converter ele, importar para o ProxMox e vincular em alguma VM.   Vendo essa movimentação gigantesca de pessoas optando pelo o ProxMox, eles aproveitaram e desenvolveram um novo método de migração de VMs, e o melhor, sendo totalmente via Web GUI e facilitaram muito esse processo, pois não precisamos colocar nenhum dedo mais no CLI do servidor!   Essa nova opção está disponível a partir da versão 8.1.8 do ProxMox e os binários que fazem essa mágica acontecer são os seguintes: pve-manager versão 8.1.8, libpve-storage-perl versão 8.1.3 e o novo binário pve-esxi-import-tools!   Atualizando  Primeiro precisamos ter algum desses repositórios configurados em nosso Proxmox: pvetest ou pve-no-subscription  Selecione o seu Host > Updates > Repositories  Caso você não tenha nenhum desses repositórios, basta ir até a opção Add e seleciona o repositório Test ou pve-no-subscription  Com o repositório adicionado, basta ir até a opção Updates, selecionar a opção Refresh para pegar os pacotes mais atualizados e após isso ir em Upgrade  APENAS ATUALIZE SEU PROXMOX SE VOCÊ TIVER CERTEZA DO QUE ESTÁ FAZENDO, ESSE PROCESSO SE MAL EXECUTADO PODE AFETAR O SEU CENÁRIO!! QUALQUER DÚVIDA PODE ENTRAR EM CONTATO COM A GENTE!!   Um Pop-up será aberto e basta configurar o Upgrade. Finalizado o upgrade é recomendado realizar um reboot do seu servidor para que ele seja executado no novo kernel (Se ele foi atualizado)  Se comunicando com o VMware A comunicação com o nosso VMware ocorre via API, e para configurar isso temos que ir em: Datacente > DataStore > Add > ESXI Iremos configurar da seguinte forma esse novo Storage:  Após configurar o Storage ele já vai estar visível nos seus servidores ProxMox.  Realizando Migração  Quando você acessar o Storage, uma tela como essa irá aparecer:  Basicamente iremos ver as VM’s existentes no seu VMware, após isso basta selecionar qual você quer migrar e selecionar a opção Import  Essa tela irá aparecer, que é as pré-configurações que você deseja fazer antes de importar:  Caso a VM tiver algum CDROM vinculado a ela no VMware ele não será migrado! A VM não pode ser migrada ligada, tem que desligar ela antes (no VMware)  Após realizar as alterações que você deseja é só clicar em Import e aguardar.  A importação finalizando a sua VM já vai estar pronta para ser utilizada!   Live Import  Para diminuir o tempo de Downtime visto que precisamos desligar a VM que vai ser migrada, o ProxMox disponibilizou a opção de Live Import, aonde durante o processo de IMPORT nós podemos ligar a VM e já deixar ela funcional, simulando o Live Restore que o ProxMox Backup Server já faz.  Mais informações  E aí, ficou interessado em simplificar suas migrações de VM? A Made4it está aqui para garantir que sua transição para o ProxMox seja a mais tranquila possível. Não deixe as dúvidas te pararem! Entre em contato conosco e agendaremos uma chamada para esclarecer tudo o que você precisa saber.  Ainda não está convencido? Dê uma olhada no nosso post “VMware x ProxMox – Qual escolher?” no blog da Made4it. Lá, detalhamos as vantagens de cada sistema para que você possa tomar a melhor decisão para o seu cenário.  Lembre-se, a Made4it é especialista quando o assunto é virtualização. Estamos à disposição para ajudar você a alcançar novos patamares com o ProxMox. Entre em contato agora mesmo e leve sua infraestrutura para o próximo nível! 

Rumo ao Futuro da Gestão Multivendors para CPEs e IoTs: TR-069 para TR-369 

Introdução  No cenário cada vez mais interconectado da tecnologia moderna, a gestão eficiente e unificada de dispositivos tornou-se crucial. A evolução do protocolo TR-069 para o TR-369 marca um ponto crucial nessa jornada, abrindo novas portas para provedores de serviços e usuários finais. Neste artigo, exploraremos a transição do TR-069 para o TR-369 e o impacto significativo que isso tem no gerenciamento de dispositivos em um mundo cada vez mais conectado.  TR-069 —> TR-369: O Futuro da Gestão de Dispositivos  O Protocolo de Gerenciamento de WAN de CPE (CWMP), conhecido como TR-069, foi um marco na capacidade dos provedores de internet de entregar serviços de forma ágil e eficiente, garantindo uma gestão proativa e segura da rede. No entanto, com o advento da Internet das Coisas (IoT) e a crescente demanda por dispositivos interconectados, tornou-se evidente a necessidade de uma evolução desse protocolo.  O TR-369, também conhecido como User Services Platform (USP), surge como a resposta a essa necessidade de evolução. Desenvolvido em conjunto por uma gama de empresas e instituições de renome, incluindo Google, Nokia, Huawei e outras, o TR-369 promete ser flexível, seguro, escalável e padronizado para atender às demandas de um mundo cada vez mais conectado.  Desafios e Oportunidades da Internet das Coisas  A crescente demanda por ambientes interconectados, como casas inteligentes e ambientes baseados em nuvem, trouxe consigo uma série de desafios e oportunidades. A monetização dos dispositivos IoT tornou-se uma prioridade para muitas empresas, levando a soluções proprietárias que, embora compreensíveis, contribuem para um ecossistema pobre e limitado.  O TR-369 surge como uma solução para esses desafios, oferecendo um padrão aberto e interoperável que promove a concorrência saudável, a inovação contínua e a redução de custos para os prestadores de serviços e usuários finais.  O Futuro da Gestão de Dispositivos: TR-369 em Ação  Com a implementação do TR-369, os provedores de serviços podem esperar uma gestão mais eficiente e unificada de dispositivos, independentemente do fornecedor. A flexibilidade e escalabilidade do TR-369 garantem que as soluções baseadas nesse padrão estejam preparadas para os desafios do futuro, mantendo-se atualizadas e adaptáveis às novas tecnologias e demandas do mercado.  Conclusão  À medida que avançamos em direção a um futuro cada vez mais interconectado, a evolução do TR-069 para o TR-369 é um passo crucial na jornada rumo a uma gestão eficiente e unificada de dispositivos. Com o apoio de empresas e instituições líderes do setor, o TR-369 promete revolucionar a forma como os dispositivos são gerenciados em um mundo cada vez mais conectado.  Prepare-se para o futuro da gestão de dispositivos com o TR-369 e descubra os benefícios de uma abordagem multifornecedores para CPEs e IoTs.  Conheça o OktopUSP: A Revolução no Gerenciamento de Dispositivos  Como patrocinadores oficial do projeto, a Made4it tem o prazer de apresentar o OktopUSP, um projeto inovador desenvolvido pela empresa Oktopus, liderado por Leandro Antonio Farias Machado. Este projeto promete revolucionar a forma como provedores de internet e integradores de TI gerenciam seus dispositivos, oferecendo controle remoto, insights poderosos e uma solução à prova de futuro.  Descrição:  O OktopUSP foi criado para capacitar provedores de internet e integradores de TI a utilizarem todo o potencial de seus produtos. Com recursos robustos e uma abordagem multifornecedores, o OktopUSP permite:  Ready-To-Go:  O OktopUSP oferece gerenciamento em nuvem ou on-premises, permitindo que você acesse seus dispositivos de qualquer lugar e receba alertas em tempo real, sem precisar modificar a topologia de sua rede.  Multi-Vendor:  Não se torne refém de um único fornecedor com soluções específicas e custosas. Com o OktopUSP, você pode comandar seu parque de dispositivos mistos com confiabilidade e segurança.  WiFi:  Com mais de 350 parâmetros para configuração de Wi-Fi e flexibilidade para monitorar diversos dispositivos IoT, o OktopUSP oferece um controle completo sobre sua rede wireless.  Em breve, traremos mais detalhes sobre o OktopUSP e também estamos orgulhosos de anunciar que o Made4Graph incluirá gerenciamento através do TR-369, além do TR-069. Fique atento às nossas atualizações para não perder nenhuma novidade!  O futuro nas soluções da Made4it  No Made4Graph, já é possível realizar o gerenciamento abrangente através do TR-069, permitindo que provedores e administradores de rede monitorem e controlem seus dispositivos com facilidade e eficácia. Além disso, a plataforma está se preparando para o futuro, com planos para implementar o gerenciamento via TR-369 em breve. Essa transição entre os dois protocolos é uma prova do compromisso da Made4it em fornecer soluções inovadoras que acompanhem as demandas em constante evolução do mercado. Com o suporte contínuo e as atualizações oferecidas pelo Made4Graph, os provedores e administradores de rede podem estar confiantes de que estão preparados para enfrentar os desafios e aproveitar as oportunidades que o futuro da gestão de CPEs e IoTs apresenta.  Fiquem ligados em nossa atualizações! Cadastre-se abaixo para não perder as novidades. 

Hacia el futuro de la gestión multivendedor para CPE e IoT: TR-069 a TR-369

Introducción En el panorama cada vez más interconectado de la tecnología moderna, la gestión eficiente y unificada de los dispositivos se ha convertido en algo crucial. La evolución del protocolo TR-069 a TR-369 marca un punto crucial en este camino, abriendo nuevas puertas a proveedores de servicios y usuarios finales. En este artículo analizaremos la transición de TR-069 a TR-369 y el importante impacto que tiene en la gestión de dispositivos en un mundo cada vez más conectado. TR-069 —> TR-369: El futuro de la gestión de dispositivos El Protocolo de Gestión de WAN CPE (CWMP), conocido como TR-069, supuso un hito en la capacidad de los proveedores de Internet para prestar servicios de forma rápida y eficaz, garantizando una gestión proactiva y segura de la red. Sin embargo, con la llegada de la Internet de los objetos (IoT ) y la creciente demanda de dispositivos interconectados, ha quedado claro que este protocolo necesita evolucionar. La TR-369, también conocida como Plataforma de Servicios al Usuario (USP), es la respuesta a esta necesidad de evolución. Desarrollado conjuntamente por una serie de empresas e instituciones de renombre, entre ellas Google, Nokia y Huawei, el TR-369 promete ser flexible, seguro, escalable y estandarizado para satisfacer las demandas de un mundo cada vez más conectado. Retos y oportunidades del Internet de los objetos La creciente demanda de entornos interconectados, como hogares inteligentes y entornos basados en la nube, ha traído consigo una serie de retos y oportunidades. La monetización de los dispositivos IoT se ha convertido en una prioridad para muchas empresas, lo que ha dado lugar a soluciones propietarias que, aunque comprensibles, contribuyen a un ecosistema pobre y limitado. TR-369 ha surgido como solución a estos retos, ofreciendo una norma abierta e interoperable que fomenta la competencia sana, la innovación continua y el ahorro de costes para los proveedores de servicios y los usuarios finales. El futuro de la gestión de dispositivos: TR-369 en acción Con la implantación de TR-369, los proveedores de servicios pueden esperar una gestión de dispositivos más eficaz y unificada, independientemente del proveedor. La flexibilidad y escalabilidad de TR-369 garantizan que las soluciones basadas en esta norma estén preparadas para los retos del futuro, manteniéndose al día y adaptándose a las nuevas tecnologías y demandas del mercado. Conclusión A medida que avanzamos hacia un futuro cada vez más interconectado, La evolución de TR-069 a TR-369 es un paso crucial en el camino hacia una gestión eficiente y unificada de los dispositivos. Con el apoyo de las principales empresas e instituciones del sector, el TR-369 promete revolucionar la gestión de los dispositivos en un mundo cada vez más conectado. Prepárese para el futuro de la gestión de dispositivos con TR-369 y descubra las ventajas de un enfoque multiproveedor para CPE e IoT. Conozca OktopUSP: la revolución en gestión de dispositivos Como patrocinadores oficiales del proyecto, Made4it se complace en presentar el OktopUSP un proyecto innovador desarrollado por la empresa Oktopus, dirigida por Leandro Antonio Farias Machado. Este proyecto promete revolucionar la forma en que los proveedores de Internet y los integradores informáticos gestionan sus dispositivos, ofreciendo control remoto, información de gran alcance y una solución preparada para el futuro. Descripción: OktopUSP se creó para que los proveedores de Internet y los integradores informáticos pudieran aprovechar todo el potencial de sus productos. Gracias a sus sólidas funciones y a su enfoque multiproveedor, OktopUSP permite: Listo: OktopUSP ofrece gestión en la nube o en las instalaciones, lo que le permite acceder a sus dispositivos desde cualquier lugar y recibir alertas en tiempo real, sin tener que modificar la topología de su red. Multiproveedor: No se convierta en rehén de un único proveedor con soluciones específicas y costosas. Con OktopUSP, puedes controlar tu parque de dispositivos mixtos de forma fiable y segura. WiFi: Con más de 350 parámetros para la configuración Wi-Fi y la flexibilidad para supervisar varios dispositivos IoT, OktopUSP le ofrece un control total sobre su red inalámbrica. Pronto os daremos más detalles sobre OktopUSP , y también nos enorgullece anunciar que Made4Graph incluirá la gestión a través de TR-369, además de TR-069. Permanezca atento a nuestras actualizaciones para no perderse ninguna novedad. El futuro en soluciones Made4it En Made4Graph ya es posible realizar una gestión integral a través del TR-069, lo que permite a los proveedores y administradores de red supervisar y controlar sus dispositivos de forma fácil y eficaz. Además, la plataforma se prepara para el futuro, con planes para implantar en breve la gestión a través de TR-369. Esta transición entre los dos protocolos es una prueba del compromiso de Made4it de ofrecer soluciones innovadoras que sigan el ritmo de las demandas en constante evolución del mercado. Con el soporte y las actualizaciones continuas que ofrece Made4Graph, los proveedores y administradores de redes pueden confiar en que están preparados para afrontar los retos y aprovechar las oportunidades que presenta el futuro de la gestión de CPE e IoT. Permanezca atento a nuestras actualizaciones. Suscríbase a continuación para no perderse las últimas noticias.

Towards the Future of Multivendor Management for CPEs and IoTs: TR-069 to TR-369

Introduction In the increasingly interconnected landscape of modern technology, efficient and unified device management has become crucial. The evolution of the TR-069 protocol to TR-369 marks a crucial point in this journey, opening new doors for service providers and end users. In this article, we’ll explore the transition from TR-069 to TR-369 and the significant impact this has on device management in an increasingly connected world. TR-069 —> TR-369: The Future of Device Management The CPE WAN Management Protocol (CWMP), known as TR-069, was a milestone in Internet providers’ ability to deliver services in an agile and efficient manner, guaranteeing proactive and secure network management. However, with the advent of the Internet of Things (IoT) and the growing demand for interconnected devices, it has become clear that this protocol needs to evolve. The TR-369, also known as the User Services Platform (USP), is the answer to this need for evolution. Jointly developed by a range of renowned companies and institutions, including Google, Nokia, Huawei and others, the TR-369 promises to be flexible, secure, scalable and standardized to meet the demands of an increasingly connected world. Challenges and Opportunities of the Internet of Things The growing demand for interconnected environments, such as smart homes and cloud-based environments, has brought with it a series of challenges and opportunities. Monetizing IoT devices has become a priority for many companies, leading to proprietary solutions that, while understandable, contribute to a poor and limited ecosystem. TR-369 has emerged as a solution to these challenges, offering an open and interoperable standard that promotes healthy competition, continuous innovation and cost savings for service providers and end users. The Future of Device Management: TR-369 in Action With the implementation of TR-369, service providers can expect more efficient and unified device management, regardless of vendor. The flexibility and scalability of TR-369 ensure that solutions based on this standard are prepared for the challenges of the future, keeping up to date and adaptable to new technologies and market demands. Conclusion As we move towards an increasingly interconnected future, The evolution from TR-069 to TR-369 is a crucial step in the journey towards efficient, unified device management. With the support of leading companies and institutions in the sector, the TR-369 promises to revolutionize the way devices are managed in an increasingly connected world. Prepare for the future of device management with the TR-369 and discover the benefits of a multi-vendor approach for CPEs and IoTs. Meet OktopUSP: The Revolution in Device Management As official sponsors of the project, Made4it is pleased to present the OktopUSP an innovative project developed by the company Oktopus, led by Leandro Antonio Farias Machado. This project promises to revolutionize the way internet providers and IT integrators manage their devices, offering remote control, powerful insights and a future-proof solution. Description: OktopUSP was created to enable internet providers and IT integrators to use the full potential of their products. With robust features and a multi-vendor approach, OktopUSP enables: Ready-To-Go: OktopUSP offers cloud or on-premises management, allowing you to access your devices from anywhere and receive real-time alerts, without having to modify your network topology. Multi-Vendor: Don’t become a hostage to a single supplier with specific and costly solutions. With OktopUSP, you can control your mixed device park reliably and securely. WiFi: With more than 350 parameters for Wi-Fi configuration and the flexibility to monitor various IoT devices, OktopUSP gives you complete control over your wireless network. We’ll be bringing you more details about OktopUSP soon, and we’re also proud to announce that Made4Graph will include management via TR-369 in addition to TR-069. Stay tuned for our updates so you don’t miss out on anything new! The future in Made4it solutions In Made4Graph it is already possible to carry out comprehensive management via the TR-069, allowing network providers and administrators to monitor and control their devices easily and effectively. In addition, the platform is preparing for the future, with plans to implement management via TR-369 soon. This transition between the two protocols is proof of Made4it’s commitment to providing innovative solutions that keep pace with the constantly evolving demands of the market. With the ongoing support and updates offered by Made4Graph, network providers and administrators can be confident that they are prepared to face the challenges and seize the opportunities that the future of CPE and IoT management presents. Stay tuned for our updates! Sign up below so you don’t miss out on the latest news.

Atualizações – Made4Flow, Made4Graph e Made4OLT – Março 2024

Made4Flow – Versão 2.7.0 Adições: Visualização de Roteador: Visualização de Interfaces: Visualização de Prefixo: Barra Horizontal: Setor: Polar: Últimos Valores: Lista de ASNs: Lista de Protocolos: Lista de Aplicações: Mapa: Alterações: Correções: Ainda não conhece o Made4Flow? Made4Graph – Versão 2.4.4 Adições: Correções: Ainda não conhece o Made4Graph? Made4OLT – Versão 1.3.1 [Beta] Adições: Alterações: Correções: Ainda não conhece o Made4OLT?

Reconfiguring ONU/ONT NOKIA G-1425-GA after reset: auto-configuration using DHCP Option 43 for ACS delivery

In this article we will talk about the process of reconfiguring Nokia G-1425-GA routers after they have been reset. In order for them to be completely reconfigured to the state they were in before the reset, an ACS TR-069 server must be up and running, persisting its previous settings. If you don’t know what an ACS server is or how useful it is, read this article. These tests were carried out in the laboratory environment of DPR Telecomunicações, NOKIA’s largest partner in Brazil. They have a large optical equipment factory and a laboratory for testing Nokia solutions. Find out more about DPR here. For the test, we used the UN model NOKIA G-1425-GA. It was completely configured, including Made4it’s ACS made4graph server, which was in charge of persisting data for provisioning. Once the laboratory environment has been properly provisioned, we apply a factory-reset to our test CPE. As we can see in the images below, all the settings have been lost, including WAN, Wifi and the ACS server returning to default. Requesting “Reset System Configuration to Factory Default“ The “default” TR-069 settings of the Nokia ONT after the reset. An important point in the lab is to observe the VLAN and addressing mode of the ONU with factory settings. In this case, the NOKIA ONU is on a WAN in VLAN 881 with DHCP active. With the router reset and the factory settings in place, we set up the Auto Provisioning infrastructure via DHCP Options 43, as described in the article. We use the same default VLAN 881 for this! Here, in a few moments, the ONU received the IP address from the DHCP server and also the ACS server. After that, the magic of TR-069 begins, with the ACS server made4graph completely reconfiguring the ONU to its previous state, including the correct WAN (user, pppoe password and BNG/BRAS access vlan), Wifi, port redirections, and much more. And how do you generate the URL for ACS delivery via DHCP Option 43? To generate the URL, Nokia uses a rule for option 43“Vendor Specific Information” coded with 3 parameters: The fields are always made up of: Based on this rule, we can generate the Option 43 code to be sent via DHCP. I’ll explain how. You must first have the data at hand: ACS server URL User name Password With this data in hand, you can generate the field in the rules that Nokia requires. Let’s take an example: 😀 To generate the ACS URL https://acs.made4graph.com.br/ with user made4graph and password made4it, we have to convert each field to hexadecimal, take note of the length of the string and put it in the correct format. URL URL (hex) Size Size (hex) https://acs.made4graph.com.br/ 68747470733A2F2F6163732E6D6164653467726170682E636F6D2E62722F 30 1E USER User (hex) Size Size (hex) made4graph 6D616465346772617068 10 0A PASSWORD Password (hex) Size Size (hex) made4it 6D616465346974 7 07 So the complete hexa field would be: 01 1E 68747470733A2F2F6163732E6D6164653467726170682E636F6D2E62722F 02 0A 6D616465346772617068 03 07 6D616465346974 This results in the final string, which can be pasted into the DHCP Server: 0x011E68747470733A2F2F6163732E6D6164653467726170682E636F6D2E62722F020A6D61646534677261706803076D616465346974 *the 0x at the beginning indicates to the DHCP Server that the following data is in hexadecimal To make things easier, we’ve created an automatic Option 43 generator for NOKIA, which you can check out here Conclusion In this article, we show you how to configure a DHCP server to deliver ACS attributes to Nokia CPEs that have just been “reset” to factory defaults without pre-setting or changing the firmware. This allows us to easily and effectively autoconfigure an ACS server URL, user and password on a Nokia CPE/ONU, making it accessible by an ACS server and allowing it to be autoconfigured via the TR-069. This technique adds a lot to environments with Nokia CPEs/ONUs, where a pre-configured DHCP server in VLAN ID 881 (Default Nokia) ensures that regardless of whether a CPE resets or loses its settings, it will always have connectivity to the ACS server and will always be properly configured via TR-069. Special thanks to DPR for providing us with all the necessary support, as well as providing the infrastructure for the tests to take place, proving that the Nokia equipment reliably implements the specification. TR-069 CPE WAN Management Protocol and allow ACS auto-configuration via DHCP Option43.

Reconfigurando ONU/ONT NOKIA G-1425-GA após reset: a auto-configuração usando DHCP Option 43 para entrega do ACS

Neste artigo iremos falar sobre o processo de reconfiguração de roteadores Nokia G-1425-GA após serem resetados. Para que eles sejam completamente reconfigurados para o estado que estavam antes do reset, é necessário um servidor ACS TR-069 configurado e funcionando, persistindo suas configurações previamente. Se não sabe o que é um servidor ACS, e nem sua utilidade, leia o artigo . Estes testes foram realizados no ambiente de laboratório da DPR Telecomunicações, maior parceira da NOKIA no Brasil. Eles contam com uma ampla fábrica de equipamentos ópticos, e um laboratório para testes de soluções Nokia. Conheça mais sobre a DPR aqui . Para o teste, usamos o modelo de ONU NOKIA G-1425-GA. Ela foi completamente configurada, incluindo o servidor ACS made4graph da Made4it, que ficou a cargo da persistência de dados para provisionamento.  Após o ambiente de laboratório estar devidamente provisionado, aplicamos um factory-reset na nossa CPE de testes. Conforme vemos nas imagens abaixo, as configurações foram todas perdidas, incluindo WAN, Wifi e servidor ACS retornando para o padrão.  Solicitando o ”Reset System Configuration to Factory Default” As configurações “default” de TR-069 da ONT Nokia após o reset.    Um ponto de importante do laboratório, observar a VLAN e modo de endereçamento da ONU com configurações de fábrica. No caso, a ONU NOKIA sobe uma WAN na VLAN 881 e com o DHCP ativo.  Com o roteador resetado, com as informações de fábrica em vigor, subimos a infraestrutura de Auto provisionamento via DHCP Options 43, conforme artigo.  Usamos a mesma VLAN 881 default para isto!  Aqui, em poucos instantes a ONU recebeu o endereço IP do DHCP server e também o servidor ACS.   Após isto, começa a mágica do TR-069, com o servidor ACS made4graph reconfigurando completamente a ONU para o estado anterior, incluindo a WAN correta (usuario, senha pppoe e vlan de acesso ao BNG/BRAS), Wifi, redirecionamentos de porta, e muito mais.  E como gerar a URL para entrega do ACS via DHCP Option 43? Para gerar a URL, a Nokia utiliza uma regra para a opção 43 “Vendor Specific Information” codificada com 3 parâmetros:   Os campos são sempre compostos por:  Com base nesta regra, podemos gerar o código da Option 43 para ser enviado via DHCP. Vou te explicar como.  Você deve primeiramente ter os dados em mãos:  URL do servidor ACS  Nome de usuário  Senha  Com estes dados em mãos, você pode gerar o campo nas regras que a Nokia requer. Vamos ao exemplo: 😀   Para gerar a URL do ACS https://acs.made4graph.com.br/ com usuário made4graph e senha made4it, temos que converter cada campo para hexadecimal, tomar nota do tamanho da string e colocar no formato correto.  URL  URL (hex)  Size  Size (hex)  https://acs.made4graph.com.br/  68747470733A2F2F6163732E6D6164653467726170682E636F6D2E62722F  30  1E  USER  Usuário (hex)  Size  Size (hex)  made4graph  6D616465346772617068  10  0A  SENHA  Senha (hex)  Size  Size (hex)  made4it  6D616465346974  7  07  Então o campo hexa completo ficaria: 01 1E 68747470733A2F2F6163732E6D6164653467726170682E636F6D2E62722F 02 0A 6D616465346772617068 03 07 6D616465346974  Chegando na string final, que pode ser colada no DHCP Server:  0x011E68747470733A2F2F6163732E6D6164653467726170682E636F6D2E62722F020A6D61646534677261706803076D616465346974  *o 0x no início indica ao DHCP Server que os dados que seguem são em hexadecimal  Para facilitar, criamos o gerador automático de Option 43 para a NOKIA, que você pode conferir aqui Conclusão Neste artigo, mostramos como configurar um servidor DHCP para entregar atributos de ACS a CPEs Nokia recém “resetadas” para o padrão de fábrica sem “pre-set” ou alteração de Firmware. Isto nos permite de forma fácil e efetiva autoconfigurar uma URL, usuário e senha de um servidor ACS em uma CPE/ONU Nokia, tornando-a acessível por um servidor ACS e permitindo ela ser autoconfigurada via o TR-069. Tal técnica agrega muito a ambientes com CPEs/ONUs Nokia, onde um servidor DHCP pré-configurado na VLAN de ID 881 (Default Nokia) garante que independente de uma CPE resetar ou perder suas configurações, sempre terá conectividade com o servidor ACS e sempre estará devidamente configurada via o TR-069.   Agradecimento especial a DPR por nos proporcionar todo o apoio necessário, além de fornecer a infraestrutura para os testes acontecerem nos comprovando que os equipamentos Nokia implementam fidedignamente a especificação TR-069 CPE WAN Management Protocol e permitem autoconfiguração do ACS via o DHCP Option43.  

DHCP Option 43 for ACS auto-configuration

Today we’re going to explore the famous DHCP Option 43, used mainly to autoconfigure devices such as Access Points, Switches, IP Phones, CPEs, IoT devices and others through TR-069. We will also show a configuration example using the DHCP Server of a Mikrotik router, delivering parameters via DHCP Option43 and allowing autoconfiguration of services in the process of assigning IP addresses to the device. This allows us, for example, to signal a controller external to the device automatically, even if the device has gone through a factory-reset. RFC 2132 “DHCP Options and BOOTP Vendor Extensions” [1] deals with various types of information that can be sent via the DHCP protocol, such as DNS, subnet mask, router address, vendor-specific attributes and much more. Option 43 is defined in this RFC as “Vendor Specific Information” and is used for DHCP clients and servers to exchange specific information with each other. The RFC doesn’t define what values I can send, nor what this information is, much less the type of data. It only describes the structure, which should be: Code Len Vendor specific information 43 n i1 i2 …  Code 1 Len 1 Date 1 Code 2 Len 2 Date 2 Code n Len n Date no. T1 n1 d1 T2 n2 T2 …  …  …  With this structure, each manufacturer or organization can model the data as is most convenient for their use. For example, for access-points the IP addresses of Wifi controllers can be configured, allowing them to be “joined” to the centralized controller, for IP Phones the IP or URL of the telephony server can be delivered and for routers that support TR-069 the ACS URL can be configured. And all this automatically! The focus of this article will be to show how to use option 43 together with TR-069, sending the URL from the ACS server to the CPE via the DHCP server. This allows the router, even when reset and without a configuration template, to learn the URL of the ACS server via DHCP, along with the user and password, the data needed to integrate with the ACS and allow the TR-069 to apply configurations to the CPE automatically. But before I continue, I’ll leave you with some links to other examples of option 43 use cases. Configure DHCP OPTION 43 for Lightweight Access Points: https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/97066-dhcp-option-43-00.html VLAN ID Discovery over DHCP: https://wiki.unify.com/wiki/VLAN_ID_Discovery_over_DHCP Use DHCP Option 43 for Unifi Accesspoint Provisioning:https://niksec.com/use-dhcp-option-43-for-unifi-accesspoint-provisioning/ How DHCP ended up in the TR-069 If you don’t know what ACS is, check out our other article . DHCP was included as one of the ways of onboarding ACS. Onboarding is the process in which the CPE/router is configured with an ACS server.There are three ways of onboarding CPEs to an ACS server, according to the Broadband Forum’s TR-069 specification [2]: The ultimate goal of any of the three is one: to have the ACS server URL configured in the CPE so that it can be managed via the TR-069 protocol. DHCP Option 43 request process The BroadBand Forum defines some steps so that the CPE can get the ACS URL via DHCP. The picture below shows the steps, and we’ll talk about each of them in a moment. Communication step by step: The TR-069 specification also defines other fields/protocols that can be used for the same purpose: DHCPv4 Option 125, DHCPv6 Option 17. They also mention various post-reset discovery rules and how to deal with connectivity problems with the ACS. But they are beyond the scope of this article. Example of a DHCP transaction with Option 43 – Packet captures Mikrotik configuration example Here, we’ll see how to configure a Mikrotik router to deliver autoconfiguration parameters to “clients” via DHCP-Server using Option43. The configuration will be based on the topology below, similar to the one used in our tests with a Nokia CPE. First you need to have the DHCP Server configured, then link the DHCP Option43 settings. We used the network 192.168.2.0/24 and Vlan 881, as in our example: You might be wondering, where did the value of option 43 come from? There is a rule to be created, and you can see how to generate it for your ACS server in the following article. Conclusion In this article, we look at how to use DHCP’s “Option43” attribute to autoconfigure an ACS server on CPEs and various devices. We discuss how it works and how it can be used to automate the delivery of specific configurations to devices using a protocol as common as DHCP. Knowing the capabilities, attributes and options that the equipment manufacturer and model support helps us to automate various configurations, including but not restricted to managing a CPE, Nokia, via the TR-069. References:[1] RFC 2132, DHCP Options and BOOTP Vendor Extensions, https://www.ietf.org/rfc/rfc2132.txt [2] TR-069, CPE WAN Management Protocol, https://www.broadband-forum.org/pdfs/tr-069-1-6-1.pdf

DHCP Option 43 para auto-configuração de ACS 

Hoje vamos explorar o famoso DHCP Option 43, usado principalmente na autoconfiguração de dispositivos como Access Points, Switches, Telefones IP, CPEs, dispositivos IoT e outros através do TR-069. Também vamos mostrar um exemplo de configuração utilizando o DHCP Server de um roteador Mikrotik entregando parâmetros via DHCP Option43 e permitindo a autoconfiguração de serviços no processo de atribuir endereço de IP ao dispositivo. Isso nos possibilita, por exemplo, sinalizar um controlador externo ao dispositivo, automaticamente, mesmo que o equipamento tenha passado por um factory-reset. A RFC 2132 “DHCP Options and BOOTP Vendor Extensions” [1] trata de diversos tipos de informações que podem ser enviadas através do protocolo DHCP como por exemplo o DNS, Máscara de sub-rede, endereço do gateway (router), atributos específicos de vendor e muitos outros mais. O Option 43 é definido nesta RFC como “Vendor Specific Information” e é usado para que os clientes e servidores DHCP troquem informações específicas entre sí. A RFC não define que valores eu posso enviar, e nem que informações são estas e muito menos o tipo de dados. Ele apenas descreve a estrutura, que deve ser: Code  Len  Vendor specific information  43  n  i1  i2  …  Code 1  Len 1  Data 1  Code 2  Len 2  Data 2  Code n  Len n  Data n  T1  n1  d1  T2  n2  T2  …  …  …  Com esta estrutura, cada fabricante ou organização, pode modelar os dados como for mais conveniente para seu uso. Por exemplo, para access-points poderem ser configurados os endereços IP dos controladores Wifi permitindo seu “join” no controlador centralizado, para Telefones IP entregando o IP ou URL do servidor de telefonia e para os roteadores que suportem TR-069 poderem ser configurados com a URL do ACS. E tudo isso automaticamente! O foco deste artigo será mostrar o uso do option 43 junto ao TR-069, enviando a URL do servidor ACS para a CPE através do servidor DHCP. Isso nos permite que o roteador mesmo resetado e sem um “template” de configuração, aprenda via DHCP a URL do servidor ACS junto do usuário e senha, dados necessários para se integrar ao ACS e permitir o TR-069 aplicar configurações na CPE automaticamente. Mas antes de continuar, vou deixar alguns links de outros exemplos de caso de uso do option 43. Configure DHCP OPTION 43 for Lightweight Access Points: https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/97066-dhcp-option-43-00.html VLAN ID Discovery over DHCP: https://wiki.unify.com/wiki/VLAN_ID_Discovery_over_DHCP Use DHCP Option 43 for Unifi Accesspoint Provisioning:https://niksec.com/use-dhcp-option-43-for-unifi-accesspoint-provisioning/ Como o DHCP foi parar no TR-069 Se não sabe o que é o ACS, consulte nosso outro artigo . O DHCP foi inserido como uma das formas de onboarding do ACS. O onboarding é o processo em que a CPE/roteador é configurada com um servidor ACS.Existem três formas de se fazer o processo de onboarding das CPEs para um servidor ACS, segundo a especificação TR-069 do Broadband Forum [2]: O objetivo final de qualquer um dos três é um só: ter a URL do servidor ACS configurada na CPE, para que a mesma possa ser gerenciada através do protocolo TR-069. Processo de solicitação do DHCP Option 43 O BroadBand Forum define alguns passos para que a CPE possa conseguir a URL do ACS através do DHCP. A figura abaixo mostra os passos, e já vamos falar de cada um deles. Passo a passo da comunicação: Na especificação do TR-069 também estão definidos outros campos/protocolos que podem ser utilizados para o mesmo fim: DHCPv4 Option 125, DHCPv6 Option 17. Também citam diversas regras de descoberta pós-reset e como lidar com problemas de conectividade com o ACS. Mas estão fora do escopo deste artigo. Exemplo de uma transação DHCP com Option 43 – Capturas de pacotes Exemplo de configuração no Mikrotik  Aqui, veremos como configurar um roteador Mikrotik para, via DHCP-Server, entregar parâmetros de autoconfiguração de “clientes” via o Option43.  A configuração será baseada na topologia abaixo, semelhante ao utilizado em nossos testes com uma CPE Nokia.   Primeiro é necessário ter a configuração do DHCP Server, depois vincular as configurações de DHCP Option43.   Utilizamos a rede 192.168.2.0/24 e a Vlan 881, conforme nosso exemplo:  Você deve estar se perguntando, de onde aquele valor da opção 43 saiu? Existe sim uma regra para ser criada, e você pode conferir como gerar para seu servidor ACS no seguinte artigo. Conclusão Neste artigo, abordamos como utilizar o atributo “Option43” do DHCP para autoconfiguração de um servidor ACS em CPEs e dispositivos diversos. Abordamos o seu funcionamento e como ele pode ser utilizado para automação de entrega de configurações específicas a dispositivos utilizando um protocolo tão comum como o DHCP. Conhecer as capacidades, atributos e opções que o fabricante e modelo de equipamento suportam nos ajudam a automatizar diversas configurações, incluindo mas não se restringindo ao gerenciamento de uma CPE, Nokia, via o TR-069. Referencias:[1] RFC 2132, DHCP Options and BOOTP Vendor Extensions, https://www.ietf.org/rfc/rfc2132.txt [2] TR-069, CPE WAN Management Protocol, https://www.broadband-forum.org/pdfs/tr-069-1-6-1.pdf