3

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.

Paul
  • 1,228
  • 12
  • 24
  • I'm going to guess that you've obfuscated your real IP addresses, and done it badly, because your described behaviour doesn't match what happens in the real world. I'd suggest using real addresses for clarity. – womble Aug 12 '11 at 07:31
  • eth0 and eth0:1 indeed differ by one. The gateway address is 9 above. The masks are 32 bit, so the actual addresses won't help. – Paul Aug 12 '11 at 07:56
  • 2
    You're very confident for someone who doesn't know why his system doesn't work. – womble Aug 12 '11 at 08:14

3 Answers3

2

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.

HampusLi
  • 3,398
  • 15
  • 14
  • This would be true normally, however 32bit masks are necessary and outside my control. To get around the lack of a broadcast domain, the gateway has a host route specified, indicating which interface it is accessible on. Note that there is no issue with connectivity incoming or outgoing. The only issue is the source address of outgoing packets is incorrect. However, your comment regarding the mask is right on the mark. The netmask for eth0:1 defaulted to 255.255.255.0. Once this was 32bit it was correct. If you remove the rest of the answer I'll accept it. – Paul Aug 12 '11 at 09:29
2

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.

O G
  • 854
  • 4
  • 6
  • This would be true normally, however 32bit masks are necessary and outside my control. To get around the lack of a broadcast domain, the gateway has a host route specified, indicating which interface it is accessible on. Note that there is no issue with connectivity incoming or outgoing. The only issue is the source address of outgoing packets is incorrect. – Paul Aug 12 '11 at 09:26
  • I meant, you were correct with the netmask defaulting (to 255.255.255.0 actually). Once the netmask is 255.255.255.255 the connected interface no longer has precedence in the route and so the static route is used, and correctly goes via the correct interface. The bit about requiring a 28bit mask was not correct. – Paul Aug 12 '11 at 09:37
  • I specified "at least" concerning the subnet prefix. However, if you are still using the /32 for the .1, can you access the default gw IP (via ping or any other sort of connection)? – O G Aug 12 '11 at 10:13
  • Yes, of course - that is my point. As stated, there has never been any connectivity issue. I'll mod up your answer, but my answer below is the way this is working. Please restore the part where you noted the default subnet mask. There is no requirement in this setup for anything other than a /32 subnet mask. The problem is the netmask on the subnet intefaces *wasn't* 32 bit, not that the eth0 subnet mask *was* 32bit. – Paul Aug 12 '11 at 12:39
1

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.

Paul
  • 1,228
  • 12
  • 24
  • Paul, if you must have the /32 on the ip addresses, try setting the default route using the source option of ip route: **ip route add default via 10.1.1.10 src 10.1.1.1 dev eth0**. (you can use _ip route change_ with same syntax if you connect to that system remotely). – O G Aug 13 '11 at 06:18
  • Thanks - no need, once the 32bit masks are in place, the existing routes for the default gateway work fine. But just so you know, all of the routes are sourced from eth0 as per the routing table in the question. This is the default behaviour with a single nic machine. – Paul Aug 15 '11 at 10:20