Giuseppe,
This is going to be a long post. Please bear with me...
First, the results of my lab experiment. I have tested the behavior of 2950, 2960 and 3560 series switches to a looped port. The switch under test was connected via Fa0/1 to a hub (for sniffing purposes) and the hub was subsequently connected to another switch whose other two ports were intentionally connected together, creating a loop. If the switch under test sent a frame via its Fa0/1 port, it arrived at the second switch, looped and returned back. I watched for the frame reflection on the hub and observed the behavior of the switch under test.
The 2950 switch was running C2950 Software (C2950-I6K2L2Q4-M), Version 12.1(22)EA13. The switch was booted with its configuration completely erased, and was initially configured using these commands:
no cdp run
vtp mode transparent
no span vlan 1-4094
int ra fa0/1 - 24
switchport mode access
no keepalive
exit
The STP, VTP, CDP and LOOP protocols were disabled by this cofniguration. After this configuration, no frames were sent out the Fa0/1 interface. Then, I have activated the LOOP frames on the Fa0/1 using the commands:
int fa0/1
keepalive
exit
The Fa0/1 started sending the LOOP frames that looped on the second switch and returned back. Upon receiving its own LOOP frame, the switch displayed on the console:
00:34:01: %ETHCNTR-3-LOOP_BACK_DETECTED: Keepalive packet loop-back detected on FastEthernet0/1.
00:34:01: %PM-4-ERR_DISABLE: loopback error detected on Fa0/1, putting Fa0/1 in err-disable state
00:34:01: STP SW: Fa0/1 new disabled req for 1 vlans
00:34:02: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down
00:34:03: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to down
The Fa0/1 was subsequently put into looped err-disabled state.
Following this experiment, I have deactivated the LOOP protocol on the Fa0/1 and activated the STP instead:
int fa0/1
shut
no keep
no shut
exit
span vlan 1
After the Fa0/1 went up and started sending BPDUs, they again looped back. The switch did not produce any console message and the port remained up/up, however, the show spanning-tree commands revealed the following (only relevant sections follow):
show span int fa0/1:
Vlan Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
VLAN0001 Desg LBK 100 128.1 Shr
show span int fa0/1 detail:
Port 1 (FastEthernet0/1) of VLAN0001 is self-looped
Note that the 2950 identified the port as LBK (looped back) and has put it into blocking state. After removing the loop and waiting 20 seconds (the max_age), the port again went through listening/learning/forwarding states.
The 2960 switch was running C2960 Software (C2960-LANBASEK9-M), Version 12.2(50)SE1. The initial configuration was identical to the 2950 and so was the individual test procedure.
After enabling only the LOOP protocol on the Fa0/1, the switch reacted to the looped frame by the following console message:
*Mar 1 00:27:31.725: %ETHCNTR-3-LOOP_BACK_DETECTED: Loop-back detected on FastEthernet0/1.
*Mar 1 00:27:31.725: %PM-4-ERR_DISABLE: loopback error detected on Fa0/1, putting Fa0/1 in err-disable state
*Mar 1 00:27:31.733: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down
*Mar 1 00:27:33.730: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to down
The messages are slightly differently formulated but the reaction is identical to 2950 - the port is errdisabled.
After reenabling the interface, deactivating the LOOP protocol and activating the STP, the port behaved identically to the 2950 behavior - it remained up/up but was identified as looped and held in blocking state:
show span:
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/1 Desg BLK 100 128.1 Shr self-looped
show span int fa0/1 detail:
Port 1 (FastEthernet0/1) of VLAN0001 is designated blocking, self-looped
The 3560 was running C3560 Software (C3560-IPSERVICESK9-M), Version 12.2(50)SE1. The initial configuration and the individual tests were identical as before - and so were the results.
After activating only the LOOP protocol on Fa0/1, the switch put the port into errdisabled state, saying:
*Mar 1 00:36:51.035: %ETHCNTR-3-LOOP_BACK_DETECTED: Loop-back detected on FastEthernet0/1.
*Mar 1 00:36:51.035: %PM-4-ERR_DISABLE: loopback error detected on Fa0/1, putting Fa0/1 in err-disable state
*Mar 1 00:36:51.044: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down
*Mar 1 00:36:53.040: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to down
After reenabling the port, disabling the LOOP and activating the STP, the port remained up/up but was identified as looped:
show span:
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/1 Desg BLK 100 128.3 Shr self-looped
show span int fa0/1 de:
Port 3 (FastEthernet0/1) of VLAN0001 is designated blocking, self-looped
To me, it seems that the LOOP frames are indeed used as a mechanism to verify whether a port is self-looped. Receiving a looped STP BPDU does not result in errdisabling the port.
You wrote that the LOOP protocol is used, for example, on PA-4E adapters to make sure that it is up/up when connected to another peering device. I am not sure about that one. The behavior of Ethernet ports on a switch and on a router differs significantly. A port on a router, at least for x600 and x800 series routers, is up/down if it is unplugged. An Ethernet port on a router is never in down/down state. Furthermore, it will go up/up as soon as it is connected to anything, including a hub - and obviously, a hub cannot send back a LOOP frame. I know that configuring no keepalive on a router Ethernet port makes the port go up/up and stops sending LOOP frames. However, the LOOP frames appear to be totally unused. I have made a quick test with looping the LOOP frames on a router. Nothing happened! The router completely ignores that it receives its own LOOP frames, and it also completely ignores if it does not receive them at all! It seems to me that on router, the LOOP is some kind of remainder of past and it actually does nothing.
A switch Ethernet port is down/down if it is unplugged, and up/up if it is connected. On switches, I have not ecountered a switchport that is up/down. The no keepalive command on a switch port cannot be used to make a switchport go up/up - it has to be physically connected.
A capability of a port to determine whether it is able to send and receive frames - yes, that is something that the Ethernet is lacking. If I remember correctly, the old 10Mbps versions of Ethernet used the SQE signalling to know if the transmitter is connected. The TP versions of Ethernet starting with 10 Mbps and faster actually periodically transmit the NLP/FLP pulses to detect a connectivity with the other party, and the 100Base-TX and 1000Base-T transceivers actually continually exchange so-called IDLE symbols when no frames are sent to maintain the synchronization of scrambling circuitry. In a sense, there is a send/transmit capability test built into Ethernet but it is still at Layer1. Frame-based connectivity tests do not seem to be a regular part of Ethernet implementation - perhaps the Ethernet OAM will change this?
Ooops, sorry for being so lengthy
Best regards,
Peter
