Announcement

Collapse
No announcement yet.

Mystery secondary IP address

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Mystery secondary IP address

    I was mucking about on my server - Ubuntu 18.04 headless (as in no desktop). I occasionally engage a VPN connection manually then turn it off when I feel I don't need it (speed difference). I was checking my network connections to see if the VPN was up or down and I noticed my local network connection had TWO IP addresses. It had the one I statically assigned, and another listed as "secondary" which I had never seen before. Note that I am not using network manager. I use networkd to control the network.

    Code:
    [FONT=monospace][COLOR=#54FF54][B]smith@server[/B][/COLOR][COLOR=#000000]:[/COLOR][COLOR=#5454FF][B]~[/B][/COLOR][COLOR=#000000]$ ip add[/COLOR]
    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
    2: enp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
        link/ether fc:aa:14:91:fd:c3 brd ff:ff:ff:ff:ff:ff
    3: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
        link/ether fc:aa:14:91:fd:c1 brd ff:ff:ff:ff:ff:ff
        inet 192.168.1.250/23 brd 192.168.1.255 scope global eno1
           valid_lft forever preferred_lft forever
        [B]inet 192.168.1.86/23 brd 192.168.1.255 scope global secondary eno1[/B]
           valid_lft forever preferred_lft forever
        inet6 fe80::feaa:14ff:fe91:fdc1/64 scope link  
           valid_lft forever preferred_lft forever
    4: wlp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
        link/ether ac:fd:ce:21:ac:0f brd ff:ff:ff:ff:ff:ff[/FONT]
    Also interesting is the old "ifconfig" command does not display the secondary IP, which might be why they've moved to using the "ip" utility instead.

    Does anyone know where this is from or why this happened and how to stop it? I'm not really sure if it's causing any problems, but I have been having an odd network behavior lately where, when my VPN is on, the network would freeze - just stop transmitting and receiving. Turning the VPN off and them back on always resolves it, but it's unpredictable and annoying. This only started a few weeks ago so I'm wondering if some update caused this.

    My netplan config is basic:
    Code:
    [FONT=monospace][COLOR=#54FF54][B]smith@server[/B][/COLOR][COLOR=#000000]:[/COLOR][COLOR=#5454FF][B]~[/B][/COLOR][COLOR=#000000]$ cat /etc/netplan/01-netcfg.yaml  [/COLOR]
    # This file describes the network interfaces available on your system
    # For more information, see netplan(5).
    network:
      version: 2
      renderer: networkd
      ethernets:
        eno1:
          dhcp4: no
          dhcp6: no
          addresses: [192.168.1.250/23]
          gateway4: 192.168.1.1
          nameservers:
            addresses: [8.8.8.8,8.8.4.4]
    #    enp2s0:
    #      dhcp4: yes[/FONT]
    Here's what I found and what I've done:
    • A web search reveals this could occur when dhcp is running on the client machine (rather than getting an IP from the network). However, I use a static IP so there is (should) be no dhcp activity at all.
    • A quick "sudo systemctl stop dhcpcd" resulted in "...service not loaded..." so that wasn't it.
    • Then I tried to see what what had created the secondary IP so I ran "ps aux | grep dhc" which revealed this: "root 2494 0.0 0.0 25992 2804 ? Ss Oct28 0:04 /sbin/dhclient -q -e eno1"
    • So I killed that process but the secondary IP remained, so I removed it manually with : "sudo ip address del 192.168.1.86/23 dev eno1"


    Now I have one IP. I haven't had a change to reboot the server yet to see if it comes back, but I'm guessing it will. Anyone have any ides what would cause this?

    Please Read Me

    #2
    Not Kubuntu, but the content might lead you in the right direction. See https://raspberrypi.stackexchange.co...y-ip-come-from
    Using Kubuntu Linux since March 23, 2007
    "It is a capital mistake to theorize before one has data." - Sherlock Holmes

    Comment


      #3
      Originally posted by Snowhog View Post
      Not Kubuntu, but the content might lead you in the right direction. See https://raspberrypi.stackexchange.co...y-ip-come-from
      Yeah, I saw that but there is no dchp daemon installed on the system in question and those files the referenced don't exist.

      Please Read Me

      Comment

      Working...
      X