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

ProCurve 4100gl/J4863A and GBE2 trunking problems

Michael Bradburn
Occasional Visitor

ProCurve 4100gl/J4863A and GBE2 trunking problems

I have a small issue I am trying to resolve. I have 2 blade encloses with 8 BL20P servers in each. I have a GBE2 in each one that I have trunked 4 ports to run to a single Procurve 4100gl switch with 8 J4863A GB modules in it. On the GBE2 side, I have set the speed to GB and the duplex to full.

On the Procurve side, I have created two trunks with 4 ports each. I have tried to set the ports to 1000-full, but I get an error: "1000-full is not applicable to port xx". Not sure why this is happeneing first of all???

So, I have two trunks configured, four ports each, one trunk for each GBE2 I want to connect to this switch. If I connect both trunks at the same time, the ports get shutdown with LACP blocking. I created the trunks with the "trunk" option, not with "LACP". I have tried to turn LACP off on all ports, but it seems to be needed whether you are using the LACP option or not on the trunks.

If I connect only one, everything is fine. If I create another VLAN and place one trunk in VLAN1 and one in VLAN2 it works fine. When they are in the same VLAN, they start blocking.

This looks to be some sort of looping problem, but I can't see why. The two GBE2 switches are not connected to each other before they are trunked at the procurve switch, so this should just look like one big network, no different than running just a single cable in place of the trunks.

Any ideas on how to get this to work properly? I need all of this on the same network, so having the two trunks in different vlans is not really a good resolution.

Thanks,

Mike
7 REPLIES
Gonzo Granello
Valued Contributor

Re: ProCurve 4100gl/J4863A and GBE2 trunking problems

Mike,

i can help with that one..... Fist of - get rid of LACP.

4100 conf> int all
4100 conf> no lacp
4100 conf> wr mem

2nd: the reason why you can't set the port to 1000 full duplex is simple. Gig always (per IEEE spec) operates in full duplex. The only parameter autonegotiated is Flow-Control.

I would recommend to set both sides to AUTO since that should not create any issues - you cannot compare that to 10/100 ports which indeed negotiate full and half duplex. Or to say it different: if you set one side to be "fixed" no auto negotiation will be possible on that port, hence the other port will not know what to do.

For your example, create two trunks, like TRK1 has ports a1-a4 and TRK2 has ports b1-b4 (just as example) and connect your server accordingly. That should work, i have done that many times. Now, there is a caveat - as always. For one, trunking does not really increase bandwith in all use cases. Why? Simple, pending on the way traffic is forwarded (most times by MAC address) traffic uses the same link it learned first unless you incorporate some load balancing method on the server side. Second, the backplane interface for the 4100 modules is two gig links / module. If you can switch traffic on the blade - not a problem, however if you try to go all 4 gig true the backplane (i.e. to another module) than you will experience some bottelneck.

Hope that helps.

///Andreas
most time the day i have to mask my contempt for the a-holes in charge......
Michael Bradburn
Occasional Visitor

Re: ProCurve 4100gl/J4863A and GBE2 trunking problems

Andreas,

Thanks for the reply, but there are still a few problems.

The GBE2 switch in the blade enclosure will only allow a trunk if duplex on the ports being trunked is set to "full". This causes a potential conflict since the Procurve will only allow "auto".

I did disable the LACP by fist removing existing trunks on the Procurve, removing the LACP support and then re-creating the trunks.

After this, same problem exists. I can not trunk the GBE2 switches more than one at a time to the Procurve switch w/o blocking occuring.
Gonzo Granello
Valued Contributor

Re: ProCurve 4100gl/J4863A and GBE2 trunking problems

Mike,

are we talking about the same thing here (vlans in Cisco terms as trunks??) or are we talking port trunking per se? If you turn flow control off on those ports involved, they will be 1000fdx, hence not autonegotiating. This is kind of a snafu in the spec, they always run 1000fdx so you cant set it to that but the autoneg really reffers to Flow Control which happens to be another setting.... :-) Lacp needs to off before creating trunks otherwise you can't set that anymore (makes sense i guess). Again Vlan membership of ports should be a non issue, it will be reset to the default Vlan (1) when creating trunks anyway - once done go to the vlan config and tagg or untagg the trunk. Let me know if that helps.

///Andreas
most time the day i have to mask my contempt for the a-holes in charge......
Gonzo Granello
Valued Contributor

Re: ProCurve 4100gl/J4863A and GBE2 trunking problems

Mike,

one more thing just crossed my mind. I understand you 2 blade server cabinets with a switch in each of them? Are you sure you turned trunking on on those ports? If so - what kind of trunks? It will loop if you create a trunk on one but not the other side. Again, LACP should be either off or you could use it if the BL servers support that. If you use lcap however, vlan membership is not absolute unless you run everything in the default vlan. (one reasons why i dont like it) So, just make sure you have trunking turned on at the server side and there is no other connection between the server cabinets, hence the switches there or at least make sure that if there is a connection that it uses a different vlan - otherwise L2 LOOOOP.

If that helps, points will be apprechiated, if not let me know.

///Andreas
most time the day i have to mask my contempt for the a-holes in charge......
Michael Bradburn
Occasional Visitor

Re: ProCurve 4100gl/J4863A and GBE2 trunking problems

Andreas,

I am talking about port trunking, not the Cisco vlan trunking. On the blade GBE2 switches, I did trunk 4 ports. The GBE2 does not support LACP, so it defaults to what the Procurve calls "trunk" port trunking, if that makes sense, not LACP. I ran 4 Cat5e cables to the Procurve and trunked 4 ports together there, so trunking is enabled on the 4 ports that attach the 2 switches together on both sides. I did this same procedure with the second GBE2 switch, but when I connect this switch, the ports start blocking.

There is no other connection between the switches, so I can not figure out why they would start loop blocking, but it looks like that is what is happening. The only way to keep them from loop blocking is to land them in seperate vlans on the procurve switch, but this is not what is needed. I need one big network, not several small ones.

I have tried all of your suggestions and the problem is still there. Best I can tell is that there is a compatability problem with these switches. For right now, I have ordered in 160+ cables to run patch panels in the blade enclosures so I can trunk from one procurve to another procurve and by-pass the GBE2 switches all together. I have 5 blade enclosures with 40 BL20P servers and 4 networks to run, so the patch panel is not the optimal solution, but it is the only one that works. Having this problem with the first two enclosures has set me way back and I have to move forward.
Gonzo Granello
Valued Contributor

Re: ProCurve 4100gl/J4863A and GBE2 trunking problems

Mike,

send me you phone # to akoertel@hp.com and let me also know where you at (timezone) and i'll try to fix that with you


///Andreas
most time the day i have to mask my contempt for the a-holes in charge......
Jeff Allen_5
Valued Contributor

Re: ProCurve 4100gl/J4863A and GBE2 trunking problems

The 2 GbE2 switches ARE connected via an internal trunk of prots 17 and 18. The behavior you are seeing is by design.

The reason you get the "cannot set to 100-full" type of error message is because half duplex is not a valid option when operating at GB speeds. The FLP frames sent to detect speed/duplex are much improved for GB over FastEth, so you are best to leave ALL GB connections set to auto/auto on both ends. "Forcing" a GB connection does not disable autonegotiation anyway - it just changes the port's advertised speed only - but it still autonegotiates the connection with it's peer.