I have a Centos 5 box with a sub interface:
ifconfig eth0 10.1.1.1 255.255.255.255
ifconfig eth0:1 10.1.1.2 255.255.255.255
The netmasks need to be 32bit in the environment this server is in. So in order to specify the default route, we let the server know where the gateway is, and then default route to it:
Destination Gateway Genmask Flags MSS Window irtt Iface
10.1.1.10 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
0.0.0.0 10.1.1.10 0.0.0.0 UG 0 0 0 eth0
So 10.1.1.10 is the default gateway, and it is out interface eth0
However, all packets that leave the server have the IP address associated with eth0:1. They need to have the IP on eth0.
The routing is defined in route-eth0:
10.1.1.10/32 dev eth0
default via 10.1.1.10
And I have tried to force the issue with GATEWAY and SRCADDR in ifcfg-eth0:
DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
IPADDR=10.1.1.1
SRCADDR=10.1.1.1
NETMASK=255.255.255.255
GATEWAY=10.1.1.10
No gateway is defined in ifcfg-eth0:1:
DEVICE=eth0:1
IPADDR=10.1.1.2
NETMASK=
The eth0 IP address is the one used for the fqdn in /etc/hosts. If I ping the fqdn, I get the eth0 IP address.
Could some let me know how I can force outgoing packets to use the IP bound to eth0 rather than the IP bound to eth0:1 as the source IP.
Not having a netmask set in the ifcfg-eth0:1 file will make Linux default to 255.0.0.0 as it's a legacy class A and it will be able to reach the gateway on that subinterface.
You would need at least a /28 prefix mask for the IP on eth0 in order to be in the same subnet with the default gateway (for the scenario you described with gateway on .10). Change the netmask of eth0 to 255.255.255.240, see if you can ping the default gateway, then you can add any further IP addresses to that device with a /32 prefix (255.255.255.255) without issues.
As stated in the question, the method of accessing the default gateway is not via a broadcast domain, each IP address should be host-only, and so having a 32 bit mask.
Access to the gateway is via two static route entries. The first is a host route to describe the interface the gateway is out of, and the second is to define the default route as that gateway.
There is not need for less than 32bit netmasks if you are explicit about the location of the gateway in the routing table.
The issue here is that the netmask was not specified for the sub interfaces, and so defaulted to /24. This meant that while the eth0 interface was 32bit, and effectively not connected to an IP network, the eth0:1 interface was in 10.1.1.0/24 and therefore a connected interface to the network the gateway IP resided. The connected interface route took precedence over the static route, and so was selected as the source IP address.
As stated in the question, the masks need to be 32bit for the behaviour to be as desired, so the answer was to change the netmask to 32bit for the subinterface. Once this happened, the only route available was the default route, to the gateway with its own host route defined.
For those unfamiliar with why this setup is used, it is used where you want flexibility with IP address allocation and conservation. There is no need to carve up the address space into subnets with this method, though it does come with administrative overheads. As stated, the environment isn't under the control of the questioner.