[j-nsp] static arp with unnumbered-address

[Alexander Arseniev]

Hello,
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 
unnumbered-address.
And if You export these /32 into Your iBGP, the /32 will be routed to 
according to usual iBGP rules (local pref|metric etc).
Thanks
Alex

------ 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.
>
>Regards,
>
>Baldur
>
>
>
>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  198.51.100.0/24 resolve via 1st
>>  /32:
>>  set routing-instances internet routing-options static route 192.0.2.11/32
>>  qualified-next-hop et-0/0/0.2766
>>  set routing-instances internet routing-options static route
>>  198.51.100.0/24 next-hop 192.0.2.11 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 192.0.2.11/24 {
>>  qualified-next-hop et-0/0/0.2766;
>>  }
>>  route 198.51.100.22/24 {
>>  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 192.0.2.0/24 range working or you can have the
>>  198.51.100.0/24 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
>>https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>>
>_______________________________________________
>juniper-nsp mailing list juniper-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/juniper-nsp