SOLVED
Can you share (sanitized, if/when necessary) outputs of CLI commands display link-aggregation verbose Bridge-Aggregation 1 and display this (this one once you're into the interface GigabitEthernet <interface-ID> contex in system-view mode)?
Execute the display this command on each member interface you have on BAGG1 so you should able to understand if there is (and where it is) a difference between BAGG1 member interfaces.
That System Log Message means that the status of some member port(s) in an aggregation group becomes inactive because the configuration of the port(s) is improper for being attached (to that aggregation group).
I'm not an HPE Employee
Hi, below is the output of both the commands,
Actually, i allowed a vlan 810 into trunk port 24, but after allowing it switch went down and my whole network went down.
what could be the reason.
I think there is an issue with terminology (and configuration that some terminology usage suggests you to apply): trunk.
Trunk in Cisco terminology means basically a port that carries more than one VLAN. In HP (ProVision based) the same word means aggregated ports (LAG, BAGG, Port Trunking and so on)...in HP (Comware based<--your case since you have an HP 5800 on one end) the meaning is similar to Cisco since it refers to port mode.
From posted screenshots, it seems you're dealing with both...a BAGG (aggregation of ports) and a port that you want it to carry more than one VLAN...the point is that you have a BAGG with just one member (that's pretty strange just to start with) and, moreover - this is the problematic part - you applied configuration changes to BAGG's member port instead of applying to the logical BAGG interface BAGG1 (which, if done that way, propagates to its members ports any change done...aka member ports inherit configurations to remain coherents with BAGG configuration).
So...you should first ask yourself if Interface GigabitEthernet 1/0/24 is the only one involved into the uplink/downlink to your HP ProCurve 5406 (port B18 is involved I see) or not...if yes...you shouldn't use a BAGG at all since you have a single interface uplink/downlink on both ends...if no (and you have at least two ports aggregated together to form a BAGG on both sides) you should stop to manage parameters "per port" and start to think and to act "per-BAGG" (on both ends) when you do configuration changes in order to let the respective Switch to propagate those changes to its member ports and, doing so, to let it to do correctly.
I'm not an HPE Employee
yes, it is strange that BAGG1 has only one port. I do not know who configured this.
Interface GigabitEthernet 1/0/24 is the only port which is uplink to HP 5406 Switch...and connected to interface B18-trk34 of HP 5406 switch.
I have few questions in my mind.
1- In this case (where only single interface in BAGG1), I allowed a VLAN on a interface GigabitEthernet 1/0/24 instead of aggregation group BAGG1, is this the reason that BAGG1 became inactive...??
2- if BAGG1 has only single port (i know this is not the correct way, at least two interfaces should be in a aggregation Group), will it create any problem if i do any changes on perticular interface which is in aggregation group BAGG1, instead of Group BAGG1 itself beacuse there is single port is involved.
3- could there be any other reason which made BAGG1 down ?
one of my collegue said this went down because of looping of particular VLAN810. but i found his statement irrelevant, because in HP5800 switch, no vlan810 configuration is created. I just allowed in a port and all went down.
i am sharing the network layout. the core switch is HP-5406.
@Champion5656 wrote: yes, it is strange that BAGG1 has only one port. I do not know who configured this.
Probably someone with a sort of Cisco background...I doubt that such type of configuration was done because LACP BAGG setup was needed even if just one initial member port was really available (maybe because there was a lack of free additional member ports...on both ends!).
Interface GigabitEthernet 1/0/24 is the only port which is uplink to HP 5406 Switch...and connected to interface B18-trk34 of HP 5406 switch.
So OK...to me single port uplink means NO BAGG is required for that uplink, it's just a physical-interface-to-physical-interface link...simple...and this approach qualifies involved physical interfaces on both ends (1/0/24<-->B18) to be properly untagged/tagged to carry necessary/required VLANs as you do normally on a port dedicated to access...you just do that on a port dedicated to trunk two switches together (exactly as you should do when you manage BAGGs/Trunks - that are logical interfaces - on both ends). So, to recap, No Trunks = No BAGGs = No LAGs = No interfaces aggregation...this means that no Trunks are necessary and you haven't to deal with any form of physical interfaces aggregated into a logical one (BAGG1 or Trk34, it doesn't matter).
I have few questions in my mind.
1- In this case (where only single interface in BAGG1), I allowed a VLAN on a interface GigabitEthernet 1/0/24 instead of aggregation group BAGG1, is this the reason that BAGG1 became inactive...??
Exactly. That's the point: when you deal with BAGGs/LAGs/Trunks deployments you should work at *that* level and you should manage just and only the BAGG/Trk logical interfaces forgetting their physical members, those ones will automatically inherit from the parent logical interface...if you not do things that way...things go weird because there will be - at some point - a misallignment between (member) physical interface configurations and (parent) logical aggregated interface configuration. Act only at higher level (BAGG/Trk) if you have them.
2- if BAGG1 has only single port (i know this is not the correct way, at least two interfaces should be in a aggregation Group), will it create any problem if i do any changes on perticular interface which is in aggregation group BAGG1, instead of Group BAGG1 itself beacuse there is single port is involved.
See above, IMHO yes. The logic is (very true on Comware based, true on ProVision based): start from default physical interfaces...build your BAGG/Trk...then, after that, you should deal only with BAGG/Trk...forget about managing member interfaces singularly (that's to avoid incoherent configurations between physical/logical levels)...BAGG/Trk manage their respective members interfaces for any change you did at BAGG/Trk logical level, VLANs included.
3- could there be any other reason which made BAGG1 down ?
one of my collegue said this went down because of looping of particular VLAN810. but i found his statement irrelevant, because in HP5800 switch, no vlan810 configuration is created. I just allowed in a port and all went down.
Your physical topology suggests no physical loop but would be interesting to see how VLANs are defined on both ends (5406 and 5800-1) for the problematic uplink.
Question 1: HP 5406 are stacked...what do you mean exactly? VSF? Here I'm supposing VSF was deployed since you should not have two separates logical Switches both acting as Core...so the other reasonable alternative is a VSF between the two...one logical Switch acting as Core for your entire network).
Question 2: Aren't you using IRF on 5800, right?
Note: having said that...all the aggregated interfaces I see in your topology are - deployed that way - unresilient (and resiliency is the reason to adopt BAGGs/Trunks, possibly with LACP)...and, in the worst case, potentially wrongly deployed.
i am sharing the network layout. the core switch is HP-5406.
I'm not an HPE Employee
@Champion5656 wrote: Which one is good stacking (VSF in case of 5406) or Redundancy Protocol ?
IMHO, if your Hardware fullfills VSF specific requirements (v3 zl2 Modules only, one MM per chassis only, VSF Links n links at 10 Gbps good or m link at 40 Gbps better, with preference for supported DACs), VSF is the way to go (no VRRP will be necessary anymore).
IRF is on HP 1950 1G & 10G. But there is no uplink on 1950 1G siwtch 2 and 1950 10G switch 2. Uplink should be there, am I right ?
Yes, you are. The basic idea is to have a Trunk (LACP) of aggregated ports that spreads into any IRF member to enhance resiliency (so from at least two interfaces on 5800-1 to two interfaces of the 1950 IRF, one per Switch possibly...so if one 1950 goes off-line the 5800 is not going to lose the connection to the remaining 1950 because one Trunk leg is still operational as operational is the running 1950). The very same is true between two IRF domains (think about an IRF of two 5800 against and IRF of two 1950 or against two IRFs made of a 1950 pair each one).
What if the uplink of 1950 1G & 10G switch 1 (which are going to hp 5800 switch-1) goes down, in that case the HP 1950 1g & 10g switch 2 will of no use, Uplink should be there ( from 1950 1g & 10g switch 2 to HP 5800 switch 2 ). Am i right or wrong ?
See above. If the entire 1950 IRF is uplinked to one 5800 (or to a future IRF of two 5800) by using a single link or an aggregated link made of two links connected to just one 1950...there is no resiliency against cable failure (single link case) or against a Switch failure (if the connected 1950 goes off-line).
see, SVI 810 is configured on the core switches. no vlan 810 is configured on 5800 and 1950 switches. VLAN 810 is present in HP 2530. I don.t think that any loop occured because of VLAN 810.
It's my opinion too.
Ques- Is there any proper procedure/steps of creating a vlan and allowing in the trunk ? I mean to say, does it matter if i allowed a vlan in a trunk before creating it in a switch or first create a vlan then allow in a trunk. Will it create any problem ? (I think it should not create a problem)
Generally on ProCurve based is sufficient to create the VLAN with vlan vlanid command and then, once into its context, assign an IP (if necessary <- usually you do that on the Core only) and a name. Once done that it's a matter of tagging the single interface (if you have a single link downlink from the Core to the Access layer) or tagging the logical TrkX (if you have aggregated links)...and do the same on the other peer at the other end.
I'm not an HPE Employee