Não ter um conjunto de máscara de rede no arquivo ifcfg-eth0: 1 fará com que o padrão do Linux seja 255.0.0.0, pois é uma classe herdada A e poderá alcançar o gateway naquela subinterface.
Eu tenho uma caixa do Centos 5 com uma subinterface:
ifconfig eth0 10.1.1.1 255.255.255.255
ifconfig eth0:1 10.1.1.2 255.255.255.255
As máscaras de rede precisam ter 32 bits no ambiente em que esse servidor está. Assim, para especificar a rota padrão, informamos ao servidor onde o gateway está e, em seguida, a rota padrão para ele:
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
Então 10.1.1.10 é o gateway padrão, e está fora da interface eth0
No entanto, todos os pacotes que saem do servidor têm o endereço IP associado a eth0: 1. Eles precisam ter o IP na eth0.
O roteamento é definido em route-eth0:
10.1.1.10/32 dev eth0
default via 10.1.1.10
E eu tentei forçar o problema com GATEWAY e SRCADDR em 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
Nenhum gateway é definido em ifcfg-eth0: 1:
DEVICE=eth0:1
IPADDR=10.1.1.2
NETMASK=
O endereço IP eth0 é o usado para o fqdn em / etc / hosts. Se eu pingar o fqdn, recebo o endereço IP eth0.
Algum poderia me informar como eu posso forçar os pacotes de saída a usar o IP vinculado a eth0 em vez do IP vinculado a eth0: 1 como o IP de origem.
Você precisaria de pelo menos uma máscara de prefixo / 28 para o IP em eth0 para estar na mesma sub-rede com o gateway padrão (para o cenário descrito com o gateway em .10). Mude a máscara de rede de eth0 para 255.255.255.240, veja se você pode fazer o ping do gateway padrão, então você pode adicionar mais endereços IP a esse dispositivo com um prefixo / 32 (255.255.255.255) sem problemas.
Como afirmado na pergunta, o método de acesso ao gateway padrão não é por meio de um domínio de broadcast, cada endereço IP deve ser somente host e ter uma máscara de 32 bits.
O acesso ao gateway é feito por meio de duas entradas de rota estática. A primeira é uma rota de host para descrever a interface da qual o gateway está fora e a segunda é definir a rota padrão como esse gateway.
Não há necessidade de máscaras de menos de 32 bits se você for explícito sobre a localização do gateway na tabela de roteamento.
O problema aqui é que a máscara de rede não foi especificada para as subinterfaces e, portanto, padronizou para / 24. Isso significava que, embora a interface eth0 fosse de 32 bits e, efetivamente, não estivesse conectada a uma rede IP, a interface eth0: 1 estava em 10.1.1.0/24 e, portanto, era uma interface conectada à rede que o IP do gateway residia. A rota da interface conectada teve precedência sobre a rota estática e, portanto, foi selecionada como o endereço IP de origem.
Como afirmado na pergunta, as máscaras precisam ser de 32 bits para que o comportamento seja o desejado, então a resposta foi mudar a máscara de rede para 32 bits para a subinterface. Quando isso aconteceu, a única rota disponível era a rota padrão, para o gateway com sua própria rota de host definida.
Para aqueles que não estão familiarizados com o motivo pelo qual essa configuração é usada, ela é usada onde você deseja flexibilidade com a alocação e a conservação de endereços IP. Não há necessidade de dividir o espaço de endereço em sub-redes com esse método, embora ele venha com sobrecargas administrativas. Como afirmado, o ambiente não está sob o controle do questionador.