ARP for a remote subnet machine, eh !

I hope I'm not out of scope here,

Try shutting down (temporarly) that 172.16.1.1 interface and reassigning the 172.16.2.1 as 172.16.1.1. Then ping 172.16.3.1 from the new 172.16.1.1. I wonder :!: :

I was also thinking of wrongly assigned subnet masks on R2, which some how made 172.16.1.1/24 local to R2, hence the ARP. But even that mmmm, na na na

You have a hell of an issue here, I'm hocked. What is puzzeling is how did it work with the layer 3 switch.

This might be a long shot, but I'm holding on one thing Smurf said :

What i see is that for some reason, Router 2 (between the pix and the router interface) is doing ARP requests directly for 172.16.1.1. i.e. you see a ARP from 10.10.2.1 for 172.16.1.1. I'm sorry but this is well confusing me ? This shouldn't be happening right ? It should be just forwarding to the Pix interface to be routed ?

Logic dictates that if Router 2 is performing ARP requests for 172.16.1.1, Router 2 has no route entry for 172.16.1.1. Is it possible to double-check this ?


The alternative method is that the PIX performs a nat translation, masking IP address 172.16.1.1 with 10.10.2.2. If this is the case, then the arp request shows that 172.16.1.1 is not being properly translated to 10.10.2.2;

In addition, I'd suggest using a syslog server to help debug the PIX interface in case your performing nat and other complex functions. When I experience problems with PIX's, my syslog server is my best friend

Update us on the situation as soon as you can Smurf.

Cheers,

Well guys, finally got to the bottom of this (while reading my CCNP Switching Book I got the insight into why it works with the switch).

R2 (or ISA Server as it really is) has its routing table messed up (3rd Party Companies Setup). A print out that was sent to me is showing that;
[code:1]172.16.1.0 255.255.255.0 10.10.2.1 10.10.2.1[/code:1]

I have never seen an entry messed up like this and i thought this would cause a loop, not the box to think that it is on the 10.10.2.0/24 subnet.

Anyhow, this route is causing the 172.16.1.0/24 traffic to be just transmitted directly onto the 10.10.2.0/24 segment.

Anyone worked out why it works with the Layer 3 switched................Correct, i had enabled InterVLAN Bridging by mistake which is a good job really because all the core routing would have been screwed.

Thanks everyone for your comments, off to install the Pix again today now that the routing table has been sorted by the 3rd Party. Fingers Crossed so i can keep a little bit of my hair

Success, yeah But it leaves another question which i will start a new thread on.

Thanks everyone

Just reading a little more and it could have been proxy arp that was actually making it work with the switch. Just posted the other question so hopefully it will make more sense to me after thats answered.