Point-to-point (/31) addresses

Has anyone got this working yet between an MT and a Cisco using OSPF as the IGP?

I can get both sides to ping using the /31 subnet mask and even get an adjacency formed but it doesn’t seem to want to exchange routes.

Eric

Not I.

For MT-MT, I use /32s, and rejoice that the vast majority of my network is extremely efficient address-use wise.
For Cisco-Cisco, /31s work great, and are only slightly depressing.
For MT-Cisco, /30s seems to be the longest common netmask that works properly with OSPF, so I go with it, and mourn the lost utility.

–Eric

In a mikrotik-only network like the one eflanery showed:

Does OSPF and MPLS LDP works well?

I can’t think of a reason why it wouldn’t work right. Of course with /31 or /32 route’s might require a different configuration than /30 subnets.
I’m pretty pleased MikroTik has added more flexible support/functionality. Their artificial software limitations used to be pretty close to ridicules.

For MT-Cisco i have done following config

cisco:
router ospf 1
log-adjacency-changes
area 172.16.0.1 stub no-summary
network 10.10.0.0 0.0.0.255 area 0.0.0.0
network 172.16.0.0 0.0.0.1 area 172.16.0.1
interface FastEthernet0/1
ip address 172.16.0.0 255.255.255.254
ip ospf network point-to-point
duplex auto
speed auto
end

MT:
[admin@MikroTik] >/ip address export compact

jan/02/1970 04:17:14 by RouterOS 5.24

software id = UR1Z-MBDA

/ip address
add address=192.168.88.1/24 comment="default configuration" interface=eth2
add address=172.16.0.1/32 interface=ether1-gateway network=31.193.120.160
....

[admin@MikroTik] > routing ospf export compact

/routing ospf area
add area-id=172.16.0.1 default-cost=1 inject-summary-lsas=yes name=172.16.0.1
type=stub
/routing ospf instance
set [ find default=yes ] name=172.16.0.1 router-id=172.16.0.1
/routing ospf interface
add interface=ether1-gateway network-type=point-to-point
/routing ospf network
add area=172.16.0.1

OSPF adjacency FULL and traffic going well!!
Router#sh ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
172.16.0.1 0 FULL/ - 00:00:31 172.16.0.1 FastEthernet0/1


and

[admin@MikroTik] > ip route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit

DST-ADDRESS PREF-SRC GATEWAY DISTANCE

0 ADo 0.0.0.0/0 172.16.0.0 110
1 ADo 172.16.0.0/31 172.16.0.0 110
2 ADC 172.16.0.0/32 172.16.0.1 ether1-gateway 0
3 ADC 192.168.88.0/24 192.168.88.1 bridge-local 0




PS
in Cisco log apper following
%OSPF-4-CONFLICTING_LSAID: Process 1 area 0.0.0.0: LSA origination prevented by LSA with same LSID but a different mask
Existing Type 3 LSA: LSID 172.16.0.0/31
New Destination: 172.16.0.0/32

Is this usable in production networks?
Where’s the catch?

BR,
M

Using it in my production network without problems.
Of course, Only Mikrotik supports this. That’s the only limitation

Is this usable in production networks?
Where’s the catch?

BR,
M

Does this tweak work with OSPF?

Yes, it works great with simple OSPF and LDP; but TE doesn’t seem to work correctly with it, so we are moving away from it (sadly).

PtMP mode for OSPF seems to be by far the most stable with a configuration like this.

–Eric

What kind of problems you have with TE?

The problem wasn’t so much directly with TE and /32 addressing, as it was with PtMP mode and CSPF.

For some reason, CSPF would never find a path through a PtMP segment, and broadcast or NBMA modes were less stable with /32 addressing.

It’s been quite a while since I played with that though (early to mid 5.x), so things may have changed.

–Eric

If the subnet is /31 would you not need to use:

10.10.10.1/31 and 10.10.10.2/31

I have run into this because only two addresses are allowed it will expect the equal amount of Ips in the subnet 10.10.10.3/31 would belong with 10.10.10.4/31

No, you need to stick to VLSM boundaries for /31s…

So, 10.10.10.0/31 pairs only with 10.10.10.1/31; 10.10.10.2/31 pairs only with 10.10.10.3/31; and 10.10.10.4/31 pairs only with 10.10.10.5/31.

That is, of course, if they will work for your situation. Usefulness of /31s is limited on MT.

Yes that’s what i’m saying. The OP’s example IPs were not in same subnet!

Routing a /32 via another /32 has been used for years in Telco DSL networks on a multitude of vendor equipment like Cisco, Adtran, etc…

It’s a very popular network design when using a PPPoE BRAS

Great.
But why isn’t more used with Mikrotik. It’s great IP saver. There’s no examples with this kind of IP addressing.

The technique that is being referred to in earlier posts really uses routing via interface rather than via a specific gateway IP. The method described causes RouterOS to place connected routes in the routing table for the remote IPs but a very similar arrangement with static routes can be achieved as follows:

Make an ARP capable layer 2 network available between 2 RouterOS devices - it can be an Ethernet, VLAN or whatever you can arrange.
Place a /32 IP number “IP A” on Router A.
Place a /32 IP number “IP B” on Router B.
Now add a route on Router A with IP B as the destination and the interface connecting Router A to Router B as the gateway.
Now add a route on Router B with IP A as the destination and the interface connecting Router B to Router A as the gateway.

Router A should now be able to ping Router B on IP B and vice versa should also work. IP A and IP B do not need to be IP numbers remotely close together. This approach works on plenty of routing engines from many suppliers.

It simply forces the routing engine to ARP for the destination IP on the relevant interface.

I tried the above but am running into an odd problem. Here is my config:

Router A

/ip address add address=172.16.0.1/32 network=172.16.0.1 interface=eoip-tunnel1
/ip address add address=10.0.0.1/24 network=10.0.0.0 interface=bridge-local
/ip route add dst-address=172.16.0.2/32 gateway=eoip-tunnel1
/ip route add dst-address=10.0.1.0/24 gateway=172.16.0.2

Router B

/ip address add address=172.16.0.2/32 network=172.16.0.2 interface=eoip-tunnel1
/ip address add address=10.0.1.1/24 network=10.0.1.0 interface=bridge-local
/ip route add dst-address=172.16.0.1/32 gateway=eoip-tunnel1
/ip route add dst-address=10.0.0.0/24 gateway=172.16.0.1

Anyone see anything wrong with this? I can ping the 172.16 addresses from both sides and it works fine, but the 10.0 addresses don’t work. I have tried to use gateway=eoip-tunnel1 for the 10.0 routes also, but that doesn’t work. Either way I set that up it says the network is unreachable.

How do I get it to route other networks (e.g. my 10.0.) over my EoIP tunnel with /32 addresses?

Also… I had them as /30s before and routing to 172.16… worked just fine, so there is something wrong with how I have the /32 set up.

-Eric

I think you are hitting a restriction on next hops not being resolvable via interface routes. I’m not sure what your overall aim is so not sure of best solution, however as a technical point note that if you make both the 10.x.x.x routes interface routes - i.e. set the EoIP tunnel interface as the gateway - and enable proxy-arp at both ends of the EoIP tunnel then you should be able to ping the 10.x.x.x addresses fine in both direction.

What I am trying to do is utilize a /32 for the end points for EoIP tunnels. I have three different routers at three different sites. My goal is to have each one have an address 172.16.0.1-3/32 and then setup EoIP tunnel (A-B, B-C, and A-C) such that A=172.16.0.1, B=172.16.0.2, and C=172.16.0.3. Each router also has its own private range A=10.0.0.0/24, B=10.0.1.0/24, and C=10.0.2.0/24. I would like to setup routes for each of these networks so that they are all routed through the EoIP tunnels with the /32 addresses.

What would you suggest is the best way to do it? Thanks.

-Eric