The mystery of the disappearing default routes
I was last week at a customer that had a strange problem: While installing the system the default route was disappearing. Those default routes are stored at the same place where all other persistent routes are stored and not at
/etc/defaultrouterin Solaris 11 Just by setting
/etc/defaultrouter they were able to set it. It took me a moment to find out was happening.
They installed the system via a 1 GBit/s interface and were moving afterwards to a group of IPMPed 10 Gbit/s interface for production purposes. After the move the default route was missing and they were setting it manually.
Okay, i’m now deleting the IP interface and renaming the data link:
Or use a different interface, that was the thing the customer did. Now configure an IP-address on this ip interface
Now I try to ping.
Okay, it seems the default route isn’t working because i was able to ping systems in the same subnet. Let’s reboot the system in order to go to the standard default route setting procedure and
Okay, a short look into routing table.
And so the result of the next command is inevitable … no route to host because there is indeed no route to host.
So, when you look into the method script of
svc:/network/routing-setup:default(the service responsible for setting at
/lib/svc/method/net-routing-setup, you will find the following part at the end.
So the persistent routes are read from the
/etc/inet/static_routes file. Let’s have a look into it:
So let’s do the same as the script.
So this explains why the route is missing. In this case it’s the
-ifp part. The IP interface simply doesn’t exists.
But where does this part originate from? It is set in the
However there is a good question, why there is the the
-ifp net0. Explicitly naming the interface is meant to side step several issues that could arise when having more than one interface in the system. And the behaviour of the system is perfectly reasonable as soon as you know that the default route as configured by the installation process isn’t in
/etc/inet/static_routes instead and is extended by the interface.
The next question was: Why did the
/etc/defaultrouter worked. This behaves the way you know it.
In the method script
/lib/svc/method/net-routing-setup you will find the following sequence of commands.
So this way to set the default route doesn’t set the default route with
-ifp, so it works after a renaming in the same way. In the case of the customer, the default route set by the installation failed because of the
-ifp with a non existing interface name, however before this the script using the
/etc/defaultrouter already set a valid default route.
The solution to this? You could directly edit the file and change the interface name (or just deleting the
-ifp net0 part. However there is a “do not edit marker”. Let us at least pretend for a second that we read such comments. The correct way is:
However with IPMP everything is different
However for the most common case (i would say 90%) of an interface name change, it’s different. When you use IPMP the routes using the member interface are automatically translated to routes for the ipmp interface. The usual check if we can reach systems outside of our network.
Okay, a route is on
net0 as the
netstat output shows.
I just delete the old interface and with it the configured addresses and create an IPMP group with just a single interface in it.
Okay, now i will assign the old address to it.
Let’s check the routing table.
Okay, route is missing. I will just restart the route configuration.
Yet another look to the routing table.
Et voila, there is a default gateway via
ipmp0. However in the file with the persistent static routes, the route is still stored as a route for
The system automatically converts the route for net0 to a route for ipmp0. You can easily do it, as it’s a somewhat safe assumption, that a already existing route for interface would be valid as well for an ipmp group with this interface.
Okay, let’s just check if this persists a boot, so i’m rebooting the system.
So it’s the same after aboot