[BlueOnyx:21956] Re: Blueonyx 5209R - strange behavior. Server sends mails from wrong IP

[Michael Stauber]

Hi Dirk,

> You mean the output of the second server.
> For sure this is also a 5209R

That's a bit weird, because this is how the routes should usually look
on a 5209R and it didn't look that way on that box:

Primary IP: 10.1.210.1
Netmask:    255.255.0.0
Vsites on:  10.1.210.1 to 10.1.210.5
Gateway:    10.1.254.2

[root at test]# ip -o route show
default via 10.1.254.2 dev eth0
10.1.0.0/16 dev eth0 proto kernel scope link src 10.1.210.1
10.1.210.1 dev eth0 scope link
10.1.210.2 dev eth0 scope link
10.1.210.3 dev eth0 scope link
10.1.210.4 dev eth0 scope link
10.1.210.5 dev eth0 scope link
127.0.0.0/8 dev lo scope link

[root at test]# route -n
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Iface
0.0.0.0         10.1.254.2      0.0.0.0         UG    eth0
10.1.0.0        0.0.0.0         255.255.0.0     U     eth0
10.1.210.1      0.0.0.0         255.255.255.255 UH    eth0
10.1.210.2      0.0.0.0         255.255.255.255 UH    eth0
10.1.210.3      0.0.0.0         255.255.255.255 UH    eth0
10.1.210.4      0.0.0.0         255.255.255.255 UH    eth0
10.1.210.5      0.0.0.0         255.255.255.255 UH    eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     lo

> Server with issue:
> GATEWAYDEV="eth0" is missing
> GATEWAY="xx.xx.91.1" is existing
> 
> Server without issue:
> GATEWAYDEV="eth0" is missing
> GATEWAY="xx.xx.91.1" is existing

Very well. I just double checked and the CD-versions should have
GATEWAY, while the OpenVZ OS-Template uses GATEWAYDEV instead. So what
you have there is fine.

> Here is the output:
> ---
> /usr/sausalito/handlers/base/network/change_route.pl -c 2
> Running: starting
> /usr/sausalito/handlers/base/network/change_route.pl: starting.
> Running: My primary IPv4 ipaddr: xx.xx.91.192
> Running: My primary IPv4 netmask: 255.255.255.0
> Running: My primary IPv6 ipaddr:
> Route for primary IPv4 IP xx.xx.91.192 already exists.
> Running: Found extra IPv4 IP: xx.xx.91.193 ... already has a route.
> @unique_netroutes: $VAR1 = [
>           'xx.xx.91.0'
>         ];
> 
> @routes_existing_ipv4: $VAR1 = [];
> 
> @routes_existing_ipv6: $VAR1 = [];
> 
> /sbin/ip route add xx.xx.91.0/255.255.255.0 dev eth0
> RTNETLINK answers: File exists
> Running: Loopback ... already has a route.
> ---

Thank you. That also looks good and I see nothing unexpected or unusual
there.

>> FWIW: It might be worth a try to edit that handler and to comment out
>> the "if"-condition right under this comment:
>>
>> # Make sure all IPv4 extra-IPs have routes:
>>
>> That should be lines 230-267 and this deals with the routes for the
>> alias IP's (anything but the primary IPv4 IP).
> 
> Should I do this?

Yes, it is worth a try. When I do that on my test-box my routing table
changes from the one shown above to this:

[root at test]# ip -o route show
default via 10.1.254.2 dev eth0
10.1.0.0/16 dev eth0 proto kernel scope link src 10.1.210.1
10.1.210.1 dev eth0 scope link
127.0.0.0/8 dev lo scope link

[root at test]# route -n
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Iface
0.0.0.0         10.1.254.2      0.0.0.0         UG    eth0
10.1.0.0        0.0.0.0         255.255.0.0     U     eth0
10.1.210.1      0.0.0.0         255.255.255.255 UH    eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     lo

The Vsites on the extra-IP's are still reachable by name and IP, because
we still have the network route:

10.1.0.0        0.0.0.0         255.255.0.0     U     eth0

So I think it might be worth to try this and see if it cuts down on the
network stack occasionally using an alias IP for outgoing traffic.

I'd like to hear some more input from you and others whether we should
keep the routes for the individual extra-IPs or not. Because it does
appear we don't need them as the network rule already covers anything.

Network rules are also added if an IP address is out-of-bounds from the
primary IP and it's netmask. For example after adding a Vsite with the
IP 10.2.210.1 (not covered by the 10.1.210.1/16 of the primary
IP/Netmask) I end up with this routing table generated by the
change_routes.pl with the commented out function for the extra-IP routes:

[root at test]# route -n
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Iface
0.0.0.0         10.1.254.2      0.0.0.0         UG    eth0
10.1.0.0        0.0.0.0         255.255.0.0     U     eth0
10.1.210.1      0.0.0.0         255.255.255.255 UH    eth0
10.2.0.0        0.0.0.0         255.255.0.0     U     eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     lo

So it added a netroute for the new IP as well:

10.2.0.0        0.0.0.0         255.255.0.0     U     eth0

-- 
With best regards

Michael Stauber