From: "Martin A. Brown" <mabrown-lartc@securepipe.com>
To: lartc@vger.kernel.org
Subject: [LARTC] the routing cache and route selection; is this correct?
Date: Tue, 29 Oct 2002 03:40:01 +0000 [thread overview]
Message-ID: <marc-lartc-103586295601326@msgid-missing> (raw)
Hello all,
I do not read C very well (especially kernel C). Though I have tried to
muddle my way through an understanding of what's going on in fib_hash.c,
fib_rules.c, and route.c, I have not succeeded to my satisfaction, hence
my post.
I'm trying to document the general process of route selection, and have
come up with the following overview. Could somebody point out any flaws
in my understanding of the use of the routing cache during route
selection and the route selection process?
Starting point: packet enters the routing stage.
- Attempt a lookup in the routing cache according to the following:
+ destination address
+ source address
+ type of service (tos)
+ fwmark (fwmark)
+ interface on which packet was received (iif)
- If a routing cache entry exists, we're done: the route has
been selected.
- If there is no routing cache entry, we continue with route selection
by consulting the RPDB and routing tables.
1 start traversing the RPDB at the highest priority
2 keep traversing the RPDB for the next matching entry
3 when a match is found, try to find a match for the destination
in the designated table
4 if there is no matching route in the specified routing table
continue to traverse the RPDB (skip back to step 2)
5 if there is a matching route, the route has been selected
So, my question:
Is the routing cache actually keyed on the above items? If I understand
Arthur's post of last Friday properly
(http://mailman.ds9a.nl/pipermail/lartc/2002q4/005641.html), he's
suggesting that the keys in the routing cache are src, dest, and tos.
If I understand my empirical evidence properly, and have muddled enough
understanding of fib_rules.c, this statement is accurate, but not complete.
My empirical evidence: I know I'm using fwmark routing on a particular
host, and packets are transmitted out the "correct" interfaces when I
generate traffic for all of the fwmark'd routes. What confuses me is the
output of "ip route show cache ip.ad.dr.es". There is no reference
whatsoever to fwmark in this output.
Can somebody confirm (as the evidence suggests) that the routing cache is
keyed on the above five elements?
-Martin
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
next reply other threads:[~2002-10-29 3:40 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-29 3:40 Martin A. Brown [this message]
2002-10-29 10:15 ` [LARTC] the routing cache and route selection; is this correct? Julian Anastasov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-lartc-103586295601326@msgid-missing \
--to=mabrown-lartc@securepipe.com \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.