Comware

 View Only
Expand all | Collapse all

vlan 1

This thread has been viewed 3 times
johnk3r

johnk3rJan 24, 2018 09:07 AM

  • 1.  vlan 1

    Posted Jan 22, 2018 03:01 AM

    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

     



  • 2.  RE: vlan 1

    Posted Jan 22, 2018 06:46 AM

    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 ...



  • 3.  RE: vlan 1

    Posted Jan 22, 2018 07:53 AM

    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 ... :/



  • 4.  RE: vlan 1

    Posted Jan 22, 2018 09:59 AM

    Hi,

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

    Regards.



  • 5.  RE: vlan 1

    Posted Jan 22, 2018 10:09 AM

    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

     



  • 6.  RE: vlan 1

    Posted Jan 22, 2018 05:06 PM

    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



  • 7.  RE: vlan 1

    Posted Jan 22, 2018 07:49 PM

    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?



  • 8.  RE: vlan 1

    Posted Jan 23, 2018 02:53 AM

    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)



  • 9.  RE: vlan 1

    Posted Jan 23, 2018 12:52 PM

    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



  • 10.  RE: vlan 1

    Posted Jan 23, 2018 08:12 PM

    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).



  • 11.  RE: vlan 1

    Posted Jan 24, 2018 09:07 AM

    @Vince-Whirlwind

    Great observation !



  • 12.  RE: vlan 1

    Posted Jan 24, 2018 09:19 AM

    @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)



  • 13.  RE: vlan 1

    Posted Jan 25, 2018 03:34 PM

    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



  • 14.  RE: vlan 1

    Posted Jan 26, 2018 07:05 AM

    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


  • 15.  RE: vlan 1

    Posted Jan 26, 2018 06:36 PM

    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



  • 16.  RE: vlan 1

    Posted Jan 27, 2018 03:13 PM

    2018-01-27 18_10_28-Adobe Digital Editions - HP ATP - FlexNetwork Solutions V3_PD43530.png

     

     

     



  • 17.  RE: vlan 1

    Posted Jan 27, 2018 10:04 PM

    Wow, that's amazing.



  • 18.  RE: vlan 1

    Posted Jan 30, 2018 03:52 PM

    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



  • 19.  RE: vlan 1

    Posted Jan 30, 2018 07:26 PM

    @VoIP-Buddy

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



  • 20.  RE: vlan 1

    Posted Jan 27, 2018 10:16 PM

    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.






  • 21.  RE: vlan 1

    Posted Jan 30, 2018 03:47 PM

    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



  • 22.  RE: vlan 1

    Posted Jan 31, 2018 06:17 AM

    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



  • 23.  RE: vlan 1

    Posted Feb 06, 2018 08:19 AM

    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



  • 24.  RE: vlan 1

    Posted Feb 06, 2018 04:07 PM

    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



  • 25.  RE: vlan 1

    Posted Feb 07, 2018 03:43 AM

    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.



  • 26.  RE: vlan 1

    Posted Feb 07, 2018 05:27 AM

    Thank you, that is very well explained.

    Here is why I don't use dynamic protocols:

    When I design a network I don't design a network where PCs are connected to link-aggregated ports on a switch. It just doesn't happen.
    In fact, I really can't remember using link aggregation on copper ports, and although I deal with PCs that use fibre connectivity at the access layer, those networks are so tightly controlled that I'm pretty sure if anybody connected a PC to link agg port, they'd be fed to the sharks, and rightly so.

    As with many of us I guess, my formal network training was originally in Cisco. Cisco had (from memory)
    "passive" - which was rubbish and a complete waste of time
     "active" - which really only worked in a pure Cisco environment
    "on" - which worked.

    From there, as we tried to get our customers to stop wasting their money on Cisco, and as we added good stuff like HP Procurve to their networks, we used Cisco "ON" and HP "Trunk" and it all worked fine.

    I have implemented recent 3COM networks. It is powerful kit, and on the whole, it's the way to go for a good many applications, which pains me to say because I am so not a fan of the whole operation at 3COM, from design to business, to the security aspect of where it comes from. I can't recall my configs, but whatever it was, it was going to play nice with Cisco "On" and HP Procurve "Trunk", so nothing dynamic, regardless of how 3COM labels it.



  • 27.  RE: vlan 1

    Posted Feb 07, 2018 01:39 PM

    Hi Vince!

    I agree with you.  We most often see this on upward or downward links to switches.  HOWEVER, there is a very good reason to use them to servers that support dynamic Link-aggregation.  You get increased aggregated bandwidth for each port connection.  The only caveat is that if they all aren't the same speed, the link will run at the speed of the slowest port.

    One reason to consider copper ports is that there are models of the 5130 EI family that support 10g on copper ports.  Typically we would see fiber to a server but we now have a copper solution too.

    Regards,

    David



  • 28.  RE: vlan 1

    Posted Feb 07, 2018 10:58 PM

    I find when creating a link aggregation for a server, I am at the mercy of the server guy and what he understands about configuring link aggregation on his server (which usually approximates to about nil).
    Generally, he will do something undocumented and on the fly and then I have to use trial and error to come up with the link agg config on my switch that works with whatever he has done.

    I used DAC to connect two Core switches once, so I guess I lied about never using copper for link aggs.