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

q-in-q / HP SPF modules

Mark Castle

q-in-q / HP SPF modules

We've been an HP customer since the mid to late 1990's and have always been happy with their switches. However i find i am now having to look elsewhere for 2 reasons:

Firstly, when are you going to support q-in-q on your standard switches (eg 2824 etc)? We're desperate for this functionality but find ourselves having to look at alternative manufacturers for it.

Secondly, why are you ripping us off with the price of SPF modules. I get really annoyed having to pay a premium because you have edited the firmware on a 3rd parties module and made it impossible to use any modules that don't have the HP codes in them. SPF is a format that is *designed* to allow interoperability. For goodness sake, stop ripping us off by buying SPF modules from Finisar, putting HP codes in them then selling them at a huge markup; its damaging your market as we and i suspect others are having to look elsewhere.

rant over..sorry.
Karl Austin
Occasional Visitor

Re: q-in-q / HP SPF modules

Couldn't agree more on both points, I've just done a quick check:

Finisar LX SFP - $129 online
HP LX SFP - £450 here in the UK

Both exactly the same thing - just the same as our HP SX SFPs are the exact same thing as the Finisar ones we had to stop using because they haven't had the HP ID blown in to them.

Q-in-Q - It's just embarassing, even D-link have switches with Q-in-Q now.
Matt Hobbs
Honored Contributor

Re: q-in-q / HP SPF modules

My views on this (and they don't necessarily represent the views of HP) is that the new firmware was brought about because of an increase of counterfeit mini-GBICs that did not always meet the quality control standards that the genuine parts do.

This costs HP in many ways, first off it is very likely a warranty call could be logged with HP on a faulty counterfeit gbic. HP not knowing it is not an HP part, sends the customer a genuine gbic and the problem is fixed, but only later down the track do HP find out it was a counterfeit part.

You may know that the gbics are Finisar but someone else probably won't, so if it ever does go faulty HP is likely to be the first point of call.

Another example is you have a 3rd party gbic that is working in another product but is just incompatible with the HP switch. You may call support and say the switch must be faulty... a new switch is sent out, but it turns out that it is indeed just incompatible for some other reason.

This all takes support time and resources caused by a faulty 3rd party product that HP is not responsible for.

Finisar are also a trusted brand, but who's to say that there aren't counterfeit Finisar gbics out there too? The only way HP could be sure was to start using these anti-counterfeiting methods.

If you want to ensure your network is going to run reliably in the long run, you should purchase the geniune tested and supported accessories.

These same measures are taken by many other companies to protect themselves and their customers. A good example is server HDD's. Vendor drives are often a few megabytes smaller than the standard disks made by the original manufacturer - so when one fails in a raid set, if a vendor drive is sent out to rebuild it, it will fail the rebuild everytime. Straight away this points to 3rd party disks and once again goes to show that support teams often don't know about this and it ends up costing you and the vendor much more.

Sergej Gurenko
Trusted Contributor

Re: q-in-q / HP SPF modules

My ideas about q-in-q (or VLAN aggregation)
HP Procurve networking primary targeting Enterprise, but not a Service Provider customers. That is why they have no Q-in-Q, MPLS and Virtual routers or simple routing tables isolation (VRF-Light) at the moment.
Other aspect is that HP Procurve are also balancing in the middle of functionality and components price. Vendors who wants to sell overpraised Service Provider equipment to the enterprises start discovering new frameworks, e.g. "Enterprise MPLS Core" from Juniper.

You can get some information about Q-in-Q from you local HP representative.
Karl Austin
Occasional Visitor

Re: q-in-q / HP SPF modules

Counterfeit SFPs - Okay, I can understand that (not 100% though, see later), but we're all adults here, surely a less drastic solution for those of us with our heads firmly screwed on and who don't want to be right royally ripped off (I'm sorry, how on Earth do you justify a price difference of £375 on LX SFPs?), is to allow us to over-ride this - Ask us some big scary question that'll put off those who don't know what they are doing e.g.

"If you disable the checking for genuine HP SFPs, then HP will not be responsible for any problems/faults arrising out of the use of non-genuine SFPs."

To be honest, the counterfeit issue doesn't really wash 100% with me, because if somone wants to produce proper counterfeits, then they'll obtain a genuine SFP, then copy it exactly - including any HP codes in, counterfeiters aren't stupid people - They may be criminals, but they aren't usually stupid when it comes to producing something counterfeit and electrical.
Sergej Gurenko
Trusted Contributor

Re: q-in-q / HP SPF modules

Back to SPF. Here is interesting document: Small Form-factor Pluggable (SFP) Transceiver MultiSource Agreement (MSA)


The SFP serial ID provides access to sophisticated identification information that describes the transceiverâ s capabilities, standard interfaces, manufacturer, and other information. The serial interface uses the 2-wire serial CMOS E2PROM protocol defined for the ATMEL AT24C01A/02/04 family of components.


Is it possible to rewrite SPF CMOS without special equipment?

Re: q-in-q / HP SPF modules

Me to fully agree that these two issues are real showstoppers right now. I can understand why HP don't want us to use other SPF modules than their own branded ones, even though I don't like it.

The lack of IEEE 802.1ad Q-in-Q support is a far bigger issue for us though. We run a Layer 2 Provider network connecting over 30 sites using Procurve switches (2626, 2824, 3400, 5300). Over that network we provide Layer 2 tunnels using 802.1Q tags for our customers. Now a days most of our customers have started to use their own Q-tags in-house and want us to transport multiple tags through our network. Syncing our tags with our customers are starting to become a major pain in the ass. Just like the OP we are very satistfied with the Procurve switches in general so I'd hate having to switch to another brand, but if HP can't provide us with Q-in-Q support within 6-12 months we have no other option than starting to repleace all our equipment.

Like some else said, it's not only the highend brands like Cisco and Extreme that has Q-in-Q support today, even low-price brands like D-Link and Zyxel have it in the their products targeting the same market segment as HP's procurve switches, so HP not supporting it is just silly. Since Dec, 2005 it's even an closed IEEE standard (802.1ad) if I'm not misinformed.
Regular Advisor

Re: q-in-q / HP SPF modules

We are in the process of buying new core switches that will connect to our Juniper routers. We have ~90 5304xl in our network and a sh*tload of 25/26 series, and would like to keep on using HP switches. We need 24 SFPs in these core switches.

However, the Jumbo frames support in 5400 and 6200 obviously does not include support for QinQ. This is only supported in the 9300 series. Cisco does not have any products with small footprint as of now that meet the requirements (no of SFPs). They will ship something called 6524 later this year that seems promising. However, today I just found Extreme (1U) and Allied Telesyn (1U) to meet our requirements, that is price, # of fibers and support for QinQ. I really wouldn't buy anything for my core that didn't support this now.

And the SFP issue - this is just a way to squeeze whatever money they don't make on service contracts out of their customers. Juniper and Extreme do not feel the need to do this.

I really liked HP before.

Rob Talley
Occasional Visitor

Re: q-in-q / HP SPF modules

Personally I think that the stance HP is taking is absurd. Next are they going to disable the switching if you have a non HP Patch cable or computer because it could be counterfeit or cause for a call? We are intelligent professionals and would like the ability to connect any manufacturers SFP device properly designed for the SFP slot... period. Being a consumer that purchases standards based/designed devices on a regular basis I am appalled. We had the pleasure of installing some switching at a site that had some Dell switches installed by a previous vendor and the HP switches were ordered by yet another but never completed. The site ordered all of the GBICs from Dell with the first order. The Dell SFP GBICs obviously are quality made and are not counterfeit yet we cannot use them. In fact they are made by Finisar the same company who makes them for HP! Also why is HP not going after the few that are manufacturing such counterfeit devices? Are there really that many counterfeiters with the equipment to produce these? Instead HP has chosen to limit the customer and thus I am voting with my money. I will purchase non HP switches from here on out.
Occasional Visitor

Re: q-in-q / HP SPF modules

One problem area with vendor SFP locking for some networks is that there are often no CWDM optics on the list (this seems to be the case for HP).

I do understand the problems caused by counterfeiting (though also agree with the comments that reprogramming the seeprom isn't going to be beyond counterfeiters) so perhaps some tucked-away fault-finder option might still make third-party SFP difficult enough to use to satisfy those requirements, but still allow people to use HP in the cases where vendor SFPs aren't available.

Further reading: