I would like to see a feature in /routing/tables, where there would be a checkmark for a table “add connected routes”.
When set, it would add the interface connected routes (that are in table main) also to this table.
I think that would solve a lot of the issues that people now encounter with the changed route mark behavior. A packet with a route mark would still be able to be locally routed, because local connections appear in that table (when you wish).
Do others agree that this would be a welcome addition?
I would like to start with clarification about current state, all the things that were changed and how, what’s intended behaviour (because at least something may not be), etc.
Adding connected routes to other routing tables sounds possibly useful, but I’m not sure how it would interact e.g. with VRF where there are also connected routes, but in other than main routing table. So if it should be only for connected routes in main routing table, or also for others. It’s complex stuff, I can’t say that I understand all details.
Thanks for confirming this. I am back to 7.2rc6 due to a problem with IPTV streams breaking and now that gives problems.
Update:
Found the cause why the IPTV steams where breaking up. It was quite a search and even WireGuard did not give away why. Using torch I noticed that traffic was returning that had as destination the VPN gateway. That traffic intermingled with the IPTV traffic and changed the destination address.
The traffic that caused it where pings to test if the connection was still open and those where generated on the router itself. As soon as I deactivated ping the IPTV stream was rock solid again.
I am using a lookup only routing for IPTV traffic and the ping uses the same table. Strange that parallel traffic has this effect on traffic that has a different destination address.
Has anyone a clue how this can be avoided without disabling the pings I use?
addition: the destination address (traffic returning) is in the same /24 range as the VPN gateway. This way I don’t have to use NAT for this traffic. It could be that the VPN provider prefers to return traffic to the gateway when things are not clear to them.
When you use VRF this option would of course not be chosen.
Please make a documentation page that describes exactly how the route marking, routing rules and VRF operate together, including all priorities and possibilities to mix them (or things you cannot mix).
In our network, the use of VRF often results in transmissions from router with wrong source address (traffic to tunnels with outside address as source), and I want to know exactly what can be done and what not.
Today I have received promising reply to my SUP-81294:
Hi,
The issue is still unresolved that could cause this, we are working on possible fixes. I cannot give you any specific ETD for this, unfortunately.
Best regards,
Oskars K.
So it seems that this undocumented routing priority changes they understand as an “issue” I stay on 7.2.1 or 6.49.5 and waiting…
So now it sounds like an intention from your side. Then I do not undestand why this major change was not documented in fw 7.2.2/7.2.3 change log (?) and why you cannot provide step-by-step help what to change in related config of i.e. dualwan scenario to be working again?
With current version, if you don’t want something use another routing table, then don’t mark routing for it. So e.g. if problem is access to router like in this example, then add dst-address-type=!local to first two rules.
Could you show me some screenshot? I have no Dst Address Type option there under ip/route. Maybe is not available on 7.2.1? (I am trying to add this option first before the upgrade now)
Was referring to the mangle rules in the reply from sob (in the linked post):
Sob wrote: With current version, if you don’t want something use another routing table, then don’t mark routing for it. So e.g. if problem is access to router like in > this example> , then add dst-address-type=!local to first two rules.
Because in this release, the routing-mark assigned by a mangle rule cannot be superseded using a routing rule. So the rules are not “nonworking” per se, it’s just that their purpose was to supersede the verdict of the mangle rules and they can’t do that any more.
We’d have to see the configuration export to say how exactly the mangle rules need to be modified to gain the same effect you currently obtain by overriding them using routing rules.
I have a static routing and related routing rules to reach directly (not via internet) some public IPs assigned to local devices or other routers in our network but also some sort of local subnets and device IPs to reach localy…all of them does not work. As I mentioned above, if developers do silently this major change, I would expect BIG warning and step by step manual what need to be check and change in the configuration to meet this new router behaviour. Now it seems that they will provide some option to switch router to the previous standard behaviour.
As mentioned before, I hope the actual behavior will be well-documented. It does not matter that much what it exactly is, as long as we know what it is without blindly trying.
(this is about routing rules, routing marks, and also VRF)
I stay on 7.2.1 or 6.49.5 and waiting…