interface indexes off by 2 in Everest images

[thomasammon]

On some of my everest csr1000v VM's, I have noticed that sometimes the ports being shown in the web interface do not match how the ports are actually connected.

For example, R1 Gi2 is connected to R2 Gi2, as shown in the GUI. But when I go to configure IP addresses in the router's consoles, I can't get reachability between the routers. So, I bring up all of the interfaces inside the CSR and turn on CDP, and I see that R2 is actually connected to R1 via Gi4. When I configure the IP addresses on Gi4, I can ping between them. I have seen this problem in this particular topology on 3 different pairs of routers. Even if I delete the nodes and recreate them, I get the same behavior on the replacement nodes. Here's some details about my setup:

25 CSR1000v routers (all running Version 16.05.01b)
EVE-NG version: 2.0.3-59
QEMU version: 2.4.0
UKSM is off
EVE is running as VM on top of ESX 6.5, 256GB of RAM and 32 CPU cores

Is this a known issue? So far, the interfaces are always exactly 2 off, so an interface labeled Gi2 in the GUI is actually Gi4.

Thanks,
Tom

[Uldis (UD)]

you have to be sure you are using right template for Everest.
Everest template name is csr1000vng
so foldername for everest must start with csr1000vng-xxxxx

UD

[thomasammon]

Hi, I have rebuilt my eve server and upgraded to the latest version. I have also named the directory as this:

/opt/unetlab/addons/qemu/csr1000vng-universalk9.16.05.01b.Everest

I still have the problem with interfaces being off by exactly 2. I noticed that the mac addresses in the log don't seem to match up to the interfaces I have configured in the GUI. For example, net1 (which should match up to GigabitEthernet2 since we are starting from 0 on the netdev device. But in the below output, net1 is assigned the MAC address 50:00:00:0a:00:01 - which is the MAC address assigned to GigabitEthernet4, as shown in "show interface" below. Why don't the nedev device numbers match up with the interfaces inside the CSR? I believe this is the source of the problem.

Oct 22 07:12:35 INFO: starting /opt/unetlab/wrappers/qemu_wrapper -T 0 -D 10 -t "X" -F /opt/qemu-2.2.0/bin/qemu-system-x86_64 -d 0 -- -nographic -device virtio-net-pci,netdev=net0,mac=50:00:00:0a:00:00 -netdev tap,id=net0,ifname=vunl0_10_0,script=no -device virtio-net-pci,netdev=net1,mac=50:00:00:0a:00:01 -netdev tap,id=net1,ifname=vunl0_10_1,script=no -device virtio-net-pci,netdev=net2,mac=50:00:00:0a:00:02 -netdev tap,id=net2,ifname=vunl0_10_2,script=no -device virtio-net-pci,netdev=net3,mac=50:00:00:0a:00:03 -netdev tap,id=net3,ifname=vunl0_10_3,script=no -device virtio-net-pci,netdev=net4,mac=50:00:00:0a:00:04 -netdev tap,id=net4,ifname=vunl0_10_4,script=no -device virtio-net-pci,netdev=net5,mac=50:00:00:0a:00:05 -netdev tap,id=net5,ifname=vunl0_10_5,script=no -device virtio-net-pci,netdev=net6,mac=50:00:00:0a:00:06 -netdev tap,id=net6,ifname=vunl0_10_6,script=no -device virtio-net-pci,netdev=net7,mac=50:00:00:0a:00:07 -netdev tap,id=net7,ifname=vunl0_10_7,script=no -device virtio-net-pci,netdev=net8,mac=50:00:00:0a:00:08 -netdev tap,id=net8,ifname=vunl0_10_8,script=no -device virtio-net-pci,netdev=net9,mac=50:00:00:0a:00:09 -netdev tap,id=net9,ifname=vunl0_10_9,script=no -device virtio-net-pci,netdev=net10,mac=50:00:00:0a:00:0a -netdev tap,id=net10,ifname=vunl0_10_10,script=no -device virtio-net-pci,netdev=net11,mac=50:00:00:0a:00:0b -netdev tap,id=net11,ifname=vunl0_10_11,script=no -smp 1 -m 4096 -name X -uuid c977fc78-ecf8-49fb-a8ea-14d02308f3b9 -drive file=virtioa.qcow2,if=virtio,bus=0,unit=0,cache=none -machine type=pc-1.0,accel=kvm -serial mon:stdio -nographic -nodefconfig -nodefaults -rtc base=utc > /opt/unetlab/tmp/0/fed59dbb-0e48-4124-afd5-6388156e2e1d/10/wrapper.txt 2>&1 &

Router#show int | i Gigabit|Hardware
GigabitEthernet1 is up, line protocol is up
Hardware is CSR vNIC, address is 5000.000a.0000 (bia 5000.000a.0000)
GigabitEthernet2 is up, line protocol is up
Hardware is CSR vNIC, address is 5000.000a.000a (bia 5000.000a.000a)
GigabitEthernet3 is administratively down, line protocol is down
Hardware is CSR vNIC, address is 5000.000a.000b (bia 5000.000a.000b)
GigabitEthernet4 is up, line protocol is up
Hardware is CSR vNIC, address is 5000.000a.0001 (bia 5000.000a.0001)
GigabitEthernet5 is administratively down, line protocol is down
Hardware is CSR vNIC, address is 5000.000a.0002 (bia 5000.000a.0002)
GigabitEthernet6 is administratively down, line protocol is down
Hardware is CSR vNIC, address is 5000.000a.0003 (bia 5000.000a.0003)
GigabitEthernet7 is administratively down, line protocol is down
Hardware is CSR vNIC, address is 5000.000a.0004 (bia 5000.000a.0004)
GigabitEthernet8 is administratively down, line protocol is down
Hardware is CSR vNIC, address is 5000.000a.0005 (bia 5000.000a.0005)
GigabitEthernet9 is administratively down, line protocol is down
Hardware is CSR vNIC, address is 5000.000a.0006 (bia 5000.000a.0006)
GigabitEthernet10 is administratively down, line protocol is down
Hardware is CSR vNIC, address is 5000.000a.0007 (bia 5000.000a.0007)
GigabitEthernet11 is administratively down, line protocol is down
Hardware is CSR vNIC, address is 5000.000a.0008 (bia 5000.000a.0008)
GigabitEthernet12 is administratively down, line protocol is down
Hardware is CSR vNIC, address is 5000.000a.0009 (bia 5000.000a.0009)

[ecze]

seems to ba an image issue because, this image doesn't follow mac ordering nor pci ID ordering....

Did you try other images ?

E.