[j-nsp] proxy-arp on EVPN irb

[Aaron1]

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 at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp