[j-nsp] static arp with unnumbered-address

Alexander Arseniev arseniev at btinternet.com
Thu Feb 13 07:12:41 EST 2020

So. this whole setup is built for saving 2 IP from each /26, correct?
If You reconsider and decide You can afford to waste 2/64 = 3% of Your 
IPv4 address estate, then on the face of it, looks like perfect use case 
for EVPN with its /32 routes auto-created from ARP.
You can assign multiple 1st IPs from multitude of /26 to each EVPN IRB 
interface with proper /26 netmask instead of tinkering with 
And if You export these /32 into Your iBGP, the /32 will be routed to 
according to usual iBGP rules (local pref|metric etc).

------ Original Message ------
From: "Baldur Norddahl" <baldur at gigabit.dk>
To: "Juniper List" <juniper-nsp at puck.nether.net>
Sent: 13/02/2020 09:50:34
Subject: Re: [j-nsp] static arp with unnumbered-address

>Hi Alex
>Thanks for the reply. Ok I managed to make a bad example. This is actually
>from our running configuration and all the routes are /32 routes. The issue
>is that the customers have all been assigned IPv4 addresses from random
>subnets. The subnets are usually sized /26 and the first address is
>configured on the router loopback interface, such that customers can use it
>as the default gateway using proxy arp.
>The problem is that arp is not working correctly. When selecting the source
>address for ARP requests, the router is picking a random IP address from
>the loopback interface instead of the IP address from the subnet that
>matches what the customer expects. This can be fixed by using:
>family inet {
>         unnumbered-address lo0.1 preferred-source-address a.b.c.1;
>     }
>However this does not fix the issue for customers having multiple IP
>addresses assigned from different subnets. And they are usually using a
>switch to connect multiple devices, so just routing IP address #2 to IP #1
>is no good.
>We come from another platform where this was not a problem. The other
>platform (ZTE) would do the right thing and do ARP using the correct source
>address without us needing to do anything. The IP addresses have been
>assigned and used by the customers for years, so we can not just simply
>change the allocation scheme. It seems Juniper is not truly into a world
>where wasting addresses with old school /30 to a customer that only needs a
>/32 is not working for us poor sods that were not born into plenty of IPv4.
>Since I do not have any hopes for getting a fix for IP source selection for
>ARP, I was thinking about ways to work around the problem. I believe I
>could argue to the customers, that they need to register their MAC address
>with us for each assigned IP. That way the router would not need to do ARP.
>But apparently it is impossible to manually set static arp for interfaces
>that use unnumbered-address.
>Den tor. 13. feb. 2020 kl. 08.30 skrev Alexander Arseniev <
>arseniev at btinternet.com>:
>>  Hello,
>>  Firstly, Your example configuration with static /24 routes and
>>  qualified-NH to IFL does not commit - even after fixing the host portion -
>>  with error message "subnet routes are not allowed with MAC NH".
>>  Secondly, You could have second static resolve via 1st
>>  /32:
>>  set routing-instances internet routing-options static route
>>  qualified-next-hop et-0/0/0.2766
>>  set routing-instances internet routing-options static route
>> next-hop resolve
>>  Thanks
>>  Alex
>>  ------ Original Message ------
>>  From: "Baldur Norddahl" <baldur at gigabit.dk>
>>  To: "Juniper List" <juniper-nsp at puck.nether.net>
>>  Sent: 12/02/2020 23:04:37
>>  Subject: [j-nsp] static arp with unnumbered-address
>>  Hello
>>  How do you program in a static arp entry on an interface that is using
>>  family inet unnumbered-address ?
>>  Eg.:
>>  interface ps1 {
>>  unit 2766 {
>>  proxy-arp restricted;
>>  vlan-tags outer 402 inner 1016;
>>  family inet {
>>  unnumbered-address lo0.1;
>>  }
>>  }
>>  }
>>  routing instance internet routing-options {
>>  interface et-0/0/0.2766;
>>  static {
>>  route {
>>  qualified-next-hop et-0/0/0.2766;
>>  }
>>  route {
>>  qualified-next-hop et-0/0/0.2766;
>>  }
>>  It is not possible to have the juniper router do correct arp in this case.
>>  You can have the range working or you can have the
>> working using preferred source address but not both. So I
>>  figured I could get away with simply hard coding the arp entry. However
>>  static arp is in the family inet address subtree so can not be specified
>>  here. Seriously ?
>>  Regards,
>>  Baldur
>>  _______________________________________________
>>  juniper-nsp mailing list juniper-nsp at puck.nether.net
>juniper-nsp mailing list juniper-nsp at puck.nether.net

More information about the juniper-nsp mailing list