Como configurar vlans nos equipamentos Ufispace
Neste artigo será demonstrado como configurar vlans nos equipamentos Ufispace, no modo trunk, hybrid e access. Primeiramente, segue abaixo o passo a passo de como criar a VLAN: Acessar modo Privilegiado: Acessar modo de configuração: Criar Bridge e configurar protocolo RSTP (requisito do OcNos). Criar Vlan e associar na bridge criada: Sair do modo de “vlan database” Verificar configurações pendentes: Saída esperada do comando acima: Caso necessário desfazer as configurações, pode ser usado o comando: Se as configurações estiverem corretas, podem ser aplicadas com o comando: Para verificar a configuração da VLAN: Com a Vlan criada, é necessário atribuir em uma interface, seja em modo TAG ou UNTAGGED (em access). Como configurar VLAN em modo Trunk: Acessar interface: Configurar em modo Layer2 e atribuir uma Bridge (criada anteriormente): Configurar modo de interface em Trunk: Configurar vlan em TAG na interface: Conferir configuração e aplicar: Como configurar VLAN no modo Access Criar Vlan e associar na bridge criada: Acessar interface: Configurar em modo Layer2 e atribuir uma Bridge: Configurar modo de interface em Trunk: Configurar vlan em UNTAGGED na interface: Conferir configuração e aplicar: Como configurar VLAN em modo Hybrid Acessar interface: Configurar em modo Layer2 e atribuir uma Bridge: Configurar modo de interface em Hybrid: Configurar vlan em UNTAGGED na interface: Configurar vlan em TAGGED na interface: Conferir configuração e aplicar: Resumo de todas configurações aplicadas: Ao final de todas essas configurações detalhadas, você estará apto a gerenciar VLANs de maneira eficiente nos equipamentos Ufispace, garantindo uma rede organizada e segura. Siga os passos com atenção e, em caso de dúvidas, não hesite em consultar a documentação oficial ou entrar em contato com o suporte técnico especializado. Gostaria de falar com um de nossos especialistas em UfiSpace e IPInfusion? Nós da Made4it somos especialistas nessas tecnologias e oferecemos serviços completos de configuração e suporte. Fale com nossos consultores para saber mais e otimizar a sua rede com soluções profissionais: https://made4it.com.br/
Onde utilizar Ufispace
Equipamentos Ufispace: Utilizações e Serviços Suportados Introdução A Ufispace é uma empresa no campo de redes e telecomunicações, especializada em fornecer soluções de infraestrutura de rede de alta qualidade. Seus equipamentos são projetados para atender às demandas crescentes de conectividade, capacidade e desempenho em diversos setores. Neste artigo, exploraremos os equipamentos S9600-72XC, S9600-56DX e S9510-28DC, onde eles podem ser utilizados e quais serviços eles suportam. Equipamentos da Ufispace S9600-72XC – Conta com 8 portas 40/100G, 64 portas 1/10/25G, 2 portas 10G (MGMT, Óptica) e 1 porta 100/1000M (MGMT, Elétrica); Processador Intel Skylake-D 8-Core @ 1.9GHz, memória 32GB DDR4, armazenamento 128GB SSD e performance de Switching Capacity 2.4Tbps, Deep Buffer 4GB. S9600-56DX – Conta com 8 portas 40/100/400G, 48 portas 40/100G, 4 portas 1/10/25G e 1 porta 100/1000M (MGMT, Elétrica); Processador Intel Icelake-D 8-Core @ 2.1GHz, memória 32GB DDR4, armazenamento 128GB SSD e performance de Switching Capacity 4.8Tbps, Deep Buffer 8GB. S9510-28DC – Conta com 2 portas 100/400G, 2 portas 40/100G, 24 portas 10/25G e 1 porta 100/1000M (MGMT, Elétrica); Processador Intel Denverton-NS 4-Core @ 1.6GHz (Standard) / Intel Denverton-NS 8-Core @ 1.7GHz (Premium), memória 8GB DDR4 (Standard) / 16GB DDR4 (Premium), armazenamento 32GB SSD (Standard) / 128GB SSD (Premium) e performance de Switching Capacity 800Gbps, Deep Buffer 2GB. Utilizações dos Equipamentos Ufispace Devido à sua alta densidade de portas e capacidade de comutação. Como Data Center Core ou Agregador de servidores. Podem ser utilizados em cenários de topologia Core, Agregação, trabalhando como BGP, MPLS, como P e PE. Em cenários de L2VPN, L3VPN, 6PE. Conclusão Os switches da Ufispace são uma ótima opção em data centers para funções críticas como núcleo e agregação de servidores devido à alta densidade de portas e capacidade de comutação. Para ISPs, eles oferecem robustez e flexibilidade necessárias para topologias complexas, suportando protocolos como BGP e MPLS, além de serviços como L2VPN e L3VPN. Equipados com processadores de última geração, memória abundante e armazenamento eficiente, esses switches garantem desempenho superior e alta capacidade, tornando-os ideais para construir infraestruturas de rede modernas e eficientes.
Acesso inicial no Ufispace
Hoje vamos falar sobre como fazer acesso inicial aos equipamentos UFISPACE com sistema operacional OcNOS da IP Infusion. O primeiro acesso ao equipamento deve ser feito utilizando um cabo serial. A maioria dos computadores hoje não dispõe de uma conexão serial, sendo assim, é possível utilizar um adaptador console usb RJ45 como o exemplo da foto: Com o cabo em mãos, deve-se conectar o lado do RJ45 na porta console do equipamento UFISPACE, conforme o exemplo abaixo: Com a conexão física entre o computador e UFISPACE, podemos então utilizar um software, como o teraterm, putty, dentre outros para fazer o acesso inicial. Neste exemplo, vamos demonstrar como fazer utilizando o Putty. Para isso, abra o Putty e insira os dados conforme abaixo: Em Serial line, coloque o nome da interface COM do seu computador. Isso pode variar de acordo com cada equipamento. Speed de acesso aos UFISPACE devem ser configurados em 115200. Com acesso via console chegaremos à tela de solicitação de usuário e senha, que por padrão vem com usuário “ocnos” e senha “ocnos”: Após acessar via console, a primeira recomendação é alterar a senha do usuário ocnos para uma mais forte, para isso, devemos seguir os passos: 1 – Entrar em modo enable: 2 – Entrar no modo de configuração: 3 – Alterar a senha do usuário, e criar um novo usuário, conforme o exemplo: 5 – Aplicar a configuração: 6 – Por fim, salvar a configuração: Agora, vamos configurar uma interface para gerência. Por padrão, equipamentos UFISPACE vem com a interface “eth0” para ser utilizada com uma gerência out-of-band. Uma boa prática, é deixar a gerência somente em uma VRF de gerência, e que tenha acesso controlado somente através dessa VRF. Para realizar essa configuração, seguimos os seguintes passos: 1 – Acessa a interface eth0: 2 – Atribui a VRF management à interface: 3 – Configura o IP de gerência e descrição da interface: 4 – Aplica configuração e salva: Para validar a configuração da interface, podemos utilizar o comando “show ip interface brief”, conforme o exemplo: Se estiver no modo de configuração, utilize o comando “do show ip interface brief” Para configurar a rota default na vrf, utilizamos o seguinte comando: Para validar a rota default na VRF, podemos utilizar o comando: Por padrão, o ssh já vem habilitado na vrf management, caso queira desativar, utilize o comando: Para ativar SSH na vrf main, utilize o comando: Por fim, é importante configurar ACL’s para proteger o acesso SSH e permitir somente redes que realmente podem ter o acesso ao equipamento. Vamos então configurar a ACL que contenha nossas redes admin, que nesse caso serão as redes 10.10.0.0/30 e 172.16.0.0/24: Agora precisamos aplicar a ACL no line vty: Testando acesso por ssh com novo usuário criado: Vemos que o acesso funcionou corretamente. Agora vamos testar se a ACL que criamos para proteção está funcionando. Neste caso, vamos utilizar como origem o IP 172.20.0.1 para acesso ao equipamento: Vemos que o ping funciona normalmente: Porém não nos dá acesso SSH, confirmando que a ACL está funcionando corretamente: Agora vamos configurar SNMP para fazer monitoramento por um sistema como o Zabbix. Para habilitar SNMP na vrf management, utilizamos o comando: Caso seja utilizada a vrf main para fazer o monitoramento, simplesmente utilizamos os comandos: É importante mantermos a hora do equipamento correta para que seja possível validar logs para troubleshooting com a hora local correta. Para isso, vamos realizar a configuração de NTP para atualização da data e hora: Para verificar os peers NTP, utilizamos o comando: Agora devemos corrigir o timezone para que a hora fique correta: Outra funcionalidade importante é a possibilidade de utilizar “commit confirmed” com timeout, para utilizar em casos de configurações que podem causar downtime na rede. Vamos fazer um exemplo alterando o hostname e aplicar com “commit confirmed timeout” de 10 segundos: Se o commit não for confirmado, a configuração irá voltar para a configuração anterior: Para confirmar o commit, utilizamos o comando “confirm-commit”. Conclusão Após concluir as configurações iniciais, o equipamento estará pronto para responder ao acesso SSH via rede para os IPs autorizados no firewall e com os usuários configurados. O monitoramento SNMP também poderá consultar as informações utilizando a Community criada. Se surgir alguma dúvida sobre a configuração inicial do UFISPACE, entre em contato conosco para que possamos auxiliá-lo.
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 aos 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 especializada. 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 da 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
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 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 selecionar 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: Datacenter > 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 são 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. Ao finalizar a importação, 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, onde 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 patrocinadora 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 nossas atualizações! Cadastre-se abaixo para não perder as novidades.
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 importante do laboratório é observar a VLAN e o 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 (usuário, 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 à 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 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 si. 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 o modelo de equipamento suportam nos ajuda a automatizar diversas configurações, incluindo mas não se restringindo ao gerenciamento de uma CPE, Nokia, via o TR-069. Referências:[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
VMware x Proxmox – Qual escolher?
Introdução Quando falamos de servidores hoje em dia, automaticamente já associamos à virtualização. Foi-se o tempo em que usávamos servidores bare-metal para executar apenas uma aplicação. Com a facilidade da virtualização e o melhor aproveitamento dos recursos do servidor, tornou-se quase obrigatório utilizar o seu servidor com algum software de virtualização. Atualmente, dois grandes nomes têm liderado quando o assunto é virtualização: VMware e Proxmox. Ainda mais depois das notícias referentes à venda do VMware para a Broadcom, esse assunto começou a ficar ainda mais em alta. E a dúvida que percorre a maioria das pessoas é: VMware ou Proxmox? Qual virtualizador escolher? Qual é o “melhor”? Ao longo deste post, iremos realizar algumas comparações entre os dois virtualizadores para que você possa decidir qual deles melhor atende à sua necessidade e, claro, também conhecer as principais funcionalidades de cada um! Visão geral dos serviços Proxmox é um virtualizador open-source atualizado e mantido pela Proxmox. Ele é baseado em Debian e utiliza como virtualizador o KVM/QEMU e LXC para containers. Ele se destaca por ser gratuito e ter uma grande variedade de funcionalidades, de forma que o limite do quanto você pode crescer e evoluir está diretamente ligado ao seu conhecimento com a ferramenta. O Proxmox também se destaca muito na questão de compatibilidade com hardwares mais antigos, pois está diretamente ligado ao kernel do Linux que está sendo utilizado. VMware é um virtualizador de código proprietário e é atualizado e mantido recentemente pela Broadcom. Atualmente, deixou de ser gratuito, passando a aderir somente à forma de licenciamento para a utilização dele. Utiliza como virtualizador tecnologias proprietárias para virtualização de servidores, e é inegável a sua alta performance e estabilidade. Ele se destaca por sua interface simples e funcionalidades que agregam muito em cenários grandes. A parte de compatibilidade do VMware depende da versão em que ele está, e quanto mais nova a versão, menos compatibilidade com hardwares considerados antigos. Facilidade de uso Proxmox, em um primeiro momento, pode parecer confuso e difícil, ainda mais porque algumas configurações precisam de integração com o CLI. Porém, depois que você se habitua com a sua interface e as funções que você precisa, tudo fica mais simples. Ele também possui uma ótima documentação que aborda todas as funções disponíveis. Também conta com um suporte pago que fica a escolha do usuário se deseja adquirir ou não, e possui uma boa comunidade ativa. VMware possui uma interface amigável e mais objetiva. Com alguns poucos cliques, você já consegue subir uma VM e deixá-la funcional. Por outro lado, caso queira ter acesso a outras funcionalidades, vai precisar adquirir uma nova licença e/ou configurar algum outro software (ex: VEEAM, vCenter). Possui uma ótima documentação e vários KBs (Base de Conhecimento o/ knowledge base) explicando diversos problemas que podem acontecer. Performance Ambos os serviços têm uma boa performance. O VMware se destaca por executar o seu SO em memória RAM, permitindo assim uma melhor navegação na sua interface. Fora isso, ambos estão bem próximos na questão de performance em cenários mistos, utilizando VMs Linux e Windows e diferentes tipos de storage e armazenamentos. Escalabilidade Ambos os virtualizadores permitem aumentar os recursos (CPU/MEM/DISCO) das suas VMs sem problemas, e se preciso, aumentar até recursos internos como adicionar mais espaço em algum datastore ou disco de suas VMs. Agora, caso você adquira mais um servidor e queira aumentar a sua infraestrutura de servidores, o Proxmox lida melhor com a adição de um novo servidor em seu sistema. Enquanto no VMware esse servidor ficaria isolado e seria preciso configurar um novo serviço (vCenter) para unir os servidores sobre sua gerência, no Proxmox basta criar um Cluster e cadastrar o novo servidor no cluster (literalmente só essas duas configurações). Recursos e funcionalidades Ambos os serviços contam com recursos e funcionalidades parecidas. No caso do VMware, o acesso a elas vai depender da licença que você possui, enquanto no Proxmox vai depender se a versão em que você está possui ou não suporte a ela. Exemplos de algumas funcionalidades que possuem em ambos: Custos Fizemos uma simulação para um servidor com 1 CPU (Socket) e esses foram os custos Para o Proxmox não é necessário licença para uso, somente para Suporte direto do fabricante caso queira. Estudos de caso e exemplos práticos Vamos supor alguns cenários e entender onde que é interessante implementar VMware ou Proxmox. PS: Irei puxar sardinha para cenários On-premises de provedores de internet! Cenário 1: Possuo um servidor usado antes de 2015 e gostaria de adicionar ele em produção para virtualizar 5 VMs não críticas. Cenário VMware: Cenário Proxmox: Ou seja, em ambos os cenários você vai conseguir implementar esse seu cenário. Claro que no caso do VMware, além do preço da licença, você tem que se atentar com o modelo do seu servidor e principalmente do ano dele. Servidores muito antigos não são suportados pelas versões mais recentes do VMware, e você terá que fazer mais investimentos para suportar o cenário de backup caso tenha mais que 10 VMs em seu cenário. Upgrade Cenário 1: Vi que a virtualização funcionou muito bem, e agora quero adicionar mais VMs, porém agora vão ter VMs críticas, e para executar essas VMs fiz um upgrade e adquiri um novo servidor. Cenário VMware: Cenário Proxmox: Conclusão Enfim, vimos que o Proxmox e VMware são bem parecidos e conseguem entregar o mesmo resultado, desde que você atente a alguns requisitos! Sobre qual é melhor, tudo depende do tamanho da sua infraestrutura e criticidade. A primeira coisa que temos que levar em conta é o investimento que irei realizar em licenças. Caso opte por utilizar VMware, veja se esse investimento não poderia ser mais útil em alguma outra área (por exemplo, realizar o upgrade de alguma peça do meu servidor interno). A minha recomendação é a seguinte: se a sua infraestrutura está 100%, com servidores novos e não precisa de upgrade, e você tem a possibilidade de adquirir as licenças, vá de VMware, pois ele vai te entregar o que tem de
Como configurar FlowSpec em Roteadores Juniper
Visão Geral: O BGP FlowSpec (Border Gateway Protocol Flow Specification) é uma extensão do protocolo BGP usado para definir regras de filtragem de tráfego em roteadores ou simplificando podendo gerar regras de firewall nos roteadores a partir de um anúncio BGP. Ao contrário do BGP convencional, que roteia com base em informações de IPv4/IPv6 e prefixo, o BGP FlowSpec permite que os administradores de rede especifiquem critérios mais granulares para o encaminhamento de pacotes, incluindo informações sobre camada 4 (portas TCP/UDP) e até mesmo padrões de pacotes. Para saber mais sobre o BGP Flowspec acesse nosso artigo falando sobre o que é BGP Flowspec através deste link. Funcionamento: O BGP FlowSpec funciona adicionando novos tipos de atributos ao BGP, permitindo aos administradores de rede especificarem regras de filtragem detalhadas. Essas regras podem incluir critérios como: As seguintes ações podem ser tomadas com o BGP FlowSpec: Quando essas regras são propagadas através da rede BGP, os roteadores podem usar essas informações para filtrar ou manipular o tráfego de acordo com as políticas definidas. Funcionamento – Mais Detalhes: No contexto do BGP FlowSpec, as ações são especificadas como parte das regras de filtro. Cada regra de filtro contém três partes principais: As ações no BGP FlowSpec são codificadas usando comunidades BGP. Cada ação é mapeada para uma comunidade BGP específica: Ao criar uma regra BGP FlowSpec, você especifica os campos de correspondência, a ação desejada e, opcionalmente, campos de protocolo. Esta regra é então codificada como uma comunidade BGP e incluída em uma mensagem de atualização BGP que é enviada para os roteadores vizinhos. Os roteadores que recebem essa regra aplicam as ações especificadas aos pacotes que correspondem aos critérios de correspondência. Por favor, note que as comunidades BGP específicas para cada ação podem variar de acordo com a implementação do BGP FlowSpec em seu equipamento de rede. Recomendo consultar a documentação do seu equipamento para obter informações detalhadas sobre as comunidades BGP associadas a cada ação no BGP FlowSpec. Casos de Uso: 1. **Mitigação de Ataques DDoS**: O BGP FlowSpec pode ser utilizado para bloquear ou redirecionar tráfego malicioso durante ataques de negação de serviço distribuídos (DDoS). As regras precisas podem ser aplicadas para filtrar o tráfego indesejado e manter os serviços online. 2. **Políticas de QoS (Qualidade de Serviço)**: Administradores de rede podem utilizar o BGP FlowSpec para garantir a qualidade de serviço, priorizando determinados tipos de tráfego com base em portas ou protocolos específicos. 3. **Implementação de Políticas de Segurança**: O BGP FlowSpec pode ser usado para implementar políticas de segurança granulares, bloqueando tráfego associado a malware ou atividades suspeitas. Exemplos de Configuração: A configuração do BGP FlowSpec pode variar de acordo com o equipamento de rede utilizado. Este exemplo explora como projetar uma solução de mitigação de DDoS em que um provedor de serviços permite que seus clientes anunciem rotas BGP FlowSpec para ele. Também discute algumas das melhores práticas que devem ser consideradas antes de implementar este tipo de solução e, finalmente, alguns dos comandos do Junos disponíveis para o ajudar a verificar se a solução de Flow-spec está funcionando corretamente. Cenário de Topologia para o exemplo: Vamos começar dando uma olhada em como nossa solução será configurada: Conforme podemos ver na topologia acima, existe a BORDA que é um equipamento Juniper que tem a função de Roteador de BGP da rede, o Made4Flow que é o software que irá analisar os fluxos e gerar regras de BGP FlowSpec dinamicamente e anunciar via BGP para o Roteador BGP chamado BORDA. Neste cenário, o ataque exemplo é um ataque de amplificação de DNS. Isto significa que a rede está recebendo um grande volume de pacotes UDP porta 53 de que na realidade não necessitaria para o funcionamento normal do ISP. O ataque enche o circuito entre o ISP e as operadoras e, efetivamente, deixa a rede inoperante. Quando o atacante decide lançar o ataque, o ISP pode utilizar o Made4Flow para gerar uma rota BGP FlowSpec apenas para pacotes UDP porta 53 e anunciá-la para o Roteador de BGP BORDA, que pode transformar essa rota em um filtro de firewall em suas interfaces de comunicação com as Operadoras. E então isso bloqueia os pacotes de amplificação de DNS na borda da rede do ISP e também na operadora (se a operadora suportar sessões FlowSpec), mas permite que o tráfego legítimo continue a chegar. Primeiramente vamos analisar as configurações da sessão BGP FlowSpec no Roteador de BGP BORDA com o Made4Flow, assumindo que o Roteador já está configurado para o encaminhamento unicast BGP normal (Sessão BGP normal para anúncio de Rotas de Blackhole ou Mitigação/Scrubbing Center). Para realizar a configuração de uma sessão BGP FlowSpec em equipamentos Juniper, utilizamos os seguintes comandos: Boas Práticas: Existem melhores práticas para proteger esta solução. Tanto as rotas BGP FlowSpec como os filtros de firewall resultantes que criam são recursos finitos no router. Sendo assim, o Roteador de BGP BORDA pode efetuar a filtragem de rotas de entrada para garantir que não receba rotas demais fora do esperado ou rotas erradas. Prefix Limit: Assim, a primeira coisa a fazer é definir um limite de prefixo para as rotas BGP FlowSpec. Poderia simplesmente definir um único limite de prefixo para as rotas inet unicast e inet flow, no entanto, este exemplo vai definir um limite separado para as rotas inet flow. Para que o Made4Flow apenas possa enviar dez rotas de BGP Flowspec de cada vez, vamos definir o limite de prefixos para 10 (esta configuração deve ser ajustada de acordo com cada cenário): Route Policy : A próxima coisa a fazer é aplicar uma política de rota de entrada. Essa política limitará o roteador a receber prefixos que são do próprio ISP com prefixos /24 até /32, que são os anunciados pelo Made4Flow. Vamos também adicionar uma Community 64496:86 para que possa identificar as rotas como sendo rotas BGP FlowSpec. Para todas as outras rotas, pode simplesmente filtrá-las com base na atribuição de rotas do cliente: 1. Crie a definição da
