HP ProCurve 5406zl routing problem

[Borvik]

I'm having some problem with routing an incoming connection - and I am no network engineer.

We got a new ISP with ethernet handoff through a WatchGuard - I do not have access to the WatchGuard. It is configured to NAT some of our public IPs to their corresponding internal server IPs, and put that traffic onto our switch on port A1.

I am unable to ping or connect to our servers using the new IP addresses assigned to us. It appears that it is routed correctly to us and our switch - but once at the switch it never reaches our servers.

Here is our setup.

We have 10 VLANs, and I believe our core switch (the 5046zl) is doing the routing between the subnets/VLANs. This core switch is connected to two other switches: a 2650, and a 2626 - I believe using some sort of Trunk. Our servers are attached to these last two switches and are in the IP subnet: 192.168.107.0/24. "show ip route" on the 5406zl shows that destination should be routed to our DMZ VLAN.

I setup a laptop with Wireshark, and configured the switch for port monitoring, then pinged one of our new public IPs. Sorting through the Wireshark data, I did find the ICMP packets coming into the switch properly NATted to the servers IP address. These were apparently being routed to a MAC address that after some digging and using walkmib on the core switch maps to the following ifPhysAddress: 291, 292, 410-417, 429, and 430. I'm not really certain how to interpret that.

I hoping someone can help me debug what is going wrong and how to fix this.

Thanks.

 

[unclerico]

You have verified that the IP range your new ISP assigned to you is setup correctly in the WatchGuard?? If the only thing that has changed is the new IP range, I would begin at the firewall.

 

[Borvik]

As I said I can't get into the WatchGuard to verify settings - however, I do believe I have figured out the issue.

Running the port monitoring on the server port, I was able to detect the ICMP reply and response from the server. While my ping was failing this indicated that the incoming routes were indeed setup correctly, and that the server was attempting to respond.

Analyzing the Wireshark data for the ICMP response, I found that the response was using our old ISP still. After trying to fix the outgoing routes within the switch (with no success), I found that the default gateway of the servers was pointing to the old router, bypassing the outgoing routes I setup in the switch.

Once I changed the default gateway of the server to point to the core switch, my outbound routes started working - and so did my ping.

 

[VinceWhirlwind]

Physical interface IDs like 291, 292, 410, etc.. are the internal way the switch identifies, say, interface G3/23, etc...

I've forgotten where you can check how these are mapped but there will be various show commands that elucidate it for you: try "show interfaces" for starters.

 

[Borvik]

Yes, I understood that - the low numbered ids I could easily map to the physical ports, though with numbers that high (well above the number of actual ports in the switch) I have to assume that they are somehow for the VLANs.

Fortunately for my issue it no longer matters, as we up and running on the new ISP - and everything appears to be working correctly. Now we just have to wait for DNS to fully propagate.