Julian Elischer wrote:
Andre Oppermann wrote:
People with the ultimate need for speed have to maintain their own
trees anyway (Bluecoat, Juniper, Sandvine, Isilon,...) and can afford
to cut some more corners anyway.
We are trying to get away from that. We are trying to get more BACK
from th
Vadim Goncharov wrote:
Compare it with a scheme where for EVERY forwarded packet, there is a
need for DOUBLE lookup - after a routing one, do another in L2 table.
ARP lookups will generally use a cheap hash once split. What's the problem?
The PATRICIA lookups are more expensive, to be sure. Do
Andre Oppermann wrote:
People with the ultimate need for speed have to maintain their own
trees anyway (Bluecoat, Juniper, Sandvine, Isilon,...) and can afford
to cut some more corners anyway.
We are trying to get away from that. We are trying to get more BACK
from those companies.
___
Li, Qing wrote:
To remove an ARP entry for host A.B.C.D in L2 table of form
(A.B.C.D -> 00:01:02:03:04:05), it is enough to do a (usual speed)
routing lookup for host A.B.C.D and modify a one pointer in
it's rtentry to NULL or remove rtentry (if it's selected to
be implemented as cloned). Thus
>
> Why a full walk, why such a dumb way?
>
Correct, we don't do a full walk.
>
> To remove an ARP entry for host A.B.C.D in L2 table of form
> (A.B.C.D -> 00:01:02:03:04:05), it is enough to do a (usual speed)
> routing lookup for host A.B.C.D and modify a one pointer in
> it's rtentry
>
> Surely, routing table should contain a cached pointer to an
> entry in L2 table (ARP in case of Ethernet), to not do double
> lookups. But still separate those tables...
>
The routing table contains only the interface route, from this
interface route the L2 table is accessed for on ne
07.01.08 @ 03:41 Andre Oppermann wrote:
Vadim Goncharov wrote:
07.01.08 @ 00:10 Julian Elischer wrote:
Is multicast and multipath routing the same?
No. They are currently orthogonal.
However it makes sense to merge the multicast and unicast forwarding
code as currently MROUTING is limite
Vadim Goncharov wrote:
07.01.08 @ 00:10 Julian Elischer wrote:
Is multicast and multipath routing the same?
No. They are currently orthogonal.
However it makes sense to merge the multicast and unicast forwarding
code as currently MROUTING is limited to a fan-out of 32 next-hops
only. In m
07.01.08 @ 00:10 Julian Elischer wrote:
Is multicast and multipath routing the same?
No. They are currently orthogonal.
However it makes sense to merge the multicast and unicast forwarding
code as currently MROUTING is limited to a fan-out of 32 next-hops
only. In multicast, next-hops ar
Bruce M. Simpson wrote:
Vadim Goncharov wrote:
Is multicast and multipath routing the same?
No. They are currently orthogonal.
However it makes sense to merge the multicast and unicast forwarding
code as currently MROUTING is limited to a fan-out of 32 next-hops only.
In multicast, next-ho
Mykola Dzham wrote:
Julian Elischer wrote:
setfib 3 /bin/sh
now by default everythign you do uses table 3.
or even
setfib 3 jail {blah}
and all the procs in the jail use table 3. You also need to do
setfib 3 jexec xxx
for extra processes you add to the jail afterwards.
Is it possible to d
Julian Elischer wrote:
OK, but we should think about it in the future. In theory, routing
socket's messages are easily extendable with FIB number in uint16_t,
as message keeps it's length...
I will do that with the advice of people who know that protocol better
than I do.
I'm afraid Linux
Vadim Goncharov wrote:
Is multicast and multipath routing the same?
No. They are currently orthogonal.
However it makes sense to merge the multicast and unicast forwarding
code as currently MROUTING is limited to a fan-out of 32 next-hops only.
In multicast, next-hops are normally just inte
Julian Elischer wrote:
>
> setfib 3 /bin/sh
>
> now by default everythign you do uses table 3.
> or even
>
> setfib 3 jail {blah}
>
> and all the procs in the jail use table 3. You also need to do
> setfib 3 jexec xxx
> for extra processes you add to the jail afterwards.
Is it possible to de
Vadim Goncharov wrote:
04.01.08 @ 00:52 Julian Elischer wrote:
By the way, I might add that in the 6.x compat. version I may end up
limiting the feature to 8 tables. This is because I need to store some
stuff in an efficient way in the mbuf, and in a compatible manner
this is easiest done by s
04.01.08 @ 00:52 Julian Elischer wrote:
By the way, I might add that in the 6.x compat. version I may end up
limiting the feature to 8 tables. This is because I need to store some
stuff in an efficient way in the mbuf, and in a compatible manner this
is easiest done by stealing the top 4 bits
Vadim Goncharov wrote:
28.12.07 @ 03:19 Julian Elischer wrote:
By the way, I might add that in the 6.x compat. version I may end up
limiting the feature to 8 tables. This is because I need to store some
stuff in an efficient way in the mbuf, and in a compatible manner this
is easiest done by s
28.12.07 @ 03:19 Julian Elischer wrote:
By the way, I might add that in the 6.x compat. version I may end up
limiting the feature to 8 tables. This is because I need to store some
stuff in an efficient way in the mbuf, and in a compatible manner this
is easiest done by stealing the top 4 bits
At Fri, 28 Dec 2007 20:40:30 +0100,
Marko Zec wrote:
> The thrust behind Julian's work seems to be providing multiple
> forwarding tables for for purposes of traffic engineering / policy
> based routing, with a single firewall instance used as a classifier.
> vimage-style network stack virtuali
On Friday 28 December 2007 14:49:15 [EMAIL PROTECTED] wrote:
> At Wed, 26 Dec 2007 16:26:11 -0800,
>
> julian wrote:
> >
> > On thing where FreeBSD has been falling behind, and which by chance
> > I have some time to work on is "policy based routing", which allows
> > different packet streams to be
[EMAIL PROTECTED] wrote:
At Wed, 26 Dec 2007 16:26:11 -0800,
julian wrote:
[...]
How does this work with Marko Zec's virtual stack system?
Best,
George
orthogonal
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/f
On Dec 27, 2007 11:19 PM, Julian Elischer <[EMAIL PROTECTED]> wrote:
>
> Ivo Vachkov wrote:
> > On Dec 27, 2007 2:26 AM, Julian Elischer <[EMAIL PROTECTED]> wrote:
> >> Resending as my mailer made a dog's breakfast of the first one
> >> with all sorts of wierd line breaks... hopefully this will be
At Wed, 26 Dec 2007 16:26:11 -0800,
julian wrote:
>
> Resending as my mailer made a dog's breakfast of the first one
> with all sorts of wierd line breaks... hopefully this will be better.
> (I haven't sent it yet so I'm hoping)..
>
>
> ---
>
>
>
> On t
Ivo Vachkov wrote:
On Dec 27, 2007 2:26 AM, Julian Elischer <[EMAIL PROTECTED]> wrote:
Resending as my mailer made a dog's breakfast of the first one
with all sorts of wierd line breaks... hopefully this will be better.
(I haven't sent it yet so I'm hoping)..
--
On Dec 27, 2007 2:26 AM, Julian Elischer <[EMAIL PROTECTED]> wrote:
> Resending as my mailer made a dog's breakfast of the first one
> with all sorts of wierd line breaks... hopefully this will be better.
> (I haven't sent it yet so I'm hoping)..
>
>
> ---
>
25 matches
Mail list logo
