http://bugzilla.suse.com/show_bug.cgi?id=1005478 http://bugzilla.suse.com/show_bug.cgi?id=1005478#c18 Marius Tomaschewski changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mt@suse.com --- Comment #18 from Marius Tomaschewski --- (In reply to Paul Stynen from comment #16)

(In reply to Knut Alejandro Anderssen González from comment #9)

...

Paul, you are using /32 as the netmask, was it intentional?

Now that was a good hint :-) If I use /24 as 'Subnet Mask' in Yast 'Statically Assigned IP Address' then 'route' command now gives the expected paths

linux-64l2:/etc/sysconfig/network # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.131.100 0.0.0.0 UG 0 0 0 eth0 192.168.131.0 * 255.255.255.0 U 0 0 0 eth0

I think Yast should complain about /32 as Subnet Mask instead of creating a system without gateway (and leaving the user clueless) ?

Yes. I do not see a feature here, but a bug -> incomplete IP configuration. Each route with gateway requires a route without gateway, that is matching the gateway. Special case: fe80:: link-local addresses in IPv6 -> they're set automatically by the kernel (derived from the HW/MAC address or e.g. tunnel endpoints). [IPv6 is not using the MAC address directly / layer 2 protocol like IPv4 did (arp, IP <-> MAC resolving), but instead L3 multicast fe80 -> ffXX] That is, to apply the route (default via 192.168.131.100), you need a direct route without gateway first matching the gateway, e.g.: # destination [gateway] (netmask) device [optional other options] 192.168.131.100/32 - - eth0 default 192.168.131.100 - eth0 or also using a network (declare the complete network to be directly connected): 192.168.131.0/24 - - eth0 default 192.168.131.100 - eth0 (default == as 0.0.0.0/0). Netmask field is kind of deprecated (IPv6 is not using a mask, but always IP/PREFIXLEN cidr notation), better/more consistent is to use /XX in destination. An IPADDR=... variable is incomplete without: a) /PREFIXLEN inside IPADDR, b) PREFIXLEN=... variable or for IPv4 only c) NETMASK=... Without a prefix len (/24 in this case), that is without a) or b) or c), it defaults to /32 (/128 in IPv6 case). Setting an IP address to an interface requires at least two things: the local address _and_ the network or the address and the peer/remote address, that is: IPADDR=192.168.131.103/24 or IPADDR=192.168.131.103 PREFIXLEN=24 or IPADDR=192.168.131.103 NETMASK=255.255.255.0 or in point-to-point case, e.g.: IPADDR=192.168.131.103 REMOTE_IPADDR=192.168.131.105 Using /24 here causes automatic creation of the 192.168.131.0/24 - - eth0 route. # ip link add dummy1 type dummy # ip link set up dev dummy1 # ip addr add 192.168.131.103/24 dev dummy1 # ip addr show dev dummy1 6: dummy1: mtu 1500 qdisc noqueue state UNKNOWN group default link/ether aa:a1:63:85:93:60 brd ff:ff:ff:ff:ff:ff inet 192.168.131.103/24 scope global dummy1 valid_lft forever preferred_lft forever inet6 fe80::a8a1:63ff:fe85:9360/64 scope link valid_lft forever preferred_lft forever # ip route show dev dummy1 192.168.131.0/24 proto kernel scope link src 192.168.131.103 # ### -> default route can be set via 192.168.131.* except of 192.168.131.103 # ip route replace default via 192.168.131.100 dev dummy1 # ip route show dev dummy1 default via 192.168.131.100 192.168.131.0/24 proto kernel scope link src 192.168.131.103 # ### but not e.g.: # ip route replace default via 10.0.0.100 dev dummy1 RTNETLINK answers: Network is unreachable # ip route show dev dummy1 default via 192.168.131.100 192.168.131.0/24 proto kernel scope link src 192.168.131.103 # ### -> still via 192.168.131.100 # ### except, you declare the gateway 10.0.0.100 or a network # ### matching it matching it as directly connected first: # ip route replace 10.0.0.0/18 dev dummy1 # ip route replace default via 10.0.0.100 dev dummy1 # ip route show dev dummy1 default via 10.0.0.100 10.0.0.0/18 scope link 192.168.131.0/24 proto kernel scope link src 192.168.131.103 Except if this: addresses applied via dhcp and statically are completely independent sets / leases and have to be complete by themselves. The DHCP server provides an own route set (routes or classless routes options) which should be complete. A dhcp setup that requires additional static routes is simply broken. When you use e.g.: BOOTPROTO=dhcp4 but also some static settings, the static settings have to be complete and all the above about direct routes is still valid for them. As you can see in comment 8, the static routes are _not_ in "ipv4:dhcp", but in the "ipv4:static" request. Usually, static addresses are applied immediately while dhcp may be applied much later or not applied at all (there is no dhcp4 server; or it is stopped ... for a maintenance week ;-)). -- You are receiving this mail because: You are on the CC list for the bug.