Routes /32 rely on 1 leaf, and when checking the evpn route table on another leaf, the route is not learned.
On leaf1
root@leaf1> show route table VRFtest.inet.0 | match 10.104.0.
10.104.0.0/16 *[BGP/170] 7w5d 23:18:39, localpref 100
10.104.0.2/32 *[BGP/170] 2d 04:23:39, localpref 100
10.104.0.8/29 *[BGP/170] 23:35:31, localpref 100
{master:0}
root@leaf1> show route table VRFtest.evpn.0 | match 10.104.0.
5:4210000500L:245::0::10.104.0.0::16/248
5:4210000500L:245::0::10.104.0.8::29/248
======On leaf2 we do not see 10.104.0.2/32
root@leaf2> show route table VRFtesting.inet.0 | match 10.104.0.
10.104.0.0/16 *[BGP/170] 3w2d 04:40:04, localpref 100
10.104.0.8/29 *[EVPN/170] 23:36:11
root@leaf2> show route table VRFtesting.evpn.0 | match 10.104.0
By default, Juniper Networks devices that support pure EVPN Type 5 routes don't advertise IP prefixes with a mask length of /32 as pure Type 5 routes. To advertise /32 prefixes, you must set up a term in an export policy that explicitly accepts these prefixes into the routing table.
https://www.juniper.net/documentation/us/en/software/junos/evpn-vxlan/topics/ref/statement/ip-prefix-routes-edit-routing-instances-protocols-evpn.html
You can create a policy option to match the desired /32 address and export it under ip-prefix-routes stanza in the routing instance hierarchy.The following are excerpts from a sample configuration:
user@qfx10002# show policy-options policy-statement slash32
term 1 {
from {
protocol bgp;
route-filter 10.104.0.2/32 exact
}
then accept;
user@qfx10002# show routing-instances EVPN-A protocols evpn
ip-prefix-routes {
advertise direct-nexthop;
encapsulation vxlan;
vni 5000;
export slash32;
9/21/2023:KB created