Comment # 18
on bug 1005478
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: <BROADCAST,NOARP,UP,LOWER_UP> 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 ;-)).