>Guy Tal: see comments inline...
>
>
> > What you are describing is a special case of using a RIB as first
>> lookup and a cache for subsequent lookup. That is indeed the case
>> for fast and silicon switching, and probably silicon. It is not the
> > case for CEF (there is no cache, only a full FIB synchronized
> > one-to-one with the RIB), and is not the case for process switching
>> (everything goes through the RIB).
>
>I apologize here, I should have specified that I was not talking about
>process switching. And I know you are being technically correct about CEF,
>but the bottom line is that the lookup is off the RIB.
AFAIK, the CEF task builds one or more (i.e., dCEF) FIBs that are in
one-to-one correspondence with the RIB. For the initial packet, the
lookup is in the FIB, not the RIB.
>
> >
>> Look at some Tolly group reports.
>
>I apologize, but I am not familiar with these reports. I went to tolly.com
>and found a terrific site. Thank you very much for pointing this out. I'll
>look into it more soon.
Look at these, and also such things as the Syracuse University
measurements of the effect of access lists (mostly on 7200's):
http://www.networkcomputing.com/1004/1004ws2.html
I agree that route cache misses and especially route cache
invalidation can have horrendous performance impact, but the caches
are often large enough for stability in an enterprise environment.
Anyplace you have a substantial part of the default-free Internet
table, caches simply don't work.
But filtering and traffic conditioning tend to be much more severe
problems than route lookup.
>
>>
>> >Without an arp
>> >cache, your device would overload looking up mac addresses. While your
>> >router may not actually be crippled without this feature, and anyone that
>> >has worked with enough 7500s knows that VIP cards are not the most stable
>> >animals out there, it is a great feature if reduced latency is more
>> important to you than money, which is a point you made earlier.
But is the latency of not using VIPs more a question of queueing for
the processor rather than raw lookup speed? Serializing onto the
bus also may be an issue. A 7500 is about the limit of shared bus
technology. Junipers are more shared memory, with its pros and cons,
and the GSR is crossbar.
> >
>> >
>> >
>> >> There are more and less hardware intensive ways to make routing
>> >> decisions. But the actual lookup time is rarely a limiting factor.
>> >
>> >I would have to disagree here as well. Perhaps lookup time isn't so bad
>if a
>> >router is sitting on a T1 somewhere, but when you have multiple oc48s
>tied
>> >into your router, processing time adds up, *real* quick.
>>
>> Again I ask, how do you know that lookup time is the problem? I work
>> with gigabit routers, and indeed work on designing next-generation
>> routers. Believe me, to run at line rate, destination lookup is not
>> nearly the concern that filtering, traffic shaping, internal
>> blocking, accounting, etc. are.
>
>Well, one specific example would be for the 75xx series of Cisco router that
>uses the VIP cards. If you attach the VIP card (from enable mode, do a
>if-con <slot#>) and then run sh proc cpu from there, and you will see that
>alot of the memory is getting tied up with routing lookups and interrupt
>requests. Add a few of these to a router and you will suffer from latency
>due to not enough memory to do lookups. I am not a big fan of VIP cards in
>practice because it seems like on a decent sized network, one will crash per
>week. But that is a specific Cisco example. What is your opinion of Juniper
>routers that are reported to achieve true line rate?
Given that I work for Nortel (and in next-generation router
research), I don't want to get into specsmanship. Tolly and others,
however, do show that Juniper generally does a better job of
approaching line rate, especially when filtering. On the other hand,
an overloaded Juniper may do even worse than an overloaded Cisco.
In big networks, constant performance monitoring and provisioning
adequate capacity before you get into trouble is a necessity.
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
