cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
40633
Views
65
Helpful
20
Replies

what's a LOOP traffic in ethereal?

Sanghee Han
Beginner
Beginner

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....)

2 Accepted Solutions

Accepted Solutions

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

View solution in original post

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

View solution in original post

20 Replies 20

Ganesh Hariharan
VIP Alumni
VIP Alumni

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

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?

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

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

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.

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..

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

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..

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

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...

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
Hall of Fame
Hall of Fame

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

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??

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: