SRv6 – Um sucessor do MPLS? – Parte 2
Em nosso último artigo do SRv6 feito por nossos especialistas, comentamos a respeito dos benefícios do SRv6 quando comparados com o MPLS, se você ainda não viu, clique no link a seguir: https://made4it.com.br/srv6-um-sucessor-do-mpls/ Neste artigo, vamos abordar sobre o funcionamento do SRv6, comparar os protocolos de Control Plane, falar sobre Data Plane e também ver as principais diferenças do SRv6 e MPLS. MPLS é uma tecnologia que ainda é muito utilizada nos dias de hoje, porém suas características de funcionamento se mostram muito diferentes do SRv6, que foi concebido não só como evolução ao MPLS mas também simplificando, e muito, o funcionamento de redes de transporte e relacionadas, adequando-as para as necessidades do futuro enquanto diminuindo a complexidade das redes. Comparação entre o SRv6 e o MPLS. Antes de falar sobre o funcionamento do SRv6, vamos analisar as principais diferenças entre ele e o consolidado MPLS. Podemos ver na tabela abaixo o antes (before) e o depois (now), mostrando a evolução e simplificação do MPLS para o SRv6: Fonte: IP Network eBook Series: SRv6, Huawei, Lanjun Luo Vemos no MPLS (before) um “stack” de protocolos e tecnologias. Tudo isso é simplificado no SRv6, onde conseguimos entregar as mesmas funcionalidades do MPLS mas sem dependência de protocolos de sinalização de “labels” (ldp/rsvp-te). Também existe a simplificação dos tipos de serviços que no SRv6 utilizam EVPN e sua ótima escalabilidade para prover acesso e transporte de serviços na rede. Aliado a tudo isso, o SRv6 atende também as necessidades de programabilidade e escalabilidade atuais que antes não eram possíveis no MPLS. O SRv6 não se restringe a redes “metro” ou transportes em ambientes “do futuro” (5G/IOT), veja no exemplo abaixo, em “before” precisamos do IP/VXLAN para transporte de informações dentro do DC1 e DC2 enquanto na rede Backbone utilizamos o MPLS com LDP, TE ou SR(MPLS). Depois temos o “After” da implementação do SRv6 com EVPN, mostrando a simplificação do cenário. Com SRv6 e EVPN, conseguimos entregar o que antes era possível apenas com um “stack” de diversos protocolos, onerando processamento e aumentando a complexidade do ambiente. Fonte: IP Network eBook Series: SRv6, Huawei, Lanjun Luo Além desses benefícios, como o SRv6 utiliza componentes nativos do IPv6 isso ajuda e muito em cenários de migração. Hoje praticamente todos os equipamentos suportam encaminhar cabeçalhos IPv6, logo a migração de um ambiente legado (MPLS) para essa nova tecnologia consegue ser orgânica, gradual, protegendo o investimento e assegurando downtimes mínimos no ambiente. Fonte: Implantação de Segment Routing IPv6 (SRv6) na VIVO – Nelson J. dos Santos Junior – Fórum Brasileiro de IPv6 2023. O SRv6 e sua simplificação é um grande aliado para integrações de grandes domínios de roteamento (como por exemplo, em casos de empresas adquiridas por outras onde tais redes precisam se comunicar e interoperar). Com o SRv6 conseguimos integrar tais redes com sumarizações simples de roteamento enquanto no MPLS exigia um planejamento extenso e uso de técnicas como InterAS OPTION A, B, C. Funcionamento do SRv6: Sabemos que no MPLS utilizamos LABELS entre camadas 2 e 3 que determinam como o pacote deve ser encaminhado em uma rede, porém é necessário que todos os equipamentos que façam parte do caminho tenham os protocolos necessários habilitados (IGP/LDP/RSVP). Podemos ver na imagem abaixo os MPLS Labels de um pacote capturado: Fonte: SINGH, Arshdepp. Fun with Revisiting MPLS basics. Linkedin, 23 de maio de 2020. Disponível em https://www.linkedin.com/pulse/fun-revisiting-mpls-basics-capturing-labels-wireshark-arshdeep-singhAcesso em: 22 de abril de 2024. Já o SRv6 utiliza uma extensão do cabeçalho IPv6 chamada de Segment Routing Header (SRH) para inserir endereços IPv6 chamados de SID (segment identifiers) para identificação do segmento de roteamento IPv6: Fonte: DayOne Intro SRv6, Juniper, HEGDE, Shaddha. et al. O SID representa um segmento específico em um segmento de domínio de roteamento, ele utiliza um endereço IPv6 de 128-bit, também conhecido como SRv6 Segment ou SRv6 SID. Em comparação com o MPLS, podemos dizer que o SID é a “label” que delimita o caminho de transporte ou o serviço, porém aqui no SRv6 transformamos isso em um endereço IPv6 único que pode ser encaminhado nativamente via IPv6 (bem mais simples, não ? 😉) Veja só a estrutura de um SID: Fonte: IP Network eBook Series: SRv6, Huawei, Lanjun Luo Locator: É a primeira parte do SID, utilizando mais bits. Tem a função de localização, representando o endereço de um node SRv6 específico. Depois de configurado em um equipamento, ele é propagado por todo o domínio SRv6 utilizando um IGP, permitindo que outros equipamentos localizem esse node em específico. Function: É uma parte do SID que designa uma função SRv6 que é executada localmente em um node específico. Comumente chamamos isto de “programa”. É uma instrução para orientar os pacotes dentro da rede. Neste SID, podemos sinalizar por exemplo uma EVPN-VPWS, ou um L3VPN específico deste node. Dado o fato de o SID estar dentro do bloco “locator” sendo este propagado pelo IGP (ISIS/OSPF) dentro do domínio SRv6, toda e qualquer comunicação orientada a este SID termina especificamente neste “node”. Uma comparação com o MPLS que podemos fazer aqui é em uma “label” usada para delimitar um serviço como L2VPN via targeted-ldp. No SRv6, basta implementarmos no head-end e tail-end instruções SID para o serviço e está feito. Os “nodes” que precisam interpretar os SIDs vão encapsular/desencapsular dados no mesmo, enquanto o restante da rede simplesmente encaminha os pacotes IPv6 com base no IGP. Argument (opcional): Usado para definir informações relevantes, como “packet flow” e “service information”, além de ser utilizado para implementar Split Horizon em cenários EVPN VPLS CE Multi-homing. Também vem sendo usado em implementações de sumarizações e simplificação de SID (G-SRv6 e uSID) mas, não vem ao caso falar sobre isso neste artigo, mas provavelmente será abordado em um próximo. Como citamos anteriormente, no core da rede SRv6 ocorre o encaminhamento de dados baseado no roteamento IPv6. Para os nós que entendem SRv6 e possuem SIDs alocados, ocorre o processamento dos cabeçalhos e instruções ali presentes. Já para os nós que não conhecem o SRv6 (equipamentos
Configuração L3 em Equipamentos Ufispace
Protocolos de Roteamento Estático e Dinâmico, OSPF e BGP Vamos apresentar a configuração de camada 3 (L3) em equipamentos Ufispace, tanto estático quanto dinâmico, utilizando protocolos como OSPF (Open Shortest Path First) e BGP (Border Gateway Protocol). A seguir, apresento um guia para configurar essas funcionalidades. Para iniciar a configuração, é necessário acessar o equipamento Ufispace via interface de linha de comando (CLI). Vamos demonstrar o acesso via ssh, mas pode também ser feito via conexão serial e telnet. Configuração diretamente na interface: Exemplo de configuração de Sub-Interface vlan. Usando como exemplo a vlan 4. Para configurar roteamento estático, adicione rotas estáticas na configuração: OSPF é um protocolo de roteamento dinâmico amplamente utilizado em redes empresariais. Para configurar OSPF no equipamento Ufispace: V4 V6 Adicionar as interfaces participantes do OSPF com os comandos: Para verificar se as configurações estão corretas e funcionando: Por fim, salve a configuração para garantir que as alterações sejam mantidas após uma reinicialização: Conclusão Configurar roteamento estático e dinâmico em equipamentos Ufispace envolve passos específicos para definir endereços IP nas interfaces, adicionar rotas estáticas e configurar protocolos de roteamento como OSPF e BGP. Seguindo este guia, é possível configurar um roteamento eficiente e robusto em sua rede. Ao final deste guia, você estará preparado para configurar roteamento estático e dinâmico em equipamentos Ufispace, utilizando protocolos como OSPF e BGP para garantir uma rede eficiente e robusta. Siga os passos com atenção e, em caso de dúvidas, consulte a documentação oficial ou busque ajuda especializada. 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. Além disso, somos parceiros oficiais da Padtec, que comercializa os roteadores UfiSpace. Fale conosco para saber mais e otimizar sua rede com soluções profissionais. Até mais! https://made4it.com.br/
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: OcNOS>enable 2 – Entrar no modo de configuração: OcNOS#configure terminal 3 – Alterar a senha do usuário, e criar um novo usuário, conforme o exemplo: OcNOS(config)#username ocnos password S3nh4-Super-F0rt3 OcNOS(config)#username made4it password S3nh4-Super-F0rtissima OcNOS(config)#username made4it role network-admin 4 – Alterar o nome do equipamento: hostname UFISPACE-01 5 – Aplicar a configuração: OcNOS(config)#commit 6 – Por fim, salvar a configuração: OcNOS(config)#do write Building configuration… [OK] 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: OcNOS(config)#interface eth0 2 – Atribui a VRF management à interface: OcNOS(config-if)#ip vrf forwarding management 3 – Configura o IP de gerência e descrição da interface: OcNOS(config-if)#ip address 10.10.0.2/30 OcNOS(config-if)#description GERENCIA 4 – Aplica configuração e salva: OcNOS(config)#commit OcNOS(config-if)#do write Building configuration… [OK] 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: OcNOS(config)#ip route vrf management 0.0.0.0/0 10.10.0.1 eth0 description ROTA DEFAULT OcNOS(config)#commit Para validar a rota default na VRF, podemos utilizar o comando: OcNOS#show ip route vrf management Por padrão, o ssh já vem habilitado na vrf management, caso queira desativar, utilize o comando: OcNOS(config)#no feature ssh vrf management Para ativar SSH na vrf main, utilize o comando: OcNOS(config)#feature ssh OcNOS(config)#commit 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: OcNOS(config)#ip access-list admin OcNOS(config-ip-acl)#10 permit tcp 10.10.0.0/30 any eq ssh OcNOS(config-ip-acl)#20 permit tcp 172.16.0.0/24 any eq ssh OcNOS(config-ip-acl)#65000 deny any any any OcNOS(config-ip-acl)#commit Agora precisamos aplicar a ACL no line vty: OcNOS(config)#line vty OcNOS(config-all-line)#ip access-group admin in OcNOS(config-all-line)#commit OcNOS(config-all-line)#do write Building configuration… [OK] 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: UFISPACE-01(config)#snmp-server enable snmp vrf management UFISPACE-01(config)#snmp-server community made4it vrf management UFISPACE-01(config)#commit Caso seja utilizada a vrf main para fazer o monitoramento, simplesmente utilizamos os comandos: UFISPACE-01(config)#snmp-server enable snmp UFISPACE-01(config)#snmp-server community made4it-vrf-main UFISPACE-01(config)#commit É 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: UFISPACE-01(config)#feature ntp vrf management UFISPACE-01(config)#ntp enable vrf management UFISPACE-01(config)#ntp server 200.160.7.186 vrf management UFISPACE-01(config)#commit Para verificar os peers NTP, utilizamos o comando: #show ntp peers ———————————————————– Peer IP Address Serv/Peer ———————————————————– 200.160.7.186 Server (configured) #show ntp peer-status Total peers : 1 * – selected for sync, + – peer mode(active), – – peer mode(passive), = – polled in client mode remote refid st t when poll reach delay offset jitter ============================================================================== * 200.160.7.186 LOCAL(0) 7 u 14 32 37 0.194 -4.870 3.314 Agora devemos corrigir o timezone para que a hora fique correta: UFISPACE-01(config)#clock timezone Sao_Paulo UFISPACE-01(config)#commit 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.
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?
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.
