Need verification of routing

[joch2joch]

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

[thisisshanky]

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

[joch2joch]

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

[marikakis]

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.

[joch2joch]

Thanks for the advice! Much appreciated!

[Kevin Dorrell]

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

[marikakis]

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!

[marikakis]

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

[s.conway]

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

http://www.microsoft.com/downloads/details.aspx?FamilyID=8FAD9237-C0A7-4B80-A5DF-46CE54DAD2DF&displaylang=EN