12-21-2004 06:50 PM - edited 03-02-2019 08:43 PM
Please refer to the attached Visio diagram
I have 2 host that are taking different paths to a mail server. When you perform a tracert, Host A takes Path A, while Host B takes Path B.
Is this because of the traffic share count 1 line?
Will this path be constant? In what circumstances will the hosts take a different path?
Thank you for the knowledge!
Joseph
12-21-2004 08:32 PM
Again all interfaces by default run fast switching. So for each source destination address pair..a different path is used. Hence the result. If you disable fast switching and enable process switching, you can see both links being used for all packets going from internal network to mail server. ("no ip route-cache")...Fast switching is faster than Process switching..hence disabling Fswitching can affect performance..
12-21-2004 10:46 PM
Hi, thanks for the advice! Still need a bit more clarification, if you don't mind.
At the present moment, fast-switching is enabled. Does this mean if
i)the network remains stable, or
ii)the fast cache is not invalidated
then Host A will indefinitely use Path A, and Host B will indefinitely use Path B?
Thanks again!
Joe
p.s. i found the following the URL that mentions abt the aging of the fast cache
http://www.cisco.com/en/US/tech/tk827/tk831/technologies_white_paper09186a00800a62d9.shtml
12-21-2004 11:39 PM
Cache maintenance is based on invalidation and ageing.
Invalidation can happen because of change in the routing table
or because of a change in the ARP table.
Normal ageing happens every minute.
As it is said in the document you provided,
1/20th of the fast cache is invalidated, randomly, every minute.
The goal of this ageing scheme is to try to refresh the cache in a 20 minute period.
So, even if you do not experience elementary problems
there are chances that an entry is invalidated randomly.
I think some cache parameters can be tuned, but I wouldn't recommend it.
M.
p.s. I am sorry, but I do not have the software that would allow me
to view the attachment in your original posting.
12-22-2004 10:12 PM
Thanks for the advice! Much appreciated!
12-24-2004 01:31 AM
Maria,
Your posting prompted me to speculate about the invalidation of the fast cache, and the algorithm they use to decide which 20th of the table to invalidate.
Of course, if the invalidation was really random, the cache would not get invalidated in 20 minutes because it would decay "exponentially". In fact, after 20 minutes the proportion of the cache to survive would be (19/20)^20, or about 36%. Cache entries would have a half-life of about 13 minutes.
Here comes the speculation: I guess they could design a pseudo-random function so that all entries were covered within a 20 minute period. In fact, if they were to use a 20-way hash function to populate a lookup table in the first place, then they could use a similar or identical hash function to select which entries to invalidate, and so guarantee to cover all of them.
I suppose I could go further and say if they use any decent hash-function to populate the lookup table, (i.e. a hash function that appears to distribute its output at random) then they could just invalidate a consecutive 1/20 block of the lookup table, and the routes would appear to be invalidated randomly.
As I say, the design stuff is just speculation on my part, and the people who really know are Cisco Engineering.
Have a nice Christmas!
Kevin Dorrell
Luxembourg
12-24-2004 01:59 AM
Hello Kevin,
As I said, "The goal of this ageing scheme is to TRY to refresh the cache in a 20 minute period."
I cannot possibly know how they are implementing this,
or if it MANAGES to completely refresh the cache in 20 minutes.
This is a real-time embedded system anyway,
and the entries are dynamically created all the time,
so I wouldn't expect complete refresh,
unless the entries were somehow all "flushed" in a particular time instance.
Whether the implementation is really random or pseudo-random,
the "random" word has the same practical consequence (as I see it).
That is, I cannot count on an entry being there for as long as
no problems occur in the network or with the router memory.
As I said, "there are CHANCES that an entry is invalidated randomly" .
Best Regards,
Maria
p.s. Merry Christmas!
May all aspects of your life that matter to you, to go for the best.
I wish to everybody peaceful vacations with minimal (if zero is not possible) network outages.
Although those network_equipment_babies seem to work quite well
when everybody is on vacation and none is messing up with them!
01-02-2005 10:29 AM
Kevin,
I am sorry I didn't spend enough thought on your implementation idea in the first place.
But afterwards, it was my own turn to think on what you said.
Yes, I think your proposal would do the job at hand.
I was wrong on the following point:
Entries are created all the time, but this fact
shouldn't count against refresh.
New entries are new entries, so they are not old!
(A tautological thing to say, but that's it in simple terms.)
My only objection would be on how efficient a hash
organization of entries would be regarding entry lookup,
which I would guess is the most common operation
and probably the most critical to do fast.
Anyway, your idea is interesting so I will give you five for it ;-)
Sorry for answering after a week,
but I was on vacation and away from the net,
trying to refresh my own cache!
Happy New Year!
Maria
01-03-2005 12:50 AM
Microsoft has a free viewer for Visio diagrams made with versions Visio 5, 2000 and 2002. It only works with Microsofts Internet Explorer 5.0 or later.
Here is the link
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide