download speeds through Procurve 1920-16G (no issues with upload)

[BennyBoy]

HI,

hoping someone can point me in the right direction.

we recently purchased a Procurve 1920-16G (web based config with very basic CLi ...ugh... although i've subequently found kbs on enabling the 'developer' enabled CLi).  

This switch services about 4 people in one department.  Their PCs are connected to it and there is a patch from this switch to our firewall, cisco asa 5515.  all 16 ports on this switch are members of the default vlan 1.

Prior to the new switch being introduced, we had these 4 users on a Procurve 5308XL , setup on a vlan, with the default gteway of this vlan pointing to the cisco asa 5515.

THE ISSUE IS:

when the users were patched into the 5308xl, there were no issues with the download and upload speeds ie from the pc browsing to www.speedtest.net we could just about max out the provisioned 50Mbps/50Mbps (up/down) internet bandwidth . 

Since we've moved the users to the 1920, their streaming of online video has been choppy and buffering.  when testing via www.speedtest.net the downoad is aroun 6Mbps, but upload still reaches close to 50Mbps

so i can only conclude that there's some issue with the configuration of this 1920 switch

I've enabled Link Aggregation , LACP -Dynamic on the port of the switch that patches through to the CIsco ASA.  but apart from that most everything else on the 1920 is default.

i've checked the port stats and there are no errors

any ideas?

[BennyBoy]

i notice there isn't an option to configure the switch with the 'ip routing' command as you'd do with Cli enabled procurves. 

is this implied by default on the 1920's?

[16again]

are you switching or routing the packets on the 1920?
If routing, beware it's internal "fast-path" ARP cache size is limited to 60 entries.  Additional hosts are software routed , resulting in low speeds

indeed, it seems the switch is always in L3 mode (but this requires multiple vlan interfaces, and clients using switch ip as l3 next-hop)

[cedimp]

Hi,

I could said something obvious for you, and you said that port statistic is correct : did you also verify on the ASA (show interface inside). Maybe some debugs (or ADSM logs) could give you some clues

I already had trouble with some asa and some switches, that forced me to fix the speed/duplex instead of auto (on both sides)

[parnassus]

Sorry, I really don't understand the role of LACP here.

LACP is a (Dynamic) Trunking protocol - you can eventually use Static Trunking too if necessary/convenient - that is primarily used to define how a group of aggregated ports - a Link Aggregation Group, or LAG in HP jargon, made up of at least 2 or more ports - behaves when is used to interconnect two active hosts by using some of theirs physical links in a aggregated style (e.g. when you need to improve resiliency against single/multiple cable/port failures and/or when you need to improve overall throughput in typicaly Switch-to-Switch, Switch-to-Host or Host-to-Host scenarios).

Why you eventually enabled LACP between the HP 1920-16G and the CISCO ASA 5515? what were your goals in doing so?

Did you instead verified bi-directional throughput performance (as example using the iperf tool) between two hosts belonging to the same subnet (on same VLAN1), both directly attached to HP 1920-16G's ports?

In a similar test, I easily saturated 1000 Mbps links locally (test was done in this way: Host A <--> Switch 1920-8G <--> Host B) so your symmetric Firewall WAN 50 Mbps D/U speed thresholds represent a tiny fraction of HP 1920-16G's switching capacity and a tiny fraction of its single port capacity.

The role of 1920-16G here, as I understand, is pure switching so if the CISCO ASA 5515 Firewall acts as the Default Gateway for the entire subnet (and so for the VLAN1) and all connected workstations use it as the Default Gateway I really doubt the HP 1920-16G could slow down switched traffic received by the CISCO ASA 5515 and forwarded to the workstations (doing so in a direction only).

Did you check the Firewall LAN port's configuration as suggested?

[BennyBoy]

thanks everyone for your contributions.  

it seems to be an incompatibility with the auto-neg between the ASA and this particular switch.  (thanks cedimp)

i eventually settled with 100/Full (ASA) and Auto/Full (1920).  the best outcome was 35Mbps/5Mbps (Down/Up).  however for the small number of users they perceive download and browsing experience as the most important factor.

i tried numerous combinations of speed and duplex on the ASA and the 1920 from 10/100/1000/Auto - half/full ... there was even a noticible difference on the 1920 when i'd use 100/Full vs Auto/Full  vs Auto-100/Full.  eg the Auto-100/Full on the switch with the 100/Full on the ASA gave 15Mbps/40Mbps (Down/Up)

i also played around with setting the port on the switch (to ASA) from Access to Trunk to Hybrid , and this didnt make a difference.  And again if i move all the same patches from the 1920 to our Procurve 5308xl, then i get close to 50Mbps/50Mbps (Down/Up).  so it must be an issue specifically between these two devices.

PS thanks parnassus for the explanation i've removed LACP.  

[cedimp]

Hi BennyBoy,

This is not a great idea to have "auto" on one side and "100FDX" on the other. From my cisco/hp experience you should have same thing on both side.

I guess you should put 100-full on each interface (on asa you have to type two line, one for speed, the other for duplex), no auto should remain on any side !

I miss the LACP part and yes i guess you should remove it.

Put  100fdx on both side, generate trafic and do a "sh int inside" on the asa and see if there are CRC or so....

And please clic on "kudo" if you find post useful !

[parnassus]

Strange.

I would check Hardware settings of connected/designated LAN interface on CISCO ASA first and verify that:

Media Type: RJ45

Duplex: auto

Speed: auto

Let/Set the HP 1920-16G connected port to CISCO to be the same: Speed auto / Full-Duplex auto.

CISCO port and HP port should then auto-negotiate flawlessly.

Keep in mind that 1 Gbps links work always in Full Duplex mode with respect to what can be set on slower 100 Mbps links.

Provided that patch cable used between the CISCO LAN interface (which is Gigabit) and the HP 1920-16G port (which is Gigabit too) is Cat. 6 certified then the link should set up at 1 Gbps automatically.

Eventually on CISCO LAN designated interface you could check (enable) the "Enable Pause Frame" check box which enable pause (XOFF) frame for Flow Control on the CISCO 1 Gbps Ethernet interface.

Always on CISCO LAN side check MTU, Jumbo Frame Support, EtherChannel (that's related to LACP Trunking discussed above and it shouldn't be used in your specific scenario) and VLAN statuses.

[BennyBoy]

...(suddenly realises basic rookie error)

parnassus - i think you've hit the mail on the head ...i've been using standard cat 5 for this interconnect and expecting Gb connection !!!! DUH *slaps forehead*

unfortunately im not in the office today but will swap out cabling next monday and will update you all.

although this doesnt explain why auto/auto on both sides gave me the poor download results (would it have defaulted to 100FDX or does it, because both interfaces accept Gb, then it wil try for Gb.).  but with that also said, there were no CRC or any errors on the switch port (didnt check the ASA)

i'll try with the pause frame option ticked on the ASA interface as suggested

fyi cedimp i did try hard set 100/FDX on both sides and it gave me poor download and poor uploads, so it was definitely worse than 100/FDX on side and auto/auto the other....definitely strange.

and agree, i've had no other issues with auto neg between ASA and numerous other model Procurve switches (4800-48g, 5406zl, 5308xl, 2910al,)...only this 1920 has caused me auto neg issues 

again, thanks so much for all your combined help

[Vince-Whirlwind]

It's worth remembering that the inter-switchport speed/duplex negotiation occurs using 2 pairs just like 100Mb ethernet communications.

Both sides can agree on Gb without actually knowing whether the other 2 pairs are even available.

In my experience, dud cabling on the Gb pairs (only) causes negotiation to be followed by the switchports going down completely.

As always, different vendors do things slightly differently, so it is possible some vendors would have a fallback to 100Mb mechanism even when Gb negotiation succeeded, but Gb connectivity failed.
(I don't even know what a 1920 is, vendor-wise. I think it's some kind of anon switch from Malaysia with HP branding).

Either way, surely the only way this could result in bad throughput would be if there were actual errors on the link - and you ruled out errors didn't you? Maybe a good question is - where are the errors and why aren't they being shown?

[parnassus]

---

@Vince-Whirlwind wrote:

(I don't even know what a 1920 is, vendor-wise. I think it's some kind of anon switch from Malaysia with HP branding).

---

That's because the HPE OfficeConnect 1920-16G (JG923A) is not ProCurve/ProVision based, it belongs to HPE 1920 OfficeConnect Switch series marketed for small business segment (so this whole thread should be moved to Smart and Unmanaged category to avoid confusion).

Downloading both Switch diagnostic and configuration files (it can be done quickly through the Switch web interface: for the diagnostic file go to Device -> Device Maintenance -> Diagnostic Information, for the configuration file go to Device -> Configuration -> Backup) could help in diagnosing what's really happening with that CISCO ASA firewall.