Bjoern A. Zeeb wrote:
On Tue, 6 May 2008, Julian Elischer wrote:
Hi,
Bjoern A. Zeeb wrote:
On Tue, 29 Apr 2008, Julian Elischer wrote:
Hi,
The patch can be found at
http://www.freebsd.org/~julian/mrt.diff
(or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6)
or source can be taken fr
On Tue, 6 May 2008, Julian Elischer wrote:
Hi,
Bjoern A. Zeeb wrote:
On Tue, 29 Apr 2008, Julian Elischer wrote:
Hi,
The patch can be found at
http://www.freebsd.org/~julian/mrt.diff
(or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6)
or source can be taken from perforce at:
//depot
Bjoern A. Zeeb wrote:
On Tue, 29 Apr 2008, Julian Elischer wrote:
Hi,
The patch can be found at
http://www.freebsd.org/~julian/mrt.diff
(or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6)
or source can be taken from perforce at:
//depot/user/julian/routing/src
So after looking at the
On Tue, 29 Apr 2008, Julian Elischer wrote:
Hi,
The patch can be found at
http://www.freebsd.org/~julian/mrt.diff
(or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6)
or source can be taken from perforce at:
//depot/user/julian/routing/src
So after looking at the patch a bit more again
On Tue, 29 Apr 2008, Julian Elischer wrote:
Hi,
a kernel needs to be created with the option ROUTETABLES=N
e.g.
+optionsROUTETABLES=2 # max 16. 1 is back
compatible.
leaving this out will result in just a single routing table as per normal.
the max is 16 but I hav
John Hay wrote:
You don't need to go to the kernel for this sort of thing unless you
specifically need to implement route policy based on which interface(s)
a packet came in on.
Yes I know that. But in the world of adhoc wireless mesh networking
there are very few non-linux people, so the
Julian Elischer wrote:
OLSR is an overlay network
Nope -- the express intention was that it could be used for basic IP
connectivity, for mobile devices. In OLSR, every node is a potential IP
forwarder unless it explicitly advertises itself as being unwilling to
forward.
and any machine th
Julian Elischer wrote:
John Hay wrote:
This confuses me
The whole point of a FIB is to decide the *next* hop for a
given input packet. So questions.
1) A packet arrives on an interface. If this interface is
associated with more than one FIB, which FIB does it get
given to?
which ever
John Hay wrote:
This confuses me
The whole point of a FIB is to decide the *next* hop for a
given input packet. So questions.
1) A packet arrives on an interface. If this interface is
associated with more than one FIB, which FIB does it get
given to?
which ever one you select, using t
On Fri, May 02, 2008 at 04:44:20PM +0100, Bruce M. Simpson wrote:
> John Hay wrote:
> >The linux guys seems to have multiple fibs (or whatever they call them)
> >which they can chain together by giving them different priorities. The
> >effect seems to be that a packet will be matched through the hi
John Hay wrote:
The linux guys seems to have multiple fibs (or whatever they call them)
which they can chain together by giving them different priorities. The
effect seems to be that a packet will be matched through the highest
priority fib to the lowest until a route match is found en then is us
> >This confuses me
> >
> >The whole point of a FIB is to decide the *next* hop for a
> >given input packet. So questions.
> >1) A packet arrives on an interface. If this interface is
> > associated with more than one FIB, which FIB does it get
> > given to?
> >
>
> which ever one you sel
> Date: Wed, 30 Apr 2008 10:25:51 -0700
> From: Julian Elischer <[EMAIL PROTECTED]>
>
> Bruce M Simpson wrote:
> > Julian Elischer wrote:
> >> An interface may however be present in entries from multiple FIBs
> >> in which case the INCOMING packets on that interface need to
> >> be disambiguated w
On Wed, 30 Apr 2008 18:56:07 BST "Bruce M. Simpson" <[EMAIL PROTECTED]> wrote:
> > 2) If that decision is taken by a a packet 'classifier',
> >isn't it in effect doing the job of a FIB (deciding the
> >next hop, which happens to be a local FIB)? Recall that
> >basically a packet passe
Bruce M Simpson wrote:
Julian Elischer wrote:
what's SSM?
Source-specific multicast, where multicast flows (channels) are
identified by both their original source address, and group address.
Multicast addresses have no meaning on their own beyond the scope of a
single link.
I haven't ch
Bruce M. Simpson wrote:
Bakul Shah wrote:
1) A packet arrives on an interface. If this interface is
associated with more than one FIB, which FIB does it get
given to?
If you only have a single FIB, there is no issue here.
If you have multiple FIBs, the decision gets made by the class
Bakul Shah wrote:
On Tue, 29 Apr 2008 13:42:03 PDT Julian Elischer <[EMAIL PROTECTED]> wrote:
Interfaces are not however assigned to FIB instance. each FIB may
contain entries for each interface, and by default they do, but you
can delete teh entries associated with a particular interface from
Julian Elischer wrote:
what's SSM?
Source-specific multicast, where multicast flows (channels) are
identified by both their original source address, and group address.
Multicast addresses have no meaning on their own beyond the scope of a
single link.
I haven't changed any of that.. Basi
Bruce M. Simpson wrote:
Wouldn't it make sense to treat each alias as on a separate
logical interface? Then each logical interface belongs to
exactly one FIB. On input you decide which logical inteface
a packet arrived on by looking at its destination MAC
address. That reduces confusion quite
Bakul Shah wrote:
1) A packet arrives on an interface. If this interface is
associated with more than one FIB, which FIB does it get
given to?
If you only have a single FIB, there is no issue here.
If you have multiple FIBs, the decision gets made by the classifier.
2) If that decis
On Tue, 29 Apr 2008 13:42:03 PDT Julian Elischer <[EMAIL PROTECTED]> wrote:
>
> Interfaces are not however assigned to FIB instance. each FIB may
> contain entries for each interface, and by default they do, but you
> can delete teh entries associated with a particular interface from
> a particu
Bruce M Simpson wrote:
Julian Elischer wrote:
An interface may however be present in entries from multiple FIBs
in which case the INCOMING packets on that interface need to
be disambiguated with respect to which FIB they belong to.
Yes, there is no way the forwarding code alone can do this.
I
> Date: Tue, 29 Apr 2008 12:17:15 -0700
> From: Julian Elischer <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
>
> Kevin Oberman wrote:
> >> Date: Tue, 29 Apr 2008 00:44:18 -0700
> >> From: Julian Elischer <[EMAIL PROTECTED]>
> >> Sender: [EMAIL PROTECTED]
> >>
> >> The patch can be found at
> >>
> Date: Tue, 29 Apr 2008 00:44:18 -0700
> From: Julian Elischer <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
>
> The patch can be found at
> http://www.freebsd.org/~julian/mrt.diff
> (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6)
>
> or source can be taken from perforce at:
>
Julian Elischer wrote:
An interface may however be present in entries from multiple FIBs
in which case the INCOMING packets on that interface need to
be disambiguated with respect to which FIB they belong to.
Yes, there is no way the forwarding code alone can do this.
It should not be expected
Bruce M. Simpson wrote:
Julian Elischer wrote:
A general purpose OS is a different beast as it has no physical
equivalent of the FIB. It may have multiple routing tables, though, to
I think setrib would be a term less likely to cause confusion then
setfib even though, in the case of your FreeBS
Julian Elischer wrote:
A general purpose OS is a different beast as it has no physical
equivalent of the FIB. It may have multiple routing tables, though, to
I think setrib would be a term less likely to cause confusion then
setfib even though, in the case of your FreeBSD patches, it's really
bo
Kevin Oberman wrote:
Date: Tue, 29 Apr 2008 00:44:18 -0700
From: Julian Elischer <[EMAIL PROTECTED]>
Sender: [EMAIL PROTECTED]
The patch can be found at
http://www.freebsd.org/~julian/mrt.diff
(or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6)
or source can be taken from perforce at
28 matches
Mail list logo
