network tool for subnet question

[Tcs]

We have several remote sites on our network. While we have had a problem wit
the way the network was originally set up (all routers bridging vs routing), at
least our subnets were in the same class. (We were using Frame Relay.) We've
been changing remote sites over to DSL, to get better performance.

This morning I overheard our junior tech asking a user, who had come here to our
office, to get the IP address of his machine. So we could help him. So I got
to wondering... (*usually* a dangerous proposition at best.) I was wondering
why there wasn't somewhere we could go, to see if *we* couldn't find the IPs. I
was thinking of the DHCP server (from my admin days), but this is *probably*
wrong. Anyway, it didn't show what I thought it would.

Then I was told that because we're using DSL, we have to use use
192.xxx.xxx.xxx. And of course this does *not* match our class. I guess the
DSL modems/routers are handling DHCP at the site. (I'm not the network guy who
set this stuff up.) So...

How can we ping everyone that is in a different class? Is it even possible? Is
there any network tool available that we could use that *would* allow this?

Thanks in advance for your response,

Tom

 

[Michael J. Davis]

I am not sure about pinging devices in different classes, but I use a tool
called Advanced IP scanner to scan my network occassionally. The tool gives
you some good info, MAC Address, Computer Name, IP Address even OS. Good
luck.

http://www.download.com/Advanced-IP-Scanner/3000-2085_4-10129317.html?tag=lst-0-1

 

[Phillip Windell]

We have several remote sites on our network. While we have had a problem wit
the way the network was originally set up (all routers bridging vs routing), at
least our subnets were in the same class. (We were using Frame Relay.) We've
been changing remote sites over to DSL, to get better performance.

Forget "classes",... for practical purposes just consider that there is no
such thing. There are Subnets,....something is either in the same subnet or
it is not. If all your Routers were previously all "bridging" then there
was only one Subnet,...just one. Bridging occurs only within a
subnet,...Routing occurs only between different subnets.

office, to get the IP address of his machine. So we could help him. So I got
to wondering... (*usually* a dangerous proposition at best.) I was wondering
why there wasn't somewhere we could go, to see if *we* couldn't find the IPs. I
was thinking of the DHCP server (from my admin days), but this is *probably*
wrong. Anyway, it didn't show what I thought it would.

Just ping the machine name,...it will return the IP#. It will also be
listed in DHCP if it was granted by DHCP,..it will also be listed in DNS and
WINS.

Then I was told that because we're using DSL, we have to use use
192.xxx.xxx.xxx. And of course this does *not* match our class. I guess the
DSL modems/routers are handling DHCP at the site. (I'm not the network

guy

DSL is just a Line Technology and operates at Layers 1 & 2. It has nothing
to do with IP#s.

You didn't have a "class",...you had an IP Range. Since I don't know what
that was or if you used Publicly Routable Addresses or RFC Private
Non-Routable Address from behind a NAT or Proxy Device there is no way I can
tell you what to do from there.

If you used RFC Private Addressing,....then you keep what you have as long
as you don't buy some piece of crap "home user" DSL NAT Device. You need
high quality commercial equipment. A DSL modem combined with a Hardware
Firewall, or MS ISA Server would serve the purpose. Note that a DSL Modem
does not have an IP# and does not deal with IP numbers in any way,...it is
nothing more than a glorified Media Converter (Tranceiver) between the Phone
Line and the CAT5 cabling. Many so-called DSL Modems on the market are not
just simple DSL Modems as they are avertised,...many are NAT Devices but
they never tell you that when you buy them. You want something with the
absolute fewest features possible,...the Proxy Server or your Hardware
Firewall are the devices that do the real work. Your DHCP should be handled
by a Windows Server running MS DHCP since it will have a 100 times more
features and abilities and will keep Active Directory updated whenever a
client's IP# changes.


--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/ISA2004_AccessRules.html

Microsoft Internet Security & Acceleration Server: Guidance
http://www.microsoft.com/isaserver/techinfo/Guidance/2004.asp
http://www.microsoft.com/isaserver/techinfo/Guidance/2000.asp

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.asp
-----------------------------------------------------

 

[Tcs]

Okay. I *said* "clases", because the first octet is different.

I've since found out that the routers at the remotes sites are still being used.
And it is *they* that handle the DHCP locally. On this end, the PIX handles
routing. (This is straight from the network guy who set it up and maintains
it.)

Another problem adding to the mix is that we're changing domains. We changed
email systems last winter, going from Lotus Notes to Exchange 2003. At the same
time, we started a domain migration. All users are in the new domain, but
almost all the computers in the old domain have yet to be moved to the new. We
have two domain controllers in the old, as well as the new. Our new Exchange
Server is in the new. My PC, along with perhaps a dozen or so others are in the
new. Thus leaving a couple hundred in the old...

BTW - We're in the middle of getting a new phone system. We're rather "spread
out" within our city, and we have a hodge podge of telephone systems in place.
It's my understanding that the new phone system, if acquired as envisioned, will
provide a T1 link to each location. And since it will be VoIP, we'll be able to
solve our network [performance] issues/problem(s) as well. Then we can get
things set up "right". Routers that "route", *one* DHCP server, etc.

When I try to ping the computer name, I get:

Ping request could not find the host <CompName>. Please check the name and try
again.

This is what I get when I try to ping the several computers I can see in the new
domain, but are at the remote sites. Anything here, I can successfully ping.

Is there no way I can ping a remote? Until we get our new T1s in place?

Thanks a lot,

Tom

 

[Phillip Windell]

Okay. I *said* "clases", because the first octet is different.

Yes, that used to be a distinction,...but it is mostly ignored now, both by
the "humans" and the hardware so it is less confusing if it is just ignored.

I've since found out that the routers at the remotes sites are still being used.
And it is *they* that handle the DHCP locally. On this end, the PIX handles
routing. (This is straight from the network guy who set it up and maintains
it.)

Well, the network guy is "playing loose" with the terminology and it makes
it difficult to know what you mean by what is said. The PIX is a NAT-Based
Firewall,...it doesn't "route" it performs NAT. Remember, I have no
background knowledge of him, you, or the network,...I can only go by what I
read in the post. But I don't want to get into a debate of the network guys
use of terminology,...I'm just trying to understand what you have there and
I have to start from "zero".

time, we started a domain migration. All users are in the new domain, but

......<shortened for space>....
The migration seems fine, I never saw anything there that caught my
attention.

When I try to ping the computer name, I get:
Ping request could not find the host <CompName>. Please check the name and try
again.
This is what I get when I try to ping the several computers I can see in the new
domain, but are at the remote sites. Anything here, I can successfully ping.
Is there no way I can ping a remote? Until we get our new T1s in place?

First you should verify that pinging by IP# works before you worry about why
the names don't resolve. But assuming that part works, your problem is the
unfinished state of the two Domains. In order to ping "by name" both the
machine you are pinging from and the machine you are pinging must be using
the same DNS Server,...if not the DNS Server is not going to know what is in
the DNS Database of the other DNS Server being used by the other machine.
Setting up Zone Transfers could solve that but I wouldn't want to do all
that for a temporary situation where DC/DNS machine will be eliminated
later.

Here's what I would do (If I am wrong someone can correct me):
You have two "pairs" of DNS Servers. Have each "pair" listed in the other
"pair's" Forwarders List and vice-versa. This is the same list where the
ISP's DNS should already be listed, but you want the ISP's DNS to be the
last one on the list with the pair of DNS Servers from the opposite Domain
listed above it. This way when a DNS Query is made, it goes first to the
DNS that is in the same Domain as the Client making the request,....if a
match is not found it is then passed on to the DNS from the other
Domain,...if a match still isn't found then it is passed to the ISP's DNS.
Assuming it doesn't create some kind of endless "query loop" I think it
would be ok.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/ISA2004_AccessRules.html

Microsoft Internet Security & Acceleration Server: Guidance
http://www.microsoft.com/isaserver/techinfo/Guidance/2004.asp
http://www.microsoft.com/isaserver/techinfo/Guidance/2000.asp

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.asp
-----------------------------------------------------