Hi We have two subnets that are connected with a Cisco router. One of the machines on subnet A is not visible from the subnet B (doesn't respond to ping)
I needed to add this command (as root) to my server (192.168.5.152):
arp -s 192.168.5.58 00:D0:BA:2D:CE:61
If the machine is rebooted, this will probably get cleared. So I added the line to /etc/rc2.d/S99local so it should automatically happen on a reboot.
I'm wondering if a new server is added to Subnet A, we have to repeat this process which is not a very good thing to do.
That MAC address appears to be allocated to Cisco, so it likely is the MAC of the router. It would therefore appear that either the router is not doing proxy arp, or else that the netmask for the server does not match the netmask of that IP range on the router.
Sure there is a better way, this issue is probably related to CEF which stands for Cisco Express Forwarding (a crappy technology BTW), If you are using bridges to connect from router to server, you may be having "Arp Broadcast Storms" upon ARP resolution.
Try Disabling CEF but only on a router because doing so in a production IP Switch (such as a Catalyst) may bring it down due to processing overhead.
I am a novice. Please tell me what I can do in terms of the commands. The two subnets are 192.168.5.0/24 and 192.16.11.0/24 This is just happening on one machine only.
What route does that machine have to the remote server? It sounds as though it may not have a route to the server at all. By setting a static MAC entry it attempts to send direct to the server as if it were on the same subnet, which effectively forces a gateway for that host.
The OP did not happen to post all the information in one place, so it was easy to lose track of some of the details.
Recapping:
The OP has a machine in 192.168.11/24 which does not, without special handling, respond to pings originated from one of the servers in 192.168.5/24. pings from that server to the other hosts in 192.168.5/24 work. The OP is able to get pings working by setting a static ARP entry on the server in 192.168.5/24. The MAC of the static ARP is in a block allocated to Cisco, and the IP address of the static ARP is in 192.168.5/24. We were, though, not told what device the IP address corresponds to, and we were not told what device the MAC corresponds to.
Since we are given that adding the static ARP entry allows the pings to work, we can deduce that the IP address of the static ARP is that of the server, the client, or the router. The server IP address was given, though, and is not the same as the IP address of the static ARP entry, which narrows the possibilities down to client or router.
We are told, though, that the problem client is in subnet "A" and the server in subnet "B", and we are told that subnet B is 192.168.5/24, so the 192.168.5.* IP that appears in the static ARP entry cannot be that of the problem client (which would have to be a 192.168.11.* IP.)
We thus deduce that the IP address of the static ARP statement is that of the router. As, though, we know that reaching the rest of subnet "A", 192.168.11.* works, we know that the server must already be able to find out the MAC of the router, and thus that the static ARP entry should not make any difference in reaching the server.
Having logically exhausted the possibilities based upon the information given, we are left only with the possibility that the information given was incorrect.
Can we, based upon the information given, deduce what part of the information was incorrect, and what the likely solution is? Well, No, once we start getting into that, the possibilities multiply too quickly and Occam's Razor would lead us to proposing that the simplest solution is that there is no ping problem at all!
It turns out, though, that there is a non-trivial scenario that would be consistant with the reported solution, with a small change to the initial conditions. Suppose that instead of the problem client being in a different *subnet*, that the problem client is in the -same- subnet but in the other *segment* (interface) of the router. If that were the case, then when the server went to do the ARP broadcast for the IP, the router would not answer because the router would deem the IP address to be local to the interface the broadcast was received on. When the OP goes on to the server and sets a static ARP entry with the IP of the client, pointing to the router's MAC, then the server would send the packets to the router, which would then hypothetically somehow know to send the packets to the other interface. The mechanism involved in that hypothesis could be a static host route on the router, or it could be that the router is hearing the MAC based upon the client's transmissions, and so knows which interface the client is on. If that was the case, then I would expect that even with the static ARP entry that from time to time the client would be unreachable if the client had not happened to have transmitted anything recently.
But I think to resolve this, the OP is going to have to tell us clearly what the IP address is of the router, and of the problem client, and what the IP address is that the OP is putting into the static ARP entry, and what the MAC address is that appears there, and also clearly indicate which interface of the router the devices are on. (I also strongly recommend that the OP check the netmask configured onto the problem client!)
With as little information posted, its extremely difficult to deduct any specific answers; however, we could help the novice out by trying some basic steps - we all have to start somewhere and should be willing to help the OP out.
I suggest verifying that the default gateway is in fact set correctly (no type-o's) on the system that you had to statically assign the static ARP entry.
In addition, verify your subnet mask. Make sure that there is no type-o's either. These two things tend to be the #1 cause of this issue that I have personally seen.
Even if the router is not performing Proxy Arp, as long as a default gateway is set on the end station, Proxy Arp does not come into play. Proxy Arp is only designed for systems needing a route out that don't already have one such as missing your default route. I prefer to actually turn off proxy arp and make sure the DG is set. This ensures you have full control over the network.
In any circumstance, verify these first two things (the proper default gateway and mask) and we can go from there.
Also if you could provide the OS's of the systems involved (i.e Windows XP, Linux, etc)
The network is laid out as follows: The outside line comes into a Firewall (Cisco 506) which has the inside IP 192.168.5.1 The output from firewall goes to a VLAN1 192.168.5.0 The output from VLAN1 goes to 2 servers and another VLAN2 192.168.11.0 All the other machines are connected to VLAN2 We can't ping from VLAN1 to a particular host on VLAN2 192.168.5.58
So it sounds to me like you gave the server an address in Subnet B, but physically connected it to Subnet A. This is not a good idea, but if you really need to make it work it can be done.
On the router, add the following configuration:
ip route 192.168.5.152 255.255.255.255 Vlan1 interface Vlan2 ip proxy-arp
Please quote context. Please see here for information on how to do so from Google Groups:
formatting link
*How* does "the output from VLAN1" go to VLAN2?
You indicate first that VLAN1 is 192.168.5.0, and that VLAN2 is
192.168.11.0, and then you indicate that there is a problem in getting from VLAN1 (i.e., 192.168.5.0) to "a particular host on VLAN2" (i.e., 192.168.11.0) namely 192.168.5.58... but that's an address from VLAN1, not from VLAN2.
Could you confirm that the information is correct? That
192.168.5.58 is connected to VLAN2 even though it is part of the IP address range you have associated with VLAN1 ?
If that is the case, then the only way it can work smoothly is if your VLANs are not based upon IP subnets but are instead based on some other factor such as packet encapsulation format (e.g., 802.2, 802.3, SNAP). But Cisco routers and switches only make port-based and subnet-based VLANs easy, so if you are using a Cisco router or switch, you probably aren't using a protocol-based VLAN.
If you are trying to have a 192.168.5.0 host on the 192.168.11.0 VLAN, then "Don't Do That!" -- it gets too messy if you have alternatives.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.