> 1. Internal structures are updated to handle SACK, and the stack handles
> the receive side of SACK properly. (The stack advertises itself as SACK
> capable, of course.)
>
> 2. The transmit side of SACK is implemented.
>
> >From what I recall about SACK, the implementation of part 1 would b
On Tue, Mar 09, 2004 at 03:19:58AM -0600, Mike Silbersack wrote:
>
> On Mon, 8 Mar 2004, Brooks Davis wrote:
>
> > I've got a co-worker who is part of a research group at ISI that
> > is doing research on long fat pipes with large streams. They are
> > intrested in doing a SACK implementation.
On Mon, 8 Mar 2004, Brooks Davis wrote:
> I've got a co-worker who is part of a research group at ISI that
> is doing research on long fat pipes with large streams. They are
> intrested in doing a SACK implementation. I hope to have some more
> information later this week.
>
> -- Brooks
In ord
< said:
> I believe that sme of the patches were considerred "experimental and
> just lacked someone to make them production quality. In other cases they
> were not against 'current' and porting them to -curren twas left as "an
> exercise for the reader". No-one who had that ime had a need for th
On Mon, 8 Mar 2004, Kevin Oberman wrote:
> > Date: Mon, 8 Mar 2004 13:22:55 -0800
> > From: Steve Kargl <[EMAIL PROTECTED]>
> >
> > On Mon, Mar 08, 2004 at 12:22:10PM -0800, Brooks Davis wrote:
> > > On Mon, Mar 08, 2004 at 10:24:31AM -0800, Kevin Oberman wrote:
> > > >
> > > > Unfortunately,
one feedback I can provide to this patch...
under [any] interface checks (the loose check mode), if the route
is pointed toward a discard interface (e.g. ds0 in freebsd, Null0 in cisco),
drop the packet.
under cisco, route pointed to null0 creates a null ad
On Mon, Mar 08, 2004 at 01:40:20PM -0800, Kevin Oberman wrote:
> I'm not trying to stat a flame war here, but it is frustrating and this
> initiative for a major network code overhaul makes me hope that
> something will actually happen. It's just that FreeBSD's network stack
> was once the best aro
> Date: Mon, 8 Mar 2004 13:22:55 -0800
> From: Steve Kargl <[EMAIL PROTECTED]>
>
> On Mon, Mar 08, 2004 at 12:22:10PM -0800, Brooks Davis wrote:
> > On Mon, Mar 08, 2004 at 10:24:31AM -0800, Kevin Oberman wrote:
> > >
> > > Unfortunately, SACK is often looked upon as a waste of effort to those
>
On Mon, Mar 08, 2004 at 01:22:55PM -0800, Steve Kargl wrote:
> On Mon, Mar 08, 2004 at 12:22:10PM -0800, Brooks Davis wrote:
> > On Mon, Mar 08, 2004 at 10:24:31AM -0800, Kevin Oberman wrote:
> > >
> > > Unfortunately, SACK is often looked upon as a waste of effort to those
> > > who use nets in m
On Mon, Mar 08, 2004 at 12:22:10PM -0800, Brooks Davis wrote:
> On Mon, Mar 08, 2004 at 10:24:31AM -0800, Kevin Oberman wrote:
> >
> > Unfortunately, SACK is often looked upon as a waste of effort to those
> > who use nets in more commercial forms where aggregation of lots of small
> > streams is
On Mon, Mar 08, 2004 at 10:24:31AM -0800, Kevin Oberman wrote:
> > Date: Sun, 07 Mar 2004 23:50:11 +0100
> > From: Andre Oppermann <[EMAIL PROTECTED]>
> > Sender: [EMAIL PROTECTED]
> >
> > David Malone wrote:
> > >
> > > On Mon, Mar 01, 2004 at 11:18:34PM +0100, Andre Oppermann wrote:
> > > > []
On Mon, Mar 08, 2004 at 05:18:59PM +0100, Andre Oppermann wrote:
> > There has been the "enternal" debate, clean up the stack and/or add features
> > or the resistance to commit the clean up and/or new features.
>
> I think these days are over and I have committed a couple of larger
> changes in t
On Mon, Mar 08, 2004 at 10:24:31AM -0800, Kevin Oberman wrote:
...
> I know that our organization would love to see SACK. Much of the
> high-performance network development that used to be on FreeBSD has
> moved to Linux simply because SACK is essential. You can't run
> trans-oceanic TCP streams of
> Date: Sun, 07 Mar 2004 23:50:11 +0100
> From: Andre Oppermann <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
>
> David Malone wrote:
> >
> > On Mon, Mar 01, 2004 at 11:18:34PM +0100, Andre Oppermann wrote:
> > > [] automatically sizing TCP send buffers to achieve optimal performance
> > >
Mark Tinguely wrote:
>
> > I think these days are over and I have committed a couple of larger
> > changes in the IP code a couple month ago with more to come.
>
> Great, I haven't been in the -current network code for a few months.
>
> Dave Zarzycki <[EMAIL PROTECTED]> posted a SACK / FACK pa
> I think these days are over and I have committed a couple of larger
> changes in the IP code a couple month ago with more to come.
Great, I haven't been in the -current network code for a few months.
Dave Zarzycki <[EMAIL PROTECTED]> posted a SACK / FACK patch for
the 22 Aug 2001 version of c
Mark Tinguely wrote:
>
>
> > > This reminded me - do you know what happened to the plan to implement
> > > SACK for FreeBSD? I'm working with a research group that's interested
> >
> > what plan, there never was one :)
> >
> > cheers
> > luigi (who wrote some FreeBSD SACK code back in 1996!)
> > This reminded me - do you know what happened to the plan to implement
> > SACK for FreeBSD? I'm working with a research group that's interested
>
> what plan, there never was one :)
>
> cheers
> luigi (who wrote some FreeBSD SACK code back in 1996!)
There has been the "enternal" debate,
David Malone wrote:
>
> On Mon, Mar 01, 2004 at 11:18:34PM +0100, Andre Oppermann wrote:
> > [] automatically sizing TCP send buffers to achieve optimal performance
> > over a wide range of bw*delay situations. (in progress)
>
> Hi Andre,
>
> This reminded me - do you know what happened to
On Sun, Mar 07, 2004 at 06:07:56PM +, David Malone wrote:
> On Mon, Mar 01, 2004 at 11:18:34PM +0100, Andre Oppermann wrote:
> > [] automatically sizing TCP send buffers to achieve optimal performance
> > over a wide range of bw*delay situations. (in progress)
>
> Hi Andre,
>
> This rem
On Mon, Mar 01, 2004 at 11:18:34PM +0100, Andre Oppermann wrote:
> [] automatically sizing TCP send buffers to achieve optimal performance
> over a wide range of bw*delay situations. (in progress)
Hi Andre,
This reminded me - do you know what happened to the plan to implement
SACK for FreeB
thank you! :)
i'll try this sometime next week and let you know of any feedbacks i have.
-J
>
> Here you go:
>
> http://www.nrg4u.com/freebsd/ipfw_versrcreach.diff
>
> This one implements the standard functionality, the definition of an
> interface through which it has to be reachable is no
Andre Oppermann wrote:
What else is missing in FreeBSD?
Cannot resist
MPLS?
1/2 :-)
Pete
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Andre Oppermann wrote:
>
> > there are still other things freebsd lacks. such as uRPF that
> > _SERVICE_PROVIDER_
> > can use. ipfw2 has verrevpath but all it does from what i know is strict
> > uRPF
> > only. service providers like myself, if we were to use freebsd boxen
Gleb Smirnoff wrote:
>
> On Thu, Mar 04, 2004 at 12:26:51PM -0500, James wrote:
> J> >that was my thought initially, BUT.. actually... you can
> J> >actually do this no problem using mrtd dumps and pick it up with a
> J> >program via bgp device :P no need to create another api it seems
On Thu, Mar 04, 2004 at 12:26:51PM -0500, James wrote:
J> >that was my thought initially, BUT.. actually... you can
J> >actually do this no problem using mrtd dumps and pick it up with a
J> >program via bgp device :P no need to create another api it seems :)
J>
J> errr??? I meant bpf d
On Thu, 4 Mar 2004, James wrote:
> > J> why inject as_path info from userland to kernel "fib"? may be netflow turning
> > J> into an api that quagga can take advantage of to gather accounting information
> > J> is more feasible?
> >
> > James, can you please describe your idea more understandi
>
> that was my thought initially, BUT.. actually... you can
> actually do this no problem using mrtd dumps and pick it up with a
> program via bgp device :P no need to create another api it seems :)
errr??? I meant bpf device...
>
> -J
>
>
> --
> James Jun
> J>why inject as_path info from userland to kernel "fib"? may be netflow turning
> J>into an api that quagga can take advantage of to gather accounting information
> J>is more feasible?
>
> James, can you please describe your idea more understandible? I can't understand
> your last s
On Wed, Mar 03, 2004 at 01:10:34PM -0500, James wrote:
J> > Currently I'm working on my Netflow implementation, and I have faced the
J> > following problem: I've already got global routing in my routing table, but it
J> > lacks AS (Autonomous System) information. The routing daemon (zebra in my c
> Do you have multiple connectivity to two separate metro area
> exchanges, with multiple upstreams at each?
i dont know about europe, but here in the US, finding transits and
filling up fib with 130K+ routes is easier than ever. welcome to equinix
> Most large cities ar
James wrote:
> rewriting of routing stack and implementing FIB-like structure as what andre
> proposed in this thread is very welcoming.
Just wait a few month and then have a look at what I put up. :-)
> there are still other things freebsd lacks. such as uRPF that
> _SER
hello -
> Is there any plans about integration of BGP routing daemon (Zebra or Quagga)
> into FreeBSD? With BGP routing daemon onboard, FreeBSD will be a strong
> alternative against expensive commercial routers. I have successfull experience
> of running FreeBSD STABLE with 2 full BGP v
On вт, 2004-03-02 at 19:32 +, Bruce M Simpson wrote:
> On Tue, Mar 02, 2004 at 07:09:02PM +0300, Gleb Smirnoff wrote:
> > I do not insist that AS pathes in kernel are good idea. If you show me an
> > other way to get AS information when constructing netflow exports in kernel,
> > I'd be than
At 14:24 02/03/2004, Brad Knowles wrote:
At 3:59 PM +0300 2004/03/02, Gleb Smirnoff wrote:
Haven't you understand? I'm the "person who has real-world experience
in running zebra in ISP environments with multiple upstreams and taking
full views".
Do you have multiple connectivity to two
On Tue, Mar 02, 2004 at 02:16:13PM -0800, Randy Bush wrote:
R> > I do not insist that AS pathes in kernel are good idea. If you
R> > show me an other way to get AS information when constructing
R> > netflow exports in kernel, I'd be thankful.
R>
R> do we need to rediscover why flow export places a
> I do not insist that AS pathes in kernel are good idea. If you
> show me an other way to get AS information when constructing
> netflow exports in kernel, I'd be thankful.
do we need to rediscover why flow export places a large processor
burden on criscos, junipers, prockets, ...?
randy
__
Hello!
On Wed, Mar 03, 2004 at 03:40:22AM +0600, Max Khon wrote:
> > The patch set is pretty extensive and intrusive and only for 4.x. Adding
> > locking for 5.x would be a pretty nice challenge as well and not easy to
> > get right for all cases.
> >
> > > This is one thing that I would like t
Hello!
On Tue, Mar 02, 2004 at 10:13:05PM +0100, Andre Oppermann wrote:
> The patch set is pretty extensive and intrusive and only for 4.x. Adding
> locking for 5.x would be a pretty nice challenge as well and not easy to
> get right for all cases.
>
> > This is one thing that I would like to u
Bruce M Simpson wrote:
>
> On Tue, Mar 02, 2004 at 07:09:02PM +0300, Gleb Smirnoff wrote:
> > I do not insist that AS pathes in kernel are good idea. If you show me an
> > other way to get AS information when constructing netflow exports in kernel,
> > I'd be thankful. I'd be also thankful if yo
James Read wrote:
>
> > I still have in mind that I would like to see vimage[1] in HEAD one day
> > ... I think it would be a pretty cool feature to have. If one can keep
> > this in mind when doing greater modelling on the network stack it
> > might help the one who will - at some time - find the
"Bjoern A. Zeeb" wrote:
>
> On Mon, 1 Mar 2004, Andre Oppermann wrote:
>
> Hi,
>
> > I put this up for coordination and cooperation in my planned work on the
> > FreeBSD networking system. This is my todo list of things I want to do
> > from now through summer 04. If you are or intend to work
Bruce M Simpson wrote:
>
> I'm open to bringing it on board as a port, but I don't feel that carrying
> a BGP daemon around in the base system is in the best interests of the
> Project or our user base.
I share that opinion. A bgpd doesn't have any business in the base tree.
> > The last time I
On Tuesday 02 March 2004 20:06, James Read wrote:
> > I still have in mind that I would like to see vimage[1] in HEAD one
> > day ... I think it would be a pretty cool feature to have. If one
> > can keep this in mind when doing greater modelling on the network
> > stack it might help the one who w
Gleb Smirnoff wrote (on Mar 02):
> Currently I'm working on my Netflow implementation, and I have faced the
> following problem: I've already got global routing in my routing table, but it
> lacks AS (Autonomous System) information. The routing daemon (zebra in my case)
> already knows ASes, but
On Tue, 2 Mar 2004, Brad Knowles wrote:
> > What's difference (*currently*) beetwen FreeBSD+Zebra and Cisco routers?
> Support for VRRP? Support for various other routing protocols
> not covered by zebra/quagga -- at least not yet, if ever? Support
> for line cards and other devices that d
On Tue, Mar 02, 2004 at 03:14:06PM +0100, Andre Oppermann wrote:
> > I've been fielding suggestions from individuals who feel using a multi-bit
> > trie might be more suitable for achieving higher PPS rates.
>
> Yes. Which one should not matter. I want to make an API for the IPv4
> routing code.
On Tue, Mar 02, 2004 at 02:36:50PM +0100, Brad Knowles wrote:
[snip]
> Oh, and then there are all the operational issues where
> zebra/quagga can't keep sessions going when a neighbor flaps, etc
> Those would require re-architecting the whole routing system, at
> which point it might m
On Tue, Mar 02, 2004 at 07:09:02PM +0300, Gleb Smirnoff wrote:
> I do not insist that AS pathes in kernel are good idea. If you show me an
> other way to get AS information when constructing netflow exports in kernel,
> I'd be thankful. I'd be also thankful if you describe how policy routing can
> I still have in mind that I would like to see vimage[1] in HEAD one day
> ... I think it would be a pretty cool feature to have. If one can keep
> this in mind when doing greater modelling on the network stack it
> might help the one who will - at some time - find the time to
> ingtegrate it.
>
>
On Mon, 1 Mar 2004, Andre Oppermann wrote:
Hi,
> I put this up for coordination and cooperation in my planned work on the
> FreeBSD networking system. This is my todo list of things I want to do
> from now through summer 04. If you are or intend to work on one of these
> please step forward so
[in response to off-list mail]
On Tue, Mar 02, 2004 at 03:58:44PM +, Bruce M Simpson wrote:
> On Tue, Mar 02, 2004 at 01:07:58PM +0100, Brad Knowles wrote:
> > If anything, I'd be inclined to look towards his work for OpenBSD
> > and see if that could be imported into FreeBSD (and maybe i
>> You need GigE, T1/E1, E3/T3 and STM-1 these days. Everything
>> else is dead.
> From what I understand from Henning, he's going to be dumping
> E-1/T-1, E3-T3, and probably also STM-1, because you can't get
> those kinds of interfaces for regular PC-type boxes. I'm not
> sure I agree with hi
< said:
> routed we support largely out of nostalgia, I guess.
Modern routed does more than just RIP; it's responsible for all sorts
of routing-table management tasks that we mostly just pretend don't
exist (e.g., responding to RTM_LOSING messages).
-GAWollman
__
Andre,
On Tue, Mar 02, 2004 at 03:34:54PM +0100, Andre Oppermann wrote:
A> > B> As to the second part of your mail: That sounds like a reasonable suggestion,
A> > B> I am sure Andre and others are paying attention to this and will take it on
A> > B> board when an implementation is nearer.
A> >
On Tue, Mar 02, 2004 at 01:07:58PM +0100, Brad Knowles wrote:
[..]
> His only issue with using exclusively PC equipment for handling
> routing is all those strange WAN protocols and cards for which
> hardware cards are rarely available beyond vendors like cisco or
> Juniper. That's why he
At 4:18 PM +0100 2004/03/02, Andre Oppermann wrote:
I'd like to see you do any real work in this area instead of
producing many and longs emails with lots of mis-informed rants
in them. Yes, this my official put-up-or-shut-up call to you.
I'm not a programmer. I haven't done anything that I
At 4:08 PM +0100 2004/03/02, Andre Oppermann wrote:
Gleb is doing the same, and so am I. However you are not. Do you
run BGP in your network?
I'm not running an ISP that is multiply connected to at least two
metro-area NAPs and has multiple upstreams at both sites, no. I
would be very inte
> TCP buffer sizing involves mainly two areas. One is good RTT
> measurements to be able to estimate the bw*delay product well and the
> other is information about memory (mbuf) usage in the networking
> system to do the right thing if memory gets low.
Why try to measure the bw*delay? Why not u
At 3:59 PM +0100 2004/03/02, Andre Oppermann wrote:
Zebra is definatly *not* a piece of s*** as you make it sound here.
Well, that was certainly the impression I got from Henning Brauer
at FOSDEM. Maybe I misunderstood him, or maybe he has different
views on this software than you do. To pro
Brooks Davis wrote:
>
> On Tue, Mar 02, 2004 at 03:00:15PM +0100, Andre Oppermann wrote:
> > Brooks Davis wrote:
> > >
> > > On Tue, Mar 02, 2004 at 10:37:41AM +0900, Lars Eggert wrote:
> > > > Hi,
> > > >
> > > > Wes Peters wrote:
> > > > >On Monday 01 March 2004 14:18, Andre Oppermann wrote:
> >
Ian Smith wrote:
>
> [-current out of ccs, I'm not subscribed]
>
> On Tue, 2 Mar 2004, Andre Oppermann wrote to Wes Peters:
>
> > > Wowsers. I can't wait to hear more. When do you expect to have a design
> > > for the ARP stuff and TCP buffer sizing, since they are underway?
> >
> > The AR
David Gilbert wrote:
>
> > "Andre" == Andre Oppermann <[EMAIL PROTECTED]> writes:
>
> Andre> [] move IPv4 routing to its own optimized routing table
> Andre> structure and add multi-path and policy-routing options.
> Andre> (planned)
>
> Andre> [] profile (don't speculate) common network s
Brad Knowles wrote:
>
> At 3:52 PM +0200 2004/03/02, Andrew Degtiariov wrote:
>
> >> Oh, and then there are all the operational issues where
> >> zebra/quagga can't keep sessions going when a neighbor flaps, etc
> >> Those would require re-architecting the whole routing system, at
> >
On Tuesday 02 March 2004 13:07, Brad Knowles wrote:
> At 11:26 AM +0300 2004/03/02, Gleb Smirnoff wrote:
> >Is there any plans about integration of BGP routing daemon (Zebra
> > or Quagga) into FreeBSD? With BGP routing daemon onboard, FreeBSD
> > will be a strong alternative against expensive
Brad Knowles wrote:
>
> At 3:59 PM +0300 2004/03/02, Gleb Smirnoff wrote:
>
> > Haven't you understand? I'm the "person who has real-world experience
> > in running zebra in ISP environments with multiple upstreams and taking
> > full views".
>
> IIRC, he's also got some pretty big c
Brad Knowles wrote:
>
> At 11:26 AM +0300 2004/03/02, Gleb Smirnoff wrote:
>
> >Is there any plans about integration of BGP routing daemon (Zebra or
> > Quagga) into FreeBSD? With BGP routing daemon onboard, FreeBSD will be
> > a strong alternative against expensive commercial routers. I ha
On Tue, Mar 02, 2004 at 03:00:15PM +0100, Andre Oppermann wrote:
> Brooks Davis wrote:
> >
> > On Tue, Mar 02, 2004 at 10:37:41AM +0900, Lars Eggert wrote:
> > > Hi,
> > >
> > > Wes Peters wrote:
> > > >On Monday 01 March 2004 14:18, Andre Oppermann wrote:
> > > >
> > > >>[] establish a testbed fo
[-current out of ccs, I'm not subscribed]
On Tue, 2 Mar 2004, Andre Oppermann wrote to Wes Peters:
> > Wowsers. I can't wait to hear more. When do you expect to have a design
> > for the ARP stuff and TCP buffer sizing, since they are underway?
>
> The ARP stuff is pretty simple and is a h
Gleb Smirnoff wrote:
>
> On Tue, Mar 02, 2004 at 09:28:25AM +, Bruce M Simpson wrote:
> B> However, not including an OSPF/BGP daemon doesn't preclude us from ensuring
> B> that APIs which are exposed for advanced routing functionality (multipath,
> B> etc) do the right thing across the board,
Bruce M Simpson wrote:
>
> However, not including an OSPF/BGP daemon doesn't preclude us from ensuring
> that APIs which are exposed for advanced routing functionality (multipath,
> etc) do the right thing across the board, are well defined, etc.
>
> As to the second part of your mail: That sound
Gleb Smirnoff wrote:
>
> Dear sirs,
>
> On Tue, Mar 02, 2004 at 04:29:57AM +, Bruce M Simpson wrote:
> B> > > > add multi-path and policy-routing options. (planned)
> B> >
> B> >would the policy-routing optioned table sort of similar to VRF's or
> B> >different routing instance
Bruce M Simpson wrote:
>
> On Mon, Mar 01, 2004 at 10:16:25PM -0500, James wrote:
> > > > [] move IPv4 routing to its own optimized routing table structure and
> >
> > finally it's about time :)
>
> I've been fielding suggestions from individuals who feel using a multi-bit
> trie might b
James wrote:
>
> > > [] move IPv4 routing to its own optimized routing table structure and
>
> finally it's about time :)
>
> > > add multi-path and policy-routing options. (planned)
>
> would the policy-routing optioned table sort of similar to VRF's or
> differ
At 3:52 PM +0200 2004/03/02, Andrew Degtiariov wrote:
Oh, and then there are all the operational issues where
zebra/quagga can't keep sessions going when a neighbor flaps, etc
Those would require re-architecting the whole routing system, at
Brooks Davis wrote:
>
> On Tue, Mar 02, 2004 at 10:37:41AM +0900, Lars Eggert wrote:
> > Hi,
> >
> > Wes Peters wrote:
> > >On Monday 01 March 2004 14:18, Andre Oppermann wrote:
> > >
> > >>[] establish a testbed for testing and qualification of TCP performance
> > >> and optimizations over a wi
Wes Peters wrote:
>
> > [] automatically sizing TCP send buffers to achieve optimal performance
> > over a wide range of bw*delay situations. (in progress)
>
> What a wonderful idea. Can't wait for the bikesheds...
What bikesheds?
> > [] establish a testbed for testing and qualification
On Tue, Mar 02, 2004 at 02:36:50PM +0100, Brad Knowles wrote:
> At 11:02 AM +0200 2004/03/02, Andrew Degtiariov wrote:
>
> > What's difference (*currently*) beetwen FreeBSD+Zebra and Cisco routers?
>
> Support for VRRP? Support for various other routing protocols
> not covered by zebra/qu
At 11:02 AM +0200 2004/03/02, Andrew Degtiariov wrote:
What's difference (*currently*) beetwen FreeBSD+Zebra and Cisco routers?
Support for VRRP? Support for various other routing protocols
not covered by zebra/quagga -- at least not yet, if ever? Support
for line cards and other devices tha
At 3:59 PM +0300 2004/03/02, Gleb Smirnoff wrote:
Haven't you understand? I'm the "person who has real-world experience
in running zebra in ISP environments with multiple upstreams and taking
full views".
Do you have multiple connectivity to two separate metro area
exchanges, with multiple u
On Tue, Mar 02, 2004 at 01:07:58PM +0100, Brad Knowles wrote:
B> > Is there any plans about integration of BGP routing daemon (Zebra or
B> > Quagga) into FreeBSD? With BGP routing daemon onboard, FreeBSD will be
B> > a strong alternative against expensive commercial routers. I have
B> > successfu
At 11:26 AM +0300 2004/03/02, Gleb Smirnoff wrote:
Is there any plans about integration of BGP routing daemon (Zebra or
Quagga) into FreeBSD? With BGP routing daemon onboard, FreeBSD will be
a strong alternative against expensive commercial routers. I have
successfull experience of running F
On Tue, Mar 02, 2004 at 09:28:25AM +, Bruce M Simpson wrote:
B> However, not including an OSPF/BGP daemon doesn't preclude us from ensuring
B> that APIs which are exposed for advanced routing functionality (multipath,
B> etc) do the right thing across the board, are well defined, etc.
Yes, thi
On Tue, Mar 02, 2004 at 11:55:56AM +0300, Gleb Smirnoff wrote:
> Read on my previous mail pls. I'm speaking of some changes that require
> altering both FreeBSD and routing daemon. Currently I'm thinking of AS path
> only, but in future some other issues can appear. Routing daemon should be close
>
On вт, 2004-03-02 at 11:26 +0300, Gleb Smirnoff wrote:
Hi
> Currently I'm working on my Netflow implementation, and I have faced the
> following problem: I've already got global routing in my routing table, but it
> lacks AS (Autonomous System) information. The routing daemon (zebra in my case)
On Tue, Mar 02, 2004 at 12:43:21AM -0800, Kris Kennaway wrote:
> On Tue, Mar 02, 2004 at 11:26:25AM +0300, Gleb Smirnoff wrote:
> > Dear sirs,
> >
> > On Tue, Mar 02, 2004 at 04:29:57AM +, Bruce M Simpson wrote:
> > B> > > > add multi-path and policy-routing options. (planned)
> > B> >
On Tue, Mar 02, 2004 at 12:43:21AM -0800, Kris Kennaway wrote:
K> > B> That's the plan, I believe, anyway... It would be nice if Quagga could be
K> > B> taught about how to add TCP-MD5 keys to both FreeBSD and OpenBSD SADBs.
K> >
K> > Is there any plans about integration of BGP routing daemon (Z
On Tue, Mar 02, 2004 at 11:26:25AM +0300, Gleb Smirnoff wrote:
> Dear sirs,
>
> On Tue, Mar 02, 2004 at 04:29:57AM +, Bruce M Simpson wrote:
> B> > > > add multi-path and policy-routing options. (planned)
> B> >
> B> > would the policy-routing optioned table sort of similar to VRF's o
Dear sirs,
On Tue, Mar 02, 2004 at 04:29:57AM +, Bruce M Simpson wrote:
B> > > > add multi-path and policy-routing options. (planned)
B> >
B> >would the policy-routing optioned table sort of similar to VRF's or
B> >different routing instances that could potentially be tied to u
On 1 Mar, Andre Oppermann wrote:
> [] move ARP out of the routing table and instantiate it once per ethernet
> broadcast domain. (started)
Applause!
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsub
On Mon, Mar 01, 2004 at 10:16:25PM -0500, James wrote:
> > > [] move IPv4 routing to its own optimized routing table structure and
>
> finally it's about time :)
I've been fielding suggestions from individuals who feel using a multi-bit
trie might be more suitable for achieving higher PP
> > [] move IPv4 routing to its own optimized routing table structure and
finally it's about time :)
> > add multi-path and policy-routing options. (planned)
would the policy-routing optioned table sort of similar to VRF's or
different routing instances that could
On Tue, Mar 02, 2004 at 10:57:38AM +0900, CHOI Junho wrote:
> From: Wes Peters <[EMAIL PROTECTED]>
> Subject: Re: My planned work on networking stack
> Date: Mon, 1 Mar 2004 15:07:52 -0800
>
> > On Monday 01 March 2004 14:18, Andre Oppermann wrote:
> > > Hi a
From: Wes Peters <[EMAIL PROTECTED]>
Subject: Re: My planned work on networking stack
Date: Mon, 1 Mar 2004 15:07:52 -0800
> On Monday 01 March 2004 14:18, Andre Oppermann wrote:
> > Hi all,
> >
> > [] automatically sizing TCP send buffers to achieve optimal performanc
On Tue, Mar 02, 2004 at 10:37:41AM +0900, Lars Eggert wrote:
> Hi,
>
> Wes Peters wrote:
> >On Monday 01 March 2004 14:18, Andre Oppermann wrote:
> >
> >>[] establish a testbed for testing and qualification of TCP performance
> >> and optimizations over a wide range of network conditions (types,
Lars Eggert wrote:
this sounds like something you could do with planetlab
(http://planet-lab.org/). Do you have access? (Or maybe I misunderstood
what you meant by "testbed".)
Argh. Yes, it runs Linux. Yes, I'm jet lagged. (But there was some talk
about running something else on planetlab at som
Hi,
Wes Peters wrote:
On Monday 01 March 2004 14:18, Andre Oppermann wrote:
[] establish a testbed for testing and qualification of TCP performance
and optimizations over a wide range of network conditions (types,
speeds, packet loss ratios, out of order, etc). (started)
Be sure to coordin
On Monday 01 March 2004 14:18, Andre Oppermann wrote:
> Hi all,
>
> I put this up for coordination and cooperation in my planned work on the
> FreeBSD networking system. This is my todo list of things I want to do
> from now through summer 04. If you are or intend to work on one of these
> please
98 matches
Mail list logo
