As I recall, proxy-arp behavior is proven by looking in the local host arp
cache and finding entries for foreign ip’s mapped to the default gateway’s mac
address. If that is still occurring, then it would seem that proxy arp
functionality is still working and you can move on to tshooting something
beyond that… like what is the upstream def gw/evpn pe doing with those packets
Aaron
> On Dec 6, 2023, at 6:16 AM, Jackson, William via juniper-nsp
> <juniper-nsp@puck.nether.net> wrote:
>
> Hi
>
> Maybe somebody knows the answer to this one:
>
> We migrated some customers to an EVPN domain away from a legacy node that
> used proxy-arp on its L3 interface.
>
> The downstream clients have some funky routing and they are relying on
> proxy-arp to resolve an offnet address (don't ask me why for our sanities
> sake)!
>
> We have a implemented EVPN bridge domain with the following config on MX PE
> nodes running 21.1 code.
>
> instance-type virtual-switch;
> protocols {
> evpn {
> encapsulation mpls;
> default-gateway do-not-advertise;
> extended-vlan-list [ 250 ];
> }
> }
> bridge-domains {
> 250 {
> domain-type bridge;
> vlan-id 250;
> interface ae68.250;
> routing-interface irb.25068;
> }
> }
>
> interfaces irb.25068 {
> proxy-arp;
> family inet {
> address 172.23.248.1/22;
> }
> mac 00:aa:dd:00:00:68;
> }
>
> This irb is in a L3VPN instance.
>
> Now the documentation states that proxy-arp and arp-suppression is on by
> default yet these clients cant reach the offnet host with or without the
> "proxy-arp" command on the irb.
>
> Any ideas?
>
> thanks
> _______________________________________________
> 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
