Click me if you are a network guru ...

So... uh... I've been implementing WANs and security environments since 1993.
My company has been teaching networking courses since 1998; I taught them at first and have trained a half-dozen other trainers and we have collectively trained a few dozen "network engineers", many of whom are considered "best we've worked with" by pretty experienced folk. We continue to support and train on networks and are considered pretty good at the doing as well as the training. Does that make me a "network guru"?

I can confirm the theoretical correct configurations for your network settings and I can describe in detail exactly what's making it work and how you'd go about establishing that to be true - that is all part of the networking issues we deal with every day in our company, where we support 2000+ networking devices (not PCs / servers - just networking devices) throughout the world.

Your configuration is not as it should be. Very astute to notice. Your gateway should always be on your network. That said, the network you are running is a very unusual network to run. There is little or no reason to subnet to that level of detail when using private addresses. Private address ranges (per RFC spec) are 10.x, 127.x, 172.16-31.x, and 192.168.x. There is a simple binary pattern that makes it those addresses, but we'll save that for the whiteboard sessions; in short, none of those are to be used in the public space ever. So, since you're dealing with 172.16.x - a native 16-bit network that is private and allows 256 networks of 254 devices with an 8-bit subnet mask (technically, the first 16-bits are a standard "net mask" for a "Class B" address range - meaning first and second bits high in first octet address - thus all bits of net mask beyond 16 are "sub-net" bits). So, it'd be pretty normal to run a 24-bit mask and get 256 nets of 254 devices from a 172.16 net. Why the deep subnet?

The important thing about the gateway - as suggested by huggy - is that the system in question has that IP in its ARP table and thus thinks it has a route to talk to it. That can be done by manual manipulation of the ARP table or by Proxy response to a request to get to the address. The method for requesting a MAC in an ARP sequence is lengthy but pretty simple:
I need to talk to another IP device.
Is it on my network?
--YES -
----L2 my source, broadcast destination
----L3 my source, direct destination
----response will come from the device, thus putting its MAC in my ARP table
--NO -
----Do I know the MAC of my gateway of last resort (or GWOLR - AKA "default gateway" - a misnomer, really)
------YES -
--------L2 my source, GWOLR destination
--------L3 my source, final destination
------NO - ARP GWOLR
--------L2 my source, broadcast destination
--------L3 my source, GWOLR destination
The end result of this sequence is that you are either talking directly to a device on your network via the direct L2 path or you are talking L2 to your gateway and L3 to the destination.

Proxy ARP devices change all this by responding to all L2 broadcast requests as though they are the L3 destination (or at least for any that they're configured to do so for). This is also the means to a man-in-the-middle data capture scheme when using an ethernet switch... but that's a more complicated story.

So... how's it working? Prolly something acting as a proxy ARP device because your config is technically "wrong".

Want to know a bit more? Type "arp -a" from command line as well as the "route print" command. Note that ARP will only report things you've actually talked to within the time-out window, so do it after something "worked". The MAC addy will tell us what brand of device it is - sometimes what model. The route info will give us a clue if there's something else going on route-wise that may be "over-riding" the config you showed us.

Fun exercise! I'm not involved on the techy stuff any more; I miss it. Thanks!
 
Bingo, and thank for the feedback Gregorx - that was a fantastic reply. When Electron asked that question last night in the chat room my only response was it had to some kind of ARP trickery. Thanks to this, I get how it works.....
 
Definitely makes sense. Wish I had access to this box myself, because it sounds like a fun project to figure out how they set it up. When I asked if they knew what the subnet / def gw is supposed to be, they were clueless. Great post Gregory!
 
Just received the results of the route print command:
Code: 
C:\>route print

===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x1000003 ...00 20 ed 25 33 c2 ...... Realtek 8139-series PCI NIC
===========================================================================

===========================================================================
Active Routes:

Network Destination		Netmask		  Gateway	   Interface  Metric
		  0.0.0.0		  0.0.0.0	   10.90.6.41	  172.16.1.1	   1
		127.0.0.0		255.0.0.0		127.0.0.1	   127.0.0.1	   1
	   172.16.1.0  255.255.255.252	   172.16.1.1	  172.16.1.1	   1
	   172.16.1.1  255.255.255.255		127.0.0.1	   127.0.0.1	   1
   172.16.255.255  255.255.255.255	   172.16.1.1	  172.16.1.1	   1
		224.0.0.0		224.0.0.0	   172.16.1.1	  172.16.1.1	   1
  255.255.255.255  255.255.255.255	   172.16.1.1	  172.16.1.1	   1
Default Gateway:		10.90.6.41

===========================================================================
 
And here is the output of the arp command right after pinging the IP address which is connected to our server.
Code: 
C:\>ping 10.90.200.52

Pinging 10.90.200.52 with 32 bytes of data:
Reply from 10.90.200.52: bytes=32 time<10ms TTL=126
Reply from 10.90.200.52: bytes=32 time<10ms TTL=126
Reply from 10.90.200.52: bytes=32 time<10ms TTL=126
Reply from 10.90.200.52: bytes=32 time<10ms TTL=126

Ping statistics for 10.90.200.52:
	Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
	Minimum = 0ms, Maximum =  0ms, Average =  0ms


C:\>arp -a

Interface: 172.16.1.1 on Interface 0x1000003
  Internet Address	  Physical Address	  Type
  10.90.6.41			00-06-28-08-98-81	 dynamic
 
rocco said:
Hi E,
I am not a net-guru, but I clicked anyway. I don't see anything wrong except for the IP address 0.0.0.0 that appears to be listening. I also notice that your mask will only allow 4 nodes locally (172.16.1.0, 172.16.1.1, 172.16.1.2 and 172.16.1.3), and 172.16.1.4 and above will be routed to your 10.90.6.41, your ISP's proxy.
Code: 
C:\>netstat -na

Active Connections
  Proto  Local Address		  Foreign Address		State
  TCP	0.0.0.0:4050		   0.0.0.0:0			  LISTENING
  TCP	172.16.1.1:4050		10.90.200.52:3800	  ESTABLISHED
...
Though that ip:port is listening, I'm wondering if it actually does anything besides take up space.
Click to expand...

rocco, its official, your're a guru, LOL :(
 
Hey Dan, just for grins run a traceroute (tracert on Windoze) to some IP past the gateway... see what that returns for hops.

It looks like a simple improperly configured gateway. As gregoryx (nice explanation, gregory!) put, the machine can still find the right place to go using ARP.

Also, the post you mentioned back a ways said something about "server" not being the name of the server. In my company, I have one named "sever". It was named by the former IT person, and either he typo'd the name "server", or he was precognitive about his keeping his job! ;-)
 
With a subnet mask of 255.255.255.252 there is little room for any options.
With that subnet mask the server should only be able to communicate with these ip addresses.

172.16.1.0
172.16.1.1
172.16.1.2
172.16.1.3

172.16.1.0 and 172.16.1.3 should be the network and broadcast addresses for the subnet.

172.16.1.1 is the server.
172.16.1.2 ??????

Something has to be acting as a gateway/router or proxy arp on 1 of those addresses.

The Arp table was listed so there appears to be no manually added arp entries.

The network and broadcast addresses are not supposed to be used for anything but I have seen them used on devices.

StevenE
 
Right on, deranged... in theory. In reality, there can easily be something on the physical (L1/L2) network that has the MAC 00-06-28-08-98-81 that is responding to all requests that it thinks are "elsewhere" (or however it's set up to reply).

Let's see what type of device that is... and if that helps... prefix 000628 is Cisco Systems, Inc.

The good news is that Cisco doesn't typically make NICs and doesn't usually put their L2 addresses on other people's stuff. Is that perhaps your Cable "router"? or DSL "modem" from the carrier? or a Cisco router? or firewall? or is there a Linksys? Maybe that's actually a Linksys name but my lookup calls it Cisco now. It's gotta be something made by / owned by Cisco.

Whatever it is is plugged into your ethernet network and is responding to requests it thinks should be leaving the network even though your broadcast asked for a 10.x device and it may not have that address. It may also be so "idiot proofed" that it IS running that address and is clever enough to say "I'm going to ignore the fact that the source IP is on a different network and reply to it anyways" or something like that.

BTW, you don't make clear: what else IS on that LAN? Where is this "server" versus whatever you're testing / pinging? Same LAN? or elsewhere?

Our company handles thousands of network and security devices and in ten years there has not been a single case that didn't ultimately make sense as to how it worked ('cept for the actual software / firmware bugs and such :)).

Thanks again for the fun exercise!
 
There is nothing else on that LAN, from what I know, the server is plugged into a switch, and there is nothing else on that subnet. Proxy Arp is the only thing that really can explain this, but when I talked to the network administrator, he couldn't figure out how this was working, so I am not sure myself what is going on. Everything is working tho, just more curious about what exactly they did. The testing/pinging is done between this server, and the one that is talking to it (shown in the netstat printout earlier), a machine on a different subnet.
 
I realize it's all working; I think it's cool that you're investigating. :)

I don't want to diss the network administrator (which usually means I'm about to), but their job rarely involves - or requires, as is evident here - actually understanding how networking works. They're usually actually responsible for servers and PCs that attach to the network, but couldn't offer the simple, accurate description of how L1-4 work (or don't) that is required to figure out things that don't act as expected. The good news for out company is that good-sized companies rely on our company's networking expertise; if they knew it well, they'd have less need of our company. To their credit, since things don't go wrong that often (even just weird things like this), they don't get the opportunities to become really strong at figuring them out. Since we service many companies and this is all we do, we get pretty good at it. So... no diss to the network admin intended at all; I'm certain he's very good at the parts of his job that he does all day every day, as are the network administrators of our clients - who pay us pretty well for our expertise.

Find that MAC. According to your testing, that's the one the machine is talking to.

What should the "default gateway" (or "router" or "firewall" or whatever name folks want to use) be for getting off that network? If that's not the answer, find things that are made by Cisco. One of them is doing it.

Keep at it! It's a fun riddle!
 
The entire problem here is not being able to physically see everything
Is it a cisco switch the server is plugged into ?
How is it connected to the rest of the network ?
Do they use an outside vendor or was it setup by a previous network administrator ?

Something purposely responding to the MAC address like that most likely would not be a cheapo dsl router or linksys device. Though the way they make these things anything is possible.

Is this a unique situation, are there other devices setup like this ?

I used to work myself for a company that supported large/small networks, but now I am content working for a very small company 6 miles from home. They have 8 offices that had been previously setup by someone else and the main office is setup as 192.168.1.x and that is a real pain.

The hardest part is always trying to unravel someone else's setup. Most 'administrators' in my experience just plug things in, never once looking at the config or security of the device.

StevenE
 
This is a server located in a customer's building which we don't have access to. As far as I know it's a pretty big network, so I would assume it's plugged into an enterprise grade switch, but you never know. Since this server is located somewhere else, I can't tell for sure if this is unique case for that network, or if thats how they run things. The network admin was as confused as I was when I asked him to explain the subnet mask and default gateway. I asked him what the subnet mask and gw were supposed to be, but he had no idea, so that doesn't help. Next time I get an opportunity to log into that machine again, I will do some more testing, but until then, there isn't much I can do. I do appreciate all the input, it's nice to see that there are plenty of people in this community which have a high level understanding of networks.
 
Thanks for letting me "play" on this one!

The "it works so let's not fix it" approach is not an all bad one; can't fault the network administrator for that! :)

Cheers!
 
You must log in or register to reply here.

Similar threads

H
Elk M1-XEP E-mail Setup --Steps that Worked for me....
2
Replies
15
Views
10K
reko19
R
Back
Top