[j-nsp] static arp with unnumbered-address
Krasimir Avramski
krasi at smartcom.bg
Thu Feb 13 16:53:12 EST 2020
Hello,
The static arp assignments are possible by borrowing the idea from
subscriber management access or access-internal routes (subs management
will do that automatically upon subscriber dhcp binding):
krasi at test# show interfaces ge-0/0/0
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 10 {
vlan-tags outer 402 inner 1016;
family inet {
unnumbered-address lo0.1;
}
}
krasi at test# show routing-instances internet routing-options
access-internal {
route 1.1.1.1/32 {
qualified-next-hop ge-0/0/0.10 {
mac-address 00:11:11:11:11:11;
}
}
}
krasi at test# run show route table internet protocol access-internal
internet.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
1.1.1.1/32 *[Access-internal/12] 00:03:51
> to #0 0.11.11.11.11.11 via ge-0/0/0.10
krasi at test# run show arp no-resolve vpn internet
MAC Address Address Interface Flags
00:11:11:11:11:11 1.1.1.1 ge-0/0/0.10 permanent
HTH,
Krasi
On Thu, 13 Feb 2020 at 15:09, Baldur Norddahl <baldur at gigabit.dk> wrote:
> 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
> >
> >
> _______________________________________________
> 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