Mailing List Archive

Hi

I assume you have some broad policy config on the leafs like this:

set policy-options policy-statement BGP-OVERLAY-IN term reject-remote-gw
from family evpn
set policy-options policy-statement BGP-OVERLAY-IN term reject-remote-gw
from next-hop 2.255.255.1
set policy-options policy-statement BGP-OVERLAY-IN term reject-remote-gw
from next-hop 2.255.255.2
set policy-options policy-statement BGP-OVERLAY-IN term reject-remote-gw
from nlri-route-type 1
set policy-options policy-statement BGP-OVERLAY-IN term reject-remote-gw
from nlri-route-type 2
set policy-options policy-statement BGP-OVERLAY-IN term reject-remote-gw
then reject
set policy-options policy-statement BGP-OVERLAY-IN term accept-all then
accept

Starting with 19.4R1 you can use complex route filters with EVPN
attributes, maybe this can help you influence the path without discarding
them?
Example: Using Policy Filters to Filter EVPN Routes | Junos OS | Juniper
Networks
<https://www.juniper.net/documentation/us/en/software/junos/evpn-vxlan/topics/example/example-using-policy-filters-to-filter-evpn-routes.html>

Another way is to use VMTO where you advertise the /32 "northbound" that
the Spines have installed so you alway have an optimal return path.
Ingress Virtual Machine Traffic Optimization | Junos OS | Juniper Networks
<https://www.juniper.net/documentation/us/en/software/junos/evpn-vxlan/topics/concept/evpn-ingress-vmto.html>

Juniper equivalent to "Cisco VXLAN EVPN Multi-Site Design" should be VXLAN
Stitching. I haven't tried it myself. QFX10k is a requirement.
Configure VXLAN Stitching for Layer 2 Data Center Interconnect -
TechLibrary - Juniper Networks
<https://www.juniper.net/documentation/en_US/release-independent/solutions/topics/task/configuration/vxlan_stitch-cloud-dc-configuring.html>

Regards
Roger



On Wed, May 18, 2022 at 8:18 AM niklas rehnberg via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

> Hi all,
>
> I have two DCs that work as multi-site , IE all subnets are available in
> both DCs.
> Using spine/leaf setup, two spines (QFX10000) on each site.
> Using the Central GW setup, the spines are L3 GWs.
> In the overlay BGP a filter has been included so the leafs see only their
> own site spines, and will result in the traffic always using the nearest
> spine to reach the WAN.
> A design problem I have found now is if the return traffic to a leaf in
> site1 comes via site2 spines.
> The spine in site2 will add a vxlan header and send it leaf in site1, but
> the leaf will drop the traffic as the spine is unknown (as I have designed
> the solution).
>
> I need suggestions on how to solve this.
> A very easy way is to remove the filter so all leafs see all spine, but the
> drawback will be that a leaf in site1 can use a spine in site2 as L3 GW.
> Cisco has a solution called "VXLAN EVPN Multi-Site Design", I have not seen
> any simulare example for juniper.
>
> Thanks Niklas
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp