Most networks need one route: everything that is not local goes to the provider. The tool creates that default route from your uplink. You only need an extra route when a network exists that is reachable somewhere else: behind a second router in your own rack, on the far side of a tunnel, or on a management LAN that arrives on a separate port.
Where it lives
Static routes sit under WAN / internet, in the Static routes group. That is deliberate: they belong with the uplink and with failover, not with dynamic routing. In the wizard you meet them in the Core router role, in the step "Uplink and static routes". In advanced mode they are at the bottom of the WAN block.
Policy routing sits further down, in the Routing (OSPF, BGP, policy) section, in the Policy routing group. That section is off by default and you switch it on yourself.
An extra route
Each row asks for three things:
- Destination
- The network the route is about, with a prefix:
10.0.0.0/8,192.168.50.0/24. A single address is written as/32. - Gateway
- The address of the router that knows that network. It has to be directly reachable from this router, so it must sit in a subnet this router has an address in. A gateway two hops away does not work.
- Distance
- Default 1. The lower the number, the more RouterOS prefers this route. Two routes to the same destination with different distances give you a backup: the one with distance 1 is used, and if it disappears the one with distance 20 takes over.
The comment field is optional, but in a year you will be glad you wrote down where that route went.
What gets generated
Each row becomes one /ip route add with dst-address, gateway, distance and your comment. Nothing more. You can check the result on the device with /ip route print; a route without the active flag means the gateway cannot be reached.
Routing tables and rules
Sometimes you do not want a destination treated differently, you want a source to take another exit. The guest network has to go over the second uplink, say, or one server always has to go through the tunnel. For that you need a separate routing table plus a rule saying who uses it.
In the Extra routing tables list, each row holds:
- The name of the table, for example
via-vpn. - Default gateway in this table: where all traffic in this table goes.
- Rule: source network using this table, optional. Fill it in and the tool writes the matching routing rule as well.
The generator writes /routing table add fib=yes name=… first, then /ip route add dst-address=0.0.0.0/0 gateway=… routing-table=…, and only after that /routing rule add src-address=… action=lookup-only-in-table table=…. That order is not a matter of taste. In RouterOS v7 a routing table is an object that has to exist before a route may refer to it; the other way round the command is refused.
What this does not cover
The action in the rule is lookup-only-in-table. That means exactly what it says: traffic from that source network uses only that table. If the gateway in the table goes away, the traffic does not fall back to the ordinary routes, it stops. If you want a fallback, that is hand work in /routing rule on the device.
Beyond that, the tool puts one default route in each table, not individual routes inside it. And the rule can only match on a source network, not on destination, interface or port. If you need that, set the base up with the tool and add the rest by hand afterwards.
Tables you do not create yourself
If you pick load balancing with PCC for several uplinks, the tool creates the tables to_wan1 and to_wan2 itself, with mangle rules that spread connections over them. You do not have to fill anything in under Policy routing for that. See Several uplinks.
From v6 to v7
This is the part that changed most between RouterOS v6 and v7. A routing mark has become a table. When you import a v6 export the tool handles it: it collects every mark from /ip route, /ip firewall mangle and the old /ip route rule, turns them into /routing table lines at the top of the script, rewrites routing-mark= to routing-table= and moves /ip route rule to /routing rule. The report names the tables it made. See From RouterOS v6 to v7.
When it does not work
- The route is there but not active. The gateway is unreachable. Check with
/pingthat the address answers and that it sits in a subnet this router has. - One direction works, the other does not. The router on the far side has no route back to your network. Routes always come in pairs.
- Traffic leaves but arrives nowhere. Check whether NAT is applied that you did not intend. Traffic between your own networks should not be masqueraded.
- The rule does nothing. Rules are walked in order. If an earlier rule already matches, yours never gets a turn:
/routing rule print.
Read on
WAN and internet for the default route itself, Several uplinks for failover and load balancing, and OSPF if you would rather stop maintaining routes by hand.