Comware

I wonder if anyone knows what method procurve 5400 switches uses for OSPF load-sharing (over links with equal costs) , Session based or Packet based? Is there any possibility to configure this?

With the newer K.13.xx software, host-based ECMP was introduced (believe it chooses a link based on a hash of the source and dest IP address). Previously it was ECMP per destination subnet which wasn't that great.

The only option that can be configured is how many ECMP paths it can choose from (1-4).

Thank you for your answer. As I understand from your answer this means that load balancing is session based, correct?

This is my take on it, but I'd actually like someone to verify my thoughts:

With host-based ECMP (ProCurve), all IP conversations between two hosts on different networks, should take the same outgoing path. A basic Layer-3 type load-balancing

Session based to me sounds more like something Layer-4, where if you had two different TCP conversations happening between the same two hosts, it could potentially put different sessions over different paths.

Packet based load-sharing, could put different packets from the same outgoing conversation over different paths.

The problem with Packet based and Host based is that there is no garauntee that the return traffic will use the same path, creating a problem if you've got any stateful firewalls. Actually if Host based ECMP uses the router-ID in its path selection algorithm it could potentially avoid this situation.

Likewise, session-based is only good if all ECMP routers support it.

There seems to be suprisingly little information about all this on the web... hoping to hear about others experience on this one.

Stefan,

AFAIK the ECMP in yl/zl 13.x code is finally comparable to what others call "per destination", which isn't the same thing as "session based" (that's what others call "per flow"). I wouldn't expect anything "per packet" in the L3 switching arena, the most widespread way to load balance on ECMP here seems to be per-destination. It might be a src-dst-hash instead of just a dst-hash (I don't know for sure, either) but that doesn't make it per-flow. That would require either some L4 fields going into the hash (typically on L3 switches) or a full fledged flow cache (typically on software routers), but FIB architectures are ever changing and hybridizing these days and ProCurve doesn't seem to publish much about how they do it (same with the QoS architecture).

HTH anyway,
Andre.

Just to clarify "session based": I mean L3 session. I don't think OSPF supports L4 session balancing. As far as I know OSPF supports per IP packet balancing or per IP session balancing. I have read the 5400 manual but it doesn't say anything on which method 5400 are using. I have problem with voice traffic (SIP) over OSPF balanced network. My feelings was that it might be a problem if the 5400 switches uses IP packet balancing and the packets are reciving to destination router in different order. I presume that they are using per IP session balancing but it would be nice to have this commited.

Hej Stefan!

I also think it would be interesting to know how the OSPF load sharing actually works and I agree that the Procurve manuals somethings is very un-specific about technical details like this.

Do you have any possibility to run a packet sniffer at one or both of your next-hop addresses while you have some known session going on? That would likely show if the sharing is by packet or session.

Re Stefan,

> Just to clarify "session based": I mean L3
> session.

That's either a dst-hash or a src-dst-hash. And it's what most L3 switches are doing.

> I don't think OSPF supports L4 session
> balancing. As far as I know OSPF supports
> per IP packet balancing or per IP session
> balancing.

OSPF doesn't "support certain kinds of load balancing" at all. OSPF just establishes routes in the RIB, and when it supports ECMP, that just means it can establish more than a single route in the RIB given the routes are all equal (destination and cost) and just differ in the path (egress interface/next hop). Typically (and default on ProCurves) it will establish up to four equal cost routes.

How exactly those ECMP routes in the RIB are later used to load balance is a question of forwarding, thus the FIB implementation. OSPF is long out of the game when it comes to the actual forwarding, and load balancing works exactly the same regardless of which routing protocol (or static, or even connected if that would be possible) once established the routes. If they are ECMP, the FIB/forwarding implementation will have to load balance them.

> I have read the 5400 manual but it doesn't
> say anything on which method 5400 are
> using.

IMO you can be sure that it's not per-packet as long as we speak of L3 switches and LAN interfaces.

> I have problem with voice traffic (SIP)
> over OSPF balanced network. My feelings
> was that it might be a problem if the 5400
> switches uses IP packet balancing and the
> packets are reciving to destination router
> in different order.

That could indeed kill RTP (not SIP) with some terminal implementations that cannot deal with out of order voice packets, but that could be easily debugged (just use the function on the IP phone that displays stream statistics [on Cisco IP phones that's a fast double-? touch] or if nothing like that is available, loop in a sniffer).

> I presume that they are using per IP
> session balancing but it would be nice to
> have this commited.

Looking at the traffic graphs of some 6200yl core switches doing ECMP to a handful of distributions, the loads on the interfaces are too different for this to be per-packet. Given that per-packet is an implementation nightmare even on software routers and much worse on hardware supported FIBs, and given the track record of HP ProCurve boxes in implementing ECMP at all, I think it's a pretty safe bet that there's no per-packet load balancing happening on the yl/zl product line. Ever.

HTH,
Andre.

Hi Andre

Thank you very much for your help and your description of load balancing in Procurve switchies, this will clearify everything for me.

Kind regards, Stefan