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