A potential problem to packet forwarding is a possibility of a routing loop. It occurs because some packets circulate endlessly due to the set of entries in the forwarding table.
Figure – 1
For example, in the Figure -1 we would have a routing loop if, for (nonexistent) destination G, A forwarded to B, B forwarded to D, D forwarded to E, E forwarded to C, and C forwarded to B. This is non-linear routing loop.
A packet sent to G would not only not be delivered, but in circling endlessly it might easily consume a large majority of the bandwidth.
Routing loops typically arise because the creation of the forwarding tables is often “distributed”, and there is no global authority to detect inconsistencies.
Even when there is such an authority, temporary routing loops can be created due to notification delays. See micro-loop article from here.
Routing loops can also occur in networks where the underlying link topology is loop-free; for example, in
the Figure – 1 we could, again for destination G, have B forward to D and D forward back to B.
Such a case is known as linear routing loop.
All packet-forwarding protocols need some way of detecting and avoiding routing loops.
Ethernet, for example, avoids nonlinear routing loops by disallowing loops in the underlying network topology, and avoids linear routing loops by not having switches forward a packet back out the interface by which it arrived.
IP provides for a one-byte “Time to Live” (TTL) field in the IP header; it is set by the sender and decremented
by 1 at each router; a packet is discarded if its TTL reaches 0.
In packet forwarding, a switch is responsible only for the next hop to the ultimate destination; if a switch
has a complete path in mind, there is no guarantee that the next hop switch or any other downstream switch
to agree to forward along that path. Misunderstandings can potentially lead to routing loops.
Last but not least packet forwarding requires cooperation and a consistent view of the network to avoid routing loops.