--- Begin Message ---
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" <[email protected]>
To: "Juniper List" <[email protected]>
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 <
[email protected]>:
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" <[email protected]>
To: "Juniper List" <[email protected]>
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 [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
--- End Message ---
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
