Here is my configuration. I am learning routes from gre/ipsec tunnels via OSPF but cannot reach them. Please help me out. I have PCC with port forwarding configured.
It seems you didn’t get what @mbaute wanted to say, so I’ll try to re-word it.
The routes learned through OSPF are added to routing table called main, which is used to route packets without any routing-mark assigned. Those rules @mbaute has shown were your own rules from the export, and the suggestion was not to replace your original ones by them (as they are the same), but to modify these rules to prevent them from matching the traffic which should use the routes learned through OSPF, so that these packets would be routed using the routing table main (or to add a rule before them which will assign some other connection-mark value to this traffic, so that the rules translating connection-markabspl_conn to routing-markto_sswl would ignore them). Something like
placed before that set of rules. You have to populate the address-list ospf-destinations with the correct list of subnets. If the OSPF destinations consist of just a few prefixes, use of /ip route rule rows to revert the routing-mark assignment may be more efficient.
Other than that:
dst-address-type=local matches only on own addresses of the router itself, not on addresses in all subnets to which these own addresses belong. Someone has misunderstood this years ago, and since then people keep copy-pasting that blindly from each other.
there is no point in assigning a connection-mark to each packet and then translate it to routing-mark using another rule. The very point of connection-mark is to mark the whole connection while handling its initial packet, and then just do the connection-mark → routing-mark translation for the rest of that connection’s packets. If done properly, this will reduce the number of rules matched against every single packet, so your CPU will become a bit colder.
Sharing particular rules makes little sense for “many other”, as everyone’s environment is a little bit different (yours is far from usual as an example, and I don’t have in mind just using country=taiwan in wireless settings of a device operated in India). So it is critical that people understand the principle, otherwise they would blindly copy-paste those rules and be surprised that the magic wouldn’t happen.
In your particular case, you assign some connection-mark values to guarantee that incoming connections via WAN and ether2 will be responded via these interfaces, so these action=mark-connection rules may stay as they are.
To both your existing PCC rules, you have to add connection-state=new dst-address-list=!ospf-destinations. This will cause the specific connection-mark value to be assigned only once, when handling the initial packet of each connection, and only if the destination is not one of those learned through OSPF. So it will exempt the connections towards destinations reachable via OSPF from the PCC distribution, as they will stay without any connection-mark, and so their packets will not get any routing-mark, and so they will be routed using routing table main which contains the routes learned via OSPF.
Since no embedded match condition like dst-address-type=accessible-through-dynamic-route is available, you have to use the address-list named ospf-destinations and populate it on your own, according to the actual address plan of your network. Maybe it is enough that it consists of all three RFC1918 private address ranges, but maybe some private ranges are accessible via WAN or ether2 or, vice versa, some public ranges are accessible via OSPF. Only you know that.
Since no embedded match condition like dst-address-type=accessible-through-dynamic-route is available, you have to use the address-list named ospf-destinations and populate it on your own, according to the actual address plan of your network. Maybe it is enough that it consists of all three RFC1918 private address ranges, but maybe some private ranges are accessible via WAN or ether2 or, vice versa, some public ranges are accessible via OSPF. Only you know that.
[/quote]
Thanks for your explanation. I got it! I actually didn’t want to manually create a list using OSPF! was looking for a way to avoid that manual address list creation.
Damn! I wish I had your ability to explain things, awesome
Thanks for your explanation. I got it! I actually didn’t want to manually create a list using OSPF! was looking for a way to avoid that manual address list creation.
[/quote]
to automate that address list you can use something like
:do {
:foreach i in=[/ip route find ospf] do={
:local network [/ip route get $i dst-address];
/ip firewall address-list remove [/ip firewall address-list find where timeout=00:00:00];
/ip fire addr add list=OSPF address=$network timeout=00:01:00;
}
:delay 60s;
} while=(true)
and keep it up with another script that checks if it’s running, like of php supervisor
Thank you, but the thing here is that you’ve understood it already before reading my explanation; the true measure of that ability is the number of people who didn’t before and do after. And here I sometimes question myself
I gave a thought to this too, but I was somehow assuming that either there are just a few subnets accessible via OSPF and not accessible via the two WANs and vice versa, hence the scripting would be an overkill, or those subnets accesible via the GRE tunnels are accessible via the two WANs too but access via the GRE tunnels is preferred, and in such case the lag between learning the route via OSPF and adding the destination to the address-list would let some connections take the suboptimal route.
And then there is e.g. the issue of an error if you attempt to add a duplicate item to an address-list (I expect multiple OSPF routes to the same distance to be learned, with different distance values), so writing and debugging a script capable of handling all such exceptions may quickly turn more complex than creating the address-list just once manually.
Another thing - for a reason I don’t understand, when the timeout of a dynamically added address-list item expires, the item stays accessible to scripting for five more seconds, indicating a timeout of 0:0:0. Do you happen to know the idea behind that?
to automate that address list you can use something like
:do {
:foreach i in=[/ip route find ospf] do={
:local network [/ip route get $i dst-address];
/ip firewall address-list remove [/ip firewall address-list find where timeout=00:00:00];
/ip fire addr add list=OSPF address=$network timeout=00:01:00;
}
:delay 60s;
} while=(true)
>
> and keep it up with another script that checks if it's running, like of php supervisor
>
> Regards,
Hello if you don't mind can you modify the script so that it adds connected routes also to the address list. I think that will solve my issue. I mean both ospf and connected routes will be added to a single address list.
UPDATE: I have finally been able to manage it. Now I can use PCC load balancing while accessing the gre tunnel networks. Now waiting for Mikrotik to FIX port flapping issue on my RB3011 with 6.48 release. I added two mangle rule: 1 to mark new connections with destination address list ospf as vpn_conn and then to make those marked connections to use main routing table. Also in the PCC rule I have used != vpn_conn in connection mark so that those are excluded from PCC.
Yes totally! adding wan interfaces to the mix would break things apart. unless the wan used is also a default, primary, no mangled gateway, you are screwed!
In my previous job I used this to exclude in my router ospf domain with family routers from networks reachable through work’s vpn. There were no redundancy whatsoever, just ptp links in a single area to reach family devices for assistance, but merely just for fun and lazyness managing routes lol
Another thing - for a reason I don’t understand, when the timeout of a dynamically added address-list item expires, the item stays accessible to scripting for five more seconds, indicating a timeout of 0:0:0. Do you happen to know the idea behind that?
this is a classic mikrotik’s “deal with it and move along”, learn through frustration to include
in every script involving lists :c . A couple of years ago they just didn’t expire unless you rebooted the router or manually deleted them but hey, 5sec is an improvement
Maybe you should exclude your LAN networks with another static list and prerouting rule, remember that your other networks with address in /ip address are also connected, including WAN and ppp ones.
Maybe you should exclude your LAN networks with another static list and prerouting rule, remember that your other networks with address in /ip address are also connected, including WAN and ppp ones.
[/quote]
yes did that only! created another addresslistfor connected routes and marked the connection with the same markings of vpn_conn
