Loopback detection on comware 7

[pattap]

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

[pattap]

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 

[pattap]

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 

[Lewis1]

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,

[pattap]

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

[pattap]

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

[Lewis1]

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

[pattap]

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