linux-3qjp:~ # ip route list
default via 10.172.112.210 dev eth0 proto dhcp
10.172.112.0/24 dev eth0 proto kernel scope link src 10.172.112.121
192.168.102.0/24 dev vmnet8 proto kernel scope link src 192.168.102.1
192.168.239.0/24 dev vmnet1 proto kernel scope link src 192.168.239.1
linux-3qjp:~ # ip route del default
linux-3qjp:~ # ip route add default via 192.168.102.131 dev vmnet8
my route table (list) always go back to
linux-3qjp:~ # ip route list
default via 10.172.112.210 dev eth0 proto dhcp
10.172.112.0/24 dev eth0 proto kernel scope link src 10.172.112.121
192.168.102.0/24 dev vmnet8 proto kernel scope link src 192.168.102.1
192.168.239.0/24 dev vmnet1 proto kernel scope link src 192.168.239.1
Sorry, my post above was a bit in haste because I had to go. Back again.
First, you seem to have the wrong idea about what the ip statement does. It works on kernel data structures connected with networking. That means that when the kernel is stopped (shutdown of the system), all what is set there is lost. It sets them, but does not configure things for next network start. So it is normal what you experience, it returns to what is configured somewhere and not what you changed it into during your previous boot session.
So when you want to change parameters used at network start, you should alter the configurations. It is there where we come to the mising information:
Do you use wicked or NetworkManager?
In both cases, do you use DHCP or not (when using NM, most probably you do)?
linux-3qjp:~ # ip route show
default via 192.168.102.131 dev vmnet8
10.172.112.0/24 dev eth0 proto kernel scope link src 10.172.112.121
192.168.102.0/24 dev vmnet8 proto kernel scope link src 192.168.102.1
192.168.239.0/24 dev vmnet1 proto kernel scope link src 192.168.239.1
linux-3qjp:~ #
soo If you can explain to me step by step I will really be thankful
I guess I start to understand. We are probably discussing host with VMware player or workstation. In this case vmnet8 is indeed not “normal” interface and is created by vmware tools. Depending on ordering between vmware tools and network start script setting default gateway via YaST may not work.
In this case creating oneshot service that sets default route and ordering it after vmware tools is the most simple solution.
I see all participants realize that you are talking about a virtual network (and this means that your answer might be found in the archives of either this Forum or the Virtualization forum).
When you create virtual networks, they might have a default router gateway (eg a NAT network) or not (eg a Host-only network).
And, at least in the case of a NAT network, <usually> a DHCP server can provide network settings to the Guest (but for whatever reason may not be made available).
So,
If a DHCP server is available, it can be used to either configure the Guest or at least provide enough information to configure a static address and inform what the default gateway should be.
If you wish to configure the Guest manually, then you would do it the usual way(start by disabling DHCP client) depending on whether you’re using Wicked or NM.
You can also add additional routes but at the moment I find it difficult to think of a typical scenario for doing this… Remember that a basic rule is that all networks that are immediately adjacent to the machine (virtual or physical) are immediately discovered and an appropriate route is added for that network automatically. You add routes manually to typically inform the machine about <remote>, non-adjacent networks and the interface to use to direct packets to that remote network.
If you do need to create a <persistent> route manually, the traditional way is to add an entry to the appropriate network interface because as you’ve discovered, adding the route by command line is effective only for the current session. You can also use YaST to configure manual persistent routing.
Bottom line,
I think it might be useful to understand why you’re adding the route manually to understand whether you’re doing the right thing.
That configuration only creates default gateways, not ordinary routing entries.
Below that, you’ll find the tool that creates ordinary routes.
The reason why you can’t/shouldn’t configure a route pointing to a vmnet or any other kind of bridging device is that those bridging devices are ordinarily seen only by the HostOS, not the Guest.
It seems to me you probably don’t understand the architecture of how networks are exposed to the Guest.
Search this Forum and the Virtualization forum for posts I’ve written about networking, I’ve posted several times explanations on what is configured in the Guest and what is configured in the Guest Properties. If you’re unable to find what you need, ask again and I or someone can look up those Forum threads for you.
I rather suspect that the User is confusing running ifconfig in the Guest and the HostOS.
If running ifconfig in the Guest displays a vmnet device, then something is very wrong…
A vmnet and any other network bridge device should display only when running ifconfig on the HostOS.
Some people do configure network bridge devices in the Guest to represent virtual switches, but that’s another story and wouldn’t typically be called a vmnet which is ordinarily reserved for devices created by the VMware app (and a virtual switch within the Guest would not be).
I decided to post the following which might be useful for someone new to running VMware (Player or Workstation).
vment8 is the default bridge device supporting a NAT network, with its own internal DHCP.
When you configure the Guest Settings (VMware Manager > Guest > Settings > Netowrk) to use this device, it configures a NAT environment for the Guest, and for most beginners this is the best choice before experimenting with other settings.
When you configure the network settings <within> the Guest, you simply configure a DHCP client wired connection.
And, this shouldn’t be any different no matter what exists in the physical world… In the real, physical world the HostOS might be using a wireless connection, maybe a BT or fiber, over a VPN or any other odd setup, but internally within the Guest, the Guest will be blissfully unaware of what exists beyond its virtual environment. All it knows is that it has a working wired DHCP connection.
Because the network is NAT, the Guest also is running in its own network which has no relationship with anything in the real, physical world. the virtualization app (VMware) handles all communications and translation between the virtual network and the real world.
So, bottom line…
To the Guest,
It lives in its own world and knows very little beyond its NAT network, and this doesn’t ever change even if the real world networking changes in any way.
The reason why the Guest lives in its own isolated networking world is because through the Guest settings, VMware handles all network interactions.
my opensuse OS its my host not guest .
what i want to do its to run a firewall guest in vmware and i want that all the traffic will go from the guest outside to opensuse OS instead using the direct network connection (eth0) (or in other words that opensuse network traffic will come from vmware)
and thanks alot for your answers I really appreciate it.