Hey Wido! Thanks for reply!
> I must say I have never tried with a JunOS VC, but why would you also? > This is a full L3 setup, correct? Why add the VC of JunOS? We are currently using two virtual chassis because it was an existing setup with running redundant L2 connections. We still need these connections. Our plan was to migrate to a L3 environment now. In a new setup we would use four single devices too. Right now this is not possible because of production systems. > Which MACs, where? Who is your gateway? We are seeing all mac-addresses on the right sides in evpn database. These are published to evpn fine. > Why not use this for the BGP session? We are using a bond because of the virual chassis on the switch side. We wanted to use 2x25G connection. We are using OSPF to learn Loopback IPs of devices. BGP connection via Loopback is the reason for one single bgp session between switch and kvm host. > Did you set a vtep-source under switch-options to lo0.0? Yes, of course we set vtep Interface to loopback. set switch-options vtep-source-interface lo0.0 Can you tell me something about your import/export rules or add a snippet too? Right now we are not using any policies. Our next steps are: We will try to run bgp sessions via interface addresses without OSPF. We will try with a single spare device without VC. We thought about using iBGP too but decided to use eBGP because of easier debugging. Thank you for your help! Julian Sluimann IT-Service [cid:phone-icon_004b6ca1-3c9d-4d5f-a392-9e20f385200f.png] 0256498996-30 [cid:mail-icon_0faae6df-067c-4ca9-a09f-d32cbfd051ea.png] [email protected] [cid:epnoxlogo_45de1f2a-1d32-4b3a-8ea0-3fc3a81feb48.png] [cid:website-icon_cd56ec0c-da12-41a5-a7c5-4e2997773e4c.png] epnox.de [cid:location-icon_d9aaf7ae-803a-430f-b99e-11ccf4e4ccff.png] Stadtlohner Str. 6, 48691 Vreden epnox GmbH Stadtlohner Straße 6 48691 Vreden Geschäftsführer: Gerd Gevering | Christian Meiners | Nils Waning | Ust.-Nummer: DE351345026 St.Nr.: 301/5813/2061 | HRB 20199 | zertifiziert nach: ISO 27001 [cid:leaf-icon-green_4afffd01-0555-42af-9279-0b6f0b5dd129.png] Bitte prüfen Sie vorher, ob ein Ausdruck dieser E-Mail wirklich notwendig ist. Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. On 2026/05/19 04:14:35 Wido den Hollander via users wrote: > > > Op 18-05-2026 om 11:25 schreef Julian Sluimann: > > Hi everyone, > > > > We are currently trying to expand our L2 VLAN-based CloudStack environment > > to include EVPN VXLAN. We've run into a problem that we can't seem to solve… > > > > But right from the start: We are using two Juniper Virtual Chassis, each > > with two Juniper EX4650 switches. The KVM hosts (Ubuntu 24.04 with > > FRRouting 10.6.1) use an LACP bond (bond1) for guest traffic. We have > > included the script needed to create the bridges. The bridge is created > > correctly; we see traffic from the VM’s "vnet" interface passing through > > the bridge and then exiting the bond encapsulated in VXLAN. However, the > > traffic simply does not seem to arrive on the other side. It doesn't matter > > whether the KVM hosts are connected to the same switch chassis. If the KVM > > hosts communicate directly with each other via BGP, everything works > > without any problems. > > > > I do see some problems with FRR <> JunOS communicating with BGP+EVPN, > but it can work. > > I must say I have never tried with a JunOS VC, but why would you also? > This is a full L3 setup, correct? Why add the VC of JunOS? > > > We noticed that the ARP table within the VM is not populated correctly. > > That's strange, because both the switches and the KVM hosts have filled > > their ARP tables with all the MAC addresses. But even if we add the missing > > MAC addresses of the VMs on both sides, they still cannot communicate with > > each other. That doesn't seem to be the problem, but perhaps it's a > > consequence of the actual problem? > > Which MACs, where? Who is your gateway? > > (see more below) > > > > > Our current FRR configuration looks like this: > > > > ! > > frr version 10.6.0 > > frr defaults traditional > > hostname kvm-h1 > > log syslog informational > > service integrated-vtysh-config > > ! > > ip prefix-list LOOPBACKS seq 10 permit 10.0.0.0/8 le 32 > > ! > > interface bond1 > > ip ospf area 0.0.0.51 > > ip ospf network point-to-point > > no ipv6 nd suppress-ra > > exit > > ! > > interface lo > > ip address 10.66.200.3/32 > > exit > > ! > > router bgp 65203 > > bgp router-id 10.66.200.3 > > no bgp ebgp-requires-policy > > no bgp default ipv4-unicast > > no bgp network import-check > > neighbor uplinks peer-group > > neighbor uplinks remote-as external > > neighbor uplinks ebgp-multihop > > neighbor uplinks update-source lo > > Correct? How does the EX learn this loopback address of the KVM host? > Why not use the address of the interface for the uplink? > > And why a bond and not two seperate BGP sessions? > > > neighbor 10.65.200.250 peer-group uplinks > > neighbor 10.65.200.250 description SWITCH1 > > ! > > address-family l2vpn evpn > > neighbor uplinks activate > > advertise-all-vni > > vni 10003168 > > route-target import 100:100 > > route-target export 100:100 > > proxy-arp > > exit-vni > > advertise-svi-ip > > exit-address-family > > exit > > ! > > router ospf > > ospf router-id 10.66.200.3 > > redistribute connected route-map OSPF_EXPORT > > exit > > ! > > route-map OSPF_EXPORT permit 10 > > match ip address prefix-list LOOPBACKS > > exit > > ! > > end > > > > Our test VNI is 10003168. It contains two VMs, each on a different KVM > > host, which in turn are connected to two different virtual switches. > > > > The "bond1" interface is used, which is defined in the Netplan as follows: > > > > bonds: > > bond1: > > mtu: "9000" > > interfaces: > > - ens2f1np1 > > - eno3np1 > > addresses: > > - "10.65.200.5/31" > > Why not use this for the BGP session? > > > parameters: > > mode: "802.3ad" > > lacp-rate: "slow" > > transmit-hash-policy: "layer3+4" > > > > This is how our juniper configuration looks like: > > > > set protocols evpn no-core-isolation > > set protocols evpn encapsulation vxlan > > set protocols evpn default-gateway no-gateway-community > > set protocols evpn duplicate-mac-detection detection-threshold 5 > > set protocols evpn duplicate-mac-detection detection-window 180 > > set protocols evpn duplicate-mac-detection auto-recovery-time 15 > > set protocols evpn multicast-mode ingress-replication > > set protocols evpn extended-vni-list 4004070 > > set protocols evpn extended-vni-list 10003168 > > > > set routing-options router-id 10.65.200.250 > > set switch-options vrf-target target:100:100 > > set switch-options route-distinguisher 10.65.200.250:100 > > Did you set a vtep-source under switch-options to lo0.0? > > > > > Session to EX4650 VC2 > > > > set protocols bgp group BGP-SW-to-SW multihop ttl 2 > > set protocols bgp group BGP-SW-to-SW multihop no-nexthop-change > > set protocols bgp group BGP-SW-to-SW family inet unicast > > set protocols bgp group BGP-SW-to-SW family evpn signaling > > set protocols bgp group BGP-SW-to-SW neighbor 10.65.100.250 description > > AS65100 > > set protocols bgp group BGP-SW-to-SW neighbor 10.65.100.250 local-address > > 10.65.200.250 > > set protocols bgp group BGP-SW-to-SW neighbor 10.65.100.250 peer-as 65100 > > > > set protocols bgp group BGP-SW-to-KVM multihop ttl 2 > > set protocols bgp group BGP-SW-to-KVM multihop no-nexthop-change > > set protocols bgp group BGP-SW-to-KVM family inet unicast > > set protocols bgp group BGP-SW-to-KVM family evpn signaling > > set protocols bgp group BGP-SW-to-KVM neighbor 10.66.200.3 description > > "AS65203" > > set protocols bgp group BGP-SW-to-KVM neighbor 10.66.200.3 local-address > > 10.65.200.250 > > set protocols bgp group BGP-SW-to-KVM neighbor 10.66.200.3 peer-as 65203 > > A snippet of the config on a QFX5120 > > > group compute { > type external; > multihop { > no-nexthop-change; > } > accept-remote-nexthop; > import compute-in; > family inet { > unicast { > extended-nexthop; > } > } > family inet6 { > unicast; > } > family evpn { > signaling; > } > export compute-out; > neighbor 2a01:XXX:2:180::7 { > description compute0; > local-address 2a01:XXX:2:180::6; > peer-as 64650; > } > } > > Here we peer over IPv6, so yes, slightly different. > > > > > set protocols bgp local-as 65200 > > > > Does anyone have experience with EVPN-VXLAN and Juniper EX4650 switches? > > It’s probably a really silly problem… but we just can’t figure it out. > > As said, the QFX5120 gave me some troubles as well, but it works! > > Wido > > > > > Thanks! > > > >
