VXLAN traffic engineering

[ Edited ]
‎04-20-2018 07:28 AM

Dear support,


I need you help as I'm not finding the solution. Please refers to the diagram below



# Design

1. Two DC

2. On each DC : two QFX10K, and a VCF (QFX5100 switches)

3. QFX10K plays SPINE role, whereas VCF is a LEAF

4. L3 Gawtays (EVPN anycast gateway) are only on QFX10K. The QFX5K (VCF) is not able to route inter-VXLAN trafic

5. Dataplane is VXLAN and Control-Plane is BGP EVPN

6. Default VTEP address are routed accross the green and blue links


# Objective :

1. Communication for RED server bewteen each DC must use the DCI red links

2. other servers (GREEN) must use the DCI green links


# What I tired

1. ijnstead of a routing solution, use all links and use QOS to differentiate traffic type for traffic protection => Not possible because QOS seems to  not be supported with VXLAN

2. Use specific loopback address that are only routed through the red link and try to change the BGP next-hop of specific route-target (one RT = on vlan).  => failed because on the VCF (QFX5K) I can have only one VTEP source address. So even the next-hop of the remote destination will be routed accross the RED link (for example), the source address on the VTEP will be routed to the green link.


Any solution guys ?


Thanks a lot





Re: VXLAN traffic engineering

‎04-20-2018 08:10 AM

Oups good news !


I had a mistake in my policy and it works fine !



1.Let's suppose default loopback are called loopback A on each routers (QFX10K and QFX5K)

2. Define new loopback (B) on each routers

3. Route loopback A with dynamic protocol (let's say OSPF)

4. Route loopback B with an other dynamic protocols (let's say ISIS)

5. On DC1 routers (QFX10K) facing DC2, when importing ebgp prefix, change the next-hop from RT VRED corresponding to Vlan VRED  to loopback B. Be carefull here : as bgp next-hop is unchange, your policy should match each different next-hop it received and update it. DO not put the same next-hop for all RT VRED !


That's all !


Salah, happy


Re: VXLAN traffic engineering

‎05-27-2019 01:57 PM

Hello !


Sort update : bad news when we pushed the configuration on production : it didn' work !


Actually, it worked fine in my labs (vqfx) because as vqfx5100 doesn't exist, I replaced it with a vqfx10k. On production we failed for the following reason :

  1. hardware limitation on QFX5K => recursive lookup to the secondary loopack is not supported by the Broadcom ASIC
  2. it works fine on QFX10K but declare unsupported by Juniper as, even not documented, any change to BGP EVPN attribut is not supported. I will be supporter after version 19.1 or later