Loop guard recovery is automatic in the sense that once BPDUs are received on the port, it will no longer be in an inconsistent state. However recovery in the sense of err-disable recovery, that it does not participate, since loop guard does not put a port in err-disable state. Loop guard will put a port in inconsistent state if it fails to receive BPDUs. The other item mentioned in documentation is when the port is in an STP blocking state, but I'm not sure that's a requirement, and not just an intention. Although you have a downlink switch to connect two clients (PCs, servers, etc) to this port, it sounds like the downlink switch is a "dumb", unmanaged switch. Such switches do not participate in STP, so they do not generate BPDUs, though they may pass though BPDUs received from a managed switch. Effectively then, you have this port as an edge port so you should remove loop guard from it. With an unmanaged switch, you do have the danger of creating a loop if another port of the unmanaged switch is connected to one of the uplink switches. However the BPDU passthrough may have a connected ports on one of the uplink switches go into a blocking state as if the unmanaged switch were an Ethernet cable. If the downlink switch is a managed switch, then it may have STP disabled. You may want to enable STP on it but with a very high priority number so that it never becomes the root bridge. Whether the switch with the edge devices is managed with STP turned off or an unmanged switch, if you trust that nobody will ever connect two or more of its ports to your uplink switch environment, then you can treat it as an end device and configure the port on the upstream switch as if connected to a single edge device. One common example of emulating this small switch and causing havoc is with VOIP phones that let you piggyback a PC behind it. Some silly users get the idea of connecting both of the phone's Ethernet ports to live Ethernet wallports. This creates a loop, particularly when the switchports have voice vlan configured which for Cisco, automatically adds Portfast to the port configuration.
... View more
Not very helpful The original poster wanted to know where the message might have come FROM. You started focusing on that, but then reverted to focusing on details about sending the message OUT from IronPort. So I have the ICID, now what? How do I get details about the incoming connection? THAT is what we're looking for, not details about the DCID.
... View more