Film at 11:00

Looks like the 45k mark was reached:

Table History

Date Prefixes
231296 43352
241296 44089
251296 43735
261296 43391
271296 43093
281296 43912
291296 45352
301296 45532

Happy New Year on the Internet,

- paul

ref: http://www.employees.org:80/~tbates/cidr-report.html

Looks like the 45k mark was reached:

Folks with 7000's and SSE's should start monitoring their memory
utilization via "show sse summary".

Tony

Hmm, it's not news for us. 45K can hold core routing only as
inter-back-bone router, not more.

But why, why this crasy CISCO could not predict future when
they designed 45K routers? It was not difficult for them
develop this box to cary 64 or 128MB RAM.

Hmm, it's not news for us. 45K can hold core routing only as
   inter-back-bone router, not more.

   But why, why this crasy CISCO could not predict future when
   they designed 45K routers? It was not difficult for them
   develop this box to cary 64 or 128MB RAM.

   > Looks like the 45k mark was reached:
   >
   > Folks with 7000's and SSE's should start monitoring their memory
   > utilization via "show sse summary".

There's a couple of comments here:

First, 45k is not the limit. More like 60k. You'll pardon me for being
cautious.

The limitation is not DRAM. It's the 64k words of SRAM that the SSE uses
for its high speed forwarding table. You don't want to pay for 64Mbytes of
SRAM. :wink:

When cisco's engineers designed the SSE, we knew very well what was
happening. We expected to be given the opportunity to produce subsequent
hardware which implemented the SSE in an ASIC. If, by that time, CIDR
hadn't killed off the exponential growth, we would have expanded the
address space. Unfortunately, cisco management decided that the SSE ASIC
should not be implemented (a mistake which, to my knowledge, cisco has not
corrected). Thus, the 7500 exists without an SSE.

Tony

First, Happy New Year.

2'th, sorry for my mistake - I just meant 45K as Cisco 4500... Through
it have not changed issue seriously -:slight_smile:

3'nd.. Do you mean VIP2 idea is worst then SSE idea?

3'nd.. Do you mean VIP2 idea is worst then SSE idea?

The VIP2 is a fine idea. However, it's again using conventional
microprocessor technology for forwarding. And unfortunately, it needs to
be fairly high end processor technology to sustain the rates. The problem
is that the traffic demand far exceeds the growth rate of processor
forwarding.

So the problem is that as we approach higher speed (post-7500) interfaces,
you're forced into more specialized hardware. At this point, not having an
SSE ASIC becomes somewhat silly. The rest of the board is ASICs, which in
volume end up cheaper than processors...

Tony

     3'nd.. Do you mean VIP2 idea is worst then SSE idea?

  The VIP2 is a fine idea. However, it's again using conventional
  microprocessor technology for forwarding. And unfortunately, it needs to
  be fairly high end processor technology to sustain the rates. The problem
  is that the traffic demand far exceeds the growth rate of processor
  forwarding.

  So the problem is that as we approach higher speed (post-7500) interfaces,
  you're forced into more specialized hardware. At this point, not having an
  SSE ASIC becomes somewhat silly. The rest of the board is ASICs, which in
  volume end up cheaper than processors...

  Tony

! Sorry, my crazy Win95 (I HATE MS!) drop me from TELNET 3 times when
! I did attempted to answer this from the home -:).
Really, there is one important question (not the blame about IOS's
memory or so on) - does hardware vendors (just as CISCO etc) really predicts
the future? When CISCO developed CS4500, they have decided 32MB RAM would be
enougph just as MIPS processor they established. Just now they (seems)
think it'll be enougph new MIPS and 128MB RAM. It's amazing but I can
easy upgrade my 1,000$ IBM PC up to 256MB RAM, but I can't do it for
my CISCO routers (about 10 - 30,000$) at all. It's easy to install
2 or 4 CPU into SUN ULTRA-2 or SGI SERVER computers, but it's impossible to do
it with routers. And so on.

What's about switching itself - I am not shure they (vendors) are on the wrong way.
Seems CISCO have well defined plan - they are moving toward from
1 CPU doing everything (CS2500 and CS4700) to (1 CPU for routing, few CPU for the
switching - VIP2) and to (1 CPU for the Routing, and many switches for the
switching - MPOATM, TAG Switching, etc) - they are trieing to build
mixed _routers + ATM_NETWORK_ backbone when routers would decide how to
forward some virtual streams (TCP connections etc) and switches would
forward the packets toward their destinations.

And this mean we'll have more troubles with the routers, not switches.
There is a lot of ways to increase switching capability (look on Stratocom,
for example); but the routers itself are far beyong. We can easyly increase
the CPU and Memory for the UNIX Servers; it's not difficult to build
server with 512MB RAM, 4x300 MHZ CPU, 10 PCI or SBUS cards; but
no one router can be expanded easyly. I wonder why it's so many discussion
there about DRAM/SRAM/etc..., there exist fast and nonblocking switches just
now; and moreover, you can install them in parallel because no one customer
need 200Mbit data links itself /this means you can use 4x100 mbit links
instead of 1x400Mbit withouth the lost of quality/. But what we'll do with
the routers next 2 years? Just now existing CS7500 and CS4700 are 30% - 50% loaded
by ROUTING (not switching but routing) and there is not ways to
scale them easily.

Or we'll go back to the UNIX boxes + GATED? Sometimes I guess this is true _:slight_smile:

Really, there is one important question (not the blame about IOS's
   memory or so on) - does hardware vendors (just as CISCO etc) really predicts
   the future?

There's a complicated answer. Yes, certain people at router vendors do
understand and can predict what is necessary. However, this does not imply
that the right thing happens. Please recall that most (all?) router
manufacturers are driven by the enterprise market, not the ISP market.

Memory constraints in the enterprise market are not an issue. Memory costs
(and even the cost of the extra SIMM socket) _are_ an issue, as they affect
the price that everyone on the street pays. This either cuts into
manufacturers profit margins or into their sales.

Thus, router manufacturers can indeed predict what's needed for the ISP
market. But history shows that they consistently make a business decision
to design hardware for the enterprise market.

   It's easy to install 2 or 4 CPU into SUN ULTRA-2 or SGI SERVER
   computers, but it's impossible to do it with routers. And so on.

In fact, it's not impossible. That's _exactly_ what you're doing when you
install a VIP.

   But what we'll do with the routers next 2 years? Just now existing
   CS7500 and CS4700 are 30% - 50% loaded by ROUTING (not switching but
   routing) and there is not ways to scale them easily.

Again, getting the switching off of the CPU is key. Once that happens
consistently, then there is much more CPU for routing computation. 30-50%
for routing is fine once that happens. It just implies that we need to
scale up the processor to match the growth in _routing_ traffic.
Fortunately, that's _FAR_ lower than transit traffic, so I believe it's a
tractable problem. Just gotta stay on the processor curve.

Tony

In cisco.external.nanog you write:

     3'nd.. Do you mean VIP2 idea is worst then SSE idea?

  The VIP2 is a fine idea. However, it's again using conventional
  microprocessor technology for forwarding. And unfortunately, it needs to
  be fairly high end processor technology to sustain the rates. The problem
  is that the traffic demand far exceeds the growth rate of processor
  forwarding.

  So the problem is that as we approach higher speed (post-7500) interfaces,
  you're forced into more specialized hardware. At this point, not having an
  SSE ASIC becomes somewhat silly. The rest of the board is ASICs, which in
  volume end up cheaper than processors...

  Tony

! Sorry, my crazy Win95 (I HATE MS!) drop me from TELNET 3 times when
! I did attempted to answer this from the home -:).
Really, there is one important question (not the blame about IOS's
memory or so on) - does hardware vendors (just as CISCO etc) really predicts
the future? When CISCO developed CS4500, they have decided 32MB RAM would be
enougph just as MIPS processor they established. Just now they (seems)
think it'll be enougph new MIPS and 128MB RAM. It's amazing but I can
easy upgrade my 1,000$ IBM PC up to 256MB RAM, but I can't do it for
my CISCO routers (about 10 - 30,000$) at all. It's easy to install
2 or 4 CPU into SUN ULTRA-2 or SGI SERVER computers, but it's impossible to do
it with routers. And so on.

What's about switching itself - I am not shure they (vendors) are on the wrong way.
Seems CISCO have well defined plan - they are moving toward from
1 CPU doing everything (CS2500 and CS4700) to (1 CPU for routing, few CPU for the
switching - VIP2) and to (1 CPU for the Routing, and many switches for the
switching - MPOATM, TAG Switching, etc) - they are trieing to build
mixed _routers + ATM_NETWORK_ backbone when routers would decide how to
forward some virtual streams (TCP connections etc) and switches would
forward the packets toward their destinations.

And this mean we'll have more troubles with the routers, not switches.
There is a lot of ways to increase switching capability (look on Stratocom,
for example); but the routers itself are far beyong. We can easyly increase
the CPU and Memory for the UNIX Servers; it's not difficult to build
server with 512MB RAM, 4x300 MHZ CPU, 10 PCI or SBUS cards; but
no one router can be expanded easyly. I wonder why it's so many discussion
there about DRAM/SRAM/etc..., there exist fast and nonblocking switches just
now; and moreover, you can install them in parallel because no one customer
need 200Mbit data links itself /this means you can use 4x100 mbit links
instead of 1x400Mbit withouth the lost of quality/. But what we'll do with
the routers next 2 years? Just now existing CS7500 and CS4700 are 30% - 50% loaded
by ROUTING (not switching but routing) and there is not ways to
scale them easily.

As Tony said, the solution is to decouple the RP and allow it to just
do routing.. Then we should be able to contain the route processing
requirement within the CPU technology growth curve.

If you are interested about the RSP/7500/VIP2s, you should talk to
your account team.. some interesting things targeted exclusively for
the ISPs are happening..

--ravi