Entorno virtual Proxmox
Como otra opción, puede considerar construir un laboratorio en Proxmox VE. Internamente, el hipervisor en EVE-NG, Ubuntu nativo KVM con libvirtd y Proxmox VE es el mismo. En los tres entornos, QEMU ejecuta la máquina virtual. Cada entorno tiene su propia CLI y GUI y utiliza distribuciones Debian o Ubuntu Linux.
Los beneficios de Proxmox VE contra EVE-NG y Ubuntu KVM nativo con libvirtd son:
- Fácil de construir clústeres de hipervisores, lo que limita el alcance de un solo BMS.
- Almacenamiento compartido fácil de adjuntar como Ceph.
- Virtualice redes entre servidores mediante la opción SDN.
- La API de REST opera sus sistemas.
Las desventajas de los beneficios de Proxmox VE frente a EVE-NG y Ubuntu KVM nativo con libvirtd son:
- La compilación de un kernel UKSM no puede guardar el uso de RAM de varias instancias de vJunos-switch. Por lo tanto, cada máquina virtual del conmutador vJunos necesita 5 GB de RAM.
- No ejecuta imágenes qcow2 comprimidas o de respaldo, sino que se expanden como imagen sin procesar en la opción de almacenamiento. Por lo tanto, cada máquina virtual del conmutador vJunos necesita 32 GB de almacenamiento.
Este documento incluye ejemplos de creación de máquinas virtuales con conmutador vJunos en Proxmox VE con un único servidor Proxmox configurado localmente y los puentes Linux estándar. Esto ayuda a comparar con los otros dos entornos descritos anteriormente. Como no ha usado la GUI de Proxmox para VM, debe ejecutar los cambios de configuración localmente después de crear imágenes juniper.conf y Linux Bridge y la interfaz de VM posteriores a los cambios de creación de VM en Proxmox VE. El ejemplo de CLI facilita su inclusión en un script para iniciar varias máquinas virtuales con conmutadores vJunos.
Para laboratorios de escalabilidad horizontal con varios servidores, se recomienda usar SDN con VXLAN como opción de transporte de red en lugar de puentes locales de Linux.
Proxmox VE Preparaciones
Después de instalar el hipervisor, cree las redes que se usarán con las máquinas virtuales del conmutador vJunos y otros usuarios del laboratorio. Como en el ejemplo anterior, use la GUI de Proxmox para crear puentes Linux estándar como los tres que se muestran a continuación y asegúrese de que estén activados.
Asigne un nombre a cada puente de Linux y, opcionalmente, puede establecer la MTU en 9200. Puede cambiar el valor de MTU mediante el script después de crear la máquina virtual. Evite rellenar/cambiar cualquiera de los otros valores.
Para todos los pasos restantes, use SSH en el servidor para ejecutar comandos BASH localmente. Primero, descargue la imagen qcow2 de vJunos-switch al servidor.
mkdir -p /root/download
Ahora, descargue su copia gratuita de vJunos-switch VM al directorio usando URL: https://support.juniper.net/support/downloads/?p=vjunos y luego verifique si la copia se ha descargado.
ls -l /root/download/ -rw-r--r-- 1 root root 3966631936 Aug 1 2023 vJunos-switch-23.2R1.14.qcow2
Implementar una máquina virtual con conmutador vJunos en Proxmox VE
Evite crear la máquina virtual inicial del conmutador vJunos mediante la GUI de Proxmox, ya que la GUI podría agregar parámetros adicionales y provocar que la máquina virtual no funcione correctamente. En su lugar, cree la máquina virtual inicial mediante la CLI y establézcala como una plantilla. A continuación, use esta plantilla para iniciar todas las máquinas virtuales adicionales desde la GUI.
Con BASH, realice los pasos siguientes en el servidor localmente:
- Configure la máquina virtual individualmente:
- El ID o número de máquina virtual. En el ejemplo, es
200. - El almacenamiento desde donde se ejecuta la imagen de la máquina virtual. En el ejemplo, es almacenamiento
local-lvm.
- El ID o número de máquina virtual. En el ejemplo, es
- Eliminar si se está ejecutando una máquina virtual existente con el mismo identificador. Esto es útil si cometió un error y desea volver a intentarlo.
- Cree la nueva máquina virtual del conmutador vJunos con todos los parámetros necesarios para iniciarla correctamente más adelante:
- Nombre de la máquina virtual. En el ejemplo,
vswitch. Puede cambiar el nombre. - RAM y CPU. No cambiar.
- Opciones especiales de BIOS y CPU necesarias para que esta máquina virtual aparezca correctamente. No cambie las opciones.
- Orden de arranque y pantalla serie. No cambiar.
- En primer lugar, la red
net0que se asigna a la interfaz fxp0 de la máquina virtual. Cambie si es necesario, pero asegúrese de que la red pueda proporcionar una concesión DHCP para la máquina virtual. - En segundo lugar, más redes que comiencen con
net1, que será la interfazge-0/0/0de la máquina virtual del conmutador vJunos. Deberá cambiar eso de acuerdo con el diseño de su laboratorio utilizando más interfaces y otros puentes de Linux. Le recomendamos que mantenga la opciónfirewall=0para cada una de esas interfaces para no complicar demasiado el diseño interno.
- Nombre de la máquina virtual. En el ejemplo,
- Importe la imagen qcow2 del conmutador vJunos a la opción de almacenamiento seleccionada. Es posible que deba cambiar la ubicación del archivo de imagen qcow2 del conmutador vJunos.
- Importe la ubicación de la imagen de configuración que desea extraer a una variable BASH.
- Agregue la ubicación de la imagen a la máquina virtual creada desde la que arrancar.
- Cree un valor predeterminado
juniper.confcon nuestra configuración inicial de Junos OS para esta máquina virtual. - Utilice el
make-config.shscript para crear una imagen que incruste su archivo individualjuniper.conf. - Importe la imagen de configuración de Junos OS a la opción de almacenamiento seleccionada.
- Importe la ubicación de la imagen de configuración que desea extraer a una variable BASH.
- Agregue la ubicación de la imagen de configuración a la máquina virtual creada.
- Compruebe y revise la configuración completa de la máquina virtual.
- Opcional: Use la máquina virtual como plantilla para futuros lanzamientos de vJunos-switch:
- Defina la máquina virtual actual como plantilla.
- Seleccione un nuevo VMID para el clon.
- Cree una máquina virtual clonada para usarla más tarde.
- Cambie las asignaciones de interfaz para el clon si es necesario.
- Inicie la máquina virtual o su clon.
- Revise la asignación de puente de Linux localmente para la máquina virtual iniciada.
- Revise la GUI de Proxmox si la máquina virtual se ha iniciado y, a continuación, acceda a la consola.
# configure the management ID for the VM and your storage location VMID="200" VMSTORAGE="local-lvm" # make sure any prior instance of this VM is down and deleted qm stop $VMID qm destroy $VMID # create a new VM without a virtual disk qm create $VMID --name switch1 --memory 5120 --cores 4 \ --args "-machine accel=kvm:tcg -smbios type=1,product=VM-VEX -cpu 'host,kvm=on'" \ --boot order=virtio0 --serial0 socket \ --net0 virtio,bridge=vmbr0 \ --net1 virtio,bridge=ge000,firewall=0 \ --net2 virtio,bridge=ge001,firewall=0 \ --net3 virtio,bridge=ge002,firewall=0 # import the vJunos image as qcow2 format in proxmox qm disk import $VMID /root/download/vJunos-switch-23.2R1.14.qcow2 $VMSTORAGE --format qcow2 | tee diskimport.txt . . transferred 31.6 GiB of 31.8 GiB (99.52%) transferred 31.8 GiB of 31.8 GiB (100.00%) transferred 31.8 GiB of 31.8 GiB (100.00%) Successfully imported disk as 'unused0:local-lvm:vm-200-disk-0' # extract image location from import VMIMAGE=`cat diskimport.txt | grep "imported disk" | awk '{print $5}' | sed 's/.:/ /' | awk '{print $2}' | sed 's/.$//'` echo $VMIMAGE local-lvm:vm-200-disk-0 # attach the qcow2 disk to the vm qm set $VMID --virtio0 $VMIMAGE,iothread=1,size=32G update VM 200: -virtio0 local-lvm:vm-200-disk-0,iothread=1,size=32G
Revise el capítulo Configuración predeterminada de Junos OS para vJunos-switch. Este capítulo le guía con el proceso de creación de una configuración individual de Junos OS para su máquina virtual con conmutador vJunos, que es similar en los demás entornos. En este capítulo también se le guía para agregar una configuración de adopción, que permite que cada nueva máquina virtual del conmutador vJunos aparezca automáticamente en el inventario de Mist Cloud. Aquí, sin repetir los mismos pasos, utilizó una configuración de inicio mínima para el acceso SSH remoto como root con la contraseña ABC123 en la interfaz fxp0.
cat <<EOF >juniper.conf
system {
host-name vjunos;
root-authentication {
encrypted-password "\$6\$DOvFAxW9\$HpxgOaGEe5L6MtDJqbWepS5NT6EW23rCuu69gwwGVFr7BpzY2MHS34mPrR0LKRqoGI19tRgpz3vFJkEueW9mQ1"; ## SECRET-DATA
}
services {
ssh {
root-login allow;
protocol-version v2;
}
}
name-server {
8.8.8.8;
9.9.9.9;
}
arp {
aging-timer 5;
}
syslog {
file interactive-commands {
interactive-commands any;
}
file messages {
any notice;
authorization info;
}
}
}
interfaces {
fxp0 {
unit 0 {
family inet {
dhcp force-discover;
}
}
}
}
protocols {
lldp {
interface all;
}
lldp-med {
interface all;
}
}
EOF
En este punto, debe haber creado una configuración de inicio de Junos OS individual y continuar el proceso.
# download the make-config.sh script from the Juniper CDN if you do not have it yet
# https://webdownload.juniper.net/swdl/dl/anon/site/1/record/168885.html
chmod 777 make-config.sh
./make-config.sh juniper.conf myconfig.img
.
./config/juniper.conf
Cleaning up...
removed '/var/tmp/tmp.hhQ0rcM92K/config/juniper.conf'
removed directory '/var/tmp/tmp.hhQ0rcM92K/config'
removed directory '/var/tmp/tmp.hhQ0rcM92K'
removed directory '/var/tmp/tmp.gvCkmgmvXy'
Config disk myconfig.img created
# import the junos config image to proxmox storage
qm disk import $VMID myconfig.img $VMSTORAGE --format raw | tee diskimport.txt
.
transferred 1.0 MiB of 1.0 MiB (100.00%)
transferred 1.0 MiB of 1.0 MiB (100.00%)
Successfully imported disk as 'unused0:local-lvm:vm-200-disk-1'
# extract image location from import
VMIMAGE=`cat diskimport.txt | grep "imported disk" | awk '{print $5}' | sed 's/.:/ /' | awk '{print $2}' | sed 's/.$//'`
echo $VMIMAGE
local-lvm:vm-200-disk-1
# attach the config-image disk to the vm
qm set $VMID --ide0 $VMIMAGE,size=16M
update VM 200: -ide0 local-lvm:vm-200-disk-1,size=16M
Ahora, todos nuestros preparativos están completos. Puede revisar la configuración de la máquina virtual resultante.
# review the VM configuration made qm config $VMID args: -machine accel=kvm:tcg -smbios type=1,product=VM-VEX -cpu 'host,kvm=on' boot: order=virtio0 cores: 4 ide0: local-lvm:vm-200-disk-1,size=4M memory: 5120 meta: creation-qemu=8.1.5,ctime=1728988040 name: switch1 net0: virtio=BC:24:11:01:06:0E,bridge=vmbr0 net1: virtio=BC:24:11:6B:0B:84,bridge=ge000,firewall=0 net2: virtio=BC:24:11:7E:5C:07,bridge=ge001,firewall=0 net3: virtio=BC:24:11:FB:40:37,bridge=ge002,firewall=0 serial0: socket smbios1: uuid=5b184467-bffe-45f3-8a4c-bb2182aa3aa5 virtio0: local-lvm:vm-200-disk-0,iothread=1,size=32524M vmgenid: a3299ccf-293b-4df2-9458-b0fa444a9c61
Como la máquina virtual no contiene credenciales ni otros factores limitantes, úsela como plantilla antes de iniciarla por primera vez. Esto le permite iniciar varias máquinas virtuales como completas o vinculadas a los clones de imagen más adelante. Siga los pasos a continuación si decide continuar.
qm template $VMID
Renamed "vm-200-disk-1" to "base-200-disk-1" in volume group "pve"
Logical volume pve/base-200-disk-1 changed.
WARNING: Combining activation change with other commands is not advised.
Renamed "vm-200-disk-0" to "base-200-disk-0" in volume group "pve"
Logical volume pve/base-200-disk-0 changed.
WARNING: Combining activation change with other commands is not advised.
# select a new VMID for the clone
VMID2="201"
# create a clone of of your template VM
qm clone $VMID $VMID2 --name switch1
create linked clone of drive ide0 (local-lvm:base-200-disk-1)
Logical volume "vm-201-disk-0" created.
create linked clone of drive virtio0 (local-lvm:base-200-disk-0)
Logical volume "vm-201-disk-1" created.
#
# at this point you may change the interfaces assigned according to your topology
#
# review the VM configuration for the clone
qm config $VMID2
args: -machine accel=kvm:tcg -smbios type=1,product=VM-VEX -cpu 'host,kvm=on'
boot: order=virtio0
cores: 4
ide0: local-lvm:vm-201-disk-0,size=4M
memory: 5120
meta: creation-qemu=8.1.5,ctime=1729094281
name: switch1
net0: virtio=BC:24:11:87:61:1B,bridge=vmbr0
net1: virtio=BC:24:11:B2:11:52,bridge=ge000,firewall=0
net2: virtio=BC:24:11:79:0C:A1,bridge=ge001,firewall=0
net3: virtio=BC:24:11:DF:BC:BF,bridge=ge002,firewall=0
serial0: socket
smbios1: uuid=b81068a9-8f7e-423a-bbb8-7738da5f98df
virtio0: local-lvm:vm-201-disk-1,iothread=1,size=32524M
vmgenid: de47f143-5f48-44c4-8674-beb7d1b91bd2
# start the clone vJunos-switch VM
qm start $VMID2
brctl show
bridge name bridge id STP enabled interfaces
ge000 8000.de5f3a3d3a9b no tap201i1
ge001 8000.da08ff719f7c no tap201i2
ge002 8000.8614a67130b7 no tap201i3
vmbr0 8000.5847ca7543fe no enp2s0
tap201i0
Si aún no ha decidido usar una plantilla o clon, inicie la primera máquina virtual con conmutador vJunos para realizar pruebas ahora.
# start the new vJunos-switch VM
qm start $VMID
# review the linux-bridges and attached interfacs for our first VM
brctl show
bridge name bridge id STP enabled interfaces
ge000 8000.0ac0df72ec4b no tap200i1
ge001 8000.623437ae4bac no tap200i2
ge002 8000.72c0fc5f9933 no tap200i3
vmbr0 8000.5847ca7543fe no enp2s0
tap200i0
Ahora puede revisar la consola de VM en la GUI de Proxmox. Asegúrese de usar el botón correcto para evitar cambios en la pantalla exterior de la máquina virtual del motor de enrutamiento. El motor de enrutamiento es donde comienza toda la configuración de Junos OS y tiene su propia pantalla. Consulte la figura siguiente para ver las opciones de consola que desea seleccionar.
El puente de Linux y la interfaz de VM posteriores a los cambios en la creación de VM en Proxmox VE
El lanzamiento de la máquina virtual del conmutador vJunos no satisface las necesidades de la mayoría de los laboratorios. Debe modificar el puente Linux estándar utilizado en el ejemplo después de cada lanzamiento de nueva máquina virtual. Para obtener una explicación detallada, consulte el capítulo Puente de Linux y la interfaz de VM posteriores a los cambios en la creación de VM. Por lo tanto, no es necesario repetirlo aquí. EVE-NG gestiona automáticamente estos ajustes.
Proxmox VE no proporciona detalles de las interfaces de VM ni sus nombres a través de la CLI localmente. Sin embargo, estos detalles están disponibles en la API de REST para la GUI. Con el comando pveshproporcionado, puede acceder fácilmente a la interfaz de máquina virtual y extraer información basada en JSON sobre las interfaces de máquina virtual creadas. Por lo tanto, es más fácil reconstruir un nuevo script vm-bridge-update.sh usando pvesh comandos and jq y programación BASH regular. Consulte las instrucciones que se muestran a continuación.
apt-get install jq rm -f vm-bridge-update.sh touch vm-bridge-update.sh chmod 777 vm-bridge-update.sh vi vm-bridge-update.sh
Copie y pegue la siguiente configuración en su editor. A continuación, guarde y cierre.
#!/bin/bash
# use API to get first nodename
pvesh get /nodes --output-format json | jq -r '.[].node' >nodes.txt
VMNODE=`cat nodes.txt | head -1`
echo 'We run this on node: '$VMNODE
# use API to get nic interfaces of our VM
pvesh get /nodes/$VMNODE/qemu/$1/status/current --output-format json | jq -r '.nics | keys[]' >/tmp/vminterfacelist.txt
# ignore first interface fxp0
cat /tmp/vminterfacelist.txt | tail -n +2 >/tmp/vminterfacelist2.txt
#cat /tmp/vminterfacelist2.txt
while IFS= read -r line
do
INTERFACE="$line"
#echo $INTERFACE
BRIDGE=`find /sys/devices/virtual/net -name $INTERFACE | grep '/brif/' | sed 's/// /g' | awk '{print $5}'`
# change MTU to higher value
RUNME="ip link set dev "$INTERFACE" mtu 9200"
echo $RUNME
eval $RUNME
# enable LLDP and 802.1x on bridge
RUNME="echo 65528 > /sys/class/net/"$BRIDGE"/bridge/group_fwd_mask"
echo $RUNME
eval $RUNME
# enable LACP on link
RUNME="echo 16388 > /sys/class/net/"$INTERFACE"/brport/group_fwd_mask"
echo $RUNME
eval $RUNME
done < /tmp/vminterfacelist2.txt
num=0
while IFS= read -r line
do
INTERFACE="$line"
BRIDGE=`find /sys/devices/virtual/net -name $INTERFACE | grep '/brif/' | sed 's/// /g' | awk '{print $5}'`
MTU=`cat /sys/class/net/$BRIDGE/mtu`
if [ "$MTU" != "9200" ]; then
echo 'Warning! Bridge:'$BRIDGE' did not follow new MTU setting of interface:'$INTERFACE' check other interfaces attached to same bridge and correct please!'
num=1
fi
done < /tmp/vminterfacelist2.txt
exit $num
Con el nuevo script, ahora puede actualizar los puentes e interfaces de Linux de la máquina virtual después de iniciarla. El primer nodo de la API seleccionada es adecuado para una sola instalación de Proxmox VE. Si tiene un clúster, es posible que deba cambiar el script anterior.
./vm-bridge-update.sh $VMID We run this on node: proxmox1 ip link set dev tap200i1 mtu 9200 echo 65528 > /sys/class/net/ge000/bridge/group_fwd_mask echo 16388 > /sys/class/net/tap200i1/brport/group_fwd_mask ip link set dev tap200i2 mtu 9200 echo 65528 > /sys/class/net/ge001/bridge/group_fwd_mask echo 16388 > /sys/class/net/tap200i2/brport/group_fwd_mask ip link set dev tap200i3 mtu 9200 echo 65528 > /sys/class/net/ge002/bridge/group_fwd_mask echo 16388 > /sys/class/net/tap200i3/brport/group_fwd_mask
Para validar la primera prueba de las mejoras del puente de Linux, busque anuncios de vecinos de LLDP desde la máquina virtual del conmutador vJunos. Con las juniper.conf instrucciones pero sin el ajuste, no verá los anuncios usando tcpdump ). Vea el ejemplo a continuación.
root@proxmox1:~# tcpdump -eni ge000 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on ge000, link-type EN10MB (Ethernet), snapshot length 262144 bytes 13:47:37.917669 bc:24:11:6b:0b:84 > 01:80:c2:00:00:0e, ethertype LLDP (0x88cc), length 322: LLDP, length 308: vjunos 13:48:07.692425 bc:24:11:6b:0b:84 > 01:80:c2:00:00:0e, ethertype LLDP (0x88cc), length 322: LLDP, length 308: vjunos
Para realizar una prueba final, inicie un segundo conmutador vJunos conectado 1:1 a la primera máquina virtual. A continuación, establezca un LAG con LACP activo entre las dos máquinas virtuales. A continuación se muestra la configuración de ambos conmutadores virtuales en la GUI de Mist Cloud.
Si inspecciona localmente en la consola del conmutador vJunos, debería ver vecinos de LLDP y los vínculos LACP establecidos entre los dos conmutadores. Este paso verifica que el laboratorio funciona como se esperaba.
root@switch1> show lldp neighbors
Local Interface Parent Interface Chassis Id Port info System Name
ge-0/0/0 ae0 2c:6b:f5:3b:3b:c0 ge-0/0/0 switch2
ge-0/0/1 ae0 2c:6b:f5:3b:3b:c0 ge-0/0/1 switch2
ge-0/0/2 ae0 2c:6b:f5:3b:3b:c0 ge-0/0/2 switch2
root@switch1> show lacp interfaces
Aggregated interface: ae0
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-0/0/0 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/0 Partner No No Yes Yes Yes Yes Fast Active
ge-0/0/1 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/1 Partner No No Yes Yes Yes Yes Fast Active
ge-0/0/2 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/2 Partner No No Yes Yes Yes Yes Fast Active
LACP protocol: Receive State Transmit State Mux State
ge-0/0/0 Current Fast periodic Collecting distributing
ge-0/0/1 Current Fast periodic Collecting distributing
ge-0/0/2 Current Fast periodic Collecting distributing