[j-nsp] static arp with unnumbered-address
Baldur Norddahl
baldur at gigabit.dk
Fri Feb 14 09:13:49 EST 2020
Hi Krasimir
Exactly what I was looking for. Thanks. Will try it as soon as possible.
Regards
Baldur
tor. 13. feb. 2020 22.53 skrev Krasimir Avramski <krasi at smartcom.bg>:
> 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