Default Gateway Setting not set after Reboot

  • Thread starter Thread starter David Morgan
  • Start date Start date
D

David Morgan

Hello

When we reboot our, W2K SP4 + all updates, server the default gateway for
one of our network cards is not set. To set it we have to disable and then
enable the card via Network and Dial-up Connections.

When we reboot ipconfig shows no default gateway. We disable and enable the
card and ipconfig shows the default gateway that was always present in the
TCP/IP properties pane for that NIC.

Anyone come across this before? Needless to say, nothing is logged in the
Event Logs.

There are two network cards in the machine, one of which is an Intel Dual
port. It is the second port on the dual port card that is exposing this
problem. All of the cards are on different subnets with different default
gateways.

Thanks

David
 
David Morgan said:
port. It is the second port on the dual port card that is exposing this
problem. All of the cards are on different subnets with different default
gateways.
Click to expand...

You can only have *one* interface with a Default Gateway,..that is why it is
called "default". That fact that the GUI lets you enter others for other
nics is irrelevant. All other "gateways" are just that,...gateways..(not
default gateways) and these all must be entered as "static routes" into the
OS's Routing Table.
 
Hi Philip

If this is the case, then how come when I access my server via NIC 1 I get a
routed reply from NIC 1.

If I access it from NIC 2, my replies come from NIC 2.

I am sure what you are saying is true, but this does not hide the fact that
one does not apply it's full configuration when the machine boots, but does
when the card is enabled and disabled.

If what you're saying is true, why don't I get a reply from NIC 2 when it is
in this 'no gateway' state? Surely a reply should come via NIC 1?

Thanks and regards

David
 
It just isn't that simple. It depends are where you are located and what you
mean by "access".
David Morgan said:
Hi Philip

If this is the case, then how come when I access my server via NIC 1 I get a
routed reply from NIC 1.

If I access it from NIC 2, my replies come from NIC 2.
Click to expand...

It just isn't that simple. It depends are where you are located and what you
mean by "access".
I am sure what you are saying is true, but this does not hide the fact that
one does not apply it's full configuration when the machine boots, but does
when the card is enabled and disabled.
Click to expand...

I'm not sure why it is doing that, but I think the first thing to do is
configure it according to standards and then see how if behaves. We could
end up just chasing our tail in circles trying to find out why something
acts "odd" when it is not configured to standards.
If what you're saying is true, why don't I get a reply from NIC 2 when it is
in this 'no gateway' state? Surely a reply should come via NIC 1?
Click to expand...

No. You will either get a reply from the IP# you "pinged" or you will get no
reply at all. The Default Gateway simply represents the way it gets there,
it does not represent the source from where it came. If you ping Nic3 and
the DFG is on Nic7,...you will get a reply from Nic3 if the route is valid,
or you will simply get no reply at all.

A DFG indicates an Unknown Route to an Unknown Place. It is the "bit
bucket",...the "last resort",...the "I don't know what else to do with
it",...of the "routing world". When the machine has a destination where
there is no established specific route and it has no idea where to send
it,...it throws it at the Default Gateway and "crosses its fingers" that
hopefully the DFG will know what to do with it. So,....by the very nature
of that, there can be only *one*. There can't be two places to an unknown
somewhere when you don't know where you are going because there is no way to
know how to make a "routing decision" on it.

I believe with Windows,...if it has more than one will just simply always
use the first one listed first in the routing table,...but then sometimes it
just shoots itself in the head and fails.

The following article doesn't describe exactly this situation but it does
reveal the machines behavior patterns in these types of situations.

Microsoft Windows XP - Multihoming Considerations
http://www.microsoft.com/resources/documentation/windows/xp/all/reskit/en-us/prcc_tcp_qpzj.asp?
 
Hi Phillip and thanks for your continued support

I think your answer to the question I asked is "I'm not sure why it is doing
that, <snip>"

For your information, NIC 1 is connected to the Internet via a firewall.
NIC 2 is connected to the Internet with no firewall. When I mention access
I mean receiving replies to pings.

All our 'routes' are valid so when NIC 2 comes up with no DFG, (even though
one has been configured), why then does it not route through NIC 1 and out
on to the Internet. I have looked at the routing tables when both DFGs are
active and as you say, for 0.0.0.0 both are listed. I wonder if that this
problem is being caused by there still being a route for NIC 2 and 0.0.0.0
but no default gateway set. I did not look at the routing table during this
'no gateway' state so I don't know.

In your example below ("If you ping Nic3 and the DFG is on Nic7,...you will
get a reply from Nic3 if the route is valid"), would Nic7 appear in a trace
route's output? I presume so.

Thanks again

David
 
Well I have just tested it.

With the DFG removed from NIC2 I get no reply to a ping. According to you,
this should come back directly from NIC2 (maybe via NIC1). It does not. It
would appear that for this NIC to reply when the request has come via a
gateway, it must have it's default gateway set in order to reply.

I should obviously point out again that I am running W2K, not XP. That
article is interesting and does back up your point. Maybe I'll remove the
gateway from the other card NIC 1, (as there's no point going through a
firewall for requests initiated from the server or for replies), although I
am convinced as per my situation above, if I remove the default gateway on
one of the cards it will no longer respond at all.

Regards

David
 
David Morgan said:
With the DFG removed from NIC2 I get no reply to a ping. According to you,
this should come back directly from NIC2 (maybe via NIC1). It does not.
Click to expand...
It

That's why I said in the last post that it matters where you are located
when you try it. If you are pinging from machine in the same subnet as NIC2
then it will respond. If you are not, then "routing" must be enabled before
the NIC2 will communicate across subnets.
I should obviously point out again that I am running W2K, not XP.
Click to expand...

That doesn't matter.
(as there's no point going through a
firewall for requests initiated from the server or for replies),
Click to expand...

That doesn't make any sense.
although I
am convinced as per my situation above, if I remove the default gateway on
one of the cards it will no longer respond at all.
Click to expand...

We are wasting our time here. You are getting this kind of behavior from the
machine because you have an over all bad design and are "covering" it with
bad techniques.

In the simplest form I can make it:...

Barring a few extreme and unusual situations, there are only two reasons to
put more that one nic in a machine:

1. It is being used as a NAT device or Proxy Server
2. It is being used as a LAN Router

In either case:
A. RRAS must be running on the machine with "routing" enabled

B. Only *one* Default Gateway exists.

C. If there are "alternate" DFGs (for things like Dead Gateway
Detection) then they must be all in the same subnet and be assigned at the
same NIC as the normal Default Gateway.

D. All other possible routes are handled by using Static Routes in the
Routing Table or by the use of Routing Protocols such as RIP, IGRP, etc.

E. If the machine acting as a Router is in the center of a "hub & spoke"
design, operating as a single Router, then there is no need for any Static
Routes.
 
Hi Phillip

Thanks for humouring me on this!

I think we're back to square one.now. I do have RRAS installed and
configured for another purpose but not running.

The fact remains that the server is connected to two subnets. I am not
interested in routing between them at this time. Each NIC has a default
gateway configured but when the machine boots up, one of the default
gateways is not set for one of the subnets on one of the NICs. This surely
is not how windows should behave as the dfg for the problematic interface is
set when the interface is disabled and enabled again.

Going to read through your posts again just in case I have missed anything.
From your post below, I am not pinging from the same subnet as NIC2 and when
the DFG is set ok on that card I get a response. When it isn't, I don't.
All the time this is happening there is a DFG on NIC 1 which works fine.

Thanks

David M
 
David Morgan said:
The fact remains that the server is connected to two subnets. I am not
interested in routing between them at this time.
Click to expand...

But that is what you are trying to do wether you realize it or not. If you
are not doing any routing on it, then the only nic you can ping from a
particular location is the nic that is in the same subnet that the host you
are pinging from. If you ping one of the nics that is in a different subnet
from wence you ping then it will fail unless routing is working because
routing is required to make the jump.

Another *BIG* issue is the cabling. There is no way I can see from here how
you have it all wired up. If every nic is sharing the same wire (plugged
into the same switch or hub) then you will get convoluted behavior which the
multiple DFGs will exaserbate.

DFGs are a *global* setting. They are not tied to a particuar nic in the way
the GUI may imply. They *are* entered in the NIC's settings that correspond
to the subnet that the DFG is part of, but other than that it is a global
setting for the whole machine. I think MS really ought to get it together
on this and rig the GUI so that once a DFG is entered on any nic in the
machine that all the other DFG dialog box locations for the other NICs
become "greyed out". They should not be come "un-greyed" until the existing
DFG is deleted thereby allowing another to be entered.
 
Back
Top