Uh, I've seen PC's with Gigabytes of RAM, but have yet to hear
of a router with such.True. There's no market yet.
Once the market is there, its usually too late for the poor fools
running the backbone.
CIDR is a bandaid.
If you seriously believe that, then you better present some other
mechanism for scaling routing. We know of only one: hiearachical
routing.
I SERIOUSLY belive CIDR is a bandaid. And talk of not accepting
routes smaller than X bits, and not allowing holes in in CIDR blocks
breaks CIDR. CIDR is a good idea, if you do NOT impletment these
practices, and is a good idea in general in that case. However,
it does not solve the problem of "router table growth" which perhaps
could more correctly be described as path growth on the gobal Internet.
The more "general" peering sites, the more total paths you have to
take, in addition to the problem of total peering sessions.
The problem is
translating from from BGP to forwarding tables installed in routers.Sorry, no. There are a number of problems. This isn't one.
Ok, I guess I was confused, I understood that route flapping which
causes a cisco router to need to be reloaded can be caused by
a flapping session, causing all of the forwarding tables/caches
to be flushed, causing the CPU load in a Cisco 7000 to reach 115%?
Have I been lied to?
Current routers do not have enough BGP processing power to
do the BGP filtering and processing power.I have about 100 counterexamples. Obviously, you can configure
arbitrarily complex filtering and if you do that, you need an
arbitrarily large amount of compute power. The fact is that there's
enough to work today.
Again, see above comment about CPU utilization and its detrmental
effects to CPU load on a Cisco causing BGP sessions to fail (which
causes more route flapping, etc.)
The other problem is the mesh nature of BGP which makes any BGP
peering site, with full mesh peering, an N^2 problem.This is fixed.
How is this fixed? With N peers at a peering location you must have
each route must have N peering sessions, which looks like N^2 to me.
Maybe a clarification of terms in order here, because it seems fairly
easy for people without formal backgrounds to confuse the issue.
And with the multiple path problem it seems easy enough to
add N proxies to reduce the total number of paths in any one
box. NOTE: this could have serious impacts on stablity with
several multihope paths in a configuration, each one being
a point of failure.
Seeing as memory is typical 1/2 the price
for a workstation as for a Cisco router, you can almost aford to
have 4 BILLION host routes in the workstation, compared to the cost
of the replacing your entire backone with the Cisco of the Month Club.No one said that you had to buy the memory for your cisco from cisco.
No, but even certified memory from my PC/workstation vendor is cheaper
than Cisco certified memory. Even with SIMMs being SIMMs, I know
better than to just plug anyone's memory module into any box.
A typical SIMM module may have as many as 70 different timing
parameters any one of which may vary by enough nanoseconds to
cause a heavily loaded machine to crash. (Maybe cisco's don't
do this, but every other workstation I've worked in in the
last 15 years had the same problem.)