1

I've got several Linux (Debian Wheezy) machines that have a peculiar problem. After booting them up, an extra route is created that has to be deleted before the machine can talk to other machines on the same subnet. After booting, the routes look like this (public IPs masked):

~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
208.XXX.XXX.0 * 255.255.255.0 U 0 0 0 vmbr0
default 208.XXX.XXX.1 0.0.0.0 UG 0 0 0 vmbr0

The 208.XXX.XXX.0 route blocks the server from communicating with any other servers in this same subnet. After deleting this route, everything is fine again. But, after rebooting, this route is back again. What is creating this route? Is it normal for a route like this to get automatically created? (In other words, should this route actually work and the fact that I have to delete it actually indicate a problem somewhere else on my network?)

This machine is running Proxmox (which is why the interfaces say "vmbr0"), so it's quite possible that this is actually a Proxmox issue. I already tried posting this question on their forums and got zero replies there.

Perhaps a better question would be to ask this: What is it about this route that could be causing machines in this same 208.XXX.XXX.XXX subnet from talking to each other?

If it helps any, here's the contents of /etc/network/interfaces (again, using XXX to avoid publishing public IPs. I promise, the first 3 octets of these IPs match.):

auto lo
iface lo inet loopback

auto vmbr0
iface vmbr0 inet static
        address 208.XXX.XXX.165
        netmask 255.255.255.0
        gateway 208.XXX.XXX.1
        bridge_ports eth0
        bridge_stp off
        bridge_fd 0
Extra Sauce
  • 71
  • 1
  • 1
  • 6
  • This seems to be the route added by your dhcp client that says that this subnet is the one you are in, your home subnet (the one you should have an ip in). What is the ip you receive from DHCP is it in the same subnet? – Gopoi May 16 '16 at 17:15
  • Please post your complete `/etc/network/interfaces` – Michael Hampton May 16 '16 at 17:19
  • Are the hosts on the same subnet on the same physical network too? If not well thats your problem. – Gopoi May 16 '16 at 17:30
  • Gopoi, each machine's IP is statically assigned. There is no DHCP server on the network. And, yes, all servers are on the same physical network. – Extra Sauce May 16 '16 at 18:44
  • Michael, I have added `/etc/network/interfaces` to my original question. – Extra Sauce May 16 '16 at 19:00
  • To answer one question yes this route is automatically created when you join the subnet (add an ip). It essentially means this subnet is on the cable. – Gopoi May 16 '16 at 19:12

1 Answers1

0

When you add an IP address to a specific interface (let it be by DHCP or manually with ifconfig), linux kernel will add this IP's subnet's route as being on that specific interface. This is because logically you are part of the subnet.

Possible issues would be:

  • The DHCP server is not giving you the right IP from the right subnet (the subnet you try to poke is behind the router)

  • There are some problem with the arp request so that your hosts can only talk through the router to each other

Gopoi
  • 547
  • 5
  • 21
  • I think you might be right about our hosts only being able to talk through the router to each other. Are you saying this is actually a router problem? – Extra Sauce May 16 '16 at 19:03
  • It would be more like the physical network not passing arp request to each other.... – Gopoi May 16 '16 at 19:09
  • The network topology is pretty simple. It looks like this: [internet]-[router]-[switch]-[servers] ...By "physical network" are you referring to the switch? The switch is a Cisco SG 200-50 using factory default settings. I'll do some googling to see if this switch could somehow be blocking arp requests. – Extra Sauce May 16 '16 at 20:17
  • Yes I was refering to the swith(es) and the servers. With you explaining how the topology of your network is, it makes it clear it is not a problem. Now since this switch is a "smart" switch, it might configured to work with certain VLAN or expecting tagged traffic by default. It might be worthwhile to check what the configuration actually is. – Gopoi May 18 '16 at 18:57
  • Thanks Gopoi. The switch isn't set up for remote management yet, so once we've got that configured, we'll check it out. – Extra Sauce May 19 '16 at 16:09