I'm trying to create a simple config at a datacenter where I am allocated a single "main" IP with a default GW on the same subnet. All is fine. Then I requested for an additional subnet which is statically routed to this main IP. It's from a different, arbitrary subnet.

This setup is virtualised, with the main IP configured on the physical server (host). If I add an address from this subnet to the host, it's working without problems. If I add an IP from this subnet to a Debian Linux 7 VM, it's again working fine. The eth0 interface of the VM is bridged with the real eth0 interface of the host machine.

I replicated this configuration in a Mikrotik VM, the setup is basically the same, with ether1 bridged. But it refuses to work. Whatever I do, the Mikrotik VM refuses to use the default gateway, claiming that it's "unreachable", despite I can ping/traceroute it just fine. I'm concluding my findings below with the setups I tried. I'm using Virtio network adapters in all cases on the VMs.

Any help is greatly appreciated.

78.y.y.128/27 - subnet of main IP
78.y.y.132 - main IP
78.y.y.129 - gateway for main IP

88.x.x.178/29 - allocated extra subnet

On the Linux VM:
On the Mikrotik VM:

Static routes always try to resolve through directly connected routes (scope=10)

You should either lower Scope for .128/27 or increase Target Scope for .129, as the "hop" for the default gateway is not directly connected:

Either this (make .128/27 as if it were directly connected) or this (Increase nexthop resolving recursivity)
You may want to have a look at http://wiki.mikrotik.com/wiki/Manual:Us ... attributes for further details.

Thanks, pukkita, I'll try this tomorrow and report back.

Well, I have tried your suggestions, but neither of them is working on RouterOS. I can't make it work, whatever I try. I even enabled proxy arp on the host so the upstream gw appears as directly connected IP, to no avail. If the ROS doesn't have an IP from the same subnet as the gateway, it doesn't work - gateway is shown unreachable and not used. I can ping the gateway IP from ROS without problems. I don't get it.

Well, I solved this, kind of.
ROS automatically adds a host route for 78.y.y.132 (main ip of the host machine, outside of the routed /29 subnet) on ether2 and I can use it as gateway for the /29 extra subnet just fine. Found the solution in another thread for a similar problem. The same method works exactly the same in a Linux OS, but I need to add the host route for the gateway manually. It requires adding some extra config to the Debian interfaces file, but oh well.

I think the way you're trying to do it doesn't work for the following reasons:

You're configuring a route that points to an interface instead of a next-hop ip address, on PtP based networks (for instance PPP or PPPoE) this doesn't matter since the connection will always have 1 single possible L2 destination (which is the remote end) but on a broadcast segment such as ethernet, how does the router know to whom it should send the frame?

Remember we've got L2 addresses and L3 addresses, the first ones tell the router where to point on the physical medium.

This is what is happening:

1.- Router receives a frame to a destination it doesn't know, so It uses the gateway of last resort (0.0.0.0)
2.- This route tells the router that it should send the packet to 78.y.y.129
3.- The router will try to find a route that matches the IP 78.y.y.129, if the scope is properly set on this case, It'll find it and point to ETHER1.
4.- Here's where the problem starts, ethernet is a BROADCAST segment, which means multiple hosts can exist on it, even if you're using a VLAN and "emulating" a PtP link (by means of only connecting 2 hosts to it), it'll still be a broadcast segment, in order to send the packet to 78.y.y.129 it has to know first what's its L2 (MAC) address, so It'll need to use ARP.
5.- The interface doesn't have IP addresses that belongs to the network the ARP is going to be targeted, so it shouldn't not use ARP because of this (the actuall RouterOS logic to handle this is unknown to me so maybe this is handled a bit different but I think it uses this principle).
6.- This is why by modifying the network parameters in the IP address assignation this works, since you're now including all the network segments you're using and it can properly use arp.

If RouterOS logic functions differently and someone could clarify or confirm this (maybe I'm wrong) would be nice, but I'm quite sure this is the way.

You could add an IP address within the same network segment that 78.y.y.129 to ether1 while keeping the other addresses and It should fix the issue.

Shaoranrch, thanks for the extensive answer. Your explanation is of course, logical, and I'm aware of the basics of IP resolution within L2 broadcast domains, but at a point it seems to contradict my findings where I said I could just ping the gateway IP just fine, yet ROS refused to use it.

OTOH, I solved the problem using another, somewhat counter-intuitive way, please see my previous post. That kind of solution perfectly aligns with how the bare Linux solution works. ROS inside is Linux, too, though I remember reading from a Mikrotik support engineer that they've rewritten the routing engine inside ROS. I have my faint doubts about this, since Linux routing is rooted deep in the Linux kernel, in development for about 20 years and re-implementing such things is no small feat by any means.

I still have same proble. static route to gateway ist active but I can't ping anything

Well, I solved this, kind of.

Code: Select all

/ip address
add address=88.x.x.177 interface=ether2 network=78.y.y.132

/ip route
add gateway=78.y.y.132

ROS automatically adds a host route for 78.y.y.132 (main ip of the host machine, outside of the routed /29 subnet) on ether2 and I can use it as gateway for the /29 extra subnet just fine. Found the solution in another thread for a similar problem. The same method works exactly the same in a Linux OS, but I need to add the host route for the gateway manually. It requires adding some extra config to the Debian interfaces file, but oh well.