Hello Don,
short answer to the question in the subject: You can't. :-)
Am 07.02.2023 um 04:36 schrieb Don Brown via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx>:
There is a default route using the gateway that is for CMN04 ETHLINE but this does not have a preferred interface set and I can't take it down at the moment to test changing that.
I want a default route for this new interface subnet I have created but from my reading the IBMi has routes at a system level not an interface level.
Stock IP stacks can't cope with more than one (default) route with otherwise identical properties (Destination IP and Netmask, and metric). The IP stack just decides on Layer 3 *destination* — bare packets with their IP address — and has no clue about higher layers, such as sessions, or who initiated a connection. Thought experiment: How would you expect the condition "Packet should go out to destination x, but there is more than one path to the destination" to be handled?
It is supported to add more than one given routing entry *with a different metric*. Usually the first entry in the routing table (implicitly sorted by metric) is used. There is no operational difference between a default route or more specific routes. If an interface goes down, the associated route(s) are invalidated from the routing table and "backup routes" with higher metric can take over.
This is universal in all operating systems I know about.
I thought I could have multiple *DFTROUTE for different interfaces but it is not allowing that or I am doing something else wrong.
No, it perfectly makes sense to now allow a "duplicate key" in the routing table.
Has anyone set up a similar requirement where two different networks are accessing the IBMi on tow different interfaces and a default route is required for each interface ?
Please keep in mind that routing decisions are almost always made for the *destination* of a packet. (There is something called policy based routing — at least available on Cisco gear and Linux — which allows to route based on packet source, though.)
Somewhat simplified: You can only have one default route. Period.
I take it your request is not for a transitional situation?
You are perfectly allowed to have more specific routes pointing through your other interface, though. So, if you aggregate all immediately important routes, and assign the result to that new interface, those will be used as soon as you configure those routes.
Beware of one particularity for *outgoing* connections, though. Most IP "applications" (aka IP clients, such as telnet, lpr, …) bind() themselves to 0.0.0.0/0 by default. Usually, the IP stack then looks up the destination route and from that derives the associated interface. That interface's address will then be used for that new outgoing connection's source address. Depending on the corporate policy/VPN/firewall settings, this might lead to "can't connect anymore" errors.
HTH.
:wq! PoC
midrange.com
