Switches, Hubs, and Modems
cancel
Showing results for 
Search instead for 
Did you mean: 

Procurve and RIP issue

SOLVED
Go to solution
The Wiz
Occasional Visitor

Procurve and RIP issue

Hi. I'm not used to working with HP switches but have come up against the following issue. Scenario: Core switch is a HP 5304XL. It talks to a firewall via OSPF for Internet access on one vlan, and to another HP switch for internal Global routes via OSPF on another. Users are on a third vlan. I recently added a remote office to the network using two (2) wireless links (the remote office is accross the road) and placed both links into the user vlan to bridge this LAN to the new office (bridging and using STP to take care of the loop). The two links connect to a HP procurve 3500YL switch with a dozen users on it. This all worked fine but as there are VoIP phones in use in the remote office, collisions in the wireless link was a potential issue.

I thus constructed a new design where the links were made into layer 3 links on new vlans in the core switch and the remote switch. I have configured RIP on these two switches for both of these vlans to get routing information to the remote office. The core switch is redistributing its configured static route for 0.0.0.0 to the remote switch via RIP. I configured opposing interfaces with differing RIP metrics to preference traffic flows. Link one at core has metric 5 added to learned routes and link two is default metric 1. Link one at remote has default metric 1 and link two has metric 5 added to learned routes. Thus, traffic flows should be from core to remote site via link two and return via link one. A psuedo full duplex set up that prevents collisions except if one link fails and all traffic flows over one link again.

This is where I run into my problem. The remote switch see's link one as the best default route (advertised by RIP from the core switch) and thus traffic flows that way which is as expected. The core switch sees the remote LAN as being via link 2 (show ip route) BUT when you do a traceroute from a user in the core site, traffic flows through the link one neighbour (shows link one IP as a hop). If I traceroute from the core switch I go through link two as expected. Why is this and how do I get the traffic from a user/server to flow to the remote office via the installed route using link two???

I either know less about RIP routing than I thought - or - the HP's do something I can't see and I don't have enough experience with them to see it. Many thanks in advance for any help offered. I have trolled HP website and perused many manuals but no luck. I am happy to post a simple network diagram if needed or some relevant config or show commands.
3 REPLIES
Matt Hobbs
Honored Contributor
Solution

Re: Procurve and RIP issue

I'm wondering if this being caused by a software bug on the 3500...

With the current version of software on the 3500, there is an issue with ICMP TTL expired messages being sent with the SA of the interface that the messages leaves from, rather than the interface that received the expired packet. This will cause your traceroutes to give you misleading information but other traffic should be taking the correct path.

If you contact ProCurve support you can request K.13.16 which should resolve that.

Otherwise, can you verify that traffic is taking the right path by blasting some traffic out and checking your port counters?
The Wiz
Occasional Visitor

Re: Procurve and RIP issue

Thanks Matt. I graphed a blast of traffic from both ends and traffic WAS flowing the way I intended it to. I suspect you are absolutely correct with your thoughts on the ICMP bug and am planning a image upgrade to mitigate any complications with troubleshooting down the track. Thanks again for the point in the right direction.
Matt Hobbs
Honored Contributor

Re: Procurve and RIP issue

No problem - I really like your "pseudo full duplex" solution. Makes perfect sense but I'm not sure if I ever would have thought of it. I'll definitely be keeping it in mind. Nice work.