HP 2626 ARP question

[James_336]

I have been working with Lightspeed Systems TTC software for content filtering. We are having trouble with the redirect pages being displayed when a user hits a blocked page. Lightspeed says that it is a HP problem in how they are handling ARP. HP says that they are using ARP according to the RFC document. This is the second content filter I have used where redirect pages will not work.....the page just times out. The filter appliance has one NIC plugged into the internal side of my PIX and the other NIC plugged into the VLAN the PIX connects to the network. Lightspeed says this it the correct way to use their system....but I am having doubts. Any ideas on this one?

[Guido Ruhnau]

Hy James, this sounds like a pix configuration problem, not an 2626 problem.
If you allow the traffic on the pix with permit any any there should no problem.
But then you have to solve the pix problem!

[Ron Kinner]

Do you have more detail on exactly what Lightspeed claims that HP is doing wrong with ARP? It seems hard to believe that ARP is even involved.

Could you be more specific about what is happening with the redirect page? Is this the page that the filter provides to indicate a blocked site? Does the filter have its own IP address on each side or is it pretending not to be there? Is it playing proxy server?

Have you got a sniffer trace of what is happening?

Ron

[James_336]

Lightspeed claims that the way HP places the ARP on VLANS is wrong. Lightspeed says that the way their product works is that when a client hits a blocked page, the Lightspeed box sends a redirect packet that sends them to a URL located on the server and it is based on the client ARP entry. I have a hard time believing this given the way ARP works and the way a machine stores the ARP entries. There is nothing wrong with the PIX setup......that I know of, everything routes and functions fine other than redirects to that Lightspeed box.

[James_336]

No, The filter does not have an IP address....it uses a proprietary protocol called IPMagic. There is no IP loaded on this machine except on the management NIC. It sits in a pass through config. on the network with one Nic hooked to the PIX, and the other hooked to the HP 2626 on the VLAN that the PIX is on. I am using the 2626 as my primary router for traffic to leave my network.

[Ron Kinner]

I assume the hosts have a default address. Is the default the IP address of the switch on their respective vlans or is it something else?

If I am a host and I want to reach xxx.com I do an dns lookup and get an IP address. Then I look in my routing table and find that the IP address I need is via my default gateway so I take the default gateway MAC address on the Ethernet packet and send it off. IF the magic filter decides xxx.com is a forbidden site then it eats the packet and sends back an ICMP redirect telling me that I can get there faster by going to A.B.C.D as my next hop. I look in my route table and find that A.B.C.D is on the same subnet so I ARP for the address and use the MAC address I get back as the address for my Ethernet packet. (I also stick that address in my ARP table so the next time it comes up I can save some time by going directly there.)

The server then somehow knows to send a nastygram back to the originator which is not difficult since the server is on the same subnet. At least I suppose that is how it works.

Now let's add the 2626 acting as a router and default gateway for its hosts with the nastygram server on a different VLAN and see what happens. As before we find that xxx.com is to be reached through our default gateway which is now the 2626. We put its MAC address on the Ethernet packet and send it off. The 2626 gets it and looks at its table and finds that the packet is internet stuff so sends it out towards the PIX where the magic filter finds it and eats it and sends back the same ICMP redirect message to the 2626 which should then look in its routing table to decide where to send it. Presumably the server lives on a separate VLAN and there are no nasty filters so it should ARP for A.B.C.D and use the resulting MAC as the address to forward the packet to. It should then put the A.B.C.D = MAC in its forwarding table and sit there happily. The packet gets sent on to the server which does its usual thing and tries to send back a nastygram to the originator. Here is where I think you are running into trouble and it has nothing to do with the 2626 or its ARP table. The server needs a route back to the original host and it will need to go back through the 2626. Check the routing table on the server to see if it knows how to get back to the host via the 2626. Run a traceroute (tracert -d on windows) back to a host and see where it goes.

If that appears correct then you will need to get a sniffer on each leg and see what really happens. With a switch this is a bit of a problem and HP's monitoring setup is sometimes only in one direction so the best way is to plug an old hub in on the line you want to sniff then plug the sniffer into the hub.

You might also check the arp tables on the switch after a session to see if the server's MAC actually gets in the arp tables. Perhaps the 2626 does not respond to ICMP redirects and just continues to send the packets the same way.

There are three options available on the 2626 which might effect how this works. One is IP Proxy-ARP which is supposed to be off by default. Another is IP ICMP Redirects which appears to be on by default. (It's not clear whether this controls the reaction to receiving ICMP redirects or just the sending of them.) Finally there is the arp age parameter which is set to 20 minutes by default. You can play with them and see if anything makes a difference.


Ron

[Sergej Gurenko]

I have heard from customers about problems with transparent proxy boxes and Procurves.
The "kill the Procurve" design is connect transparent box (Transparent traffic shaper, content checker, mail gateway) to a two separate VLANS to the same procurve. If this box forward same MAC to a booth ports procurve gets crazy.
Try to connect Lightspeed to procurve with only one port. Other plug directly to pix, via crossower or hub.
Back to the theory:
You are using VLANS. May be this is the issue with SAT (SourceAddressTable)? HP uses one SAT table per switch for all vlans (SVL). Procurve goes crazy when see same MAC on two or more vlans. Cisco in the same situation feels good. Cisco uses ILV (separate SATs for each vlan). Check this issue.
P.S. Please correct me if 5300xl series start to use separate SAT for separate vlans.

[Ralph Bean_2]

Hello Sergei -

Like others posting here, I doubt that this is an ARP problem.

Some have suggested that the problem has to do with the ProCurve switches' MAC forwarding database implementation. If so, then I have a couple of observations.

First of all, some ProCurve switches have a single MAC forwarding database, while others have forwarding databases that can support the same MAC address on multiple VLANs. This is essentially the subject of the FAQ at http://www.hp.com/rnd/support/faqs/5300xl.htm#question34 .

Secondly, the FAQ that I referenced above suggests a workaround.

Regards,
Ralph

[James_336]

Sergei,

Currently the PIX is plugged into one of the NIC's on the Lightspeed box, and the other NIC is plugged into the HP 2626 so it sits passively between the 2 devices. I am convinced that it is a HP 2626 issue as this is the second content filter to display this problem. It is highly unlikely that 2 different servers running 2 different content filters can have the same problem. Do you know if the problem you speak of pertains to the 2626, or just the 5300xl?

[Sergej Gurenko]

James,
I think you are not the only one Lightspeed TTC user with Procurve switch. That mean other users have no this problem. Try to update you switch to a latest firmware and disable ALL automatic features of the switch (LACP, CDP, what else?)
At the ent try to implement TTC in router mode.
At the end try to connect check if the same configuration works without Procurve (temporary replace witc HUB, or other switch. You can even connect one PC directly to the TTC.

Where the page you want to tedirect the user located? Outside the pix in the DMZ/internet, or incide the PIX, close to user PC?

[James_336]

Maybe I overcomplicated things, but let me run this past the group. I am thinking the reason my redirects are not working is that the Lightspeed box is on the same network as the PIX on the internal network because I needed it to continue the connection to the PIX VLAN I have setup. This puts the Lightspeed box solely on the same network as the PIX only. I am thinking if I can somehow get the Internal connection to the same VLAN as the clients are on, this will alleviate my problem. I am having a hard time coming up with a solution around this problem. I am thinking that my PIX should not be on its own subnet, but on the same subnet as my client computers?