Ubuntu 18.04.5 LTS Network is defind but cannot get to anything even an identical(except IP) system

Screen captures for above items off one of the two VMs.

If I list the other hoost in the /etc/hosts file I'm able to ping.
This seems like an issue of DNS server settings. How do I get them to set -the yaml file was supposed to do that based on the syntax I followed. These were working prior to thet IP changes.
2020-12-12_21-41-24.jpg
2020-12-12_21-43-53.jpg
2020-12-12_21-45-00.jpg
2020-12-12_21-54-22.jpg
2020-12-12_22-10-07.jpg
2020-12-12_22-13-09.jpg

First change your /etc/resolv.conf file to by this...

nameserver 1.1.1.1
nameserver 8.8.8.8
nameserver 8.8.4.4

Select allOpen in new window

Which will likely be sufficient to get your DNS working... as /etc/hosts entries simply usurp/hijack DNS resolution.

Update this comment + mention if the above /etc/resolv.conf provides a temporary fix.

Note: The IP 24.196.87.83 is currently unpingable.

Also nmap suggests no services are running, so this IP seems to be completely offline.

Might be your router (looks like your ISP is Charter/Spectrum) has some old gateway or IP cached.

Also mentions if pinging 1.1.1.1 + 8.8.8.8 works or fails.

Have a) all applicable MX, A, AAAA and CNAME DNS records been updated and b) 24 hours has passed since the update?

If dynamic DNS is in use, has ddclient's configuration file been updated and the results checked in /var/log/ddclient?

So they can't ping each other? Can you ping 24.196.87.65 from each server?

Your ISP gateway address of 24.196.87.65 pings back, so that's good.

And... normally I'd expect your gateway address to be 24.196.87.254 so maybe your gateway address is incorrect.

You're running systemd-resolved which is one of the most broken excuses of code in the wild.

As soon as you restore some connectivity, remove + replace systemd-resolved with dnsmasq.

https://www.experts-exchange.com/questions/29162917/Huge-DNS-queries-from-openshift.html provides instructions to completely nuke systemd-resolved, blocking it from ever being revived by any future system update.

And... normally I'd expect your gateway address to be 24.196.87.254 so maybe your gateway address is incorrect.

Not all networks use a /24 (255.255.255.0) subnet mask. The gateway address is fine as it is within the configured network range.

I see, your last image shows 8.8.8.8 is unpingable.

Mention exactly what changed on this system, it's entire history.

For example, changing an IP in /etc/netplan/50-cloud-init.yaml will never work, if you're using a plain vanilla Ubuntu Bionic install.

Detail the entire history of this machine

1) Why the IP changed.

2) Every single /etc/* file change you made.

3) If this is actually a machine or container or VM instance.

Tip: Run a find + grep across all /etc files searching for your previous IP address + your base interface name + provide a list of files where these strings are found.

Post the output from the following on each server...

ping 24.196.87.65
netstat -rn

Select allOpen in new window

Try this check, replacing eno1 with your base interface name.

net14 # find /etc -type f -exec egrep -l -e 51.79.19.215 -e eno1 {} \;
/etc/systemd/network/50-public-interface.link
/etc/systemd/network/50-default.network
/etc/motd
/etc/sysctl.d/disable-IPv6-autoconf.conf
/etc/hosts

Select allOpen in new window

For plain vanilla Ubuntu Bionic installs, there should be 0 files in /etc/netplan.

The reason you get the error message "enp0s3 is not for us" is likely because one of the /etc/systemd/network files has already run (higher order of precedence - runs first) to already do some enp0s3 work, so by the time /etc/netplan/* files run (much later), part or all of these files has no effect.

If you have a plain vanilla Bionic install, remove all /etc/netplan files, the find the exact file where your interface + old IP was set, then only make changes to these exact files.

Note: Be sure to keep copies of all original files for reference.

David Favor
No luck making those changes. Do I have to restart something or will it change with just an edit?

pinging 8.8.8.8 fails as well as 1.1.1.1

I've power cycled both the modem and router and flushed the arp table on the router.
2020-12-13_07-31-49.jpg

Dr. Klahn:

Yes the DNS has been updated and passes the check for config and syntax.
Its been down since 12/7/20

some one not unless I put the other system i.n my hosts file other wise it's Destination host unreachable.

Its static IP so the DHCP issue does not apply

David Favor
No, the gateway is definately24.196.87.65 it's working on every other device - Windows Server, 3 raspberry pi's an iMac 4 echo dots and a printer

David Favor:
IP Had to change because we changed ISPs from a local provider to Spectrum for more bandwidth.
This is a VM running on Oracle Virtual box as is the other system. The settings for network are bridged and that hasn't changed and used to be fine for years before the ip change

Files Changes
root@eagle:/# grep -rnwl 64.250.105 '/var' | more
/var/lib/denyhosts/hosts
/var/lib/denyhosts/purge-history
/var/lib/denyhosts/hosts-valid
/var/lib/denyhosts/users-hosts
/var/lib/denyhosts/hosts-restricted
/var/lib/denyhosts/sync-received
/var/lib/denyhosts/hosts-root
/var/cache/debconf/config.dat-old
/var/cache/debconf/config.dat

root@eagle:/# grep -rnwl 64.250.105 '/etc'
/etc/cloud/cloud.cfg.d/50-curtin-networking.cfg
/etc/nagios/nrpe.cfg
/etc/nagios/nrpe_local.cfg
/etc/netplan/50-cloud-init.yaml
/etc/fail2ban/jail.local
/etc/postfix/main.cf
/etc/hosts.deny
/etc/hosts.deny.purge.bak
/etc/hosts.allow
/etc/hosts

some one:

See attached
2020-12-13_08-00-09.jpg

David Foster hare is the find output

No old addresses in either file
2020-12-13_08-00-09.jpg

Removed files no better
Attached current interfaces file
2020-12-13_08-14-57.jpg

Might be easier to just setup a new VM + get it working.

Then record the file settings + compare them with the VM that's not working.

Since you can't ping the gateway address from inside the VM, trying pinging from your local machine (almost surely this will work).

If gateway ping works from the machine + fails from inside the VM, then your first fix will be the VM's networking, as pings from inside VM to gateway must succeed before any networking changes you make will have any effect.

some one not unless I put the other system i.n my hosts file other wise it's Destination host unreachable.

Its static IP so the DHCP issue does not apply

Were you replying to me there?

I am just asking for IP connectivity, not DNS or connectivity using hostnames so you shouldn't have to put anything in a hosts file in order for IP connectivity to be successful. Also, I never mentioned DHCP.

Can you provide output from the following command on each server, please:

arp -a

Select allOpen in new window

some one
Sorry if I mixed the reply up last time

Here you go
2020-12-13_09-11-49.jpg

David yes ping wirks from the windows server and it will work on the VM if there's a host file entry for the remote system. I can ping each server from the other but I've got both in /etc/hosts allow.

So you can ping the servers from each other?

Have you checked the VM networking configuration? If the servers can ping each other but not their gateway I'd check that the VM NICs are configured correctly in the hypervisor.

I've made no changes to the Oracle VirtualBox settings at all. their bridged in both cases abd are using the primary windows network adapter hust like the previous ip set up did. it seems like DNS is somehow not right because if I add an entry to /etc/hosts then I can ping and access the system in the file.

If you can't ping the gateway using the IP address you have bigger problems. DNS is not used in any way in order for the two servers to ping the gateway IP. If that doesn't work you've got a bigger issue than DNS resolution.

What do you mean exactly when you say...

if I add an entry to /etc/hosts then I can ping and access the system in the file.

If I add a host to /etc/hosts I'm able to successfully ping it.

Spectrum kills gateway pings on their POS wireless gateway/router. (I'm tempted to replace it with my almost new Netgear R7000)

Attached is my route table

Please be specific in what you're referring to with "bigger problems" Nothing but an IP Address was changed here the system could be put back to old settings with untaring a file but I lose access to that old ISP and IP Range by 12/31 so this has to be working by then.
2020-12-13_20-33-11.jpg

FYI The VirtualBox network settings are attached
2020-12-13_21-39-37.jpg

I'm not a VirtualBox expert but would be worth rebooting the entire server? Not sure I HAVEN'T done it before but doing it would insure we tried that.

you probably should be using the netplan utility instead of modifying runtime and files

Kelly:

I modify the 50 file in etc netplan then run netplan --debug apply is there some other way to do this? Thats what I've seen in various sites as the correct method.

You said, "David yes ping works from the windows server and it will work on the VM if there's a host file entry for the remote system. I can ping each server from the other but I've got both in /etc/hosts allow."

If you can ping IPs from with your VM, just not hosts, this points to a DNS problem.

So try these + verify the IP ping works + the host ping fails.

imac> ping -c 1 google.com
PING google.com (172.217.9.142): 56 data bytes
64 bytes from 172.217.9.142: icmp_seq=0 ttl=118 time=8.565 ms

--- google.com ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 8.565/8.565/8.565/0.000 ms

imac> ping -c 1 172.217.9.142
PING 172.217.9.142 (172.217.9.142): 56 data bytes
64 bytes from 172.217.9.142: icmp_seq=0 ttl=118 time=7.252 ms

--- 172.217.9.142 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 7.252/7.252/7.252/0.000 ms

Select allOpen in new window

If the IP ping works + ping by host/domain fails, your next step will be to debug your DNS.

First step of DNS debugging will be to see who's listening on DNS ports.

Provide the output of the following, which will likely show your local DNS listeners...

netstat -pluten | egrep :53

Select allOpen in new window

You should read the netplan manual. https://ubuntu.com/blog/ubuntu-bionic-netplan

note that manual modifications of resolv.conf will be overwritten by the system as modern Ubuntu uses templates for network resolution.

Again read the netplan howto, it's short and easy.

David Favor:

BOTH FAILED....

your other test along with the other 2 are attached.

Thanks for the clear instructions.
2020-12-14_21-13-13.jpg

Kelly Black:

Thanks I tool a look for *.yaml files in the indicated locations.

Not a one. Result capture attached.

It still looks to me like a problem with the host networking configuration. Your arp output shows that you cans resolve the MAC address of anything.

I'm not sure what network configuration you're shooting for. But were I in your shoes, I'd start by looking at these examples to set up netplan at:

https://netplan.io/examples/

Ubuntu is designed such that using netplan to manage your network will be cleaner than modifying files. If it was previously setup using the files method, the configuration would be in

/etc/network/interfaces

Select allOpen in new window

Note that in Ubuntu networking is so easy that you can literally set it up temporarily from command line to test, something like:

sudo ifconfig eth0 192.168.72.6 netmask 255.255.255.0

Select allOpen in new window

sudo route add default gw 192.168.72.1 eth0

Select allOpen in new window

If you still have problems at that point, there's a more fundamental issue, like the network connection itself.
Kettering's Observation: When a problem becomes intensely complicated, it's usually a fundamental that is wrong.

sudo lshw -class network -short

Or you can use "dmesg | more" to verify that the ethernet controller was in fact installed.

Do Not Forget: when you use something like files or netplan to modify the network config, you'll need to reload it with:

sudo systemctl restart networking

Select allOpen in new window

I'll take a look at these tomorrow too late here tonight. These are the only two systems (and VMS) that are having issues with the new ISP network.


Side question - I have a 16 port switch down by the ISP routers for each network. can I plug both routers into that same switch and be able to use either network depending on how I configure the server's network? Anything special I need to do? I want to possibly roll back to the old setup that works and then restart the changes from the beginning and carefully watch what changes at each step.. The switches are dumb. No segmentation, VLANs or management in either.

Dumb switches would be called a hub. if they are just hubs then you could do that, but you'll be getting a good deal of collision. If they are indeed switches, you would want to configure them to the ISP gateway, and run dhcp on the inside. search for "setting up a DMZ in networking "

they are both switches but completely unmanaged. Plugin and run.

I'm not sure exactly where it's going. switches imply that there's an intelligent operating system in the box so it's comfigurable. if they auto configure there's no guarantee the settings are compatible across the network.

with regards to your original question: on the VM systems Ensure that the network adapter is configured for NAT or Bridged, and not Host Only

if you still have problems, bypass the switch and route the host computers network cable directly to the main router as a test.

if none of this is working there's a layer here. the problem gets convoluted by bringing other questions into it. Try to resolve it

Dumb switches are called unmanaged switches. Hubs and switches are different things and should not be confused.

unmanaged switch is just a collision avoidant hub. if you're going to contribute, contribute. don't just cross talk.

this isn't even part of the original question

I came here for help not a holy war over switch vs. hub and what is or isn't part of the definition. you all have a nice day now. I'll be rebuilding both vms with Ubuntu 20.04.x

Kelly, I have contributed. You made an incorrect statement in relation to what you referred to as something which wasn’t part of the original question . I simply cleared up an important distinction. I’ll clear up another incorrect statement too, in that an unmanaged switch isn’t just a collision-avoidant hub.

And George, you have received help. Your reaction is a little over the top. Good luck with your rebuild.