[j-nsp] EVPN IRB / gateway selection

[Roger Wiklund]

Hi Nathan

You're not missing anything. EVPN Overlay IRB VGA selection does NOT take
underlay metrics into consideration yet (it's on the roadmap)
What you need to do is to filter out the remote DC IRB VGAs on each leaf
switch using a policy.

Leaf switches:
set policy-options policy-statement OVERLAY-IN term reject-remote-gw from
family evpn
set policy-options policy-statement OVERLAY-IN term reject-remote-gw from
next-hop [ 100.0.0.13 100.0.0.14] <--*Loopback VTEP IPs of remote DC you
want to reject*
set policy-options policy-statement OVERLAY-IN term reject-remote-gw from
nlri-route-type [ 1 2 ]
set policy-options policy-statement OVERLAY-IN term reject-remote-gw then
reject
set policy-options policy-statement OVERLAY-IN term accept-all then accept

Add this OVERLAY-IN as an import policy for your BGP Overlay group.

*Note, this policy filters out ALL route type1 and route type2 routes, so
not only the VGA MAC. After 19.4R1 you can enhance this policy to only
filter out the VGA MAC from the remote DC.
This is useful if you have L2 stuff connected directly to Spine that you
want to stretch to both DC1 and DC2. With the above policy those L2 VNIs
will be rejected.

https://www.juniper.net/documentation/en_US/junos/topics/concept/evpn-routing-policies.html

Regards
Roger

On Sun, Feb 23, 2020 at 2:45 AM Nathan Ward <juniper-nsp at daork.net> wrote:

> Hi all,
>
> Doing some EVPN work at the moment, and have come across something we’re
> struggling with, and can’t quite figure out if it’s a fundamental thing
> we’re missing or if we’ve missed a magic knob somewhere. Have tried the two
> sets of eyes thing, to no avail.
>
> EVPN, eBGP underlay, iBGP overlay. Following the VLAN aware EVPN guide
> from the Juniper docs.
>
> QFX10k spine, QFX5110 leaf. EVPN-VXLAN.
>
> We have 2 “DCs” in the lab, each “DC" with 2 spines and one leaf (will be
> more leafs in prod, obviously!)
>
> We are using a single EVPN domain at the moment, so there’s no real
> separation between the DCs other than there’s more hops to go inter-DC vs
> intra-DC - at the moment, again, lab, figuring out what is going to work
> best for us.
>
> We are using the IRB virtual gateway functionality, on all 4 spines, and
> are finding that the IRB instance which gets selected by the leaf is the
> one which most recently came up - if we disable/undisable one, it starts
> attracting traffic from all leafs. Trace options on protocols evpn shows
> bits about MAC moves when an IRB comes up - for the autogenerated VRRP
> style gateway MAC.
>
> Our expectation was that it would select the IRB on the shortest path -
> i.e. the shortest eBGP underlay path, but that is not at all what happens,
> the eBGP path appears to not be considered at all.
>
> The ESI is the same (autogenerated) and is signalled as “all active”.
> We have tried fiddling around with the gateway communities - no advertise,
> advertise, etc.
>
> We have not (yet) tested an (mc-ish) LAG ESI, to see if the behaviour is
> the same there, or if it’s limited to IRB.
>
> Is this a QFX5110 thing? There are notes in some docs about hardware
> limitations with ECMP, but this is not equal paths so not sure it’s related.
> Have we missed a knob somewhere?
>
> --
> Nathan Ward
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>