Details
Description
After some intense discussions with specification and certification people the following definitionis agreed on:
- If a portsubmodule shall perform a specific remote check (e.g. check MRPDomainUUID) and the check for a specific neighbor is configured via PDPortDataCheck.CheckPeers:
- if no neighbor is detected (Link down or no LLDP frame received), a diagnosis with "no peer detected" shall be issued and the specific diagnosis shall not be issued.
- if a peer is detected and the specific check fails (e.g. wrong MRPDomainUUID), a diagnosis for this specific check shall be issued
- If a portsubmodule shall perform a specific remote check (e.g. check MRPDomainUUID) and the check for a specific neighbor is NOT configured via PDPortDataCheck.CheckPeers:
- if no neighbor is detected (Link down or no LLDP frame received), NO diagnosis shall be issued (neither "no peer detected" nor the specific diagnosis).
- if a peer is detected and the specific check fails (e.g. wrong MRPDomainUUID), a diagnosis for this specific check shall be issued
The current implementation does not respect 2.a and issues a diagnosis "no peer detected" in this case. This is wrong and shall be fixed.
Attachments
Issue Links
- blocks
-
PSPNCORE-369 Unexpected "no peer detected" diagnosis
- Closed
- clones
-
PSPNSV4-1158 do not report diagnosis "no peer detected" if no neighbor is detected but PDPortDataCheck.CheckPeers is not configured
- Closed