Good afternoon!
I'm new here so be gentle.
I have a nice, new, certified CAT6 LAN with a problem.
Here is some history on our network. We have a class B WAN which has been further subdivided by our issuing authority into smaller masks due to the fact that most locations don't have 256 hosts and we have too many locations for whole subnets.
Our location has 4 masked subnets (4 different sets of addresses XXX.XXX.YYY.XXX, where YYY is different on each subnet). None of these is a whole 256 host mask. All of these subnets ride the same physical network where a Cisco 2600 (single ethernet port) connects us upstream. We have appropriate subnet masks to define them, i.e. 255.255.255.192 or 224, etc.
Our issuing authority saw fit to provide secondary gateway addresses within the Cisco so that each subnet had it's own virtual gateway.
Now, one particular subnet, let's call it 026 for sake of example, is where a server resides, providing resources for whatever host is part of the NT/2000 domain. Any host configured for the 026 subnet has no major network performance issues (outside of intermittent stuff probably created by hosts on the other subnets) when accessing resources on that server. None of the subnets have any performance issues when accessing internet or upstream resources. Any host placed on a subnet other than 026 experiences some of the most unGodly network performance problems when accessing server shares (drives, printers).
Now, I had given the server an auxilliary IP address on one of the other subnets and tried again, but still there was a performance issue.
I recently found an article on WildPackets that explains how the RFC has changed from an old doctrine to a new doctrine that defines the way a router can redirect ARP traffic. RFC 1812 says that redirects should be discarded if a new gateway is more than one hop (which it shouldn't be) but that a Redirect Message must NOT be generated in a router unless all the following conditions are met:
The packet is being forwarded out the same physical interface from which is was received.
The IP source address in the packet is on the same Logical IP (sub)network as the next-hop IP address, and
The packet does not contain an IP source route option.
It seems to me that we are failing on the last 2 points. There is a reference that either the IP stack has to support Redirects or (as a stop-gap) Proxy ARP must be enabled in the router so as to prevent unnecesary traffic loading, performance degradation and propagation delays.
I have no access to the router to check its config and our authority is less than helpful on this situation. I'm trying to gain ammunition to set a course of action on this problem.
What I want to know is this: Is a Cisco 2600 too old to support Redirects, and if so, could this problem be attributed to Proxy ARP being disabled or am I barking up the wrong tree entirely?
Remember, I've pretty much ruled out the possibility of cabling being the issue as when a host is experiencing this problem on a different subnet as 026, I can put it back on the 026 subnet and eliminate the problem.
Bottom line is, I have to use the other subnets as our authority can't give me a larger, complete subnet.
Any ideas from anyone?
Thanks,
Brett
I'm new here so be gentle.
I have a nice, new, certified CAT6 LAN with a problem.
Here is some history on our network. We have a class B WAN which has been further subdivided by our issuing authority into smaller masks due to the fact that most locations don't have 256 hosts and we have too many locations for whole subnets.
Our location has 4 masked subnets (4 different sets of addresses XXX.XXX.YYY.XXX, where YYY is different on each subnet). None of these is a whole 256 host mask. All of these subnets ride the same physical network where a Cisco 2600 (single ethernet port) connects us upstream. We have appropriate subnet masks to define them, i.e. 255.255.255.192 or 224, etc.
Our issuing authority saw fit to provide secondary gateway addresses within the Cisco so that each subnet had it's own virtual gateway.
Now, one particular subnet, let's call it 026 for sake of example, is where a server resides, providing resources for whatever host is part of the NT/2000 domain. Any host configured for the 026 subnet has no major network performance issues (outside of intermittent stuff probably created by hosts on the other subnets) when accessing resources on that server. None of the subnets have any performance issues when accessing internet or upstream resources. Any host placed on a subnet other than 026 experiences some of the most unGodly network performance problems when accessing server shares (drives, printers).
Now, I had given the server an auxilliary IP address on one of the other subnets and tried again, but still there was a performance issue.
I recently found an article on WildPackets that explains how the RFC has changed from an old doctrine to a new doctrine that defines the way a router can redirect ARP traffic. RFC 1812 says that redirects should be discarded if a new gateway is more than one hop (which it shouldn't be) but that a Redirect Message must NOT be generated in a router unless all the following conditions are met:
The packet is being forwarded out the same physical interface from which is was received.
The IP source address in the packet is on the same Logical IP (sub)network as the next-hop IP address, and
The packet does not contain an IP source route option.
It seems to me that we are failing on the last 2 points. There is a reference that either the IP stack has to support Redirects or (as a stop-gap) Proxy ARP must be enabled in the router so as to prevent unnecesary traffic loading, performance degradation and propagation delays.
I have no access to the router to check its config and our authority is less than helpful on this situation. I'm trying to gain ammunition to set a course of action on this problem.
What I want to know is this: Is a Cisco 2600 too old to support Redirects, and if so, could this problem be attributed to Proxy ARP being disabled or am I barking up the wrong tree entirely?
Remember, I've pretty much ruled out the possibility of cabling being the issue as when a host is experiencing this problem on a different subnet as 026, I can put it back on the 026 subnet and eliminate the problem.
Bottom line is, I have to use the other subnets as our authority can't give me a larger, complete subnet.
Any ideas from anyone?
Thanks,
Brett