Andina Link 2024
¡Descubre la Andina Link 2024: El Epicentro de la Innovación en Telecomunicaciones en América Latina! Únete a nosotros del 18 al 21 de marzo de 2024, en la impresionante Cartagena, Colombia, para la Exposición y Conferencia Andina Link 2024, un evento con más de 30 años de historia y reconocido como el más influyente en la región para la industria de las telecomunicaciones. ¿Por qué participar? Localización El evento se llevará a cabo en Cartagena, una ciudad histórica y encantadora en la costa caribeña de Colombia. Con sus playas de aguas cristalinas, arquitectura colonial y cultura vibrante, Cartagena proporciona un ambiente inspirador para conexiones significativas y negocios prósperos. Visita el Stand P51 de Made4it en la Andina Link ¡No te pierdas la oportunidad de conocer al equipo de Made4it en la Andina Link 2024! Descubre cómo podemos impulsar tu infraestructura y tecnología hacia nuevos niveles de excelencia. ¡Reserva tu lugar ahora y sé parte de esta experiencia única! Consulta el mapa completo del evento en el sitio web oficial. Hoteles Sugeridos HOTEL LAS AMÉRICAS Y CENTRO DE CONVENCIONES HOTELES CERCANOS AL HOTEL LAS AMÉRICAS HOTEL LAS AMÉRICAS Y CENTRO DE CONVENCIONES(CASA DE PLAYA Y TORRE DEL MAR) ¿Podemos hablar?
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 o 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 sua 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, e 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
VMware vs Proxmox – ¿Cuál elegir?
Introducción Hoy en día, cuando hablamos de servidores, los asociamos automáticamente a la virtualización. Atrás quedaron los días en que utilizábamos servidores bare-metal para ejecutar una sola aplicación. Con la facilidad de la virtualización y el mejor aprovechamiento de los recursos del servidor, se ha hecho casi obligatorio utilizar su servidor con algún software de virtualización. En la actualidad, dos grandes nombres lideran la virtualización: VMware y Proxmox. Más aún tras la noticia de la venta de VMware a Broadcom, este tema se ha vuelto aún más candente. Y la pregunta que se hace la mayoría es: ¿VMware o Proxmox? ¿Qué virtualizador elegir? ¿Cuál es el “mejor”? A lo largo de este post, haremos algunas comparaciones entre los dos virtualizadores para que puedas decidir cuál se adapta mejor a tus necesidades y, por supuesto, ¡conocer las principales características de cada uno! Resumen del servicio Proxmox es un virtualizador de código abierto actualizado y mantenido por Proxmox. Está basado en Debian y utiliza KVM/QEMU como virtualizador y LXC para contenedores. Destaca por ser gratuita y tener una gran variedad de funcionalidades, por lo que el límite de lo que puedes crecer y evolucionar está directamente ligado a tu conocimiento de la herramienta. Proxmox también destaca en lo que respecta a la compatibilidad con hardware antiguo, ya que está directamente vinculado al núcleo Linux utilizado. VMware es un virtualizador de código propietario y recientemente ha sido actualizado y mantenido por Broadcom. Actualmente, ya no es gratuito, sino que sólo se requiere una licencia para utilizarlo. Utiliza tecnologías propias de virtualización de servidores como virtualizador, y su alto rendimiento y estabilidad son innegables. Destaca por su interfaz sencilla y sus funcionalidades que aportan mucho a los grandes escenarios. La parte de compatibilidad de VMware depende de la versión en la que se encuentre, y cuanto más nueva sea la versión, menor será la compatibilidad con hardware considerado antiguo. Facilidad de uso Proxmox, a primera vista, puede parecer confuso y difícil, sobre todo porque algunas configuraciones requieren la integración con la CLI. Sin embargo, una vez que te acostumbras a su interfaz y a las funciones que necesitas, todo resulta más fácil. También cuenta con una excelente documentación que cubre todas las funciones disponibles. También tiene soporte de pago, que los usuarios pueden elegir comprar o no, y cuenta con una buena comunidad activa. VMware tiene una interfaz más objetiva y fácil de usar. Con unos pocos clics, puedes poner en marcha una máquina virtual. En cambio, si desea acceder a otras funciones, deberá adquirir una nueva licencia y/o configurar otro software (por ejemplo, VEEAM, vCenter). Dispone de una excelente documentación y varias KB (Knowledge Base) que explican diversos problemas que pueden surgir. Rendimiento Ambos servicios funcionan bien. VMware destaca por ejecutar su sistema operativo en memoria RAM, lo que permite navegar mejor por su interfaz. Aparte de eso, ambos están muy cerca en términos de rendimiento en escenarios mixtos, utilizando máquinas virtuales Linux y Windows y diferentes tipos de almacenamiento y almacenamiento. Escalabilidad Ambos virtualizadores te permiten aumentar los recursos (CPU/MEM/DISK) de tus VMs sin problemas, y si es necesario, incluso aumentar los recursos internos como añadir más espacio a algunos de los datastores o discos de tus VMs. Ahora, si adquiere otro servidor y desea aumentar su infraestructura de servidores, Proxmox maneja mejor la adición de un nuevo servidor a su sistema. Mientras que en VMware este servidor estaría aislado y habría que configurar un nuevo servicio (vCenter) para unir los servidores bajo su gestión, en Proxmox basta con crear un Cluster y dar de alta el nuevo servidor en el cluster (literalmente sólo estas dos configuraciones). Características y funcionalidades Ambos servicios tienen características y funcionalidades similares. En el caso de VMware, el acceso a ellos dependerá de la licencia que tengas, mientras que en Proxmox dependerá de si la versión en la que te encuentras tiene soporte para ello o no. Ejemplos de algunas de las funcionalidades que tienen en ambos: Costes Hicimos una simulación para un servidor con 1 CPU (Socket) y estos fueron los costes No necesitas una licencia para utilizar Proxmox, sólo el apoyo directo del fabricante si lo deseas. Estudios de casos y ejemplos prácticos Supongamos algunos escenarios y comprendamos dónde es interesante implantar VMware o Proxmox. PD: ¡Voy a llamar la atención sobre los escenarios in situ de los proveedores de Internet! Escenario 1: Tengo un servidor usado de antes de 2015 y me gustaría añadirlo a producción para virtualizar 5 VMs no críticas. Escenario VMware: Escenario Proxmox En otras palabras, en ambos escenarios podrás poner en práctica tu escenario. Por supuesto, en el caso de VMware, además del precio de la licencia, tienes que prestar atención al modelo de tu servidor y, sobre todo, a su año. Los servidores muy antiguos no son compatibles con las últimas versiones de VMware, y tendrás que hacer más inversiones para soportar el escenario de copia de seguridad si tienes más de 10 máquinas virtuales en tu escenario. Escenario de actualización 1: Vi que la virtualización funcionaba muy bien, y ahora quiero añadir más VMs, pero ahora habrá VMs críticas, y para ejecutar estas VMs actualicé y compré un nuevo servidor. Escenario VMware: Escenario Proxmox Conclusión En cualquier caso, hemos visto que Proxmox y VMware son muy similares y pueden ofrecer el mismo resultado, ¡siempre que se cumplan algunos requisitos! Todo depende del tamaño de su infraestructura y de su criticidad. Lo primero que tenemos que tener en cuenta es la inversión que voy a hacer en licencias. Si decido utilizar VMware, ¿qué pasaría si esa inversión no pudiera ser más útil en algún otro ámbito (por ejemplo, actualizar alguna parte de mi servidor interno)? Mi recomendación es la siguiente: si tu infraestructura está al 100%, con servidores nuevos que no necesitan actualización, y puedes permitirte las licencias, apuesta por VMware, porque te dará lo mejor en el mundo de la virtualización. Sin embargo, si tienes una infraestructura pequeña/mediana, Proxmox te servirá MUY bien, pues ya tenemos acceso
VMware vs. Proxmox – Which one to choose?
Introduction When we talk about servers today, we automatically associate them with virtualization. Gone are the days when we used bare-metal servers to run just one application. With the ease of virtualization and better use of server resources, it has become almost mandatory to use your server with some virtualization software. Currently, two big names are leading the way when it comes to virtualization: VMware and Proxmox. Even more so after the news of VMware‘s sale to Broadcom, this subject has become even more hotly debated. And the question on most people’s minds is: VMware or Proxmox? Which virtualizer to choose? Which is the “best”? Throughout this post, we’ll make some comparisons between the two virtualizers so that you can decide which one best suits your needs and, of course, get to know the main features of each one! Overview of services Proxmox is an open-source virtualizer updated and maintained by Proxmox. It is based on Debian and uses KVM/QEMU as a virtualizer and LXC for containers. It stands out because it’s free and has a wide range of features, so the limit to how much you can grow and evolve is directly linked to your knowledge of the tool. Proxmox also stands out when it comes to compatibility with older hardware, as it is directly linked to the Linux kernel being used. VMware is a proprietary code virtualizer and has recently been updated and maintained by Broadcom. Currently, it is no longer free, but only requires a license to use it. It uses proprietary server virtualization technologies as a virtualizer, and its high performance and stability are undeniable. It stands out for its simple interface and features that add a lot to large scenarios. The compatibility part of VMware depends on the version it is in, and the newer the version, the less compatibility with hardware considered to be old. Ease of use Proxmox, at first glance, may seem confusing and difficult, especially since some configurations require integration with the CLI. However, once you get used to its interface and the functions you need, everything becomes easier. It also has excellent documentation that covers all the available functions. It also has paid support, which users can choose whether or not to purchase, and has a good active community. VMware has a user-friendly and more objective interface. With just a few clicks, you can get a VM up and running. On the other hand, if you want access to other features, you will need to purchase a new license and/or configure other software (e.g. VEEAM, vCenter). It has excellent documentation and several KBs (knowledge base) explaining various problems that can occur. Performance Both services perform well. VMware stands out for running its OS in RAM memory, thus allowing you to better navigate its interface. Other than that, both are very close in terms of performance in mixed scenarios, using Linux and Windows VMs and different types of storage. Scalability Both virtualizers allow you to increase the resources (CPU/MEM/DISK) of your VMs without any problems, and if necessary, even increase internal resources such as adding more space to some of your VMs’ datastores or disks. Now, if you acquire another server and want to increase your server infrastructure, Proxmox handles the addition of a new server to your system better. While in VMware this server would be isolated and a new service (vCenter) would have to be configured to unite the servers under its management, in Proxmox all you have to do is create a Cluster and register the new server in the cluster (literally just these two configurations). Features and functionality Both services have similar features and functionalities. In the case of VMware, access to them will depend on the license you have, while in Proxmox it will depend on whether or not the version you are on has support for it. Examples of some of the features they have in both: Costs We did a simulation for a server with 1 CPU (Socket) and these were the costs For Proxmox you don’t need a license to use it, only direct support from the manufacturer if you want to. Case studies and practical examples Let’s assume a few scenarios and understand where it is interesting to implement VMware or Proxmox. PS: I’m going to draw attention to the on-premises scenarios of Internet providers! Scenario 1: I have a used server from before 2015 and would like to add it to production to virtualize 5 non-critical VMs. VMware scenario: Proxmox scenario: In other words, in both scenarios you will be able to implement your scenario. Of course, in the case of VMware, in addition to the price of the license, you have to pay attention to the model of your server and especially its year. Very old servers are not supported by the latest versions of VMware, and you will have to make more investments to support the backup scenario if you have more than 10 VMs in your scenario. Upgrade Scenario 1: I saw that the virtualization worked very well, and now I want to add more VMs, but now there will be critical VMs, and to run these VMs I upgraded and bought a new server. VMware scenario: Proxmox scenario: Conclusion Anyway, we’ve seen that Proxmox and VMware are very similar and can deliver the same result, as long as you meet a few requirements! It all depends on the size of your infrastructure and its criticality. The first thing we have to take into account is the investment I’m going to make in licenses. If I choose to use VMware, what if that investment couldn’t be more useful in some other area (for example, upgrading some part of my internal server)? My recommendation is this: if your infrastructure is 100%, with new servers that don’t need to be upgraded, and you can afford the licenses, go with VMware, because it will give you the best in the virtualization world. However, if you have a small/medium-sized infrastructure, Proxmox
Atualizações – Made4Flow, Made4Graph e Made4OLT – Fevereiro 2024
Made4Flow – Versão 2.6.2 Alterações: Correções: Made4Graph – Versão 2.4.3 Adições: Correções: Made4OLT – Versão 1.3.0 [Beta] Adições: 1 – Adicionada possibilidade de reiniciar ONU configurada. 2 – Adicionado quantidade máxima de OLTs por licença. 3 – Adicionada opção de Save manual e Autosave de OLTs. 4 – Adicionada implememntação de comandos Telnet 5 – Adicionado terminal via Telnet na OLT Alterações: 1 – Templates podem receber Board, slot e port como parâmetros. 2 – DBA profile selecionável de 1 a 5. 3 – Corrigido bug, Vlans só podem ser criadas dentro do range de 1 a 4094. Correções: 1 – Corrigido bug ao enviar nova licença.2 – Corrigido bug, agora campo de Vlans só aceita number.
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 apartir 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 atraves 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 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 policy: 2.
How to configure FlowSpec on Juniper Routers
Overview: BGP FlowSpec (Border Gateway Protocol Flow Specification) is an extension of the BGP protocol used to define traffic filtering rules on routers or, more simply, to generate firewall rules on routers from a BGP announcement. Unlike conventional BGP, which routes based on IPv4/IPv6 and prefix information, BGP FlowSpec allows network administrators to specify more granular criteria for packet forwarding, including layer 4 information (TCP/UDP ports) and even packet patterns. To find out more about BGP Flowspec, visit our article on what BGP Flowspec is here. Operation: BGP FlowSpec works by adding new types of attributes to BGP, allowing network administrators to specify detailed filtering rules. These rules can include criteria such as: The following actions can be taken with BGP FlowSpec: When these rules are propagated through the BGP network, routers can use this information to filter or manipulate traffic according to the defined policies. Operation – More Details: In the context of BGP FlowSpec, the actions are specified as part of the filter rules. Each filter rule contains three main parts: Actions in BGP FlowSpec are coded using BGP communities. Each action is mapped to a specific BGP community: When you create a BGP FlowSpec rule, you specify the matching fields, the desired action and, optionally, protocol fields. This rule is then encoded as a BGP community and included in a BGP update message that is sent to neighboring routers. The routers that receive this rule apply the specified actions to the packets that match the matching criteria. Please note that the specific BGP communities for each action may vary depending on the BGP FlowSpec implementation on your network equipment. I recommend consulting your equipment’s documentation for detailed information on the BGP communities associated with each action in BGP FlowSpec. Use Cases: 1. **DDoS attack mitigation: BGP FlowSpec can be used to block or redirect malicious traffic during distributed denial of service (DDoS) attacks. Precise rules can be applied to filter out unwanted traffic and keep services online. 2. **QoS (Quality of Service) policies: Network administrators can use BGP FlowSpec to guarantee quality of service by prioritizing certain types of traffic based on specific ports or protocols. 3. **Implementing Security Policies**: BGP FlowSpec can be used to implement granular security policies, blocking traffic associated with malware or suspicious activity. Configuration examples: The BGP FlowSpec configuration may vary depending on the network equipment used. This example explores how to design a DDoS mitigation solution in which a service provider allows its customers to advertise BGP FlowSpec routes to it. It also discusses some of the best practices that should be considered before implementing this type of solution and, finally, some of the Junos commands available to help you check that your Flow-spec solution is working correctly. Topology scenario for the example: Let’s start by taking a look at how our solution will be configured: As we can see from the topology above, there is the BORDA, which is a Juniper device that acts as the network’s BGP router. Made4Flow which is the software that will analyze the flows and generate rules of BGP FlowSpec dynamically and announce it via BGP to the BGP router called BORDA. In this scenario, the example attack is a DNS amplification attack. This means that the network is receiving a large volume of UDP port 53 packets that it doesn’t actually need for the ISP to function normally. The attack fills the circuit between the ISP and the operators and effectively renders the network inoperable. When the attacker decides to launch the attack, the ISP can use the Made4Flow to generate a BGP FlowSpec route for UDP port 53 packets only and announce it to the BORDA BGP Router, which can turn this route into a firewall filter on its communication interfaces with the Operators. And then this blocks the DNS amplification packets at the edge of the ISP’s network and also at the carrier (if the carrier supports FlowSpec sessions), but allows legitimate traffic to continue arriving. First, let’s look at the BGP FlowSpec session settings on the BORDA BGP router with Made4Flow, assuming that the router is already configured for normal BGP unicast routing (Normal BGP session for announcing Blackhole or Mitigation/Scrubbing Center routes). To configure a BGP FlowSpec session on Juniper devices, we use the following commands: Good practices: There are best practices for protecting this solution. Both the BGP FlowSpec routes and the resulting firewall filters they create are finite resources in the router. Therefore, the BGP BORDA router can filter incoming routes to ensure that it receives too many unexpected routes or wrong routes. Prefix Limit: So the first thing to do is to set a prefix limit for BGP FlowSpec routes. You could simply define a single prefix limit for the routes inet unicast e inet flowroutes, however, this example will define a separate limit for the inet flow. So that Made4Flow can only send ten BGP Flowspec routes at a time, let’s set the prefix limit to 10 (this setting should be adjusted according to each scenario): Route Policy : The next thing to do is to apply an inbound route policy. This policy will limit the router to receiving prefixes that are from the ISP itself with prefixes /24 to /32, which are those announced by Made4Flow. Let’s also add a Community 64496:86 so that it can identify the routes as BGP FlowSpec routes. For all other routes, you can simply filter them based on the client’s route assignment: 1. Create the policy definition: 2. Apply the policy as an import policy in the BGP session with Made4Flow: Maximum prefixes: The last thing to do is to set a maximum number of BGP FlowSpec prefixes that can be installed in the routing table. This example sets a maximum of 10,000 routes, but let’s also configure the router to notify the administrator via a syslog message when a 90% limit is reached. This setting must be applied to all routers in the example ISP’s network: It
Cómo configurar FlowSpec en los routers Juniper
Visión general: BGP FlowSpec (Border Gateway Protocol Flow Specification) es una extensión del protocolo BGP que se utiliza para definir reglas de filtrado de tráfico en los routers o, más sencillamente, para generar reglas de cortafuegos en los routers a partir de un anuncio BGP. A diferencia del BGP convencional, que enruta basándose en IPv4/IPv6 e información de prefijos, BGP FlowSpec permite a los administradores de red especificar criterios más granulares para el reenvío de paquetes, incluida información de capa 4 (puertos TCP/UDP) e incluso patrones de paquetes. Para obtener más información sobre BGP Flowspec, visite nuestro artículo sobre qué es BGP Flowspec a través de este enlace. Operación: BGP FlowSpec funciona añadiendo nuevos tipos de atributos a BGP, lo que permite a los administradores de red especificar reglas de filtrado detalladas. Estas normas pueden incluir criterios como: Se pueden realizar las siguientes acciones con BGP FlowSpec: Cuando estas reglas se propagan a través de la red BGP, los routers pueden utilizar esta información para filtrar o manipular el tráfico de acuerdo con las políticas definidas. Funcionamiento – Más detalles: En el contexto de BGP FlowSpec, las acciones se especifican como parte de las reglas de filtrado. Cada regla de filtrado contiene tres partes principales: Las acciones en BGP FlowSpec se codifican utilizando comunidades BGP. Cada acción se asigna a una comunidad BGP específica: Cuando se crea una regla BGP FlowSpec, se especifican los campos coincidentes, la acción deseada y, opcionalmente, los campos de protocolo. A continuación, esta regla se codifica como una comunidad BGP y se incluye en un mensaje de actualización BGP que se envía a los routers vecinos. Los routers que reciben esta regla aplican las acciones especificadas a los paquetes que cumplen los criterios de coincidencia. Tenga en cuenta que las comunidades BGP específicas para cada acción pueden variar en función de la implementación de BGP FlowSpec en su equipo de red. Le recomiendo que consulte la documentación de su equipo para obtener información detallada sobre las comunidades BGP asociadas a cada acción en BGP FlowSpec. Casos prácticos: 1. **Mitigación de ataques DDoS: BGP FlowSpec puede utilizarse para bloquear o redirigir tráfico malicioso durante ataques de denegación de servicio distribuidos (DDoS). Se pueden aplicar reglas precisas para filtrar el tráfico no deseado y mantener los servicios en línea. 2. **Políticas de calidad de servicio (QoS): Los administradores de red pueden utilizar BGP FlowSpec para garantizar la calidad del servicio priorizando determinados tipos de tráfico en función de puertos o protocolos específicos. 3. **Aplicación de políticas de seguridad**: BGP FlowSpec puede utilizarse para aplicar políticas de seguridad granulares, bloqueando el tráfico asociado a malware o actividades sospechosas. Ejemplos de configuración: La configuración de BGP FlowSpec puede variar en función del equipo de red utilizado. Este ejemplo explora cómo diseñar una solución de mitigación DDoS en la que un proveedor de servicios permite a sus clientes anunciar rutas BGP FlowSpec para él. También analiza algunas de las mejores prácticas que deben tenerse en cuenta antes de implementar este tipo de solución y, por último, algunos de los comandos de Junos disponibles para ayudarle a comprobar que su solución Flow-spec funciona correctamente. Escenario topológico del ejemplo: Empecemos por ver cómo se configurará nuestra solución: Como podemos ver en la topología anterior, existe el BORDA, que es un dispositivo Juniper que actúa como enrutador BGP para la red, el Made4Flow que es el software que analizará los flujos y generará reglas para BGP FlowSpec dinámicamente y anunciarlo vía BGP al router BGP llamado BORDA. En este escenario, el ejemplo de ataque es un ataque de amplificación DNS. Esto significa que la red está recibiendo un gran volumen de paquetes UDP puerto 53 que en realidad no necesita para que el ISP funcione con normalidad. El ataque llena el circuito entre el ISP y los operadores y deja la red inoperativa. Cuando el atacante decide lanzar el ataque, el ISP puede utilizar el Made4Flow para generar una ruta BGP FlowSpec sólo para paquetes UDP puerto 53 y anunciarla al Router BORDA BGP, que puede convertir esta ruta en un filtro firewall en sus interfaces de comunicación con los Operadores. Y entonces esto bloquea los paquetes de amplificación DNS en el borde de la red del ISP y también en el operador (si el operador soporta sesiones FlowSpec), pero permite que el tráfico legítimo siga llegando. En primer lugar, vamos a analizar la configuración de la sesión BGP FlowSpec en el router BGP BORDA con Made4Flow, suponiendo que el router ya está configurado para el enrutamiento unicast BGP normal (sesión BGP normal para anunciar rutas Blackhole o Mitigation/Scrubbing Center). Para configurar una sesión BGP FlowSpec en dispositivos Juniper, utilizamos los siguientes comandos: Buenas prácticas: Existen buenas prácticas para proteger esta solución. Tanto las rutas BGP FlowSpec como los filtros de cortafuegos resultantes que crean son recursos finitos en el router. Por lo tanto, el enrutador BGP BORDA puede filtrar las rutas entrantes para asegurarse de que recibe demasiadas rutas inesperadas o erróneas. Límite del prefijo: Así que lo primero que hay que hacer es establecer un límite de prefijos para las rutas BGP FlowSpec. Podría simplemente definir un límite de prefijo único para las rutas inet unicast e inet flujosin embargo, este ejemplo definirá un límite separado para las rutas flujo inet. Para que Made4Flow sólo pueda enviar diez rutas BGP Flowspec a la vez, fijemos el límite de prefijos en 10 (esta configuración debe ajustarse en función de cada escenario): Política de rutas : Lo siguiente que hay que hacer es aplicar una política de rutas entrantes. Esta política limitará el router a recibir prefijos que provengan del propio ISP con prefijos /24 a /32, que son los anunciados por Made4Flow. Añadamos también una Comunidad 64496:86 para que pueda identificar las rutas como rutas BGP FlowSpec. Para el resto de rutas, basta con filtrarlas en función de la asignación de rutas del cliente: 1. Cree la definición de la política: 2. Aplique la política como política de importación en la
Como migrar Vmware para Proxmox?
Recentemente, a nova proprietária da VMware fez uma declaração que ecoou em toda a comunidade: não haverá mais licenças gratuitas da VMware, e os custos das licenças novas aumentaram em 40%. Essa mudança drástica nas políticas de licenciamento levou muitos profissionais de TI e empresas a reavaliar suas estratégias de virtualização. Como resultado, soluções alternativas estão emergindo, com destaque para o Proxmox, o virtualizador Open Source mais amplamente utilizado em todo o mundo. O Proxmox oferece uma gama completa de recursos comparáveis aos oferecidos pela VMware, incluindo funcionalidades como cluster, replicação, alta disponibilidade (H.A.) e a garantia de alta disponibilidade, tudo isso sem os altos custos de licenciamento associados à plataforma VMware. Com a capacidade de realizar todas essas operações essenciais de virtualização sem comprometer a qualidade ou a confiabilidade. Se você já utiliza VMware e está considerando migrar para o Proxmox, elaboramos um artigo detalhado que demonstra o processo de migração de VMs diretamente da VMware para o Proxmox. Este guia prático oferece instruções passo a passo para garantir uma transição suave e eficiente, permitindo que você aproveite ao máximo os recursos e benefícios do Proxmox em seu ambiente de virtualização. Processo de migração do ProxMox Export O primeiro passo é realizar a instalação do ovftools através desse link após isso você pode enviar via SCP para o seu servidor ProxMox utilizando o comando: Logo após isso em seu servidor Proxmox, de a permissão de execução para o arquivo enviado e logo em seguida execute ele: Pronto, o OVFtools já está instalado! Com esse binário iremos avançar duas etapas, o export e a conversão, o OVFTOOLS irá se conectar remotamente em seu servidor VMware ESXI, e atravez da linha de comando você irá informar qual a VM que deseja exportar, logo em seguida o ovftools já irá baixar essa VM e logo em seguida converter para o padrão do Proxmox, para realizar essa etapa no servidor aonde está instalado o OVFTOOLS execute o comando: Após finalizar o Export, vamos importar essa VM utilizando o comando: E após o IMPORT finalizar a VM já vai estar configurada em seu ProxMox Com alguns poucos comandos já conseguimos migrar a nossa primeira VM do VMware para o Proxmox, basta repetir esse procedimento para as demais VM’s do seu ambiente. Porém, não é só isso. O ProxMox tem várias outras funções interessantes que você pode utilizar já no início da sua implementação, fique ligado nos próximos posts! Você irá aprender a: A migração do VMware para o Proxmox pode ser uma escolha estratégica para otimizar seus recursos e reduzir custos sem comprometer a qualidade. Se você está buscando uma alternativa sólida e econômica para suas necessidades de virtualização, estamos aqui para ajudar. Entre em contato conosco para explorar as possibilidades e iniciar o processo de migração para o Proxmox.
How do I migrate from Vmware to Proxmox?
Recently, VMware ‘s new owner made a statement that echoed throughout the community: there will be no more free VMware licenses, and the cost of new licenses has increased by 40%. This drastic change in licensing policies has led many IT professionals and companies to re-evaluate their virtualization strategies. As a result, alternative solutions are emerging, most notably Proxmox, the most widely used Open Source virtualizer in the world. Proxmox offers a full range of features comparable to those offered by VMware, including functionalities such as clustering, replication, high availability (H.A.) and the guarantee of high availability, all without the high licensing costs associated with the VMware platform. With the ability to perform all these essential virtualization operations without compromising quality or reliability. If you already use VMware and are considering migrating to Proxmox, we’ve put together a detailed article that demonstrates the process of migrating VMs directly from VMware to Proxmox. This practical guide offers step-by-step instructions to ensure a smooth and efficient transition, allowing you to take full advantage of the features and benefits of Proxmox in your virtualization environment. ProxMox migration process Export The first step is to install ovftools using this link, after which you can send it via SCP to your ProxMox server using the command: After that, on your Proxmox server, give the execution permission to the uploaded file and then run it: That’s it, OVFtools is installed! With this binary we will proceed to two steps, the export and the conversion, OVFTOOLS will connect remotely to your VMware ESXI server, and through the command line you will inform which VM you want to export, then ovftools will download this VM and then convert it to the Proxmox standard, to perform this step on the server where OVFTOOLS is installed run the command: After finishing Export, let’s import this VM using the command: And after IMPORT is finished, the VM will already be configured in your ProxMox With just a few commands, we have already managed to migrate our first VM from VMware to Proxmox. All you have to do is repeat this procedure for the other VMs in your environment. But that’s not all. ProxMox has several other interesting functions that you can use right from the start of your implementation, so stay tuned for future posts! You will learn to: Migrating from VMware to Proxmox can be a strategic choice to optimize your resources and reduce costs without compromising on quality. If you’re looking for a solid, cost-effective alternative to your virtualization needs, we’re here to help. Contact us to explore the possibilities and start the migration process to migration.