vJunos EVO Interface Mappings

[kevinpppb]

Hi all,

I'm facing an issue running Juniper vJunos EVO on my eve-ng pro installation. (hardware and software detail at the bottom of this post)

The issue is that the interface mappings as displayed in the eve-ng topology view do not match the interfaces once vJunos EVO has booted up. For example in the diagram below:

Initial Setup.png

PR1 should see PE2, et-0/0/0 as an LLDP neighbour on et-0/0/1, but it does not. What it actually sees is nothing like the topology:

PR1 Output.png

If I then go and check on PE2 things get even stranger. I see PR1 via LLDP on et-0/0/4, but I still see my own interfaces as LLDP neighbours.

I have followed the instructions as found at:
https://www.eve-ng.net/index.php/docume ... vo-router/
I see this issue with both 23.2R1-S1.8 and 23.1

Initially, since I was seeing odd neighbours I thought the problem might be to do with the PFE and RPIO smart bridge settings. I double checked the PFE/RPIO bridge settings, but these were correct.
The next thing I tried was to configure two separate bridges, one for the PFE interconnect and the other for the RPIO. This was just in case the smart bridge was doing something odd but I still saw the same behaviour.
This got me thinking that there might be an issue with the template and how the interfaces are names and numbered. I commented out "eth_format: et-0/0/{0}" from the template and then manually specified the revenue interface names individually. Unsurprisingly, this made no difference so I restored the template.

The only consistency I can see is that et-0/0/0 is connected to et-0/0/3 and than et-0/0/1 is connected to et-0/0/2. So the Smart Bridge does seem to be working, but for whatever reason, these interfaces are not being mapped correctly to the PFE 1/4 and RPIO 2/3 interfaces. Given this consistency, I tried changing the order of the interfaces in the template to offset the interface numbers by 4. This resulted in them still being wrong, but wrong by the offset in the order I entered.

Finally I put the PFE and RPIO interfaces at the bottom of the list in the template and the interfaces are now consistent as far as LLDP is concerned in that there is a 1:1 mapping between the two routers and there is traffic correctly passing the revenue interfaces:

LLDP Working correctly.png

The template now looks like this;

Code: Select all

<snip>
eth_name:
- re0:mgmt-0
- et-0/0/0
- et-0/0/1
- et-0/0/2
- et-0/0/3
- et-0/0/4
- et-0/0/5
- et-0/0/6
- et-0/0/7
- et-0/0/8
- et-0/0/9
- et-0/0/10
- et-0/0/11
- pfe1
- rpio2
- rpio3
- pfe4
#eth_format: et-0/0/{0}
<snip>

So for now, I have a workaround, but the questions remain:

• Does anyone else have this issue?

• Why does the template ordering make a difference?

• Is there an issue with the template? (I surely can't be the only one with this issue)

Interestingly, I have the same issues when running under ESXi which is why I rebuilt on bare metal just to sure this wasn't a nested hypervisor problem.

Any tips or assistance would be gratefully received.

Thanks

Kevin


The hardware is HP DL380G9, 2 x E5-2696 v4 (22 cores each), 256Gb RAM, 4 x 1TD SSD's in a RAID 10 array. It is running eve-pro 5.0.1-120 on bare metal with Ubuntu 20.04.

root@eve:~# uname -a
Linux eve 5.17.8-eve-ng-uksm-wg+ #1 SMP PREEMPT Mon May 16 10:08:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
root@eve:~# dpkg -l eve-ng-pro
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-==============================================
ii eve-ng-pro 5.0.1-120 amd64 A new generation software for networking labs.
root@eve:~#

[Uldis (UD)]

Version 23.1R1.8-EVO works flawless
Hostname: vEV-01
Model: ptx10001-36mr
Junos: 23.1R1.8-EVO
Yocto: 3.0.2
Linux Kernel: 5.2.60

EVE Pro 5.0.1-120
Tested to connect also Cisco routers no issues

tested newest vEVO 23.2, and YES indeed it messup interface order, but it is not EVE issue, but this particular 23.2 vEVO image

below is lab with 23.1R1.8-EVO

[kevinpppb]

Hi Uldis,

Thank you for checking in your lab.

So if I want both images to work, I'll need to create a new device template, named accordingly with the modified template.

Cheers

Kevin

[Uldis (UD)]

I reported this to Juniper, and they agreed,... sorry, shit
we have to wait new erelease
better dont touch that 23.2

I dont know if you had such or not, but this one vEX is the best, Junipeer engineers provided for test
21.2R3-S1.7, 25 ports
As I know this release was not published in Juniper site
see below

[kevinpppb]

Hi Uldis,

I was just in touch with my Juniper SE. He pointed me to this:

https://www.juniper.net/documentation/ ... nged.html

So in fact, for 23.2 this is normal behaviour as it no longer needs the PFE and RPIO bridges. From the perspective of eve-ng and the templates, one needs to either modify the template and stick with a single version - or else create a new template with a different name and remove the RPIO and PFE interfaces for 23.2

vEX has no issues for me.

Thank you again for your testing time - and your development work on eve-ng!

Regards

Kevin