Hello Nishant,
How STP can block self-looped ports from carrying data ?? In our network I have never seen STP blocking self-looped ports.
My experience is that STP on LAN Catalyst switches verifies whether a port receives the same BPDU it has sent itself. If that happens, STP moves the port to the discarding (blocking) state.
What are these "STP and LOOP frames",
STP frames are STP BPDUs. I apologize for not using a common terminology here.
LOOP frames are messages of a so-called LOOP protocol. This protocol is used on Catalyst switches to detect if a port loops back to itself. If a port receives a LOOP message it sent itself, the switch will deactivate the port.
The STP and LOOP protocols are different and independent protocols.
Giuseppe Larosa and I discussed the LOOP and STP protection of self-looped ports at length in this thread - I encourage you to read it carefully although it is quite long:
https://supportforums.cisco.com/message/3005900#3005900
I know keepalive messages are sent through ports every few seconds( default every 10 secs)
Correct but these keepalives you are talking about are precisely the LOOP messages I am talking about.
But keepalive messages are general TCP based and not a STP feature
TCP? Not necessarily. The term keepalives is a name for a general mechanism used to ensure a liveliness of a neighbor, of a link between neighbors, or of a connection between communicating peers. There are many ways to implement these keepalives, strongly depending on the technology and the application.
In HDLC, PPP and Frame Relay, keepalives are simple frames of the particular L2 technology containing sequence and/or magic numbers that are exchanged periodically between interconnected peers. There is no IP involved in these Layer2 keepalives. In GRE, a keepalive is a double-GRE-encapsulated packet that a router sends to itself via the other tunnel endpoint to verify that the tunnel is correctly configured and working on both ends. All these mechanisms verify the liveliness of a Layer2 link (in this sense, a GRE tunnel is also considered a Layer2 link). TCP, as you correctly mentioned, also has an optional support for keepalive segments to verify that the TCP connection between the client and server is still alive - but note that TCP keepalives are by far not the only keepalives that exist.
With respect to the keepalive command on Ethernet interfaces, I would personally call that command an unfortunate choice of name. Ethernet technology by itself does not have any keepalive mechanism. This command actually allows sending and processing the LOOP frames that were originally intended to form a primitive testing mechanism between stations connected to a single Ethernet segment. This usage never became widespread. Cisco seems to reuse this LOOP message for a different usage: verifying whether a port is self looped. Catalyst switchports send these LOOP frames sourced and destined to the same MAC address belonging to that switchport. If a port receives its own LOOP frame, it will be disabled.
Keepalive messages are sent every 10 secs by default, what will happen if I have a transimission media which loops traffic momentarily (suppose for 5secs) every now and then. Keepalives may not detect such momentarily occured loops and put the port in err-disabled state. What will be effect of such loops in network.
As I explained earlier, if we are talking about keepalives on Ethernet interfaces then there is actually nothing of the sort. The "keepalives" are exactly the LOOP frames that are performing a totally different function, and in fact, they are expected not to arrive back - otherwise, the port will be considered looped.
One point to consider here: a self-looped port will reflect any frames back to the switch. However, this alone will not cause a true switching loop in which frames are circulating endlessly, because of a simple fact that a frame received on a port is not forwarded back through it. Even if a frame is originally sent out a self-looped port and is reflected back, it will not be propagated again through the same port upon receiving it. Hence, self-looped ports cause unwanted replication of traffic and instability of MAC address tables but they do not cause infinite loops by themselves.
So, chances of occassional loops are very high.
Chances of self-looped ports? How is that possible? Are the customers creating these loops themselves?
What are effects of self-loop on L3 based network?
I have heard that L3 based network are better at controlling effect of transient self-loops because of TTL field in packets of L3 switched network. Is that true??
It is true that an IP packet will not circulate forever in a network because each pass through a router will decrement the TTL field in its header, and decrementing the TTL to 0 will result in the packet being dropped. In addition, creating a self-looped port on a router will not cause the traffic to loop at all: such a packet will need to be encapsulated into a frame whose destination MAC is supposed to be different from the sender MAC (in this case, the router's NIC), as the router is surely not going to send a packet to itself.
As you told, the effects of self-looped traffic are obvious: broadcast, multicast and unknown destination unicast frames caught in an endless loop. Is this effect same with L3 based network ???
Self-looped ports do not cause any looping in L3-routed or L3-switched network. Looping in L3-based networks is caused by routing loops created by incorrect routing table entries. Self-looped ports do not influence routing tables. The effect of a routing loop in a routed network may be similar: traffic being routed in circles, never reaching its destination and consuming bandwidth on links, but the avalanche effect of traffic multiplication as seen in L2 loops should not take place, as in unicast routing, packets are never multiplicated.
Best regards,
Peter
