[j-nsp] EVPN IRB / gateway selection

[Nathan Ward]

Hi,

> On 23/02/2020, at 11:38 PM, Roger Wiklund <roger.wiklund at gmail.com> wrote:
> 
> 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 <https://www.juniper.net/documentation/en_US/junos/topics/concept/evpn-routing-policies.html>
> 
> Regards
> Roger

Hah! I literally arrived at this solution just now myself, and am checking email before calling it a day and going to approach it again tomorrow.

Just been through a “let’s try ebgp everywhere” loop, and a few other “let’s try this a whole different way” attempts.

Thanks for the (unintentional) sanity check!

Our spines run as RRs for the local leaf switches, the spines have a full mesh - could I put such a policy on the spine, or, does it need to be on leaves?



It would be *fantastic* for underlay metrics to be part of route selection, it seems.. well.. kind of crazy that it’s not in there already. For networks with a folded CLOS topology this seems fine.. until a leaf-spine link failure which could result in some quite poor paths, I think. For different topologies, i.e. ones with different path lengths, this is regularly going to result in poor selected paths.

--
Nathan Ward