Mailing List Archive

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

Hi

It seems that proxy arp is disabled by default:
proxy-arp | Junos OS | Juniper Networks
<https://www.juniper.net/documentation/us/en/software/junos/multicast-l2/topics/ref/statement/proxy-arp-edit-interfaces.html>

Regarding proxy-arp for EVPN (arp suppression) it only works for the same
subnet, not between subnets.

So that seems to match what you're seeing that you must enable proxy-arp on
the IRB in order to reach the other subnets.

Regards
Roger


On Wed, Dec 6, 2023 at 5:04?PM Aaron1 via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

> 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
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Hi

This is what I have done, but it doesn’t appear to work.

We have had to send to the clients via DHCP a set of /32 host routes to circumvent this problem.

I will open a TAC case and raise with my SE to see whats what.

Thanks for the feedback.

From: Roger Wiklund <roger.wiklund@gmail.com>
Sent: Friday, December 8, 2023 2:25 PM
To: Aaron1 <aaron1@gvtc.com>
Cc: Jackson, William <william.jackson@gibtele.com>; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] proxy-arp on EVPN irb

** WARNING: This email originates from outside of the organisation **

Hi

It seems that proxy arp is disabled by default:
proxy-arp | Junos OS | Juniper Networks<https://www.juniper.net/documentation/us/en/software/junos/multicast-l2/topics/ref/statement/proxy-arp-edit-interfaces.html>

Regarding proxy-arp for EVPN (arp suppression) it only works for the same subnet, not between subnets.

So that seems to match what you're seeing that you must enable proxy-arp on the IRB in order to reach the other subnets.

Regards
Roger


On Wed, Dec 6, 2023 at 5:04?PM Aaron1 via juniper-nsp <juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>> wrote:
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<mailto: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<http://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<mailto:juniper-nsp@puck.nether.net>
> https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net<mailto: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

Help me out a bit...
I've used a lot of proxy-arp and bridging (never at the same time...!)
in the past on bridged consumer services... simple stuff. To evaluate
a proxy-arp config, I'd want the IPs of a sample host and your offnet
host, and routing and ARP tables in addition to the interface config.
Is your offnet host not on in the bridge domain? Am I missing
something obvious?




On Wednesday 13/12/2023 at 9:58 am, "Jackson, William via juniper-nsp"
wrote:
> Hi
>
> This is what I have done, but it doesn’t appear to work.
>
> We have had to send to the clients via DHCP a set of /32 host routes
> to circumvent this problem.
>
> I will open a TAC case and raise with my SE to see whats what.
>
> Thanks for the feedback.
>
> From: Roger Wiklund <roger.wiklund@gmail.com>
> Sent: Friday, December 8, 2023 2:25 PM
> To: Aaron1 <aaron1@gvtc.com>
> Cc: Jackson, William <william.jackson@gibtele.com>;
> juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] proxy-arp on EVPN irb
>
> ** WARNING: This email originates from outside of the organisation **
>
> Hi
>
> It seems that proxy arp is disabled by default:
> proxy-arp | Junos OS | Juniper
> Networks<https://www.juniper.net/documentation/us/en/software/junos/multicast-l2/topics/ref/statement/proxy-arp-edit-interfaces.html>
>
> Regarding proxy-arp for EVPN (arp suppression) it only works for the
> same subnet, not between subnets.
>
> So that seems to match what you're seeing that you must enable
> proxy-arp on the IRB in order to reach the other subnets.
>
> Regards
> Roger
>
>
> On Wed, Dec 6, 2023 at 5:04?PM Aaron1 via juniper-nsp
> <juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>>
> wrote:
> 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<mailto: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<http://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<mailto:juniper-nsp@puck.nether.net>
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> _______________________________________________
> juniper-nsp mailing list
> juniper-nsp@puck.nether.net<mailto: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

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Wed, Dec 13, 2023 at 03:58:00PM +0000, Jackson, William via juniper-nsp wrote:
> We have had to send to the clients via DHCP a set of /32 host routes to circumvent this problem.

If you are able to configure the clients with /32 routes via DHCP, why
don't you just configure the clients with the proper netmask/gateway
via DHCP to begin with. Then you won't need the abomination of
proxy-arp.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp