static ip

**greg612** · 2 Days Ago

All this was done right after i changed yaml to static see post #56 for out of box yaml

Code:

network: 
    version: 2
    renderer: networkd
    ethernets:
        eno1:
          addresses:
              - 192.168.25.3/24
          nameservers:
              addresses: [9.9.9.9, 149.112.112.112]
          routes:
              - to: default
                via: 192.168.25.1

Here is pinging all the way out the door I can ping everything everything can ping it
james@mustang:/$ sudo netplan generate --debug and
sudo netplan apply

got no errors but it didnt show anything either I believe that is good?

Code:

james@mustang:/$ ip a
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 noprefixroute 
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether f8:b1:56:e4:ca:fc brd ff:ff:ff:ff:ff:ff
    altname enp0s25
    inet 192.168.25.3/24 brd 192.168.25.255 scope global eno1
       valid_lft forever preferred_lft forever
    inet6 fe80::fab1:56ff:fee4:cafc/64 scope link 
       valid_lft forever preferred_lft forever

james@mustang:/$ ip r
default via 192.168.25.1 dev eno1 proto static 
192.168.25.0/24 dev eno1 proto kernel scope link src 192.168.25.3
 
james@mustang:/$ ping 192.168.25.1
PING 192.168.25.1 (192.168.25.1) 56(84) bytes of data.
64 bytes from 192.168.25.1: icmp_seq=1 ttl=64 time=0.830 ms
64 bytes from 192.168.25.1: icmp_seq=2 ttl=64 time=0.776 ms
64 bytes from 192.168.25.1: icmp_seq=3 ttl=64 time=0.810 ms
64 bytes from 192.168.25.1: icmp_seq=4 ttl=64 time=0.754 ms
64 bytes from 192.168.25.1: icmp_seq=5 ttl=64 time=0.795 ms
64 bytes from 192.168.25.1: icmp_seq=6 ttl=64 time=0.807 ms
^C
--- 192.168.25.1 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5138ms
rtt min/avg/max/mdev = 0.754/0.795/0.830/0.024 ms

james@mustang:/$ ping 192.168.145.1
PING 192.168.145.1 (192.168.145.1) 56(84) bytes of data.
64 bytes from 192.168.145.1: icmp_seq=1 ttl=64 time=0.928 ms
64 bytes from 192.168.145.1: icmp_seq=2 ttl=64 time=0.787 ms
64 bytes from 192.168.145.1: icmp_seq=3 ttl=64 time=0.677 ms
64 bytes from 192.168.145.1: icmp_seq=4 ttl=64 time=0.674 ms
64 bytes from 192.168.145.1: icmp_seq=5 ttl=64 time=0.734 ms
64 bytes from 192.168.145.1: icmp_seq=6 ttl=64 time=0.661 ms
^C
--- 192.168.145.1 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5134ms
rtt min/avg/max/mdev = 0.661/0.743/0.928/0.093 ms

james@mustang:/$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
14 packets transmitted, 0 received, 100% packet loss, time 13312ms

james@mustang:/$ ping google.com

**TheFu** · 2 Days Ago

I must be stupid.
Some posts aren't labeled.
I don't understand which outputs are for which configurations. Please CLEARLY LABEL which outputs go with which netplan config. Don't be afraid to edit prior posts, so this thread doesn't get even longer. Usually if a thread isn't answered in the first 20 posts, it becomes a discussion or deadend because people get sidetracked.

https://netplan.readthedocs.io/en/la...-ip-addresses/ is the official documentation. The example at the top of that page ... seems pretty clear. Maybe following it would be better?

I do a number of things different on all my systems, so perhaps my working netplan files don't have the same complex interactions that Ubuntu forces? IDK.

When I look again at the netplan.yaml in post #42, I don't see anything wrong. In some of the others, I see missing dhcp4/6 lines or lines with "no", not "false".
I also don't see any search: lines. I've never NOT had those, but I have multiple LAN and WAN domains, so it has always made sense to have them. IDK if it matters, just that #42 doesn't.

Think I need a few days off from this problem. Hopefully, someone else will have some fresh ideas.

**greg612** · 2 Days Ago

I've never had search on there ever lol always worked thats what gets me out of all this.

I NEVER had a problem with setting a static ip They have all worked just fine

Til the last upgrade to 22.04 then it all quit working and hasnt worked since.

well im giving up growing real tired of this, maybe debain or the free red hat dont know Thanks

**MAFoElffen** · 2 Days Ago

@TheFu, @greg612 --

Originally Posted by TheFu

https://netplan.readthedocs.io/en/la...-ip-addresses/ is the official documentation. The example at the top of that page ... seems pretty clear. Maybe following it would be better?

I do a number of things different on all my systems, so perhaps my working netplan files don't have the same complex interactions that Ubuntu forces? IDK.

@TheFu -- You are going to hate this. But I have an alternate work-around at the end that goes along with what you do... I know this is a long-read (which isn't what you like), but it has details that will explain what changed, and what works now. I tried to summarize it without losing those details...

I brought this up in the Noble-DEV Cycle... That things were changing with Server 24.04 under-the-covers, that started back with 18.04...
RE: https://ubuntuforums.org/showthread....hlight=netplan
People blew me off, so I researched it, looked into it deeply, and made it work for me... I haven't shared (yet) what I really found under the covers there.

As TheFu knows that in 18.04, Ubuntu got deeper into using cloud-init... Which he hates. LOL. He has fought against it and used different ways to try to uninstall, disable and cripple it. Each release since then has deeper hooks using cloud-init. I keep that in the back of my mind, when things like this come up...

First thing is that, for security, they took away a bunch of the usual read permissions, and changed other permssion of system files like the netplan .yaml files, and the cloud-init .cfg files... So now to look at them with grep now, you have to use sudo.

This is how it is through 24.04 now...

Look at this (new) header to the new /etc/netplan/50-cloud-init.yaml file that is generated by the newer installs:

Code:

mafoelffen@maf-server1-0:~$ sudo grep . /etc/netplan/50-cloud-init.yaml
[sudo] password for mafoelffen: 
# This file is generated from information provided by the datasource.  Changes
# to it will not persist across an instance reboot.  To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    ethernets:
        enp1s0:
          dhcp4: true
          dhcp: true
    version: 2

The part in red, is how it is configured now, which will be explained in Option #1. The part of that in green will be explained in Option #2.

Option #1
What that means, is that, like when the old /etc/resolv.conf file changed from being a static file, to a dynamic file that can be overwritten, now this file is the same, overriden and overwritten if cloud-init reapplies it's settings. If you don't want that to happen, and make that into a static file again, skip to Option #2...

To make this work, how it is currently configured now, you have to edit file /etc/cloud/cloud.cfg.d/90-installer-network.cfg

Code:

mafoelffen@maf-server1-0:~$ sudo grep . /etc/cloud/cloud.cfg.d/90-installer-network.cfg
# This is the network config written by 'subiquity'
network:
  version: 2
  ethernets:
    enp1s0:
      dhcp4: true
      dhcp6: true

Note, when you first go to edit this file, it will contain whatever was used as network settings in the installer when it was installed. It used this file on the first boot, and used cloud-init to apply them...

This is what I changed that file to:

Code:

mafoelffen@maf-server1-0:~$ sudo grep . /etc/cloud/cloud.cfg.d/90-installer-network.cfg
# This is the network config written by 'MAFoElffen'
network:
  version: 2
  ethernets:
    enp1s0:
      addresses:
      - 192.168.122.52/24
      nameservers:
        addresses:
        - 9.9.9.9
        - 149.112.112.112
        search: []
      routes:
      - to: default
        via: 192.168.122.1
      optional: yes

Notice I changed things there to mirror what this OP is trying to use, except the specific address, which my server KVM VM was on a different subnet...

To trick cloud-init into thinking it is the first reboot, and reapply the changed network config... without changing major things with it, do this:

Code:

sudo rm /var/lib/cloud/data/instance-id
sudo cloud-init init --local

That will generate the new/updated /etc/netplan/50-cloud-init.yaml file... But if you check your ip stats, or do cloud-init... It is not applied yet... but check the .yaml file to make sure it was updated by cloud-init, before applying it...

Code:

mafoelffen@maf-server1-0:~$ sudo grep . /etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by the datasource.  Changes
# to it will not persist across an instance reboot.  To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    ethernets:
        enp1s0:
            addresses:
            - 192.168.122.52/24
            nameservers:
                addresses:
                - 9.9.9.9
                - 149.112.112.112
                search: []
            optional: true
            routes:
            -   to: default
                via: 192.168.122.1
    version: 2

If updated, then apply it.

Code:

sudo netplan generate
sudo netplan apply

Check it:

Code:

mafoelffen@maf-server1-0:~$ sudo cloud-init init
Cloud-init v. 24.1.3-0ubuntu3 running 'init' at Sun, 05 May 2024 17:09:38 +0000. Up 4890.62 seconds.
ci-info: ++++++++++++++++++++++++++++++++++++++Net device info++++++++++++++++++++++++++++++++++++++
ci-info: +--------+------+----------------------------+---------------+--------+-------------------+
ci-info: | Device |  Up  |          Address           |      Mask     | Scope  |     Hw-Address    |
ci-info: +--------+------+----------------------------+---------------+--------+-------------------+
ci-info: | enp1s0 | True |       192.168.122.52       | 255.255.255.0 | global | 52:54:00:3e:5f:43 |
ci-info: | enp1s0 | True | fe80::5054:ff:fe3e:5f43/64 |       .       |  link  | 52:54:00:3e:5f:43 |
ci-info: |   lo   | True |         127.0.0.1          |   255.0.0.0   |  host  |         .         |
ci-info: |   lo   | True |          ::1/128           |       .       |  host  |         .         |
ci-info: +--------+------+----------------------------+---------------+--------+-------------------+
ci-info: +++++++++++++++++++++++++++++++Route IPv4 info+++++++++++++++++++++++++++++++
ci-info: +-------+---------------+---------------+---------------+-----------+-------+
ci-info: | Route |  Destination  |    Gateway    |    Genmask    | Interface | Flags |
ci-info: +-------+---------------+---------------+---------------+-----------+-------+
ci-info: |   0   |    0.0.0.0    | 192.168.122.1 |    0.0.0.0    |   enp1s0  |   UG  |
ci-info: |   1   | 192.168.122.0 |    0.0.0.0    | 255.255.255.0 |   enp1s0  |   U   |
ci-info: +-------+---------------+---------------+---------------+-----------+-------+
ci-info: +++++++++++++++++++Route IPv6 info+++++++++++++++++++
ci-info: +-------+-------------+---------+-----------+-------+
ci-info: | Route | Destination | Gateway | Interface | Flags |
ci-info: +-------+-------------+---------+-----------+-------+
ci-info: |   0   |  fe80::/64  |    ::   |   enp1s0  |   U   |
ci-info: |   2   |    local    |    ::   |   enp1s0  |   U   |
ci-info: |   3   |  multicast  |    ::   |   enp1s0  |   U   |
ci-info: +-------+-------------+---------+-----------+-------+
mafoelffen@maf-server1-0:~$ ip a
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 noprefixroute 
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:3e:5f:43 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.52/24 brd 192.168.122.255 scope global enp1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe3e:5f43/64 scope link 
       valid_lft forever preferred_lft forever

Option #2
To stomp on that, and make your .yaml file(s) from getting overwritten... Create the file /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following contents:

Code:

network: {config: disabled}

You can then either delete file /etc/cloud/cloud.cfg.d/90-installer-network.cfg or not. Since the newer file is numbered starting with "99-*" the order of precedence is canonical, so it will apply what is later.

You can also either edit the /etc/netplan/50-cloud-init.yaml file with your changes, or delete it and create your own netplan .yaml file (or just rename it) that is more descriptive, implying it is no loner using cloud-init, such as /etc/netplan/01-network-config.yaml

Option #2 is the simpler way, which I think most people might follow... Because it follows what has been working recently, and is know, with less steps to make changes. Just be aware that with every release, it digs deeper into this newer strategy in Option #1.

**Doug S** · 1 Day Ago

I agree this thread has been hard to follow.

Originally Posted by greg612

Code:

james@mustang:/$ ping 192.168.145.1
PING 192.168.145.1 (192.168.145.1) 56(84) bytes of data.
64 bytes from 192.168.145.1: icmp_seq=1 ttl=64 time=0.928 ms
...

Okay, well, that is address is new. It might be an idea to know more about your LAN and if packet monitoring is possible on 192.168.25.1 and/or 192.168.145.1?

If you are willing, I'd like to try something different. It might be waste of time. The question I am wanting to answer is: Is it the send or return path that is the problem? I would PM you my external static IP address and set tcpdump on that externally facing server to monitor ICMP traffic to observe if your ping packets are actually being sent out to internet.

EDIT: If you have some packet monitoring ability on your routers, you should be able to check the send and return paths yourself. Example from mine:

1: External IF:

Code:

doug@s15:~$ sudo tcpdump -tttt -n -i enp1s0 icmp
[sudo] password for doug:
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
2024-05-05 14:18:40.656692 IP WW.XXX.YYY.ZZZ > 8.8.8.8: ICMP echo request, id 4030, seq 1, length 64
2024-05-05 14:18:40.661764 IP 8.8.8.8 > WW.XXX.YYY.ZZZ: ICMP echo reply, id 4030, seq 1, length 64
2024-05-05 14:18:41.658189 IP WW.XXX.YYY.ZZZ > 8.8.8.8: ICMP echo request, id 4030, seq 2, length 64
2024-05-05 14:18:41.662782 IP 8.8.8.8 > WW.XXX.YYY.ZZZ: ICMP echo reply, id 4030, seq 2, length 64
2024-05-05 14:18:42.660189 IP WW.XXX.YYY.ZZZ > 8.8.8.8: ICMP echo request, id 4030, seq 3, length 64
2024-05-05 14:18:42.664789 IP 8.8.8.8 > WW.XXX.YYY.ZZZ: ICMP echo reply, id 4030, seq 3, length 64
2024-05-05 14:18:43.662198 IP WW.XXX.YYY.ZZZ > 8.8.8.8: ICMP echo request, id 4030, seq 4, length 64
2024-05-05 14:18:43.666787 IP 8.8.8.8 > WW.XXX.YYY.ZZZ: ICMP echo reply, id 4030, seq 4, length 64
^C
8 packets captured
8 packets received by filter
0 packets dropped by kernel

2: Internal IF:

Code:

doug@s15:~$ sudo tcpdump -tttt -n -i br0 icmp
[sudo] password for doug:
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
... delete some unrelated ICMP  "tcp port 443 unreachable" packets ...
2024-05-05 14:18:40.656639 IP 192.168.111.136 > 8.8.8.8: ICMP echo request, id 4030, seq 1, length 64
2024-05-05 14:18:40.661788 IP 8.8.8.8 > 192.168.111.136: ICMP echo reply, id 4030, seq 1, length 64
2024-05-05 14:18:41.658163 IP 192.168.111.136 > 8.8.8.8: ICMP echo request, id 4030, seq 2, length 64
2024-05-05 14:18:41.662804 IP 8.8.8.8 > 192.168.111.136: ICMP echo reply, id 4030, seq 2, length 64
2024-05-05 14:18:42.660163 IP 192.168.111.136 > 8.8.8.8: ICMP echo request, id 4030, seq 3, length 64
2024-05-05 14:18:42.664811 IP 8.8.8.8 > 192.168.111.136: ICMP echo reply, id 4030, seq 3, length 64
2024-05-05 14:18:43.662172 IP 192.168.111.136 > 8.8.8.8: ICMP echo request, id 4030, seq 4, length 64
2024-05-05 14:18:43.666809 IP 8.8.8.8 > 192.168.111.136: ICMP echo reply, id 4030, seq 4, length 64
^C

3: The internal client computer (192.168.111.136):

Code:

doug@s19:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=60 time=5.34 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=60 time=4.84 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=60 time=4.84 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=60 time=4.83 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 4.832/4.962/5.341/0.218 ms
doug@s19:~$

**greg612** · 1 Day Ago

I will report back packing to leave for work at moment . If i cannot get to it tonight it will be thursday....... I wont leave u hanging we all have to much invested in it now.... Besides I really want to know wtf ya know

**MAFoElffen** · 1 Day Ago

+1 -- Also traceroute, tracepath, mtr & netstat...

Since I did this for a while, having 'many' hats and being exposed to a whole lot of things (CISCO Academy being part of that), people these days do not seem to bring up the older tools that have been around for ages. WireShark is very powerful and a great tool for seeing exactly what is going on. I used that a lot for network diagnostics.

Seeing things as they happen, you can try to understand what is not working right. Lack of information, is like... Then you have to rule out all the myriad of possibilities. Better to check things off, of what isn't the problem to narrow the search to what something 'could be'.

One of my niche's is "diagnostics"... Logically breaking things down to how they should work, and what happens if that step doesn't, into a flow chart kind of affair, to figure out what may be the problem,

**TheFu** · 1 Day Ago

Don't forget chattr, for when files are being changed and you don't want that. For a few years right after resolvconf was introduced, I'd delete the symlink for /etc/resolv.conf, create a new file with my DNS settings, then make it immutable. Worked great, until I forgot the flag was set and couldn't update it. Same with setfacl. When normal permissions aren't working as expected, it can drive me crazy. Now I know to check both ACLs and attribs, but 25 yrs ago, those were new enough to me that I didn't think of them as likely.

In capture the flag competitions, I like to screw with other teams using chattr. Nobody thinks of it. They just don't.

Thread: static ip

Thread Tools

Display

Re: static ip

Re: static ip

Re: static ip

Re: static ip

Re: static ip

Re: static ip

Re: static ip

Re: static ip

Bookmarks

Bookmarks

Posting Permissions