# Why an explicit static route for my def. gateway? [SOLVED]

## damato

I dunno when exactly it happend. But today I had to reboot my server which normally obtains the IP address via DHCP from my provider. However, during reboot it obtained the IP, but failed to set the default gateway. In fact, the following error was outputted instead:

```

 *   Bringing up eth0

 *     dhcp

 *       Running dhclient ...SIOCADDRT: Network is unreachable

                                             [ ok ]

 *       eth0 received address 212.227.132.120/32

```

However, after having looked at the routing tables it showed up as:

```

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo

```

Nothing more. Of course I tried then to add the defaul gateway manually like that:

```

# ip route add default via 10.255.255.1 dev eth0

RTNETLINK answers: Network is unreachable

```

That was the point when I started to get curious of what the heck is going on here because IMHO such a call shouldn't at all be refused with network unreachable, because ifconfig or ip addr show perfectly shows the eth0 device to be up and running:

```

eth0      Link encap:Ethernet  HWaddr 00:10:4F:1A:79:96  

          inet addr:212.227.132.120  Bcast:212.227.132.120  Mask:255.255.255.255

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:348 errors:0 dropped:0 overruns:0 frame:0

          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:37613 (36.7 Kb)  TX bytes:4804 (4.6 Kb)

          Interrupt:19 Base address:0xdead 

```

So after a while I found out that I can perfectly add the default gateway when added a static route to it in advance:

```

# ip route add 10.255.255.1 dev eth0

# ip route add default via 10.255.255.1 dev eth0

# ip route show

10.255.255.1 dev eth0  scope link 

default via 10.255.255.1 dev eth0 

```

After that everything worked out perfectly fine and without any further network issues. However, I was still pretty much confused why such a static route might be required as that was the first time I saw it. And especially if you consider my DHCP usage above you can get an idea why that really may be a problem because the DHCP client simply isn't able to add the default route cause there doesn't exist a static route to the default in advance...

Well, first I thought it might be a DHCP issue, so I disabled the whole DHCP stuff in my /etc/conf.d/net and tried to set the IP/route statically:

```

config_eth0=( "212.227.132.120/32 broadcast 212.227.132.120" )

routes_eth0=( "default via 10.255.255.1" )

```

But still I was immediately presented with the same "Network unreachable" error. So I change the above /etc/conf.d/net definition and set it:

```

config_eth0=( "212.227.132.120/32 broadcast 212.227.132.120" )

routes_eth0=( "10.255.255.1"

              "default via 10.255.255.1" )

```

Which causes a static route to the default be first generated and then the default. And voila, everything worked out fine and without any issues.

However, the main question still remains! Why the heck I have to explicitly set a static route for my default gateway? Is that really required, since when and why? As I said, I normally use DHCP so the dhcp clients must really have a hard time setting the default gateway without such a mandatory static route to it. So IMHO it really doesn't look very good and right but probably someone has a good explaination for it.

BTW: I have tested that with kernel 2.6.18 and 2.6.19 as well as with ifconfig and/or iproute2.

And help is highly appreciated as I really want to go back to using the DHCP....

cheers,

jensLast edited by damato on Sat Dec 30, 2006 9:59 am; edited 2 times in total

----------

## sp7xfq

Hi,

IMHO everything works fine. 

Your default route address, and you IP are in different subnets. And your system does not know the way to your gateway - network 10.255.255.1 is unreachable. So, if you set manually route to 10.255.255.1 via eth0, then all works ok.

I think that your DHCP should provide route to the 10.255.255.1 network.

br.

----------

## damato

 *sp7xfq wrote:*   

> Hi,
> 
> IMHO everything works fine. 
> 
> Your default route address, and you IP are in different subnets. And your system does not know the way to your gateway - network 10.255.255.1 is unreachable. So, if you set manually route to 10.255.255.1 via eth0, then all works ok.
> ...

 

No sorry, IMHO the bahaviour is not correct as the default route itself defines through which interface all other traffic is routed and to which gateway. AFAIK the gateway IP can be anything and doesn't require to have an explicit network route for it specified. At least that was something that worked for several years. I really can't see why it should be required to have an explicit network route specified just to set the default gateway.

----------

## lefsha

Have got the same problem now.

Who is your provider?

It seems something goes wrong there...

It doesn't work in that way

```
* Service net.eth0 starting

 * Starting eth0

 *   Loading networking modules for eth0

 *     modules: apipa arping ccwgroup iptunnel macchanger macnet rename ifconfig system dhcpcd ip6to4

 *       ifconfig provides interface

 *       dhcpcd provides dhcp

 *   Configuring eth0 for MAC address 00:E0:81:20:F4:4E ...                                                                                          [ ok ]

 *   Bringing up eth0

 *     dhcp

 *       Running dhcpcd ...

Error, eth0: RTNETLINK answers: Network is unreachable                                                                                               [ ok ]

 *       eth0 received address 213.101.233.3/24

```

But it works in that case, besides I've got no real IP. 

```
* Service net.eth0 starting

 * Starting eth0

 *   Loading networking modules for eth0

 *     modules: apipa arping ccwgroup iptunnel macchanger macnet rename ifconfig system dhcpcd ip6to4

 *       ifconfig provides interface

 *       dhcpcd provides dhcp

 *   Configuring eth0 for MAC address 00:E0:81:20:F4:4E ...                                                                                          [ ok ]

 *   Bringing up eth0

 *     dhcp

 *       Running dhcpcd ...                                                                                                                          [ ok ]

 *       eth0 received address 192.168.1.64/24

 * Service net.eth0 started

```

Just crazy...

BTW Location: Dresden, Germany

----------

## damato

 *lefsha wrote:*   

> Have got the same problem now.
> 
> Who is your provider?
> 
> It seems something goes wrong there...
> ...

 

My provider is 1&1 in Germany. I rented a root server there and the IP values I mentioned here are the ones my provider's DHCP is supplying. However, taking DHCP apart I don't think that anything is wrong with that. Why shouldn't I be allowed to set a default gateway manually to a host in a different subnet not currently listed in my route table? I really don't understand why the same worked for years and suddenly since a while it seems to be not working anymore.

 *lefsha wrote:*   

> 
> 
> But it works in that case, besides I've got no real IP. 
> 
>  * Service net.eth0 starting
> ...

 

But well, what is the default gateway the DHCP in that request did send you? Because if it is also in 192.168.1.x then it is normal that it succeeds. But if you try to manually set a default gateway now to, i.e. 192.168.2.1 then you will also get the "Network is unreachable" error which IMHO isn't fairly correct as the default route automatically implies a host route. If you specify a default gateway you also define the network interface and so on. So I don't really see why it shouldn't work and why I have to explicitly add a network route to the same network of my default gateway. That just seems to be wrong.

 *lefsha wrote:*   

> 
> 
> Just crazy...
> 
> BTW Location: Dresden, Germany

 

It is yes. But well, what's wrong with my location?  :Smile: 

----------

## lefsha

Yes. You are right. May be I have a different problem.

But look. That What I got in the first case

/etc/resolv.conf

```
# Generated by dhcpcd for interface eth0

search lan

nameserver 10.0.0.138

nameserver 212.247.156.66

nameserver 212.247.156.70
```

Even if I will remove the first line it won't work

The question is why I got this nameserver?

And in the second.

```
# Generated by dhcpcd for interface eth0

search lan

nameserver 192.168.1.254

```

In that case you see that it is not public IP. But connection to Internet works...

P.S. If I cut & paste your line it still doesn't mean it related to you...

In that case it is related to me...   :Rolling Eyes: 

Moin Moin

----------

## UberLord

 *lefsha wrote:*   

> [/code]
> 
>  *   Bringing up eth0
> 
>  *     dhcp
> ...

 

Could you add the -d flag to dhcpcd and post the debug output as I'd like to see what it's trying to do when it shows that RTNETLINK error.

```
dhcpcd_eth0="-d"
```

Thanks

----------

## damato

 *UberLord wrote:*   

>  *lefsha wrote:*   [/code]
> 
>  *   Bringing up eth0
> 
>  *     dhcp
> ...

 

I could also send you the debug output, but the "static route requirement" is really not just a DHCP issue. In fact I first tried to run tests with all different dhcp clients we have and all produced the same result.

The issue is that somehow it is REQUIRED to set an explicit static route to your default gateway if the gateway is not within your own subnet and IMHo that's not correct. A default route automatically implies a static route to the host that is set to the default gateway. There is IMO no reason to force to setup an explicit static route to e.g. 10.255.255.1 with "route add 10.255.255.1 dev eth0" if you just want to do a "route add default dev eth0 gw 10.255.255.1". But that is what is required, just test it yourself and try to set a default gateway to an IP which is not part of your subnet. You always get a "Network is unreachable" which AFAIR wasn't the case in previous gentoo versions.

So the question remains. Why do I need to set a static route for my default gateway before I can do a "route add default ..."?

----------

## UberLord

 *damato wrote:*   

> The issue is that somehow it is REQUIRED to set an explicit static route to your default gateway if the gateway is not within your own subnet and IMHo that's not correct.

 

No, it is correct.

 *Quote:*   

> A default route automatically implies a static route to the host that is set to the default gateway.

 

No it does not. A default route simply says "If you try to reach an ip not in my subnets then send to this ip". It does not say anything about a static route to the host, which in turn means there needs to be a subnet route to the gateway.

----------

## damato

 *UberLord wrote:*   

>  *damato wrote:*   The issue is that somehow it is REQUIRED to set an explicit static route to your default gateway if the gateway is not within your own subnet and IMHo that's not correct. 
> 
> No, it is correct.
> 
> 

 

Sorry, but since when should that be correct or required?

 *UberLord wrote:*   

> 
> 
>  *damato wrote:*   A default route automatically implies a static route to the host that is set to the default gateway. 
> 
> No it does not. A default route simply says "If you try to reach an ip not in my subnets then send to this ip". It does not say anything about a static route to the host, which in turn means there needs to be a subnet route to the gateway.

 

Sorry again, but where is that documented and since when is that required? As I said, it previously worked and I can't remember that I explicitly had to set a static route to the IP of my default gateway before I could set the default route itself. That's something very new to me with my >10 years of Linux/Network experience...

And just looking on how you set the default route:

```

route add default gw 10.255.255.1 dev eth0

```

Can't you see that the information is kinda redundant if you consider how a static route to the default gateway is set?

```

route add 10.255.255.1 dev eth0

```

So if you look on these two different route calls, then you might spot that for both I have to specify the interface 'eth0' and so the default route setup should automatically imply all information required for the internal routing table. I still principially refuse to see the reason why I have to set a static route before I can set the default gateway. And I guess that's exactly the reason why the DHCP clients fail to set the default gateway as well. They simply can't do it because they refuse to first set a static route to the IP of the gateway as they also probably think that it is not required.

----------

## UberLord

 *damato wrote:*   

>  *UberLord wrote:*    *damato wrote:*   The issue is that somehow it is REQUIRED to set an explicit static route to your default gateway if the gateway is not within your own subnet and IMHo that's not correct. 
> 
> No, it is correct.
> 
>  
> ...

 

Since the linux network kernel developers said so.

BTW, the same restriction applies to FreeBSD too, so I guess they're all wrong and you're right eh?

<pointless argument snipped>

Lets look at your first post.

```
config_eth0=( "212.227.132.120/32 broadcast 212.227.132.120" )

routes_eth0=( "default via 10.255.255.1" ) 
```

Lets see now shall we? You've assigned a public IP to eth0 but you want a route via a private gateway. Why don't you try this

```
config_eth0=( "10.255.255.10/8" "212.227.132.120/32 broadcast 212.227.132.120" )

routes_eth0=( "default via 10.255.255.1" ) 
```

(May not work as I'm not entirely sure of the subnet you're on)

And bingo! You're working. Why is this working? Well, because we assigned a private IP to eth0, it kernel automatically assigned a subnet route so your gateway now works.

----------

## damato

 *UberLord wrote:*   

>  *damato wrote:*    *UberLord wrote:*    *damato wrote:*   The issue is that somehow it is REQUIRED to set an explicit static route to your default gateway if the gateway is not within your own subnet and IMHo that's not correct. 
> 
> No, it is correct.
> 
>  
> ...

 

No that's not what I meant of course. I just want to try to understand why I thought that this might or should be possible.

 *UberLord wrote:*   

> 
> 
> Lets look at your first post.
> 
> ```
> ...

 

Hmm, I understand your point and what you are trying to say. But can't you see that this is a kind of redundant information that forced static route.

However, lets get back to the issue when it comes to DHCP servers and clients. If you now consider the fact that my provider wants to set the default gateway to 10.255.255.1 which is not an IP of the subnet of my server you might see that this calls for trouble if a static route is required in advance. I also dunno why my provider wants to use that private default gateway address but thats what is provided to the DHCP clients and therefore to my server as well.

----------

## UberLord

 *damato wrote:*   

> 
> 
> Hmm, I understand your point and what you are trying to say. But can't you see that this is a kind of redundant information that forced static route.

 

Not really. 10.x.x.x is a private subnet, to which any IP requests will require a subnet route. The same is true of the other private subnet allocations such as 192.168.x.x.

My understanding is that all private IP ranges require subnet routes. Think about it - logically you should be on the same network as the gateway.

 *Quote:*   

> However, lets get back to the issue when it comes to DHCP servers and clients. If you now consider the fact that my provider wants to set the default gateway to 10.255.255.1 which is not an IP of the subnet of my server you might see that this calls for trouble if a static route is required in advance. I also dunno why my provider wants to use that private default gateway address but thats what is provided to the DHCP clients and therefore to my server as well.

 

Then I suggest your provider has a configuration error.

OR they are using Classless Static Routes to install the subnet route, which only dhcpcd-3 supports by default in the open source world. dhclient can, but requires nasty script hacks. udhcpc could, but requires a patch to the source code (patches for both are in our bugzilla)

dhcpcd-3 is in portage, ~ARCH but stable enough - try that and see if it solves your problem.

----------

## damato

 *UberLord wrote:*   

>  *damato wrote:*   
> 
> Hmm, I understand your point and what you are trying to say. But can't you see that this is a kind of redundant information that forced static route. 
> 
> Not really. 10.x.x.x is a private subnet, to which any IP requests will require a subnet route. The same is true of the other private subnet allocations such as 192.168.x.x.
> ...

 

It is not the point that the two IPs are in a different subnet that I am curious about. That is clear, as well as that the 10.x.x.x is a private network address. What I am curious about is that "route add default gw 10.255.255.1 dev eth0" already implies the same information like "route add 10.255.255.1 dev eth0" as I explicitly specify an interface to both commands. So syntactically, the first command should already succeed as the routeing system already gets all information it would require. So it might setup a static route itself for it without forcing me to set it up explicitly. Hope you get my point here..

 *UberLord wrote:*   

> 
> 
>  *Quote:*   However, lets get back to the issue when it comes to DHCP servers and clients. If you now consider the fact that my provider wants to set the default gateway to 10.255.255.1 which is not an IP of the subnet of my server you might see that this calls for trouble if a static route is required in advance. I also dunno why my provider wants to use that private default gateway address but thats what is provided to the DHCP clients and therefore to my server as well. 
> 
> Then I suggest your provider has a configuration error.
> ...

 

Well, a configuration problem might exist yes, but I can remember that it once worked and without having to put an explicit static route in place. That's what I am mostly curious about. Well and guess what. I am of course running ~ARCH and I also already installed dhcpcd-3, but it didn't help. still the same error with "Network unreachable". So currently I have setup a static route like I explained above. However, I would really love to switch back to DHCP as that is what my provider suggests in case they have to change something.

----------

## UberLord

 *damato wrote:*   

> What I am curious about is that "route add default gw 10.255.255.1 dev eth0" already implies the same information like "route add 10.255.255.1 dev eth0" as I explicitly specify an interface to both commands.

 

It doesn't imply it, it requires it as a pre-requisite.

 *Quote:*   

> So syntactically, the first command should already succeed as the routeing system already gets all information it would require.
> 
>  So it might setup a static route itself for it without forcing me to set it up explicitly. Hope you get my point here..

 

No, it doesn't have enough information.

Other valid routes to 10.255.255.1 are

10.0.0.0/8

10.255.0.0/16

10.255.255.0/24

Which one does it pick by default?

It can't as guessing is just plain wrong - so you have to supply it.

 *Quote:*   

> Well, a configuration problem might exist yes, but I can remember that it once worked and without having to put an explicit static route in place. That's what I am mostly curious about. Well and guess what. I am of course running ~ARCH and I also already installed dhcpcd-3, but it didn't help. still the same error with "Network unreachable". So currently I have setup a static route like I explained above. However, I would really love to switch back to DHCP as that is what my provider suggests in case they have to change something.

 

Maybe the provider changed their configuration. Have you asked them how it's mean to be configured?

----------

## sp7xfq

Hi,

 *damato wrote:*   

> And just looking on how you set the default route:
> 
> ```
> 
> route add default gw 10.255.255.1 dev eth0
> ...

 

Strict determination of device is also usefull/necessary if you have got two or more interfaces in the same network.

----------

## lefsha

 *UberLord wrote:*   

>  *lefsha wrote:*   [/code]
> 
>  *   Bringing up eth0
> 
>  *     dhcp
> ...

 

Sure. Here it is.

```
lefsha etc # lefsha init.d # ./net.eth0 restart

 * Caching service dependencies ...                                                                                                                  [ ok ]

 * Service net.eth0 stopping

 * Stopping eth0

 *   Loading networking modules for eth0

 *     modules: apipa arping ccwgroup iptunnel macchanger macnet rename ifconfig pppd system dhcpcd ip6to4

 *   Bringing down eth0

 *     Stopping dhcpcd on eth0 ...                                                                                                                   [ ok ]

 *     Shutting down eth0 ...                                                                                                                        [ ok ]

 * Service net.eth0 stopped

 * Service net.eth0 starting

 * Starting eth0

 *   Loading networking modules for eth0

 *     modules: apipa arping ccwgroup iptunnel macchanger macnet rename ifconfig pppd system dhcpcd ip6to4

 *       ifconfig provides interface

 *       pppd provides ppp

 *       dhcpcd provides dhcp

 *   Configuring eth0 for MAC address 00:E0:81:20:F4:4E ...                                                                                          [ ok ]

 *   Bringing up eth0

 *     dhcp

 *       Running dhcpcd ...

Info, eth0: dhcpcd 3.0.1 starting

Info, eth0: ethernet address = 0:e0:81:20:f4:4e

Info, eth0: broadcasting for a lease

Debug, eth0: Sending DHCP_DISCOVER with xid 1606637997

Debug, eth0: waiting on select for 10 seconds

Debug, eth0: got a packet with xid 1606637997

Info, eth0: offered lease of 83.181.76.74

Debug, eth0: Sending DHCP_REQUEST with xid 1606637997

Debug, eth0: waiting on select for 10 seconds

Debug, eth0: got a packet with xid 1606637997

Info, eth0: no renewal time supplied, assuming 43200 seconds

Info, eth0: no rebind time supplied, assuming 75600 seconds

Info, eth0: leased 83.181.76.74 for 86400 seconds

Info, eth0: adding IP address 83.181.76.74 netmask 255.0.0.0

Info, eth0: adding route to 0.0.0.0 (0.0.0.0) via 83.181.64.1, metric 0

Debug, eth0: resolvconf completed                                                                                                                    [ ok ]

 *       eth0 received address 83.181.76.74/8

 * Service net.eth0 started

Press any key to continue...                                
```

But now it works!!! I mean the connection to internet.

And I still got strange nameserver....

```
# Generated by dhcpcd for interface eth0

search lan

nameserver 10.0.0.138

nameserver 212.247.156.66

nameserver 212.247.156.70

```

Do I have to keep debug option on to have working internet???

----------

## UberLord

Everyone interested in this, https://bugs.gentoo.org/show_bug.cgi?id=158867

I do not like the RedHat patch, so if we can make dhcpcd work (as it does have all the info) then I'll make dhclient work properly!

----------

## damato

Let me point out that the issue seems to be fixed with the latest dhcpcd-3.0.8-r1 update. The dhcpcd maintainer seem to have integrated a patch which takes care of the above mentioned problem. So everyone having the same issue please update to the very latest dhcpcd ebuild available.

----------

## Larde

Hi!

I guess I kind of have the same problem:

```

Jan 12 10:30:45 root dhcpcd[7440]: eth0: dhcpcd 3.0.9 starting

Jan 12 10:30:45 root dhcpcd[7440]: eth0: ethernet address = 0:e:a6:86:a5:92

Jan 12 10:30:45 root dhcpcd[7440]: eth0: broadcasting for a lease

Jan 12 10:30:48 root dhcpcd[7440]: eth0: offered lease of 85.214.68.152

Jan 12 10:30:48 root dhcpcd[7440]: eth0: got subsequent offer of 85.214.68.152, ignoring 

Jan 12 10:30:48 root dhcpcd[7440]: eth0: leased 85.214.68.152 for 21600 seconds

Jan 12 10:30:48 root dhcpcd[7440]: eth0: adding IP address 85.214.68.152 netmask 255.255.255.255

Jan 12 10:30:48 root dhcpcd[7440]: eth0: adding default route via 85.214.64.1 metric 0

Jan 12 10:30:48 root dhcpcd[7440]: eth0: RTNETLINK answers: Network is unreachable

```

So I wasn't able to reach my machine on network after reboot. Luckily my provider offers a full remote console so I could login that way and set a default route.

Wasn't it supposed to be ok with dhcpcd 3.0.9?

Regards,

Larde.

----------

## UberLord

It is OK. Your DHCP server needs to be configured to add the host route to the router.

----------

