Multiple static IP Debian 9 Stretch on one interface

13,038

Solution 1

You cannot have multiple default gateway for one interface, and in my opinion the way you are adding multiple IP to the same interface is incorrect.

Add the secondary IP with this notation :

iface enp2s0 inet static
  address XX.4.87.10
  netmask 255.255.255.224
  gateway XX.4.87.1
  # route XX.4.87.0/27 via XX.4.87.1
  up route add -net XX.4.87.0 netmask 255.255.255.224 gw XX.4.87.1 dev enp2s0

iface enp2s0:1 inet static
  address XX.4.87.47
  netmask 255.255.255.224
  # I removed the "gateway" instruction in this block, as it is a secondary IP
  up route add -net XX.4.87.0 netmask 255.255.255.224 gw XX.4.87.33 dev enp2s0

Solution 2

My Debian 9 works like that using the hint from @Marc R.

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug   enp0s3
#iface enp0s3   inet dhcp

iface enp0s3    inet static
address     192.168.0.203
netmask     255.255.255.0
gateway     192.168.0.1

iface enp0s3    inet static
address     192.168.0.204
netmask     255.255.255.0

Usually i ever uses eth0:1 or devicename:1 for multi ip now for my surprise at Debian 9 looks like it handles the split by itself.

Share:
13,038

Related videos on Youtube

Marc R.
Author by

Marc R.

Updated on September 18, 2022

Comments

  • Marc R.
    Marc R. over 1 year

    Cannot add multiple IPs to network interface.

    While trying to add an IP to the interface enp2s0 via Webmin it says:

    Failed to save interface : Missing or invalid interface name
    

    It's a known bug in Webmin, so lets skip this right now.

    Modifying /etc/network/interfaces directly

    auto lo
    iface lo inet loopback
    iface lo inet6 loopback
    
    auto enp2s0
    allow-hotplug enp2s0
    iface enp2s0 inet static
      address XX.4.87.10
      netmask 255.255.255.224
      gateway XX.4.87.1
      # route XX.4.87.0/27 via XX.4.87.1
      up route add -net XX.4.87.0 netmask 255.255.255.224 gw XX.4.87.1 dev enp2s0
    
    iface enp2s0 inet static
      address XX.4.87.47
      netmask 255.255.255.224
      gateway XX.4.87.33
      up route add -net XX.4.87.0 netmask 255.255.255.224 gw XX.4.87.33 dev enp2s0
    
    iface enp2s0 inet static
      address XX.4.87.37
      netmask 255.255.255.224
      gateway XX.4.87.33
      up route add -net XX.4.87.0 netmask 255.255.255.224 gw XX.4.87.33 dev enp2s0
    
    iface enp2s0 inet6 static
      address XXXX:4f8:140:701e::2
      netmask 64
      gateway fe80::1
    

    The first (main-IP) and the second in the list are always connectable, but the third permanently not. So I'm able to switch the IPs order and can access my server after a reboot, what I'm doing wrong?

    (I've also tried the legacy method of Debian Docs but this is crashing it all)

    root@hdtu1 ~ # systemctl status networking.service
    ● networking.service - Raise network interfaces
       Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
       Active: failed (Result: exit-code) since Wed 2018-08-01 22:40:12 CEST; 7s ago
         Docs: man:interfaces(5)
      Process: 2184 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
      Process: 2179 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ] && [ -n "$(ifquery --read-environment --list --exclude
     Main PID: 2184 (code=exited, status=1/FAILURE)
    
    Aug 01 22:40:12 hdtu1 systemd[1]: Starting Raise network interfaces...
    Aug 01 22:40:12 hdtu1 ifup[2184]: RTNETLINK answers: File exists
    Aug 01 22:40:12 hdtu1 ifup[2184]: ifup: failed to bring up enp2s0
    Aug 01 22:40:12 hdtu1 systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
    Aug 01 22:40:12 hdtu1 systemd[1]: Failed to start Raise network interfaces.
    Aug 01 22:40:12 hdtu1 systemd[1]: networking.service: Unit entered failed state.
    Aug 01 22:40:12 hdtu1 systemd[1]: networking.service: Failed with result 'exit-code'.
    
    • anders
      anders almost 6 years
      Excuse me if I come off about as a noob (because I am).. By why are your gateways the same in the second and third example? Here is an example I use to trick a program to thinking it is talking outside of the LAN so I can redirect it to a local proxy: 'sudo ip addr add 170.33.33.33/32 dev eth0' do /24 for your local LAN. I would check out 'man ip' for the rest of your needed command line options. Hope this helps! If you describe better your needs, I may be able to write an answer. Good luck!
    • Marc R.
      Marc R. over 5 years
      The gateways are given from the housing center. I will have a look for the proxy and will come back to you.
    • mivk
      mivk over 5 years
      This Debian wiki section has all the needed info, detailing the various ways to have assign multiple IPs : NetworkConfiguration#Multiple_IP_addresses_on_one_Interface
  • Marc R.
    Marc R. over 5 years
    A few minutes ago I've exactly reading about that issue you're talking about. The networking service is restarting without trouble now while I'm following your corrections, but the IPs are not connectible after a reboot. Only if i left auto enp2s0:0 and auto enp2s0:1 in place the server answers correctly, but the networking service restart fails on ExecStart=/sbin/ifup
  • Marc R.
    Marc R. over 5 years
    Update: If I'm removing the gateway and signing both IP XX.4.87.37 && XX.4.87.47 to iface enp2s0:0 it works as expected (why?). After a reboot and a restart of the networking service. No trouble anymore. Thank you!!
  • Luis Vazquez
    Luis Vazquez over 4 years
    This is the way you added secondary IP address in the 90's and the first decade of the 2000's. It has been more than a decade since the ifconfig command has been deprecated and this kind of "alias" interface configuration with it. With the replacement of the ip tools you should add multiple addresses to the same physical interface, and the ethX:N naming is gone forever.