Support for EVPN-VXLAN in vJunosEvolved (vptx)

[riccardo-roveri-labs]

Right now EVPN and VXLAN configuration module is only supported on vjunos-switch. For my understanding even if junos-evo is different from junos the basic evpn-vxlan configuration seem the same to me.

I am replicating my current topology that runs on qfx5130 that run evo and for me would be nice being able to use evo. Is there some limintation of virtualized junos-evo?

Thanks,
Riccardo

[ssasso]

Ciao Riccardo,
It should work, but I never found the time to verify/test it.

If you want, you can try to enable the device feature flags, copy (or symlink) the proper templates, and run integration tests.

If they work as expected, you can create a PR for it ;)

[riccardo-roveri-labs]

I copy pasted from vjunos-switch and with a few tweaks it seems to work with my topology. I will try to fork it and test it properly if i find the time.

Because 80% of the stuff is the same but not 100% what do you suggest doing? Is there a smarter solution than copy paste and mainain both file? I see that for other modules thare are just shared ones named junos.
Can i create a vptx.j2 and vjunos-switch.j2 with specific config and a junos.j2 with common config?

[ipspace]

I copy pasted from vjunos-switch and with a few tweaks it seems to work with my topology. I will try to fork it and test it properly if i find the time.

Worst case, upload what you have, and I'll take it from there.

Because 80% of the stuff is the same but not 100% what do you suggest doing? Can i create a vptx.j2 and vjunos-switch.j2 with specific config and a junos.j2 with common config?

I would do something along those lines (I did the same for IOS/XE), but as I said, just upload (or submit a PR) with your changes, and I'll do the cleanup. I have no problem doing that, but don't have time to figure out how to make things work with Junos

PS: Remember the days when Juniper claimed how they're better than the competition (= Cisco) because they have one software that runs on all platforms?

[ssasso]

Can i create a vptx.j2 and vjunos-switch.j2 with specific config and a junos.j2 with common config?

In that case you need to "include" the common file in the platform files - if I remember correctly, if there is a more specific platform file then junos.j2 is never read.

[ssasso]

they have one software that runs on all platforms?

The software runs. It's the config that won't work 🤪

[rickycraft]

PS: Remember the days when Juniper claimed how they're better than the competition (= Cisco) because they have one software that runs on all platforms?

I spent 4h try to debug EVPN-VXLAN config for then discovering that even if both QFX and PTX run evo they have different data-plane knobs for enabling tunnel encapsulation/decapsulation.

• still me but from the right account 🥸

[rickycraft]

I tried, but the static vxlan part is totally different, it needs a dedicated routing-instance of type virtual-switch. The tests take ages to run, i did not manage to find a way to run them in parallel.

Busy week but when i have time i will try to keep working on it here.

[DanPartelly]

I tried, but the static vxlan part is totally different, it needs a dedicated routing-instance of type virtual-switch. The tests

I think the right way to approach the problem is to get a working configuration first, test it manually and save it. Then you know how to modify the templates. Do not try to get everything up at once. Get Vxlan working, then go on to EVPN. Leave the lab up till you iron out a config.

Then use netlab create / netlab initial -o , while you work on templating. Do not boot the beasts till you are satisfied with what configs are generated, at least in a fist approximation

You may want to run tests last, Evo boots very slow. Just my 2 cents.

[rickycraft]

That is basically what I am doing, but is not obvious to understand where it breaks.

Bit new to the project and how to debug it well and efficiently.

[ipspace]

I tried, but the static vxlan part is totally different, it needs a dedicated routing-instance of type virtual-switch.

So I would suggest (as @DanPartelly did) to focus on VXLAN first. VXLAN is mostly just bridging, and sometimes the IRB part just works.

The tests take ages to run

I hope you have a server with fast SSD. I once tried to run Junos VMs on a server with traditional disks, and the results were catastrophic.

i did not manage to find a way to run them in parallel.

It depends on where the bottleneck is, but if it's disk access, then running tests in parallel wouldn't be any faster. Use the multilab plugin (https://netlab.tools/plugins/multilab/) if you want to run them in parallel, or run a test in the background while working on something else.

Busy week but when i have time i will try to keep working on it here.

👍 Thank you!

[ipspace]

That is basically what I am doing, but is not obvious to understand where it breaks.

When you get stuck, just describe what's going on, and we might be able to help you move on.

Bit new to the project and how to debug it well and efficiently.

@DanPartelly nailed it:

• Pretend VXLAN works (set the feature flag)
• Start a lab (for example, one of the integration tests in https://github.com/ipspace/netlab/tree/dev/tests/integration/vxlan)
• Device configuration will fail because there is no VXLAN template (or it's broken)
• Configure the device manually, tweak stuff until validation works.
• Collect the device configuration with "netlab collect", extract the VXLAN-related part of it
• Inspect the node data structures with "netlab inspect --node name". You can also specify the bit you're interested in, for example "netlab inspect --node name vlans" or "netlab inspect --node name vxlan"
• Using the collected device configuration, node data, and other templates, create Jinja2 templates that will result in your desired configuration

Assuming you have the lab still running, the best way to check the templates is "netlab initial -o directory -l node" -- that will create the configurations for your node in the output directory. If it reports Jinja2 errors, you fix them. If the configurations aren't right, you keep changing the template.

After you have the correct configurations:

• Do "netlab initial -l node" to check the deployment of the configurations on the node.
• If you want to be absolutely sure, shut down the lab, and restart it with "netlab up topology --validate".
• The validation part might fail due to timing errors, particularly on Junos. It takes forever to wake up. I'll deal with the timing issues when merging, but it would be nice to know where they are.
• If you get validation errors that might be due to timing, retry "netlab validate" a bit later. If it passes, it's just Junos being stubborn.

At this point, you have some basic functionality (for example, VXLAN bridging). Now start the next integration test (for example, VXLAN with IRB) and repeat the process.

Hope this helps (and it needs to go into a development document ;)

[rickycraft]

Where can I find which integration test pass with vjunos-switch?

Some stuff do not seem to be working with also those, so for now does not make sense to implement them in vptx.

[ipspace]

Where can I find which integration test pass with vjunos-switch?

https://tests.netlab.tools/_html/vjunos-switch

[rickycraft]

I got stuck quickly on the static VXLAN side. I am following this guide from juniper that should work for both flavours but it seems not. Probably something trivial that i am missing.

It just refuses to learn the arp of the devices connected to it:

admin@dut> show arp
MAC Address       Address         Name                      Interface               Flags
aa:c1:ab:e5:0c:33 10.1.0.2        10.1.0.2                  et-0/0/0.0              none
Total entries: 1

admin@dut> show ethernet-switching mac-ip-table

admin@dut> show arp
MAC Address       Address         Name                      Interface               Flags
aa:c1:ab:e5:0c:33 10.1.0.2        10.1.0.2                  et-0/0/0.0              none
Total entries: 1

admin@dut> show ethernet-switching table

MAC flags (S - static MAC, D - dynamic MAC, L - locally learned, P - Persistent static, C - Control MAC
           SE - statistics enabled, NM - non configured MAC, R - remote PE MAC, O - ovsdb MAC
           GBP - group based policy, B - Blocked MAC)


Ethernet switching table : 9 entries, 9 learned
Routing instance : evpn-switch
    Vlan                MAC                 MAC         Age   GBP     Logical                NH        MAC        RTR
    name                address             flags             Tag     interface              Index     property   ID
    blue                aa:c1:ab:16:0f:09   D             -           et-0/0/4.0             0                    0
    blue                aa:c1:ab:2f:0b:65   D             -           et-0/0/4.0             0                    0
    blue                aa:c1:ab:78:3a:08   D             -           vtep-53.32770          0                    0
    blue                aa:c1:ab:c6:98:63   D             -           et-0/0/3.0             0                    0
    red                 aa:c1:ab:10:55:61   D             -           et-0/0/1.0             0                    0
    red                 aa:c1:ab:2d:65:08   D             -           et-0/0/2.0             0                    0
    red                 aa:c1:ab:4b:38:38   D             -           et-0/0/2.0             0                    0
    red                 aa:c1:ab:b2:db:9f   D             -           vtep-53.32770          0                    0
    red                 aa:c1:ab:b7:7b:c0   D             -           et-0/0/1.0             0                    0

Here is the config for the test vxlan/03-vxlan-irb.yml

set version 24.4R2.21-EVOI20250814151007-evo-builder-1
set interfaces et-0/0/0 mtu 1614
set interfaces et-0/0/0 unit 0 description "dut -> s2"
set interfaces et-0/0/0 unit 0 family inet address 10.1.0.1/30
set interfaces et-0/0/1 mtu 1514
set interfaces et-0/0/1 unit 0 description "[Access VLAN red] dut -> h1"
set interfaces et-0/0/1 unit 0 family ethernet-switching vlan members red
set interfaces et-0/0/2 mtu 1514
set interfaces et-0/0/2 unit 0 description "[Access VLAN red] dut -> h1a"
set interfaces et-0/0/2 unit 0 family ethernet-switching vlan members red
set interfaces et-0/0/3 mtu 1514
set interfaces et-0/0/3 unit 0 description "[Access VLAN blue] dut -> h3"
set interfaces et-0/0/3 unit 0 family ethernet-switching vlan members blue
set interfaces et-0/0/4 mtu 1514
set interfaces et-0/0/4 unit 0 description "[Access VLAN blue] dut -> h3a"
set interfaces et-0/0/4 unit 0 family ethernet-switching vlan members blue
set interfaces irb unit 1000 description "VLAN red (1000) -> [h1,h1a,h2,s2] [external]"
set interfaces irb unit 1000 family inet mtu 1500
set interfaces irb unit 1000 family inet address 172.16.0.7/24
set interfaces irb unit 1001 description "VLAN blue (1001) -> [h3,h3a,h4,s2] [external]"
set interfaces irb unit 1001 family inet mtu 1500
set interfaces irb unit 1001 family inet address 172.16.1.7/24
set interfaces lo0 unit 0 family inet address 100.99.0.7/32
set interfaces re0:mgmt-0 unit 0 family inet address 10.0.0.15/24
set interfaces re0:mgmt-0 unit 0 family inet6 address 2001:db8::2/64
set forwarding-options tunnel-termination
set policy-options policy-statement ecmp then load-balance per-flow
set routing-instances evpn-switch instance-type virtual-switch
set routing-instances evpn-switch vtep-source-interface lo0.0
set routing-instances evpn-switch remote-vtep-list 100.99.0.8
set routing-instances evpn-switch interface et-0/0/1.0
set routing-instances evpn-switch interface et-0/0/2.0
set routing-instances evpn-switch interface et-0/0/3.0
set routing-instances evpn-switch interface et-0/0/4.0
set routing-instances evpn-switch vlans blue vlan-id 1001
set routing-instances evpn-switch vlans blue l3-interface irb.1001
set routing-instances evpn-switch vlans blue vxlan vni 5001
set routing-instances evpn-switch vlans blue vxlan ingress-node-replication
set routing-instances evpn-switch vlans blue vxlan static-remote-vtep-list 100.99.0.8
set routing-instances evpn-switch vlans red vlan-id 1000
set routing-instances evpn-switch vlans red l3-interface irb.1000
set routing-instances evpn-switch vlans red vxlan vni 5000
set routing-instances evpn-switch vlans red vxlan ingress-node-replication
set routing-instances evpn-switch vlans red vxlan static-remote-vtep-list 100.99.0.8
set routing-options router-id 100.99.0.7
set routing-options forwarding-table export ecmp
set protocols ospf area 0.0.0.0 interface lo0.0
set protocols ospf area 0.0.0.0 interface et-0/0/0.0 interface-type p2p
set protocols lldp interface re0:mgmt-0 disable
set protocols lldp interface all