[j-nsp] static arp with unnumbered-address
Baldur Norddahl
baldur at gigabit.dk
Thu Feb 13 08:08:06 EST 2020
Den tor. 13. feb. 2020 kl. 13.12 skrev Alexander Arseniev <
arseniev at btinternet.com>:
> Hello,
> So. this whole setup is built for saving 2 IP from each /26, correct?
>
No the purpose is to avoid needing to use a /30 minimum per customer. Lets
say we have subnet 192.0.2.0/26:
192.0.2.0 network - unusable
192.0.2.1 default gateway for customers
192.0.2.2 customer1 unit 10 vlan 10
192.0.2.3 customer2 unit 11 vlan 11
192.0.2.4 customer3 unit 12 vlan 12
etc
192.0.2.63 broadcast - unusable
So each customer is on a different vlan also called the customer vlan
(CVLAN) model (actual deployment uses q-in-q). We use /32 routes to each
customer, however the customer believes he is part of a /26. This is so
multiple customers can share the same gateway IP address.
The IP waste is related to the size of the subnet. In this case we choose a
/26 which means we lose 3 IPs out of 64. The alternative without using
unnumbered address would look like this:
192.0.2.0 network IP unit 10 vlan 10
192.0.2.1 gateway unit 10 vlan 10
192.0.2.2 customer1 unit 10 vlan 10
192.0.2.3 broadcast unit 10 vlan 10
192.0.2.4 network unit 11 vlan 11
192.0.2.5 gateway unit 11 vlan 11
192.0.2.6 customer2 unit 11 vlan 11
192.0.2.7 broadcast unit 11 vlan 11
etc
Each customer would then live inside his very own /30 and done like that it
would probably just work. Nobody wants to do it like that anymore. The
waste is 75%.
Regards,
Baldur
> 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
>
>
More information about the juniper-nsp
mailing list