Comware

Hi All 

I've just configured loopback detection on 5510 running 7.1.045, Release 1111P01

with the following commands 

interface GigabitEthernet1/0/1

port link-mode bridge
port link-type hybrid
undo port hybrid vlan 1
port hybrid vlan 111 tagged
port hybrid vlan 222 untagged
port hybrid pvid vlan 222
qos trust dscp
poe enable
loopback-detection enable vlan 222 111
loopback-detection action shutdown

ther is also a command in the global config mode:

loopback-detection interval-time 5

Now I've been testing it and the switch doesn't seem to be generating a SNMP trap, also it seems that there is some built in recovery mechanism that we have no control over.

What I mean is that when there is a loop (one cable patched into the same switch) ports involved will get shut and switch will try to bring them up after a few seconds, if the loop exists they will be shut down again. This process goes on until the loop is removed.

Now the display loopback-detection command seems to be useless here as even if there is a loop it won't show there. The only place wehre you can confirm this is dis int g1/0/1 for example.

As in oppose to comware 5 there is no loopback-detection enable multiport command available but what I need here the most is a way of seing that there is a loop in IMC rather then waiting for end users to report the problem .

Has anyone have experience with this feature on comware 7?

Some outputs from the switch while loop was created:

%Oct 13 10:51:45:437 2016 FLOOR IFNET/3/PHY_UPDOWN: GigabitEthernet1/0/22 link status is up.
%Oct 13 10:51:45:437 2016 FLOOR IFNET/5/LINK_UPDOWN: Line protocol on the interface GigabitEthernet1/0/22 is up.
%Oct 13 10:51:45:466 2016FLOOR IFNET/3/PHY_UPDOWN: GigabitEthernet1/0/21 link status is up.
%Oct 13 10:51:45:468 2016 FLOOR IFNET/5/LINK_UPDOWN: Line protocol on the interface GigabitEthernet1/0/21 is up.
%Oct 13 10:51:45:474 2016 FLOOR LLDP/6/LLDP_CREATE_NEIGHBOR: Nearest bridge agent new neighbor created on Port GigabitEthernet1/0/22 (IfIndex 22), Chassis ID is mmm:aaa:ccc, Port ID is GigabitEthernet1/0/21.

%Oct 13 10:51:47:111 2016 FLOOR LPDT/4/LPDT_LOOPED: Loopback exists on GigabitEthernet1/0/21.
%Oct 13 10:51:47:116 2016 FLOOR LLDP/6/LLDP_DELETE_NEIGHBOR: Nearest bridge agent neighbor deleted on Port GigabitEthernet1/0/22 (IfIndex 22), Chassis ID is mmm:aaa:ccc, Port ID is GigabitEthernet1/0/21.

%Oct 13 10:51:47:126 2016 FLOOR LPDT/4/LPDT_VLAN_LOOPED: Loopback exists on GigabitEthernet1/0/21 in VLAN 111
%Oct 13 10:51:47:126 2016 FLOOR LPDT/4/LPDT_LOOPED: Loopback exists on GigabitEthernet1/0/22.
%Oct 13 10:51:47:155 2016 FLOOR IFNET/3/PHY_UPDOWN: GigabitEthernet1/0/21 link status is down.
%Oct 13 10:51:47:157 2016 FLOOR IFNET/5/LINK_UPDOWN: Line protocol on the interface GigabitEthernet1/0/21 is down.
%Oct 13 10:51:47:164 2016 FLOOR LPDT/4/LPDT_VLAN_LOOPED: Loopback exists on GigabitEthernet1/0/22 in VLAN 111
%Oct 13 10:51:47:165 2016 FLOOR LPDT/5/LPDT_VLAN_RECOVERED: Loopback on GigabitEthernet1/0/21 in VLAN 111 recovered.
%Oct 13 10:51:47:168 2016 FLOOR LPDT/5/LPDT_RECOVERED: Loopback on GigabitEthernet1/0/21 recovered.
%Oct 13 10:51:47:196 2016 FLOOR LPDT/5/LPDT_VLAN_RECOVERED: Loopback on GigabitEthernet1/0/22 in VLAN 111 recovered.
%Oct 13 10:51:47:198 2016 FLOOR LPDT/5/LPDT_RECOVERED: Loopback on GigabitEthernet1/0/22 recovered.
%Oct 13 10:51:47:203 2016 FLOOR IFNET/3/PHY_UPDOWN: GigabitEthernet1/0/22 link status is down.
%Oct 13 10:51:47:205 2016 FLOOR IFNET/5/LINK_UPDOWN: Line protocol on the interface GigabitEthernet1/0/22 is down.

< FLOOR>dis loopback-detection
Loopback detection is enabled.
Loopback detection interval is 5 second(s).
No loopback is detected.

dis int g1/0/21

GigabitEthernet1/0/21
Current state: DOWN (Loopback detection down)
Line protocol state: DOWN

There is MIB subtree missing on the switch itself (I think )

I compared output of dis snmp-agent mib-view from HP3100 where snmp trap is generated to one from 5510 and noticed that  MIB Subtree: hh3cLI is not present on 5510, this is the one containing needed OIDs.

Does anyone know if there is a way of importing this into 5510

I think file .snmpboots in the flash memory might have something to do with it but there is not much on the net about it 

ok I've managed to activate needed subtree 

all can be done from CLI

the subtree I needed was hh3cLI 1.3.6.1.4.1.25506.2.95

on the switch 

[FLOOR]snmp-agent mib-view included ViewDefault 1.3.6.1.4.1.25506.2.95 ?
mask Subtree mask corresponding to MIB subtree
<cr>

I'm not sure what mask subtree does but it did what I expected without it

[FLOOR]dis snmp-agent mib-view
View name: ViewDefault
MIB Subtree: iso
Subtree mask:
Storage-type: nonVolatile
View Type: included
View status: active

View name: ViewDefault
MIB Subtree: snmpUsmMIB
Subtree mask:
Storage-type: nonVolatile
View Type: excluded
View status: active

View name: ViewDefault
MIB Subtree: snmpVacmMIB
Subtree mask:
Storage-type: nonVolatile
View Type: excluded
View status: active

View name: ViewDefault
MIB Subtree: snmpModules.18
Subtree mask:
Storage-type: nonVolatile
View Type: excluded
View status: active

View name: ViewDefault
MIB Subtree: hh3cLpbkdt
Subtree mask:
Storage-type: nonVolatile
View Type: included
View status: active

I only need to test whether trap is generated once loop exists 

Hello,

Did you manage to send traps with the included subtree procedure you described above ?

In fact, I have the same problem with bpdu protection traps, I tried the same configuration associated to bpdu protection traps, but there is no changes.

I also tried to activate the "debugging snmp trap process" commands to log traps processed by the switch, but there is no sign of any trap process linked to these events...

I am really wondering if this trap feature exists on comware v7 (there is no problem in comware v5)

Regards,

Lewis, no, unfortunately that didn't do the trick, still no sign of SNMP traps. This is with HP at the moment so I'm waiting for some feedback from them. Will drop a note in here once they get back to me

HP advised to upgrade to the newest software which did, still no joy. Waiting for more feedback from HP support

Thank you for the updates on this topic. I will also contact an HPE sales manager to see if this problem is known...

In my case it turned out that there wasn't a trap to alarm in IMC configured.

Traps weren't visible in the terminal of comware7 switch as I used to see them on comware 3 and 5.

If you want to see your snmp from the switch itself you need to use debug snmp etc