Hi all,
We are getting more and more ip addresses allocated that use a /31 subnet.
This is now an accepted practice and the other main players accept the /31 subnet.
If you try to use a /31 subnet on a Mikrotik Router though it will fail.
It will accept you putting in the ip addresses but when you put in the gateway address you will notice it will say unreachable and won’t work.
Obviously the reason that the ISP’s are giving out these addresses is to limit the number of IP Addresses required.
So it would be nice to see the /31 subnetting working in a Mikrotik.
Works in Cisco, Juniper etc…
Maybe you do not need to use /31 address at all. You can put /32 address to your interface and gateway address to network address field:
add address=192.168.1.111/32 interface=ether6 network=192.168.1.1
Try it.
While this does ‘work’, this is not the right solution. The routing table then contains 1 or 2 /32’s instead of a /31. At best you are doubling the number of PtP routes you need to carry; at worst, your routing table is missing routes. This also does not vendor-interoperate well.
Please just implement RFC3021 support…
http://www.faqs.org/rfcs/rfc3021.html
http://packetlife.net/blog/2008/jun/18/using-31-bit-subnets-on-point-point-links/
Put /32 on interface, static route the “other” IP /32 with gateway=interface.
Eg, 192.0.2.176/31 = isp, 192.0.2.177/31 = you.
Try this:
/ip address add address=192.0.2.177/32 interface=ether1
/ip route add dst=192.0.2.176/32 gateway=ether1
/ip route add dst=0.0.0.0/0 gateway=192.0.2.176
Of course - natural support for a common-practice RFC is better than a workaround, all day long and twice on Sunday.
Implementing RFC3021 is long overdue.
I for one simply do not use the Mikrotik /32 method because IP designs should avoid depending on proprietary features when a perfectly good RFC is available, suitable and supported by multiple vendors.
I second the feature request and would add that any mention to the /32 hack, as beeing against RFCs and proprietary to mikrotik’s software, should be considered harmful and explicitely mentionned as discouraged in the documentation.
+1
+1
Sure. You are all right. Just to mention, I am using it and do not see any problems with it. There is no better and working option so far.
I do not understand why someone (NicolBolas) who did not helped here to anyone (http://forum.mikrotik.com/memberlist.php?mode=viewprofile&u=72512) gave me -3 points with this justification:
That’s no solution, merely a dangerous hack and an excuse for Mikrotik not to implement the RFC.
I just wanted to help with bypassing problem, and not to justify something that is not aligned in ros according to someones opinion. I am not responsible for ros and I am not justifying anything in it. I am just a user willing to share experience.
And I have good eperience with /32.
+1
32-bit prefix is not Mikrotik proprietary and is not against RFC and definitely is NOT harmful.
Hmm, mrz, ok, 32 bit prefix is not Mikrotik proprietary and not against RFC.
But still, /31 is useful to have to use on a PtP link to conserve IP addresses in the IP space.
Some ISPs I have seen also assign /31 addresses.
Also, a /31 also reduces routing table size which is nice when using any routing protocols, rather than 2 /32 addresses on the routing table, there’s a single /31 in lieu.
So +2 in my opinion.
Needed +1
/31 actually works on Mikrotik if the Mikrotik is the odd-numbered host.
I tested it in RoS v6.28 with a Cisco router as the even-numbered host, and it works great. OSPF forms adjacency just as it should.
If the Mikrotik is the “network” end, though, it does’t work. For that end, you can use /32 as the local address, and set a static route /31 with gateway=etherX interface to put the route into the table. (it won’t enter OSPF properly this way, of course)
The actual reason I replied, though, is because there’s a way that gives double this amount of IP savings for customer attachment circuit assignments.
1: Black hole route some master network prefix, e.g. 192.0.2.0/24 → black hole
2: Put 192.0.2.1/32 and 192.0.2.255/32 as IP addresses on a “loopback” bridge interface on ALL routers.
3: Set arp-type=proxy-arp on all interfaces that should participate in this /24.
4: Use normal /30 addresses on active OSPF interfaces - private IP if you want to really squeeze things.
5: For each connected customer, create a /32 route with gateway=etherX interface (or vlanX - whatever interface is the customer’s unique interface) and pref-source=192.0.2.1
Note that each router has an anycasted copy of the .1 and .255 addresses, so “broadcast” traffic doesn’t get shot all over your network, and pings to the default GW by your customers will be answered by their actual default GW router.
*EDIT: The above works, but Mikrotik has a slightly simpler way to achieve the same thing. Instead of a black hole route for 192.0.2.1/32, you assign each customer’s interface IP as 192.0.2.1/32 and set network=192.0.2.X (where X is the customer’s single IP). You do not need the /32 static route with gateway=etherX/vlanX. This /32 IP address method will create a normal “connected” route for the customer’s /32 address automatically, and OSPF will detect it as a natural route, thus it won’t need to be redistributed into OSPF. You still need to have arp=proxy-arp so that the customer can communicate with the other members of the /24 block.
We called this solution “secret sauce” at the job where I implemented this, and it has many benefits:
It creates no additional entries in the route table as compared with a /31 scheme - but it lets you pack a whopping 253 customers per /24.
Each customer is on their own private layer2 broadcast domain, so there’s no way for the customers to attack each other’s WAN interfaces with broadcast things like netcut, rogue dhcp, rogue RA (ipv6 equivalent), etc. In fact, IPv6 can be assigned with whatever mechanism you choose to use (/127, /64, link-local-only, etc)
You can assign addresses from this range on any router you choose. (although, keeping them in aggregated clumps is smart for many reasons)
The customer cannot arbitrarily configure any address from the /24 - only the one you created the /32 route for will work.
If the customer wants additional IP addresses, you can route them exactly as many as needed without wasting any on subnets. (add additional IPs to the circuit with more /32 routes to the interface or else route additional addresses using the existing /32 as the next hop)
Now the only wasted address space on P2P links is on your own infrastructure’s core links - and there are vastly fewer of these so the lack of /31 shouldn’t hurt so much if you use “secret sauce” on your attachment circuits.
It seems that feature was added in some 6.x release:
[admin@MikroTik] > /ip address export
# dec/04/2015 15:46:44 by RouterOS 6.29.1
# software id = RS8Z-V97X
#
/ip address
add address=192.168.88.1/24 comment="default configuration" interface=\
ether2-master-local network=192.168.88.0
add address=10.10.0.95/24 interface=ether1-gateway network=10.10.0.0
add address=172.16.240.1/31 interface=tun1 network=172.16.240.0
add address=172.16.240.255 interface=lo0 network=172.16.240.255
+1
All hacks are not working with BGP.
IP address assigned by ISP end up with .255/31, I’m getting BGP routes - but marked as inactive.
Solution?
I am using the /32 PtP route workarounds listed above to get my ISP-assigned /31 WAN working. However, L2TP does not work due to the missing WAN/31 route.
So there are good reasons to properly support /31 routes in RouterOS, as these missing routes break any services that rely on routes to work (BGP, L2TP, probably IPsec too)
- 1
We really need this since we are low on IPV4 and use a lot of /32
If you are low on IPv4 addresses then by using /32 you can save more addresses than by switching to /31