Hi guys,
Let's first reiterate how process switching works. This will help to understand the drawbacks in fast switching.
When a packet comes into a router, this is roughly what the router would do if it handled the packet in the process switching path:
- Look up the destination IP address in the routing table. If the lookup returns only the next hop IP address without the information about the egress interface, perform another lookup in the routing table, this time looking for the next hop IP address found in the previous iteration. Repeat this until the lookup returns information about the egress interface, remembering the last found next hop IP address as well.
- After the egress interface for the next hop IP address is identified, use the Layer3-to-Layer2 mapping table for this interface (such as ARP table, NHRP table, IP/DLCI, IP/VPI-VCI) to determine the Layer2 address of the last next hop that was identified in the previous step.
- Encapsulate the IP packet into a newly constructed frame using the Layer2 addressing determined in the previous step and send it out the egress interface.
I have omitted the usual steps with verifying the checksum of the ingress IP packet, decrementing the TTL, recalculating the checksum etc. - these need to be done anyway.
While this process seems to be relatively straightforward, it is at the same time quite ineffective.
- No information about the lookup results is ever stored. For one million packets going to the same destination, this process is repeated itself one million times, each time producing the very same result but never storing it for further reuse.
- Recursive lookups in the routing table are expensive by themselves, and if the routing table has thousands or even more entries, going over them even once is an expensive operation. Multiply this by the number of recursive lookups necessary for a single packet, and multiply that again by the number of packets going to the same destination, and you'll see soon why this doesn't scale.
Fast switching, also neatly called route cache, is a concept that can be summarized as "Route once, forward many times". Whenever a packet for a new, not-yet-seen destination comes in, it is routed by the process switching exactly as described before. However, the resulting information from these daunting lookups (egress interface, Layer2 address of the next hop) will then be stored in a tree-based route cache organized for rapid lookups. The next time a packet for the same destination comes in, the information for its routing/forwarding is already readily available in the route cache with a single non-recursive lookup - just use it to encapsulate the packet into a frame and forward it.
While this seems to be a perfect idea, there is - apart from other disadvantages related to housekeeping of the cache - still a major drawback: If your router suddenly experiences an inrush of millions of packets to yet-unseen destinations, they will all need to be process switched because the route cache does not yet contain information about them. This means that all advantages of the fast switching are lost, and in fact, the incurred load of process switching these gazillions of packets to yet-unseen destinations can truly bring the router down to its knees. This can happen easily when, for example, a backbone router comes online, routing protocol converges and the router suddenly becomes a transit router for many destinations.
This is what, I believe, the book tries to explain.
Best regards,
Peter
