vlan 1

[tetzPeha]

Hi,

im trying to understand why HP force vlan 1 everywhere on comware 5 and 7.

when i configure a trunk, comware force the vlan 1 unless i dont write "undo port trunk permit vlan 1"

if i remove the vlan 1 from the trunk, i have no flow/network on PC connected on the switch.

So, how i can remove the vlan 1 and have connections ?

interface Bridge-Aggregation1
 description VERS COEUR
 port link-type trunk
 port trunk permit vlan 1 60
 link-aggregation mode dynamic

to

interface Bridge-Aggregation1
 description VERS COEUR
 port link-type trunk
 undo port trunk permit vlan 1
 port trunk permit vlan 60
 link-aggregation mode dynamic

without vlan 1, the switch cannot works ... so what i miss ? what i dont understand from HP ?

thx for your reply

[johnk3r]

Hello!

As far as I know, ALL manufacturers use a Vlan1 as default, so this behavior is not specific to HPE / ARUBA.

About your problem, if you want to remove a Vlan1 from this communication, you have to ensure that the interconnect switches do not use Vlan1 for communication.

Remember that Vlan is a broadcast domain that is usually associated with an IP address ...

[tetzPeha]

hi !

i never had this trouble/issue on cisco"s device, when i disable vlan 1 i dont have any problems. With HP, when i disable it and shutdown interface, sometimes i need it to have some flows ... :/

[sdide]

Hi,

what is at the other end of the link, and how is that other end configured?

Regards.

[tetzPeha]

same configuration both BAGG.

fun fact, last week, i used "port trunk permit vlan all" and PC's clients cant reach every services. (both BAGG the permit vlan all) when i configure with "port trunk permit vlan 1 200" everything works

seems weird :D

[VoIP-Buddy]

My experience with a lot of customer configs is that most specifically do not want VLAN 1 running everywhere because it is the default VLAN.

Comware breaks up the VLAN from the interface.  You can never remove VLAN 1 but VLAN 1 doesn't ever need to have an interface. 

In additon to permitting VLAN's across a trunk, you need to make sure that the ports are all in the desired VLAN.  There is also the notion of the default VLAN for a trunk.  That's the PVID.  For traffic that is not tagged, it will go out on the PVID. 

From your configuration example it appears that you have not added the ports to VLAN 60.  Go into VLAN 60 and use the port command to add the ports to the VLAN as untagged ports.  For ports that you want tagged traffic, set that up in the interface for the port in question.

Regards,

David

[Vince-Whirlwind]

Is the PC in VLAN60?
Show us the PC's switchport config.

It is completely normal to create switch-to-switch links that have no VLAN1 on them.

Having said that, you are using "dynamic" LACP (why?) which is something I have never done, so maybe that LACP negotiation protocol requires VLAN1 in order to function?

[tetzPeha]

port on device are on vlan 60.

switch can reach google, but not the pc :) i must make again the LACP and now, it's good (i dont know why).

im not an HP expert, i worked with cisco before. On every LACP, i saw "link-aggregation mode dynamic", can you explain me what is the purpose of this command ? because i can activate the lacp edge-port also. (the LACP are between 2 switches)

[VoIP-Buddy]

LACP could care less what runs over it.  It is just a data link.  In most cases, it is better to use Dynamic (LACP) Link Aggregation than Static as LACP maintains link state and if one has a problem it will deal with it.  If none are available the Link Agg is down.  WIth Static Link Agg, the link is always up... even when it is not.  The switch will never know that the link is gone and the bits will pile up on the floor...  ;-)

You can run anything on that datalink..  set it as a trunk or access.  Doesn't matter.

You'll want to run VLAN 60 across the link and all of the ports on the switch that will need that access need to be placed in VLAN 60 or you won't get the traffic across.  If you set it up as a trunk, most customers as I said previously, will remove VLAN 1 from the trunk since it is the default VLAN.

Regards,

David

[Vince-Whirlwind]

I have never had problems with static link aggregation. In the extremely rare situation that a physical link fails, then its interface no longer receives aggregated traffic in either direction.
I have managed many, many aggregated links over the years, adding or removing links on the fly whilst under monitoring and the situation you decribe has never arisen.
The only problems with link aggregation I have seen is when a software bug fails to hash the traffic destination properly (VMWare) or when a software bug causes MAC address tables to be populated wrongly (Nortel).
(Never had problems on HP, I almost always just use non-LACP Trunks on HP. At one point I tried switching to LACP and found it far more work and I gave up on it).

Early in my networking career, I encountered Cisco VTP and the BIG lesson from that is that your network topology should be *by design*, not subject to risk-prone dynamic protocols.
(Except for routing protocols, although I have seen people use them completely unnecessarily in some instances too).

[johnk3r]

@Vince-Whirlwind

Great observation !

[tetzPeha]

@Vince-Whirlwind

thx for your feedback, so for a BAGG, your advice is to do not use "link-aggregation mode dynamic" ?

and btw, VTP from cisco, i never use it, i disable it because it's a lack of security (same on HP)

[VoIP-Buddy]

I wouldn't draw that conclusion.  I would vote to always use dynamic and therefore LACP.  It is much more resiliant and the other benefit is that with multiple links, your link-aggregation bandwidth grows with each added link.  Static doesn't do that.

Regards,

David

[johnk3r]

Are not we confusing the LACP issue? Because COMWARE only works with static Link-Aggregation. When we enter with the syntax below, the switch will be using static lacp.

 link-aggregation mode dynamic

[VoIP-Buddy]

Johnk3r,

Sorry but no.  You are incorrect.  Comware does static and dynamic link aggregation.  If you use static link agg there is no state information maintained and the link is always up.  The other end will never know if there is a link down.

If you set the mode to dynamic, it uses LACP and that will maintain link state information and allow multiple links to be bound into the link aggregation to increase the bandwidth as the sum of all of the link speeds.  Assuming, of course, that all of the links are of the same speed.  If there are mixed speeds, the link agg will run at the speed of the slowest link.

To my knowledge there is nothing called "static LACP."  If you are using LACP you are doing dynamic link aggregation.

Regards,

David

[johnk3r]

[Vince-Whirlwind]

Wow, that's amazing.

[Vince-Whirlwind]

---

If you use static link agg there is no state information maintained and the link is always up.  The other end will never know if there is a link down.

I'm not sure what you mean.
If a link is physically up, and if it is in a LAGG, then that link ID will be included in the LAGG hashing algorithm and potentially receive outgoing packets.
If a link is not physically up and it's in the LAGG, the LAGG will not send any packets to it, no matter how you have it configured.

[VoIP-Buddy]

Vince-Whirlwind,

That's not how it works on Comware.  In a static Link agg, if the link goes down on the other side Comware doesn't know it and data will continue to flow into the link agg.  That has been my experience.  Static link-agg also does not aggregate the speed either.  It's just a pipe that is always open.

David

[VoIP-Buddy]

johnk3r,

I'm not sure where you got that text from but there is no such a thing as "Static LACP."  By it's nature, LACP is a dynamic protocol that manages the ports in a link aggregation group.  On Comware, that is what a dynamic Link-agg is. 

Static is static.  Ports are added to the a link-agg group and no state information is maintained.  It is just "there."

Regards,

David

[johnk3r]

@VoIP-Buddy

This screenshot was taken in the ebook for certification level architect (ASE) written by HPE.

[sdide]

Hi all,

there seems to be a bit confusion in the thread about the wording.

"LACP" is a specific protocol. It is this protocol that is used to achieve dynamic behavior in a link aggregation (normally a protocol induces something dynamic, because information travel across units using the protocol and updates behavior accordingly => hence dynamic as opposed to static.) "

Link aggregration" however is not neccesarily dynamic.

As i understand it, the big difference between static and dynamic om Comware is that when using dynamic mode both ends agree on which physical ports are Selected and which are Unselected in the aggregation-group.

And about a "link going down in one end" - normally Link is achieved using LLC frames and so link is something both ends agree about. Normally. I have seens links up in one direction only due to faulty switch or transceivers, but this affects all things among others Link aggregation.

Regards

[BjKo]

---

wrote:

---

If you use static link agg there is no state information maintained and the link is always up.  The other end will never know if there is a link down.

I'm not sure what you mean.
If a link is physically up, and if it is in a LAGG, then that link ID will be included in the LAGG hashing algorithm and potentially receive outgoing packets.
If a link is not physically up and it's in the LAGG, the LAGG will not send any packets to it, no matter how you have it configured.

---

Do not mix up static LACP with a static link aggregation. A static link aggregation does not use any protocol to negotiate, LACP is always negotiated.

With dynamic LACP you could connect the port with another device, which does not use LACP (PC, phone, ...) and it will continue without a link aggregation. The Port does not receive LACPDUs and does not build a link aggregation but still works and learns MACs and forwards traffic normally.

With static LACP the port will not continue to work when it does not receive LACPDUs. It will be in a active LACP port, sending and listening to LACPDUs, but it will not forward traffic. 
In Comware you cannot configure ports to change between link aggregation and "normal" dynamically, in Procurve you can (but you also need GVRP if you want VLANs).

With static link aggregation the link will always send and expect traffic based on the hash algorythm, independent from the state of the other site. If the other site uses LACP, both ports will be physically up, but since static LAs don't send LACPDUs they will not transmit the traffic and the traffic will be discarded. 

 In short: You can just connect two ProCurves, which use dynamic LACP on every port, without creating a loop.
Please refer to this old Procurve document:
http://h22208.www2.hpe.com/eginfolib/networking/docs/switches/WB/15-18/5998-8162_wb_2920_mcg/content/ch04s07.html#s_Static_LACP_trunks

[VoIP-Buddy]

Folks,

There is no such thing as "static LACP."  As was previously pointed out, LACP is the protocol that is used in a link-aggregation group to control the ports dynamically. 

STATIC Link-Aggregation means that the parameters are set up manually on each side to allow data to pass.  There is no port management. 

If you are using LACP, you are creating a dynamic Link-Aggregation group.

Regards,

David

[BjKo]

---

wrote:

Folks,

There is no such thing as "static LACP."  As was previously pointed out, LACP is the protocol that is used in a link-aggregation group to control the ports dynamically. 

STATIC Link-Aggregation means that the parameters are set up manually on each side to allow data to pass.  There is no port management. 

If you are using LACP, you are creating a dynamic Link-Aggregation group.

Regards,

David

---

Static and Dynamic does not refer to the LACP protocol but to the interfaces. 
The interfaces can dynamically join and leave the LACP. 

This is not intended by the LACP protocol, the protocol stops traffic transfer when a mismatch is detected but it does not make the interface leave the link-aggregation.

Imagine you make a 4 interface LACP and connect 2 interfaces to the other switch and, for whatever reason, connect the other two to PCs. The other two (PC) would not work. This is by design of the LACP.
With a dynamic LACP the other two would leave the link-aggregation and would work. The two interfaces are NOT LACP interfaces at this point.