Hi Kristian,
at first: thanks for your feedback. I really like the general idea of
this patch, however:
1) Instead of using the interface index to decide on interface metric, a
table-option is added to interfaces. This way, users are sure which tables will
be used for policy routing and can avoid overlaps. The table-option must be set
for an interface to be 'multi-wan', and all routes belonging to the interface
will be added to this table.
This might be acceptable for IPv4 but is not for IPv6. I see the point
of the table-attribute and don't object to it. However it must not
default to "main" but to something interface-specific. One of the main
points of adding "multi-wan" IPv6-support was to filter IPv6 traffic by
source-address so that it is isn't sent through an interface where the
source-address might be rejected by the upstream router or where it
simply shouldn't go (e.g. in case of ULA-traffic).
2) Routes are added both to the original table (for example main) and the
interface-specific table. This is done to ensure networked applications running
on the node will behave as intended. If routes are only added to the
interface-specific tables, traffic from applications not binding to an interface
will not be routed correctly.
Again I doubt this is a good idea and at least for IPv6 this again
totally defeats the purpose (e.g. source-filtering, see above).
Does a routing policy for each interface table "from lo lookup ..."
(like it was done for IPv6) not cover all locally originating traffic?
If it does not, please provide an example where this isn't sufficient.
So in the current state: NAK from my side.
I could however imagine a compromise here and being in favor for this if
we make the following changes to it:
* Adding an interface-specific default for the interface_table.
* Adding routes to specific tables only (not twice to different tables).
* Adding default routing policies for IPv4 so that each table is looked
up from every source-address by default for backwards
compatibility (also: source-based filtering doesn't make
sense for masquerading NAT)
* If one wants to restrict traffic (e.g. lan-traffic must only go to
wan and not to wan2 or so) he can simply add policy rules
through UCI with a higher priority than the default ones
(e.g. from lan lookup XYZ + from lan unreachable).
Anyway such an intrusive change to IPv4 routing would be needed to be
ACKed by more developers.
Regards,
Steven
PS: Also please avoid unrelated changes (interface_write_resolv_conf) or
unrelated white-space changes in any follow-up patches.
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
