Switches, Hubs, and Modems
1752681 Members
5544 Online
108789 Solutions
New Discussion

Re: Routing Problem between Procurve 9300 and 5308 switches.

 
Brady Hiscox
Occasional Contributor

Routing Problem between Procurve 9300 and 5308 switches.

I have this problem that I just can't seem to figure out, maybe I've been looking at it to long in a uncomfortable little server room. I thought I would ask the forum to see if anyone else had ideas.

A rundown of the setup is as follows. There is a HP Procurve 9300 switch as a core with quite a few HP Procurve 5308 switches as edge switches. Most of the configurations are identical with the exception of a few test switches.

On the 9300 we have some core devices landed on it that are Linux and windows boxes. On the edge we have 90% linux boxes and a few windows pc's. There's really nothing special going on here.

The problem is we are getting timeouts when communicating from one end to the other. Additionally if I do a traceroute from any machine to the other end on the core the hop that goes through the core switch will timeout until finally getting to the destination.

Basically in the system that is in place this is causing a ton of false alarms and failover devices to kick in when they shouldn't be.

I don't have the configurations handy on this computer but will try to attach them later. A rundown is as follows:

On the core switch there are several /24 networks with a default gateway of .254 in each of them. The network ranges are essentially all 192.168.x.0/24

Interconnecting the switches are /30 subnets in the 192.168.10.x/30 range.

OSPF is the routing protocol in use, spanning tree is enabled as well as PIM-DM.

On the edge it is all /24 subnets with the default gateway being .1 in the range they are all addressed in the 192.168.x.0/24 manner.

The trunks between the switches are just setup as trunks with no lacp and the trunk is untagged in a respective vlan on each edge switch and the core switch.

The default vlan is unaddressed and has no ports tagged or untagged.

I sort of inherited this design and it is in a mission critical application that makes changing this nearly impossible. Sorry I was not able to attach some network configurations but I gave you the majority of the information.

Thanks in advance.
1 REPLY 1
Ben Dehner
Trusted Contributor

Re: Routing Problem between Procurve 9300 and 5308 switches.

This is difficult, because your problem could be in layer 2 or layer 3. Without some more detailed information, it is hard to diagnose the issue. I am not familiar with these particular models of switches, but here are a few things to check.

For layer 2, I would suggest that any interswitch trunks always be tagged ports. You will also want to review the VLAN configuration and make sure that they are consistent. Since each of your links are a seperate /30 subnet, this means that they need to be in seperate VLANs. All of these VLANs need to be defined in the core switch, with the appropriate VLAN on the edge switch. In the long run, it would probably be eaiser to create a single /24 network as the "routing backbone" network, rather than dealing with all of these /30.

Also, you state that "the trunks between the switches are setup as trunks with no lacp". I don't know how these switches do trunking, if you have multiple links for the ISLs make sure that spanning tree isn't randomly disabling some of the ISL ports.

At layer 3, review the OSPF configuration. First, make sure that each switch has a unique router ID. You will want to check the routes and the LSDB on all of the switches to make sure the routes are being propagated properly. Each switch should have a router LSA from each other switch in your environment. I have also noticed that sometimes OSPF needs to be tweaked a bit differently for point-to-point networks (like your /30 links) verses a broadcast network.

Also check the area ID of each of the switches. If there are multiple areas in the OSPF config, those also have to be consistent, and the core 9300 has to be set up as an ABR.

Hopefully, there may be something here that helps.
Trust me, I know what I'm doing