A PTX running EVO peering with an L2 switch in an EVPN with MAC-VRF is seeing an issue with ARP resolution.
The system is configured with an L3 VRF:
set routing-instances PublicInternet instance-type vrf
set routing-instances PublicInternet routing-options router-id 10.0.0.1
set routing-instances PublicInternet routing-options autonomous-system 65001
set routing-instances PublicInternet routing-options graceful-restart
set routing-instances PublicInternet routing-options multipath
set routing-instances PublicInternet routing-options auto-export
set routing-instances PublicInternet interface irb.1010
set routing-instances PublicInternet interface lo0.600
set routing-instances PublicInternet route-distinguisher 10.0.0.1:65001
set routing-instances PublicInternet vrf-import Import_from_EVPN
set routing-instances PublicInternet vrf-target target:12345:12345
Tied to IRB.1010:
set interfaces irb unit 1010 arp-resp unrestricted
set interfaces irb unit 1010 family inet address 100.1.1.100/24
And, a MAC VRF instance tied to L2:
set routing-instances client-1010 instance-type mac-vrf
set routing-instances client-1010 protocols evpn encapsulation vxlan
set routing-instances client-1010 protocols evpn default-gateway advertise
set routing-instances client-1010 protocols evpn duplicate-mac-detection auto-recovery-time 9
set routing-instances client-1010 protocols evpn extended-vni-list all
set routing-instances client-1010 protocols evpn vni-options vni 1010
set routing-instances client-1010 vtep-source-interface lo0.0
set routing-instances client-1010 service-type vlan-aware
set routing-instances client-1010 interface et-0/0/4.0
set routing-instances client-1010 route-distinguisher 10.99.0.51:1010
set routing-instances client-1010 vrf-target target:12345:1010
set routing-instances client-1010 vlans vl-1010 vlan-id 1010
set routing-instances client-1010 vlans vl-1010 l3-interface irb.1010
set routing-instances client-1010 vlans vl-1010 vxlan vni 1010
Has a BGP EVPN signalled peer:
set protocols bgp group g1-vxlan type external
set protocols bgp group g1-vxlan multihop ttl 255
set protocols bgp group g1-vxlan multihop no-nexthop-change
set protocols bgp group g1-vxlan local-address 10.99.0.51
set protocols bgp group g1-vxlan hold-time 9
set protocols bgp group g1-vxlan log-updown
set protocols bgp group g1-vxlan family evpn signaling
set protocols bgp group g1-vxlan peer-as 65003
set protocols bgp group g1-vxlan graceful-restart
set protocols bgp group g1-vxlan multipath multiple-as
set protocols bgp group g1-vxlan bfd-liveness-detection minimum-interval 300
set protocols bgp group g1-vxlan bfd-liveness-detection multiplier 3
set protocols bgp group g1-vxlan bfd-liveness-detection session-mode automatic
set protocols bgp group g1-vxlan neighbor 10.99.0.1
set protocols bgp group g1-vxlan vpn-apply-export
It learns a Type 2 Route for a host behind the switch. The host has an address of 100.1.1.11. But, the catch is the switch is not sending up the MAC/IP as a Type 2 route, only the MAC:
root@ptx> show route table bgp.evpn.0 evpn-mac-address 7c:fe:90:ff:91:da
bgp.evpn.0: 19 destinations, 32 routes (19 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both
2:10.99.0.11:1010::0::7c:fe:90:ff:91:da/304 MAC/IP
As expected no ARP is learned/installed:
root@ptx> show arp no-resolve
MAC Address Address Interface Flags
90:2d:77:0d:37:83 10.99.10.41 ae0.0 none
98:19:2c:bd:e1:f4 10.99.20.41 ae1.0 none
7c:fe:90:ff:91:d4 100.1.1.31 irb.1010[ .local..56 ] permanent remote
7c:fe:90:ff:91:dc 100.1.1.41 irb.1010[ .local..56 ] permanent remote
7c:fe:90:ff:91:d6 100.1.1.51 irb.1010[ et-0/0/4.0 ] permanent remote
Total entries: 5.0
Pings to the host fail:
root@ptx> ping 100.1.1.11 routing-instance PublicInternet
PING 100.1.1.11 (100.1.1.11) 56(84) bytes of data.
^C
--- 100.1.1.11 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2027ms
With no ARP seen via monitor traffic on irb.1010 and no ARP is actually sent by the PTX.
ARP packets are not sent by the PTX for hosts resolved over a vtep interface.
The problem here is that the PTX running EVO does not support ARP resolution via the VTEP interface that points to the client off of the L2 switch. It expects to learn the Type 2 MAC and MAC/IP routes for systems off of the L2 switch so that the local ARP cache can be populated. Junos has a CLI knob for proxy-mac-ip-advertisement:
https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/proxy-macip-advertisement-edit-interfaces.html
But, that functionality is not in EVO at this time. So, the only solution is to have the peer L2 switch send both Type 2 routes.