mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether 02:00:00:00:00:24 brd ff:ff:ff:ff:ff:ff
inet 10.17.1.139/26 brd 10.17.1.191 scope global eth0
inet6 fe80::ff:fe00:24/64 scope link
valid_lft forever preferred_lft forever
wcs-mf-smt:~ # ip r
default via 10.17.1.129 dev eth0
10.17.1.128/26 dev eth0 proto kernel scope link src 10.17.1.139
127.0.0.0/8 dev lo scope link
169.254.0.0/16 dev eth0 scope link
wcs-mf-smt:~ # ip neigh
10.17.1.129 dev eth0 lladdr 00:00:0c:9f:f2:00 REACHABLE
`
Harley
---
### Author:  [@ab1](https://forums.suse.com/u/ab1)
#### Post date: [December 5, 2017, 8:26pm UTC](https://forums.suse.com/t/sles-12-network-issue/30625/4 "2017-12-05T20:26:23Z")
Unless I am missing something, your broken box does not have a default
route. Your ‘ip r’ information shows one route, for the local network,
but that does not help at all when you want to get packets from here to
any other box off the local network, including back to where packets
arriving from there originated.
Compare the output from your broken and working boxes, respectively:
Broken:
```auto
wcs-mf-winxs-db2p:/tmp # ip r
10.17.1.128/26 dev eth0 proto kernel scope link src 10.17.1.156
```
Working:
```auto
wcs-mf-smt:~ # ip r
default via 10.17.1.129 dev eth0
10.17.1.128/26 dev eth0 proto kernel scope link src 10.17.1.139
127.0.0.0/8 dev lo scope link
169.254.0.0/16 dev eth0 scope link
```
Try adding the default route of 100.17.1.129 to your broken box. On non-Z
systems I do this with ‘yast lan’, like this:
```auto
sudo /sbin/yast lan
```
In there you should see a tab for routing, and in there is a spot for an
IPv4 default gateway. Put in the IP address, save/Finish, and then test
again.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.
If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
---
### Author:  [@x0500hl](https://forums.suse.com/u/x0500hl)
#### Post date: [December 5, 2017, 9:15pm UTC](https://forums.suse.com/t/sles-12-network-issue/30625/5 "2017-12-05T21:15:49Z")
I think that you mis-typed as there isn’t a 100.17.1.129 it is 10.17.1.129.
/etc/sysconfig/network/routes contains
```auto
default 10.17.1.129 - -
```
On the Routing tab of ‘yast lan’:
Default IPv4 Gateway is set to 10.17.1.129.
Default IPv6 Gateway is blank.
The Routing Table box is empty.
Enable IPv4 Forwarding is unchecked.
Enable IPv6 Forwarding is unchecked.
Not sure where to make the change you suggested.
---
### Author:  [@x0500hl](https://forums.suse.com/u/x0500hl)
#### Post date: [December 5, 2017, 10:10pm UTC](https://forums.suse.com/t/sles-12-network-issue/30625/6 "2017-12-05T22:10:03Z")
Ab,
I was also working this issue with the Network team here (the router and firewall folks). One of them found that the default gateway was not being picked up from /etc/sysconfig/network/routes. He had me run ‘netstat -rnv’ and it displayed:
`wcs-mf-winxs-db2p:/tmp # netstat -rnv
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.17.1.128 0.0.0.0 255.255.255.192 U 0 0 0 eth0`
He then had me temporarily add a gateway by issuing ‘route add default gw 10.17.1.129’. I was then able to PuTTY into the server.
Any idea how to make this permanent (i.e. without coding a script to issue the command at boot time)? I will continue to research how to accomplish that.
Harley
---
### Author:  [@ab1](https://forums.suse.com/u/ab1)
#### Post date: [December 6, 2017, 12:26am UTC](https://forums.suse.com/t/sles-12-network-issue/30625/7 "2017-12-06T00:26:27Z")
Yes, exactly; I’m glad the same conclusion was reached.
It should already be permanent, per the configuration files, but it seems
the networking configuration or stack is a bit off. I have seen routes
NOT-add properly when the required NIC was not yet fully up, but I presume
you are using static IP addresses, so that should be unlikely. I’ve also
seen odd things happen when there was a duplicate IP on the network
somewhere, as the system may try to avoid conflicts for you since those
are generally bad; any chance of that situation happening lately?
Do you see anything useful when trying to get the status of the network
service?
```auto
sudo systemctl status network
```
For fun, while on the box physically-ish, could you restart your
networking to see if it comes up properly now that the rest of the system
is already working/booted?
```auto
sudo systemctl restart network
```
As a note, while it is probably generally fine to do, I’ve seldom worked
with the files under /etc/sysconfig/network/ directly, and would generally
recommend using Yast to configure things when doing so manually. Yast is
pretty robust, particularly around networking, and uses those files
itself; since I have had great luck using Yast, and seldom any problems
like this, it makes me wonder if some of the magical bits may be unhappy
with your changes for some pesky reason. To be fair, you already know I
am not a Z-series expert, so maybe issues there happen more-often in these
cases and all of my experience is for naught.
The route command basically shows the same thing as the ‘ip’ command, so
that’s good, and adding a route manually via ip (or route) does what the
system should be doing behind the scenes. Hopefully we can find something
in the logs (above) that will help us figure things out.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.
If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
---
### Author:  [@x0500hl](https://forums.suse.com/u/x0500hl)
#### Post date: [December 15, 2017, 4:35pm UTC](https://forums.suse.com/t/sles-12-network-issue/30625/8 "2017-12-15T16:35:07Z")
Ab,
Your asking for info from ‘sudo systemctl status network’ showed me what my problem is.
In order to clone the disk for the server I needed to have it come up with a new IP address as the ‘real’ server is up an running. I saved a copy of ifcfg-eth0 in /etc/sysconfig/network and called it ifcfg-eth0.save.
[CODE]wcs-mf-winxs-db2p:~ # systemctl status network
â wicked.service - wicked managed network interfaces
Loaded: loaded (/usr/lib/systemd/system/wicked.service; enabled; vendor preset: disabled)
Active: active (exited) since Wed 2017-12-06 07:53:35 CST; 14s ago
Process: 1884 ExecStart=/usr/sbin/wicked --systemd ifup all (code=exited, status=0/SUCCESS)
Main PID: 1884 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 512)
CGroup: /system.slice/wicked.service
Dec 06 07:53:04 wcs-mf-winxs-db2p systemd[1]: Starting wicked managed network interfaces…
Dec 06 07:53:35 wcs-mf-winxs-db2p wicked[1884]: lo up
Dec 06 07:53:35 wcs-mf-winxs-db2p wicked[1884]: eth0 up
Dec 06 07:53:35 wcs-mf-winxs-db2p wicked[1884]: eth0.save no-device
Dec 06 07:53:35 wcs-mf-winxs-db2p systemd[1]: Started wicked managed network interfaces.
[/CODE]
Seeing the ‘eth0.save’ in the list rang a bell where (about 10 years ago) we had weird network issues upgrading to SLES 10 when we named a saved copy as filename.save. I renamed ifcfg-eth0.save to save.ifcfg-eth0, rebooted, and tested. I was able to PuTTY in without issuing the temporary command to define the gateway.
Thank you very much for your assistance with this.
Harley
---
### Author:  [@ab1](https://forums.suse.com/u/ab1)
#### Post date: [December 15, 2017, 5:24pm UTC](https://forums.suse.com/t/sles-12-network-issue/30625/9 "2017-12-15T17:24:28Z")
Well that’s just great! Thank-you for posting back how you found the
issue as that is one worth remembering, and since memories are imperfect,
this is worth indexing via Google.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.
If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.