On 8/6/20 1:56 PM, Marc Roos wrote:
Yes indeed! Thanks
:-)
I can't remember exactly. I was working on this half year ago. I think it has to do with that multiple networks are created in the same namespace. I am retesting this now.
ACK
No
That will be a problem.
Hmmm interesting. So I cannot make it like that if a process chooses interface 1, it gets routings for that interface and if it chooses interface 2 it gets those routings?
That depends.I know that it's possible to apply ip rules to choose routing tables based on various criteria. But I don't remember if there are convenient ways to carte blanch apply rules to choose routing tables as described using the old world methods.
The new world method of l3mdev / VRF should be able to do what you are asking to do.
Though, I don't see a need to do so with the example that you provided.More specifically, I don't see any reason why testeth0 (192.168.10.232/24) and testeth1 (cc.cc.cc.43/24) can't co-exist in the same routing table.
You can easily have a default via cc.cc.cc.1.Using the default (main) routing table means that you don't have to add a route to 192.168.10.114 as it will be covered by the directly attached route.
You won't need any rules either.
I will get back to you on this. I think that this could maybe be related to that both interfaces need to be able to communicate with the same host ip. (and can have gateways)
Maybe there is something that you know that makes this more complicated. But I'm not seeing any reason to not use the default (main) routing table for all of this.
You can easily have one or more gateways (routes) on one or more interfaces.Typically you can only have one /default/ gateway be used at a time. (There are some ways to define multiple and influence how they are chosen.)
Do you mean that both interfaces need to communicate with the same remote host IP?
If that is the case, please elaborate more on the network topology between the network namespace and the remote host IP.
Also, please clarify if the "(remote) host IP" is on the host system providing the network namespace or something else.
Please provide some information on what testeth0 and testeth1 are. I can't tell if they are physical NICs or vEth NICs or something else.
-- Grant. . . . unix || die
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
