At 04:21 PM 2/4/98 -0500, you wrote:
>> o How is the forwarding mechanism on the router making use of
>> that IP forwarding table. In some cases (e.g. when using a
>> "route cache"), the router will pick a single next-hop for
>> each new entry it puts in the "route cache", so unless there
>> is a cache invalidation all the traffic to a given destination
>> will travel over over same wire to the same next-hop. In
>> recent route-cache code the "destination" is generally a
>> "prefix", not a host (eh, remember good old times? ;-). In
>> other cases, the forwarding engine can be made to do a "per-
>> packet" choice of next hop (process switching on old gear and
>> apparently CEF switching with new software), since no
>> simplified route cache (with only a single next-hop) is
>> involved in those cases. I'm sure there can be variations on
>> these themes, e.g. source-dest hash, as you mention (anyone
>> know how cisco's netflow-based route cache does this?),
>> although I can see that anything host-based will tend to scale
>> badly in backbone routers.
>>
>
>Would you agree that any type of 'route caching' wouldn't scale well on
>a backbone router? I think that you have to have full table with all
>best paths on a forwarding engine. (I might be off topic cause it's not
>about
>some today's HW.) The penalty for doing multiple lookups can be minimal
>when it'll be done in ASIC.
>
> Regards,
> Greg
>
>
Depending on whether you want load-balancing on a per-packet or
per-destination basis, you may or may not want to have 'ip route-cache'
implemented on the serial-links. If certain destinations are impacting
system performance as opposed to random traffic, then you would probably
want to load-balance on a per-packet decision instead, therefore disabling
caching. Otherwise once the cache was established for a particular
destination, you would not see traffic shared between the links for that
destination.
YMMV depending on the circumstances. I would recommend trying both
scenarios(cacheing/not-cacheing) for your situation and seeing which
performs best for you. Depending on your distribution of traffic types,
either solution may be a better fit for your application.
al
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:15 EDT