Mailing List Archive

Yes, no doubt. But I'd like to see router's vendors predicted
future better than in the past. We all know few serious mistakes CISCO
did - with the memory size in CS4500, with CS7000 and CS7010 routers;
and I am afraid to fail into new trap in future...

> > 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.
>
> Well, it's also somewhat more complicated to distribute the tasks in a router
> to multiple CPUs.
>
> There are plenty of ways to break Bays by accidentally doing that distribution
> wrong.
>
> > Aleksei Roudnev, Network Operations Center, Relcom, Moscow
>
> Avi
>
>

---
Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
- - - - - - - - - - - - - - - - -

In cisco.external.nanog you write:


>not to make this too cisco specific, but...

>the number of entries in the forwarding cache on the
>sse is generally more than the number of routes in
>the bgp rib (because of the way the cache handles
>more-specifics of over-lapping aggregates). so in
>addition to the raw number of routes in the rib, the
>efficiency (and scope) of aggregation are also
>important data points

>now a question. what does an sse do when its cache
>fills? it used to(*) bring down the whole sse, which
>doesn't really make much sense given that it's a
>cache and therefore it's normal operation for it to
>be incomplete. anyone know an answer to that one?


SSE memory usage is monitored and if it falls below a particular
threshold, the ager will become more aggressive in aging entries..

--ravi


>/jws

>(*) -- "used to" implies that it happened before,
>which it did. but that was largely due to the
>ineffeciency of the data structures, and the problem
>was solved such that 2 years (and counting) was added
>to its life

> >
> > 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. ;-)
> >
> > 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
- - - - - - - - - - - - - - - - -

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

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



>---
>Aleksei Roudnev, Network Operations Center, Relcom, Moscow
>(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager)
>(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
- - - - - - - - - - - - - - - - -

In cisco.external.nanog you write:

>Yes, no doubt. But I'd like to see router's vendors predicted
>future better than in the past. We all know few serious mistakes CISCO
>did - with the memory size in CS4500, with CS7000 and CS7010 routers;
>and I am afraid to fail into new trap in future...


Yep.. we are hearing you. Hopefully we will not fall into the same
trap again.

--ravi


>> > 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.
>>
>> Well, it's also somewhat more complicated to distribute the tasks in a router
>> to multiple CPUs.
>>
>> There are plenty of ways to break Bays by accidentally doing that distribution
>> wrong.
>>
>> > Aleksei Roudnev, Network Operations Center, Relcom, Moscow
>>
>> Avi
>>
>>

>---
>Aleksei Roudnev, Network Operations Center, Relcom, Moscow
>(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager)
>(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
- - - - - - - - - - - - - - - - -