Actually, you don't have the problem quite right.
The problem is not the sheer size of the routing table. The 64 MB RP
has fixed that for quite a while. It is not the processing load
associated with the route change. An RS6K can keep up easily if it
doesn't have to page (enough RAM in the box), and so can a 68020 if it
was allowed enough CPU time to do something.
The problem is that when a large set of routes change, a large set of
routes in the SSP are invalidated. This results in a large amount of
traffic forwarded to the RP. The SSP is bludgenning the RP in order
to tell it that it needs some cache entires updated. The RP then
can't keep adjacencies up and more route change results, which can
kill other routers. If it gets far enough out of hand, the
instability can turn into a stable oscillation and you have a melted
backbone. This is a consequence of the architecture and the cache
design. I've been pointing out this for years. Now it blew up.
This is very fixable and Cisco could even fix it without requiring
everyone to throw out their Cisco 7000s. Just get rid of the cache
completely and push full routing from the RP to the SSP!
Curtis
ps - This is my guess. Cisco or Sprint have not yet confirmed or
denied this. Perhaps Sean or Tony would care to comment. 