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

Blocking a link on GbE2?

Anders_35
Regular Advisor

Blocking a link on GbE2?

Because of maintenance work, I wanted to reroute traffic from one network link to another. Specifically, I wanted traffic from a blade enclosure to exit through Switch B (right side) instead of Switch A (left side).

A and B are configured identically, they run RSTP, and they both have a 4-port trunk to ProCurve 3424's. Spanning-tree blocks the interconnect trunk (Trunk 1), so both switches keep their uplink trunk open.

Now, I want to block the uplink from Switch A, so that RSTP will open the interconnect links and pass all traffic from A through B.

So, I tried disabling the trunk. (Not the ports, just the trunk.)

Our spanning tree reacted immediately, and a topology change was logged.
BUT Switch A still kept the interconnect trunk blocked, and tried sending the traffic over the now disabled uplink.

So, did I screw up? Or was this as wrong as it looks to me?
14 REPLIES
Matt Hobbs
Honored Contributor

Re: Blocking a link on GbE2?

Hi Anders,

I'm not that familiar with the GbE2's.... instead of disabling the trunk on the GbE2, why not disable those ports on the 3424 instead?

Matt
Lei.Ma
Frequent Advisor

Re: Blocking a link on GbE2?

and,if 3424 use static trunk. maybe can you try use lacp trunking?
Anders_35
Regular Advisor

Re: Blocking a link on GbE2?

Sure, I could've done all that.
But as it happened, I tried to block the link from the blade-end, and I just wonder why it failed.

The only reason we're not using LACP is that originally, the blades were plugged into a switch that didn't support it. (And I'm not sure that the old GbE2 firmware did either.) We just haven't taken the time to reconfigure.

Ray: do you think that this would have made a difference?

Matt Hobbs
Honored Contributor

Re: Blocking a link on GbE2?

When you disabled the trunk, did the ports go offline on the ProCurve and remain offline?

I'm imagining a situation where disabling the trunk simply removes it and they become 4 independant ports again, therefore 3 of them would be blocked but 1 would still be active which is why the interconnect trunk was still blocking.

I can't imagine the type of trunk (LACP or other) making any difference on this whatsoever.
Anders_35
Regular Advisor

Re: Blocking a link on GbE2?

No, they didn't. That's one of the things that's puzzling.. All 4 uplink ports were forwarding, and the 2 interconnect ports were still blocking.

I am guessing that there is an issue with the way these switches separate ports and trunks. Much neater on the procurves, where for all practical purposes, the trunk replaces its ports.
Anders_35
Regular Advisor

Re: Blocking a link on GbE2?

Just to clarify:

>All 4 uplink ports were forwarding,

RSTP was /listing/ them as forwarding.
But since the trunk was disabled, no traffice made it through.

And the consequence was that there was no link out of that switch whatsoever.
Matt Hobbs
Honored Contributor

Re: Blocking a link on GbE2?

Did you check on the ProCurve as well if those ports were forwarding? (Or the GbE2 if you were referring to the ProCurve's spanning-tree forwarding status).

You'll only see the blocking on one side of the link, not on both. I apologise if you knew that.

Anyway, it's sounds very much like that's what happened, the trunk was removed from the configuration, they become normal ports and spanning-tree on the ProCurve blocked 3 out of 4 ports (which is good) and on the GbE2 it looked as though nothing had changed.
Anders_35
Regular Advisor

Re: Blocking a link on GbE2?

Yeah, that does sound like plausible explanation. However, there is no trace of STP blocking anything in the ProCurve log.

I've logged this with HP support, so let's see what they say. They did confirm that they have seen issues with the GbE2's confusing a trunk and it's individual ports before.

Lei.Ma
Frequent Advisor

Re: Blocking a link on GbE2?

sorry about last time reply, but LACP can do Dynamic trunk,when you disable the Trunk maybe the lacp dynamic generate lacp trunk from 4 uplink . and the spanning-tree priority sitll high?
show interface config, show lacp ,show trunks; show spanningtree , after you disable the trunk. check the cost and priority.
i am not sure it,just assumed.
DaGuru
Trusted Contributor

Re: Blocking a link on GbE2?

Anders,

In stead of dissabling the trunk, try dissabling the physical uplinks themselves. This will assure no traffic gets through. Being that you had a topology change, I would agree with the others in that the ports probably managed to forward data.

I clipped the following from the CLI Guide.

To temporarily disable a port without changing its stored configuration attributes, enter the following command at any prompt:
Main# /oper/port /dis
Note: Be sure to dissable all 4 trunk members.

Because this configuration sets a temporary state for the port, you do not need to use apply or save. The port state
will revert to its original configuration when the GbE2 Interconnect Switch is reset.
---------------------------------------------
I work for HP, but my posts and replies are my own.
Anders_35
Regular Advisor

Re: Blocking a link on GbE2?


Hi, Dennis.

>In stead of dissabling the trunk, try
>dissabling the physical uplinks

Well, that's what I was trying to avoid.
Two commands vs. eight for the entire operation reduces likelyhood of errors significantly.


>Being that you had a topology change, I
>would agree with the others in that the
>ports probably managed to forward data.


Only RSTP data. No switched data came through from the servers hanging off that switch.
And herein lies the mystery...
Since RSTP kept the ports open, why was there even a TCN? The STP didn't really change.
DaGuru
Trusted Contributor

Re: Blocking a link on GbE2?

Purely speculation on my part, but if the VLAN(s) are assigned to the Trunk, disabling the trunk may have allowed the member ports to revert back to their pre-configured state (transmitting BPDUs on the native VLAN.) This may have been enough to signify a TCN as dropping the trunk could have generated a 'flapping' state.

You might be able to catch the anomaly with a protocol analyzer?

I'll be interested to see what direction your support ticket leads you.
---------------------------------------------
I work for HP, but my posts and replies are my own.
Anders_35
Regular Advisor

Re: Blocking a link on GbE2?

Yeah, that sounds like it. HP pointed me to an advisory (EB050408_CW01) for a similar situation, in which a broadcast storm occurs because disabling trunks momentarily puts ports in that "flapping state".
(I don't recall all details, and that web page is not available just now..)

This teaches me another lesson.
In a discussion here the other day (also with Matt Hobbs), I made the assumption
that a port would only change into a bridge link following a "link up".

Apparently, that was very wrong.
Connery
Trusted Contributor

Re: Blocking a link on GbE2?

Anders,
One of the easiest ways to manually force a particular port (or trunk) to become the root port/trunk is to manually change the STP port cost value.

In your setup, you could have increased the port cost value on Switch A's uplinks, forcing it to start using the interconnect ports (17/18) because they would then have a lower STP port cost. Or, you could have decreased the port cost on the interconnect ports to achieve the same thing.

In regards to TCNs, you'll get TCN's anytime a non-Host port changes it's status (examples: blocking to forwarding, forwarding to blocking, link up, link down, etc.)

regards,
-sean