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 <kr...@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@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@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@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@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 <bal...@gigabit.dk> wrote: > >> Den tor. 13. feb. 2020 kl. 13.12 skrev Alexander Arseniev < >> arsen...@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" <bal...@gigabit.dk> >> > To: "Juniper List" <juniper-nsp@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 < >> > >arsen...@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" <bal...@gigabit.dk> >> > >> To: "Juniper List" <juniper-nsp@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@puck.nether.net >> > >>https://puck.nether.net/mailman/listinfo/juniper-nsp >> > >> >> > >> >> > >_______________________________________________ >> > >juniper-nsp mailing list juniper-nsp@puck.nether.net >> > >https://puck.nether.net/mailman/listinfo/juniper-nsp >> > >> > >> _______________________________________________ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp