what's a LOOP traffic in ethereal?

Answered Question
Jan 20th, 2010

Hi all,


I'm testing and analyzing the captured packet in ethereal.

but i can't know about LOOP traffic.


I connect two routers each other with fast-ethernet.


       R1 ------------------------------------- R2

      fa0/1                                    fa0/1

   

then R1 and R2 send the LOOP traffic each other per 60 secs.


R1's fast ethernet MAC : 00:1a:6c:fe:49:80

R2's fast ethernet MAC : 00:1a:6c:70:7a:66


when R1 and R2 connect each other and any configuration is not applyed in that interface,

R1 sends LOOP frame into the media as the below

source_MAC : 00:1a:6c:fe:49:80

destination_MAC : 00:1a:6c:fe:49:80


finally, source_MAC and destination_MAC is the same.

  ScreenHunter_001.jpg


what is this frame??


is it keepalive frame?


why R1 sends LOOP frame that has use the same MAC(source and destination MAC)

if R1 sends the above LOOP frame,

I think R2 will ignore it because desination MAC is not R2's MAC.


is the reason that R1 sends LOOP frame just to test media state?



i attache the captured cap file.

you can find this issue in odd packet number(1,3,5....)

Correct Answer by Peter Paluch about 7 years 1 month ago

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

Correct Answer by Giuseppe Larosa about 7 years 1 month ago

Hello Peter,

this is my current understanding of ethernet keepalive.


if I take an Rj-45 ethernet port for example an ethernet of a PA 4E and i leave it unplugged the interface is down/down

If with the port unplugged I disable keepalive (no keepalive under interface config) the ports  comes up and it is even pingable (because when pinging an ethernet interface the packet is not sent out on the wire like it happens with serial or ATM interfaces).

Ethernet interfaces have no carrier to be detected and no TDM framing to be detected.


My first idea was that keepalive frames were sent out with MAC SA= router NIC MAC and MAC DA= broadcast.


I've done some searches and most of links point to the following:


http://www.mit.edu/~jhawk/ctp.pdf


http://lwn.net/Articles/330797/


ECTP packets can be sent to unicast, broadcast, or the ECTP reserved
+       cf:00:00:00:00:00 multicast address



>> If the LOOP frame was supposed to be received back, what would be the action if it was not received back?

see above to consider the port down


the fact that receving back its own keepalive frames is a sign of a loop for me is related to a famous bug on C3750 and other switches on fiber based ports where the suggested workaround was to disable keepalive on those ports.

This bug has been discussed in several threads in the forums.


It is reasonable that if the  objective is to test capability to send and receive ethernet frames a test with a frame sent out on wire and then received back would be the most meaningful.



Sanghee:

http://wiki.wireshark.org/Loop


We are speaking of something so basic, that received frames could be simply ignored and not passed to upper layers as suggested in above documents. I will look again at how you did your tests.


I'm ready to change my mind again about this as I did several times in the past.



Hope to help

Giuseppe

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (6 ratings)
Loading.
Ganesh Hariharan Wed, 01/20/2010 - 22:59

Hi Sanghee,


Configuration testing protocol is a part of the original Ethernet specification that doesn't appear in IEEE 802.*, or any other specification.Your logs is basically a type of Ethernet Keepalives messages type what i can predict.With the code Ethernet type code of 0x9000 i can say it be a ethernet keep alive messages.


On broadcast media like an Ethernet, keepalives are slightly different. Since there are many possible neighbors on the Ethernet, the keepalive is not designed to determine if the path to any one particular neighbor on the wire is available. It is only designed to check that the local system has read and write access to the Ethernet wire itself. The router produces an Ethernet packet with itself as the source and destination MAC-address and a special Ethernet type code of 0x9000. The Ethernet hardware sends this packet onto the Ethernet wire and then immediately receives this packet back again. This checks the sending and receiving hardware on the Ethernet adapter and the basic integrity of the wire.


Hope that clear out your query !!


If helpful do rate the valauable post.


Regards

Ganesh.H

Sanghee Han Thu, 01/21/2010 - 00:01

thanks for your help.


but i have a question about your comment.


in your saying,


The Ethernet hardware sends this packet onto the Ethernet wire and then immediately receives this packet back again.



how can the router receive keepalive frame as soon as it sent the frame?


does the router wait the frame from other device?

or does it determines by itself without receiving the frame on the wire?


could you explain this more detail for me?

Giuseppe Larosa Thu, 01/21/2010 - 00:08

Hello Sanghee,


>> the frame is sent out on the wire, whoever is on other side of the cable by seeing ethertype 0x9000 sends back the frame.


that is the ethertype 0x9000 obliges the other party to send back the frame to help original sender to perform its link integrity test


It  should be part of ethernet conformance to behave in this way when receiving a loop frame.


Hope to help

Giuseppe

fgasimzade Thu, 08/21/2014 - 22:54

Dear Giuseppe

5 years passed, but it is now actual for me, so I got a question:

 

If ethertype obliges the other party to send back the keepalive frame, why does the switch disables the port when it receives the keepalive message it just sent? I doesnt look right.. Some sources say that if own keepalive message is received, it means there is a loop on the network, but your saying that keepalive messages must be bounced back to the sender..

 

Thank you

Boyan Sotirov Fri, 08/22/2014 - 02:30

That's a valid question.

As described here by the author of the thread, the routers and the switches react differently to the Ethernet LOOP frame.

Me personally, I've played around with it and I can confirm that when I send over a LOOP frame to a Cisco switchport, a frame that I've captured, the switch error disables the port as soon as it receives it.

fgasimzade Fri, 08/22/2014 - 02:42

The interesting part of it is that the LOOP frame sent from the switch has the switch's MAC as Source and Destination. 

So, let's imagine switch A sends a loop frame out of its uplink port to switch B

The frame has MAC:A as a source and MAC:A as a destination. When switch B receives the frame, it stores MAC:A in the mac-address table bounding it to its uplink port (basically this is how a switch populates its mac address table)

The switch B then examines the frame, and sees that the destination mac is MAC:A. Switch B knows that MAC:A is available through its uplink port to Switch A and then forwards the packet. So now Switch A receives its own loop frame back and must disable the port.

It means any uplink port on any switch with keepalives enabled must be put in err-disable even if there is no loop..

Peter Paluch Fri, 08/22/2014 - 06:58

Hi guys,

 

If ethertype obliges the other party to send back the keepalive frame, why does the switch disables the port when it receives the keepalive message it just sent? I doesnt look right.

 

Keep the following facts in mind first: The LOOP frames are originally part of an old Ethernet control protocol suite called Ethernet Configuration Testing Protocol, or ECTP. Consider it somewhat similar to ICMP in IP networks. The LOOP frames would be similar to a PING. The ECTP is not mandatory for IEEE-based Ethernet implementations, is purely software-based, and today, it is practically forgotten and unimplemented. In fact, throughout my lifelong contact with networks, I have never seen ECTP implemented or used. It should only be noted that in modern Ethernet networks, its features are provided by Ethernet OAM.

The EtherType of a LOOP frame "obliges" the other party to respond only if it implements the necessary driver. As none of today's operating systems have an ECTP driver, you cannot expect a device to respond to these LOOP frames. It's as simple as that: to basic Ethernet, these LOOP frames are just like any other frames - they only carry data. It is up to the operating system, its drivers and its software to implement proper handling of the LOOP frames, and as I said, no current operating system implements ECTP.

To detect self-looped ports, Cisco reached out to LOOP frames but uses them in a different way than what were originally intended for. Normally, the LOOP frames would be sent to a different MAC address than the sender, and a reply would be expected to arrive back, confirming the possibility of the two stations to communicate together. However, Cisco addresses the LOOP frames to their very sender - something they were absolutely not inteded to be in their original specification - and should such a frame be truly received back by its sender, it is a clear indication there is a loop in the network. Therefore a switch port is brought down as soon as it receives its own LOOP frame back - normally, that should not happen. Perhaps the name of the LOOP frame is unfortunate because a port actually hopes not to receive its own LOOP frame back. It's just that Cisco reached out to this ancient ECTP and reused some of its messages for its own purposes, not really being compatible with ECTP - just being harmless to stations if they happened to support ECTP after all.

 

The frame has MAC:A as a source and MAC:A as a destination. When switch B receives the frame, it stores MAC:A in the mac-address table bounding it to its uplink port (basically this is how a switch populates its mac address table)

The switch B then examines the frame, and sees that the destination mac is MAC:A. Switch B knows that MAC:A is available through its uplink port to Switch A and then forwards the packet. So now Switch A receives its own loop frame back and must disable the port.

 

There is an important error in this analysis: A switch never forwards a frame back the port through which it arrived. It is true that the SwitchB learns about the SwitchA MAC address on the port through which the LOOP frame arrived. However, when it discovers that the destination MAC address of this LOOP frame is learned on the same port, it will discard the frame rather than forwarding it back to SwitchA. So in a well-behaved switched network, LOOP frames are never forwarded back to their senders because that would necessitate sending them back through the very port they arrived through - and that is prohibited.

Best regards,
Peter

fgasimzade Fri, 08/22/2014 - 07:10

Dear Peter, thank you for your explanation

The situation I had recently was the following:

Switch A is connected with a single cable to Switch B. Out of a sudden Switch A uplink port was err-disabled with a Detect Loop Back message.

What I think happened is for some reason (probably CAM tables of Switch B was full or Switch B received a Spanning Tree TCN messages and aged out the CAM table) Switch B started flooding (broadcasting) all received frames out of all its ports. So is it possible that when Switch B received the Loop frame from Switch A, it broadcasted this frame out of all interfaces including the uplink port to Switch A?

Otherwise I have no idea how Switch A received its own loop frame back..

Peter Paluch Fri, 08/22/2014 - 07:21

Hi,

I believe that with a properly behaved switch, neither a TC-based CAM flush nor an overfilled CAM should be the cause of the issue. The logic is rather simple: both with a CAM flush or an overfilled CAM, the common result is that the frame's destination cannot be found in the CAM. This is the same situation as with receiving a frame whose destination has not been seen yet. You surely agree with me that even such frames are never flooded back through their incoming port, whether they are addressed to unknown unicast destination, to a multicast or even to a broadcast destination.

I am currently at a loss as to what could have caused the problem with the looped port. However, as I indicated, a well-behaved switch never forwards a frame back the ingress port no matter what. We may be experiencing some kind of software or hardware glitch or perhaps some race condition but in any case, this behavior would not be normal. There are networks with huge inflows of frames to formerly unknown destinations, yet we do not see the frames being reflected back where they come from, nor do we experience these issues in networks with lots of TCNs and TCs flying around.

I wonder: What kind of STP are you running between these two switches? And are they both Cisco Catalyst switches?

Best regards,
Peter

fgasimzade Fri, 08/22/2014 - 07:49
Yes, they were both Cisco Caralyst running MSTP. We had 3 switches behaving this way, 2 of them were connected to switch B, another one was on the different part of the network. What was in common is that these 3 switches were using FastEthetnet ports for uplinks nad keepalives were enabled by default on these ports. All other switches are interconnected by Gig (dual purpose or fiber) and keepalives are disabled by default on these ports. Another thing is that one of those 3 switches went into err-disabled every 10 sec (default time for keepalive messages) another two about every 20-25 mins...
Peter Paluch Sun, 08/24/2014 - 16:08

Hello,

Thanks for responding back. So you are running MSTP. The funny thing is that in labs, I have occassionally seen ports being brought down into err-disabled state because of a loopback condition exactly when switches were running MSTP. I did not see it happening with PVST+ or RPVST+. While the STP version should not have any impact on this, the MSTP seemed to somehow predispose the switches for this issue.

I will have to investigate much deeper if there is any causal dependence here. So far, it seems to me to be some kind of an obscure bug.

Best regards,
Peter

Giuseppe Larosa Wed, 01/20/2010 - 23:39

Hello Sanghee,

your understanding is correct they are ethernet keepalive frames used to check the link.

They can be recognized because MAC SA = MAC DA = Router NIC MAC address and ethertype = 0x9000


the frame is sent out on the wire, whoever is on other side of the cable by seeing ethertype 0x9000 sends back the frame.

The frame original sender receives its own frames back and knows that the ethernet port can be considered in operational state.



see


http://www.groupstudy.com/archives/cisco/200112/msg01021.html


Hope to help

Giuseppe

Sanghee Han Thu, 01/21/2010 - 00:16

Thanks Giuseppe, my teacher .


but i have a question about your comment.


in your saying


the frame is sent out on the wire, whoever is on other side of the cable by seeing ethertype 0x9000 sends back the frame.



but i can find the reply frame in the captured file.


if, as your explanation,

A(00:1a:6c:fe:49:80) must be receive for the keepalive frame it sent from other device.

but ethereal file shows just sending file.


there is no receiving frame from other device.


could you explain this more detail??

Peter Paluch Thu, 01/21/2010 - 01:04

Giuseppe,


Are you sure about this? I have never seen any device, be it a Cisco box, a Linux/Windows machine or any other Ethernet-capable node to actually send back a received LOOP frame. Moreover, I believe that a Cisco switch actually uses these LOOP frames to detect a self-looped port (all other loops are eliminated by STP) and so it expects not to receive the LOOP frame back.


If the LOOP frame was supposed to be received back, what would be the action if it was not received back? All switchports send the LOOP frames but the end stations - Windows, Linux - do not bother reflecting them back.


I have to confirm my suspicion in a lab in a few hours but for now, I somehow do not see how the LOOP frames are useful if they are not used for self-looped port detection.


Best regards,

Peter

Correct Answer
Giuseppe Larosa Thu, 01/21/2010 - 01:42

Hello Peter,

this is my current understanding of ethernet keepalive.


if I take an Rj-45 ethernet port for example an ethernet of a PA 4E and i leave it unplugged the interface is down/down

If with the port unplugged I disable keepalive (no keepalive under interface config) the ports  comes up and it is even pingable (because when pinging an ethernet interface the packet is not sent out on the wire like it happens with serial or ATM interfaces).

Ethernet interfaces have no carrier to be detected and no TDM framing to be detected.


My first idea was that keepalive frames were sent out with MAC SA= router NIC MAC and MAC DA= broadcast.


I've done some searches and most of links point to the following:


http://www.mit.edu/~jhawk/ctp.pdf


http://lwn.net/Articles/330797/


ECTP packets can be sent to unicast, broadcast, or the ECTP reserved
+       cf:00:00:00:00:00 multicast address



>> If the LOOP frame was supposed to be received back, what would be the action if it was not received back?

see above to consider the port down


the fact that receving back its own keepalive frames is a sign of a loop for me is related to a famous bug on C3750 and other switches on fiber based ports where the suggested workaround was to disable keepalive on those ports.

This bug has been discussed in several threads in the forums.


It is reasonable that if the  objective is to test capability to send and receive ethernet frames a test with a frame sent out on wire and then received back would be the most meaningful.



Sanghee:

http://wiki.wireshark.org/Loop


We are speaking of something so basic, that received frames could be simply ignored and not passed to upper layers as suggested in above documents. I will look again at how you did your tests.


I'm ready to change my mind again about this as I did several times in the past.



Hope to help

Giuseppe

Correct Answer
Peter Paluch Thu, 01/21/2010 - 04:51

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

Giuseppe Larosa Thu, 01/21/2010 - 07:56

Hello Peter,

your results are interesting and show a behaviuor near to your description at least on Cisco LAN switches

I had found some papers that were comforting my idea of keepalive but your tests are clear.


Ad yes thosePA 4E ethernet ports if unplugged were up/down forgive me I'm at home for a sick leave and it was ten years ago.


I need some young brilliant mind like yours to keep on track.



Hope to help

Giuseppe

Peter Paluch Thu, 01/21/2010 - 08:27

Giuseppe,


It was a pleasure to make this lab. I have also confirmed many important things to myself. So you're on a sick leave? I am sorry to read that. I sincerely hope you will get well soon!


Regarding that remark about "young brilliant minds"... no comment


Best regards,

Peter

Sanghee Han Thu, 01/21/2010 - 17:21

Hi Peter and Giuseppe,


I came to the office just now and surprised at many reply.


thanks for your kindly answer and comments.


it's a great help for me.


at now, understand the keepalive(loop) frame clearly.


thanks agian.




i'm sorry that i can't express my appreciation well because of my poor english.

but i believe you may understand what i'm saying

CARLO CIANFARANI Mon, 11/07/2011 - 14:23

Hi,


recently I've done some test to better understand router ethernet keepalives. On C3725 show interface for an unplugged fastethernet shows only outgoing pkts 60 byte each (ethernet LOOP frames):


C3725#sh run int fa0/1

Building configuration...


Current configuration : 88 bytes

!

interface FastEthernet0/1

no ip address

duplex auto

speed auto

no cdp enable

end


C3725#sh int f0/1

FastEthernet0/1 is up, line protocol is down

  Hardware is Gt96k FE, address is 0007.b35b.d2f1 (bia 0007.b35b.d2f1)

  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

     reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation ARPA, loopback not set

  Keepalive set (10 sec)

  Auto-duplex, Auto Speed, 100BaseTX/FX

  ARP type: ARPA, ARP Timeout 04:00:00

  Last input 2d12h, output never, output hang never

  Last clearing of "show interface" counters 00:04:05

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

  Queueing strategy: fifo

  Output queue: 0/40 (size/max)

  5 minute input rate 0 bits/sec, 0 packets/sec

  5 minute output rate 0 bits/sec, 0 packets/sec

     0 packets input, 0 bytes

     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

     0 watchdog

     0 input packets with dribble condition detected

     24 packets output, 1440 bytes, 0 underruns <---------- 24 keepalives sent 60 byte each

     0 output errors, 0 collisions, 0 interface resets

     0 babbles, 0 late collision, 0 deferred

     0 lost carrier, 0 no carrier

     0 output buffer failures, 0 output buffers swapped out

C3725#


fa1/0 is unplugged and the state is (up, down).



Connecting now fa1/0 to a switch port i/f state change in (up, up); however traffic sniffing shows only LOOP frames sent but not received back.



So I try to guess the objective behind ethernet keepalive is just check if local controller is able to physically transmit frames on the wire (tx pair).


Does it make sense ?

Actions

This Discussion