I use SLES15 SP1, and I know the SLES forums. But at this time, I can´t post any Thread at the SLES Forum! I don´t no why! (Microfocus forums works well with my account)
I thing there are no big difference between LEAP 15.1 and SLES15.1
I use two NIC (eth0, eth1) with two Subnet: eth0 10.10.10.10 (internal) and eth1 10.10.20.10 (DMZ)
The Gateway should be 10.10.10.1 for eth0 and 10.10.20.1 for eth1.
I try:
Edit the /etc/sysconfig/network/ifcfg-eth0 and -eth1 with add Gateway=‘10.10.10.1’ (eth0) and Gateway=‘10.10.20.1’ (eth1) dosn´t work
at Yast/Network Settings/Routing/Routing Table with Destination:default, Netmask:- Gateway:10.10.10.1 Device:eth0 and Destination:default, Netmask:- Gateway:10.10.20.1 Device:eth1 and delete the default IP4 Gateway
the /etc/sysconfig/network/routes is now emty and zwo new files are generated: ifroute-eth0 (default 10.10.10.1 - eth0) and ifroute-eth1 (default 10.10.20.1 - eth1)
reboot
it also dosn´t work (now the default route is 10.10.20.1 - the 2nd entry)
at Yast the default IP4 Gateway is 10.10.20.1 with eth1 and the Routing Table is empty :(
ip route:
default via 10.10.20.1 dev eth1
10.10.10.0/24 dev eth0 proto kernel scope link 10.10.10.10
10.10.20.0/24 dev eth1 proto kernel scope link 10.10.20.10
Any idear how I can config two gateways on two Nic´s?
SUSE forums are part of SUSE support offerings, are not they? I assume you pay for SUSE support?
Any idear how I can config two gateways on two Nic´s?
You create two routing tables, classify outgoing packets based on whatever criteria are appropriate in your case and add rules to use the right table for each packet class.
As far as I always understood routing, routes are going from one system to another system (thus NOT from one NIC to another). This means that you can indeed define routes to systems on other networks going through routers on different (sub)nets the system is connected to. And the traffic then indeed goes through the NIC connected to the same network as that router.
When all routes fail for a connection asked for, there is a fallback to the default router. Again, that router is connected to one of the (sub)net(s) the system is connected to. There can of course only be one default router. And all traffic that is not routed to other routers thus go to that router and thus through the NIC connected to the same (sub)net as the default router.
When I understand what you try to do, is that you try to define two default routers for your system, That is impossible.
You can define e.g. a route to another network of your company, say 10.0.30.0/24 to go to a router that is part of the 10.0.20.0/24 network. Traffic to 10.0.30.0/24, will the go through the NIC with 10.0.20.10 via 10.0.20.1.
Likewise you can have a route for 10.0.40.0/24 going through router 10.0.10.1 and thus using the NIC with 10.0.10.10.
But you can have only one deafult route for all that is not covered by the two routes mentioned above.
On your system you should have only one routing table
And within that routing table you should have
one default gateway (only one and not more than one!)
and two gateway routers.
From what you posted, I <think> your machine is configured correctly except that as you say 10.10.20.1 is your default gateway instead of 10.10.10.1.
I don’t know if the YaST networking module is any different in SUSE than openSUSE, but in openSUSE this should be easily corrected by specifying in the top section of the routing tab.
Note that you should <not> be defining 10.10.20.1 as a default gateway <anywhere> because by your description it’s only a regular gateway, not “the” Default Gateway.
On openSUSE, the 10.10.20.1 gateway like any other non-default gateways would be listed in the lower section.
Also,
When posting your results and in particular your “ip route” you should post the entire output enclosed in
tags instead of posting only an excerpt and then describing what the routing gateways are supposed to do... The table by itself will provide the entire picture.
There are alternatives to using YaST to configure multiple gateways and routes as well...
I haven't looked closely to know exactly what YaST does under the hood today, but in "the old days"
- You configure only "the" default gateway.
- You can then create the manual command that defines a new route and the gateway address required.
- To make the command persistent across reboots, add the command to /etc/sysctl.conf
HTh,
TSU
What is your reason for wanting two gateways? Are you able to clarify further? When just wanting to reach a given directly-connected network (ie within the same subnet) no gateway address is required as ARP will take care of the IP connectivity. You can of course add static routes for networks that may lie beyond/behind that subnet via another router.
my problem is an asymmetric routing
maybe someone can use my solution
For better understuding
This is a mailserver. 10.10.10.10 (eth0) the internal net, 10.10.20.10 (eth1) the external net.
.1 are the Gateways and 10.10.20.1 the SMTP Relay. At the 10.10.10.10 are running internal agent (Mail Transport Agent),
and at 10.10.20.10 the SMTP - agent.
Network: wicked
the standard config: 10.10.10.10/24 with 10.10.10.1 default Gateway and 10.10.20.10 w/o Gateway
Everythink work fine:
Mail in (SMTP): Spamfilter - 10.10.20.1 - 10.10.20.10 to the SMTP Gateway.
Internal will the mails delivery by the Mail Transport Agent (10.10.10.10) with routing over the default Gateway to the Networks.
Mail out: to the Mail Transport Agent (10.10.10.10) - at the Server internal to the Internet Gateway 10.10.20.10 to the SMTP Relay 10.10.20.1
but there is a Management Network 10.10.30.0/24 with an admin PC 10.10.30.150
at the Mail Server both Agents use a Web based Monitor and admin console - I need a conection from 10.10.30.150 - to 10.10.20.10 and 10.10.10.10
From 10.10.30.150 to 10.10.10.10:
From 10.10.30.150 to 10.10.30.1 to 10.10.10.1 to 10.10.10.10 and back 10.10.10.10 is a /24 Net and use the default Gateway 10.10.10.10 to 10.10.10.1 to 10.10.30.1 to 10.10.30.150 - it works
but From 10.10.30.150 to 10.10.20.10
From 10.10.30.150 to 10.10.30.1 to 10.10.20.1 to 10.10.20.10 and back? 10.10.20.10 is also a /24 Net and need the default Gateway (10.10.10.1)
at this point the Packets run back in a different way - asymmetric routing (Firewall blocks…)
thx to arvidjaar - policy based routing will be the solution:
vi /etc/iproute2/rt_tables
add: 100 rt2
and add ip route and rules:
ip route add 10.10.20.0/24 dev eth1 src 10.10.20.10 table rt2
ip route add default via 10.10.20.1 dev eth1 table rt2
ip rule add from 10.10.20.10/32 table rt2
ip rule add to 10.10.20.10/32 table rt2
it works, but ip route and ip rule are not persistent across reboots. At this time I can´t find the right place to make the command persistent across reboots
Maybe you’re leaving something out, but I don’t see why you need PBR (see the man pages for ip-rule for your two “ip rule add” commands).
It would seem to me that simple “route add” commands were all you needed to create the needed routing gateway entries… unless you wanted to apply special restrictions but your posts in this thread didn’t require restrictions, only default functionality.
In any case…
If you have a set of working commands that do what you want and you just want to make them persistent,
The “old school” way of making routing commands persistent across reboots is to simply create entries of those commands in
/etc/sysctl.conf
Of course, then reboot to verify your handiwork.
Of course, these routing commands and optionally any kind of name resolution should be configured on the hosts you want to grant “knowledge of networks accessible”
If you want me to possibly suggest a simpler solution,
I’d need…
Your mail machine
ip addr
ip route
Your administrative machine
ip addr
ip route
Any other machine that might need access to a network that’s not accessible by its Default Gateway
As I described, there should be only <one> Default Gateway on each machine that in most cases is “the” path that eventually leads to the Internet, need to know that address.
Other gateway addresses to networks that aren’t accessible by the Default Gateway should be self-evident if your description is accurate.
From your description, I assume that the non-default gateways are all on the Mail server, and not any other machine.
Assume you are running your SMTP Server as a standalone server, and it’s used only to relay outbound mail… not for inbound, and not configured as an extension of your mail server app.
The physical topology (ie network cards) on each machine and whether the above network interfaces are bound to these NICs or if different.
Decided to take some moments to check up on any changes that might have happened recently in systemd, and found something interesting…
The file I suggested (/etc/sysctl.conf) which is likely the most popular file for humans to automate modifications to procfs is being deprecated, so it looks like entries should be written into one of the other sysctl*.conf files…
Hi @Wolfgang_Bleim ,
I spent good three hours to figure out this, and it’s incredibly strange how nothing proper can be found on the internet. The official solution from SUSE I found is quite old and still relative to systemV.
This solution was applied to a machine running openSuSE 15.3
Here’s how I solved it, changed for your case:
Added the rules to a newly created file ifrule-eth1 in /etc/sysconfig/network/ with this content:
ipv4 from 10.10.20.10/32 table 100
ipv4 to 10.10.20.10/32 table 100
Note that this file wants the table ID and not the name. More details in man ifrule
Added this line to ifcfg-eth1:
POST_UP_SCRIPT=compat:suse:bindtable-eth1
This will run a script inside /etc/sysconfig/network/scripts . More details in man 5 ifcfg
Create a custom script bindtable-eth1 with a command that contains the table specification, apparently none of the wicked config files support it. The content of the script simply being:
#!/bin/sh
ip route add 10.10.20.0/24 dev eth1 src 10.10.20.10 table rt2
ip route add default via 10.10.20.1 dev eth1 table rt2
Just to play along the rules, edited ifroute-eth1:
default 10.10.20.1 - eth1 100
I was hoping this one alone would do the trick but it didn’t. You can actually omit it eventually and do everything in the script at 3).
What a waste of time for what I believe is such a common scenario!
