0

I have been trying to get static ip working on a Debian 10 install. The server is to operate in a VLAN separate from any other network. The VLAN id according to the router interface is 3. The router model is Pakedge RE-2.

The router configuration:

IP: 192.168.2.1
Netmask: 255.255.255.0
DHCP range: 192.168.2.2 - 192.168.2.10

The following is what the VLAN is configured for:

VLAN IP: 192.168.0.1
Netmask: 255.255.255.0
DHCP range: 192.168.0.10 - 192.168.0.254

The server static ip is 192.168.0.2. The following is /etc/network/interfaces:

# 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
auto eth0
allow-hotplug eth0
#iface eth0 inet static 
#   address 192.168.0.2
#   netmask 255.255.255.0
#   gateway 192.168.0.1

The following is interfaces.d/eth0:

# 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
#auto eth0
#allow-hotplug eth0
iface eth0 inet static 
    address 192.168.0.2
    netmask 255.255.255.0
    gateway 192.168.0.1

I am able to ping domains names and IPs successfully with dhclient eth0, but it is using an IP that's in the dhcp range of the router. ip route before dhclient eth0:

default via 192.168.0.1 dev eth0 onlink 
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.2

ip route after dhclient eth0:

default via 192.168.0.1 dev eth0 onlink 
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.2 
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.3

'ip a' output before dhclient eth0

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0b:db:be:9f:a5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.2/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::20b:dbff:febe:9fa5/64 scope link 
       valid_lft forever preferred_lft forever

I'm not sure what to do. It seems like the gateway might be an issue since dhcp works, but changing it to the router ip (outside the vlan) doesn't seem to work and it doesn't work no matter how many times I reboot or restart the networking daemon. I would also like to add that it seems like restarting the networking daemon doesn't detect changes in in /etc/network/interfaces.d/eth0 when it restarts so it seems like every change I make to test I need to restart which is exceedingly annoying.

EDIT: I'd also like to add that the Ethernet connection works (domains and IPs ping back successfully and websites work) on other computers that I plugged into to test (yes, even after disabling wifi). It seems to be this particular server I'm having issues with. It has Windows XP Professional installed on another partition, but it seems not to be able to communicate automatically there either. I would say this is a hardware problem, but dhcp works fine. Probably, the other computers I was testing were using dhcp and just connecting back to the router outside the VLAN since static wasn't set. I'll retest with no dhcp and dhcp to see given ip.

EDIT 2: I disabled the dhcp server for the vlan and the router and I am still not able to connect to the internet on the server. I'd also like to mention that I couldn't ping 192.168.0.1 (the vlan ip i.e. the gateway) before I disabled the dhcp servers and I still can't ping 192.168.0.1.

EDIT 3: Thanks to A.B, I was able to manually able to use the vlan interface. The commands are as follows: ip address delete 192.168.0.2/24 dev eth0; ip link add link eth0 name eth0.3 type vlan id 3; ip link set dev eth0.3 up; ip address add 192.168.0.2/24 dev eth0.3; ip route add default via 192.168.0.1 dev eth0.3

//Deletes the address assigned to eth0
ip address delete 192.168.0.2/24 dev eth0;

//Creates a link to eth0 with the vlan interface eth0.3 which is configured for vlan id 3
ip link add link eth0 name eth0.3 type vlan id 3; 

//Sets eth0.3 up
ip link set dev eth0.3 up; 

//Adds and associates 192.168.0.2/24 with eth0.3
ip address add 192.168.0.2/24 dev eth0.3;

//Configures the default route to go to the gateway 192.168.0.1 with the eth0.3 interface
ip route add default via 192.168.0.1 dev eth0.3;

However, this does not resolve the issue with the ifupdown configuration files. A.B says the address on eth0 may be the cause of the ifupdown issues. In the comments, there is information regarding configuring eth0.3 as an interface in the interfaces configs which may be helpful to someone. I ended up installing the vlan package, modprobing 8021q, and creating a file named eth0.3 in /etc/network/interfaces.d/ with the following:

auto eth0.3 
iface eth0.3 inet static 
        address 192.168.0.2
        netmask 255.255.255.0
        gateway 192.168.0.1
        vlan-raw-device eth0 

But, as already stated, for me this ended up causing the networking daemon to fail (after a reboot) because ifup can't bring up eth0.3. If someone has information which can help resolve this, that would be great.

EDIT 4: When I removed auto eth0.3 from eth0.3 in /etc/network/interfaces.d, the networking daemon no longer failed on restart and showed that it was active and after a reboot systemctl --failed showed that no daemons failed to start; however, pinging still yields Destination Host Unreachable (even after restart).

17
  • Hi Yetto and welcome! The fact that with dhclient you receive an IP in the 192.168.2.x subnet it means the VLAN on the router isn't working properly, it's configured on the right port? It could also mean the router doesn't set the VLAN in access mode, if this is the case you need to configure the VLAN also on Debian 10, edit again /etc/network/interfaces and add this: ## vlan for eth0 with ID - 5 ## auto eth0.5 iface eth0.5 inet static address 192.168.0.2 netmask 255.255.255.0 gateway 192.168.0.1 vlan-raw-device eth0 Replace VLAN ID 5 with your VLAN ID – DarkVex Feb 15 '20 at 21:28
  • I forget to say that you need also to install the vlan package in that case.. "apt-get install vlan" for manage the vlan and then load the kernel module "modprobe 8021q" – DarkVex Feb 15 '20 at 21:37
  • Thanks for the response. I don't have the vlan package, but I was able to load 8021q. After implementing the your suggested changes and restarting the networking daemon I get an error saying that ifup failed to bring up eth0. I commented the auto eth0 and allow-hotplug eth0 and moved them to /etc/network/interfaces.d/eth0 and I got the same error restarting the networking daemon. I will let you know if the error changes after installing vlan. – Yetoo Feb 15 '20 at 21:53
  • I installed vlan and then rebooted and the networking daemon now fails on ifup failing to bring up eth0.3. I believe 3 is the correct vlan id since the router interface states that this vlan id is 3. – Yetoo Feb 15 '20 at 22:24
  • 1
    Add the output of ifup -v eth0.3 to see what is failing. – Piotr P. Karwasz Feb 15 '20 at 22:25
0

I've seen the chat with @a-b you were able to get the VLAN working but you still have the issue with the scripts for bring up and down the interface. For load the 8021q module at boot just do:

echo 8021q | sudo tee -a /etc/modules

Then try to setup /etc/network/interfaces file in that way:

iface eth0 inet static

auto eth0.3
iface eth0.3 inet static
        address 192.168.0.2
        netmask 255.255.255.0
        gateway 192.168.0.1
        vlan-raw-device eth0
3
  • Router is incapacitated at the moment and I will have time tonight to fix it and test this. In the meantime, thanks for the response. – Yetoo Feb 17 '20 at 21:30
  • When I just had that in /etc/network/interfaces other than the loop back (commented out the source interfaces.d line so it wouldn't source), it couldn't bring up eth0 even with the 8021q module loaded. – Yetoo Feb 18 '20 at 7:39
  • I also want to mentioned I also tried commented relevant parts out of interfaces and changed eth0 in interfaces.d to just iface eth0 inet static, and it couldn't bring up eth0 even with the 8021q module loaded. Before, it was just eth0.3 that couldn't be loaded. – Yetoo Feb 18 '20 at 7:53
0

I resolved the issue with ifupdown.

If someone reading this didn't read the comments and other answer, install the vlan package ('apt-get install vlan' or dpkg -i <vlan package name.deb> (latter if you are offline and manually transferring the deb to the system)) and (I would reboot before loading and doing the next part) load the 8021q kernel module via modprobe 8021q and/or put 8021q in /etc/modules-load.d/modules.conf so it will be loaded at every boot. Then edit the following network configuration files as so (replace ips or other configuration options as needed):

Revision of /etc/network/interfaces that worked:

# 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 

Revision of /etc/network/interfaces.d/eth0 that worked:

# The primary network interface
auto eth0
allow-hotplug eth0
iface eth0 inet manual 
        pre-up ip link set dev $IFACE up
        pre-down ip link set dev $IFACE down

Revision of /etc/network/interfaces.d/eth0.3 that worked:

# The vlan network interface
auto eth0.3
allow-hotplug eth0.3
iface eth0.3 inet manual
        address 192.168.0.2
        netmask 255.255.255.0
        gateway 192.168.0.1
        vlan-raw-device eth0

Subsequently restarting the networking daemon (systemctl restart networking) should succeed (verify status with systemctl status networking) and pinging should be successful. A verification reboot (recommended) should yield the same.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.