Request for comments

Request for comments

[Cornel Ciocirlan]

Hi, 

I was thinking of starting a project to implement a Cisco-like
"NetFlow" architecture for Linux. This would be relevant for edge routers
and/or network monitoring devices.  

What this would do is keep a "cache" of all the "flows" that are passing
through the system; a flow is defined as the set of packets that have the
same headers - or header fields. For example we could choose "ip source,
ip destination, ip protocol, ip source port [if relevant], ip destination
port [ if relevant ], and maintain a cache of all distinct such
"flows" that pass through the system. The flows would have to be
"expired" from the cache (LRU) and there should be a limit on the size of
the cache.

What can we use the cache for: 

a) more efficient packet filtering. After a cache entry is created for a
flow,  we apply the ACLs for the packet and associate the action with the
flow. All subsequent packets belonging to the same flow will be
dropped/accepted without re-appying the packet filtering rules
b) traffic statistics. When expiring a flow in the cache we could send a
special "messagge" to a user-space process with the 
	* flow caracteristics (ip src,ip dest etc)
	* total number of packets that were associated with this flow
	* flow start timestamp, flow last-activity timestamp
	* avg pkts/second while the flow was active
	* total bytes transmitted for this flow 
c) we could make routing decisions by looking at the flow cache, eg when 
  we first create the flow we look into the routing table and save the 
  index of the output interface in the flow cache. Subsequent packets
  matching the flow will not  cause a search through the routing table. 
d) prevent denial-of-service by configuring for example automatic
filtering of a flow that matches more than some-high-value pps (Most flows
will probably be 1000 pps max, while packet floods can be 5k-25k easily)

Problems: 
- some overhead will be added, however if we implement a) and c) above we
can reduce it. d) will also make the system perform better under high
load.
- we need to come up with a pretty efficient data structure to search
through it very quickly - if we route 20k pps, too much overhead will kill
us. I was thinking of a hash table with AVL trees instead of linked lists,
which I think the buffer cache is using; other options: splay trees maybe
useful ?)
- in all cases we'll need something like an expiry thread that actively
removes inactive flows from the cache 

Is it useful at all ? Point b) above could be implemented in userspace
(Actually I've done a basic skeleton a while ago). Are the others worth
the trouble ?

What do you gurus think ?

Kind regards,
Cornel.

Re: Request for comments

[Crutcher Dunnavant]

++ 19/07/01 18:44 +0300 - Cornel Ciocirlan:
> a) more efficient packet filtering. After a cache entry is created for a
> flow,  we apply the ACLs for the packet and associate the action with the
> flow. All subsequent packets belonging to the same flow will be
> dropped/accepted without re-appying the packet filtering rules

I'm seeing an identification problem arise here. You have to be able to
identify packets in a flow robustly, and you have to be able to spot packets
trying to fake it. I dont see any way in which you will be able to avoid
the packet filtering rules here.

-- 
Crutcher        <crutcher@datastacks.com>
GCS d--- s+:>+:- a-- C++++$ UL++++$ L+++$>++++ !E PS+++ PE Y+ PGP+>++++
    R-(+++) !tv(+++) b+(++++) G+ e>++++ h+>++ r* y+>*$

Re: Request for comments

[Francois Romieu]

Cornel Ciocirlan <ctrl@rdsnet.ro> ecrit :
[heavy linux networking rewrite in sight]
> Is it useful at all ? Point b) above could be implemented in userspace
> (Actually I've done a basic skeleton a while ago). Are the others worth
> the trouble ?
> 
> What do you gurus think ?

* Are you sure of where the cycles are spent when routing >> 20kpps ?
I have always been told that the lack of polling/batch processing kills
the software router. 
* What against the (not widely used) CONFIG_NET_FASTROUTE ?
* <mantra> mpls is good </mantra> Did you browse mpls at www.ietf.org
(and sourceforge for the current state of mpls-linux) ?
* IANAG but it looks like a wait for 2.5 project btw.

-- 
Ueimor

Re: Request for comments

[jlnance]

On Thu, Jul 19, 2001 at 06:44:52PM +0300, Cornel Ciocirlan wrote:

> What this would do is keep a "cache" of all the "flows" that are passing
> through the system; a flow is defined as the set of packets that have the
> same headers - or header fields. For example we could choose "ip source,
> ip destination, ip protocol, ip source port [if relevant], ip destination
> port [ if relevant ], and maintain a cache of all distinct such
> "flows" that pass through the system. The flows would have to be
> "expired" from the cache (LRU) and there should be a limit on the size of
> the cache.

This sounds a lot like what MPLS does.  I believe that someone has MPLS
patches for the kernel, but I dont know who.  You might want to find them
and take a look.

Jim

Re: Request for comments

[Andi Kleen]

Cornel Ciocirlan <ctrl@rdsnet.ro> writes:

> Hi, 
> 
> I was thinking of starting a project to implement a Cisco-like
> "NetFlow" architecture for Linux. This would be relevant for edge routers
> and/or network monitoring devices.  

Linux 2.1+ already has such a cache in form of the rtcache since several
years.

-Andi

Re: Request for comments

[Jakob Østergaard]

On Thu, Jul 19, 2001 at 07:33:02PM +0200, Andi Kleen wrote:
> Cornel Ciocirlan <ctrl@rdsnet.ro> writes:
> 
> > Hi, 
> > 
> > I was thinking of starting a project to implement a Cisco-like
> > "NetFlow" architecture for Linux. This would be relevant for edge routers
> > and/or network monitoring devices.  
> 
> Linux 2.1+ already has such a cache in form of the rtcache since several
> years.

NeTraMet is a project that will give you NetFlow-like data.  You set up traffic
meters on your routers, and gather data centrally from the meters using SNMP.

Works great.

See: http://www2.auckland.ac.nz/net/Accounting/ntm.Release.note.html

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

Request for Comments

[Jan Willem Stumpel]

I'm trying to make a 'dosemu for dummies' that I'd like to hear
the opinion of the experts about.

www.jw-stumpel.nl/dosemu.html

Regards, Jan

Request for comments

[Barclay Jameson]

When reading code for libcephfs.cc (giant branch) it wasn't apparent
to me for the lines 95 and lines 101 what the return values was
expected from the function calls init and mount other than 0.

It was only after tracing a bit of code did I see that error code such
as: -ENOENT and -EEXIST could be returned as well.

It would be awesome if comments were added for these functions to show
what the expected return values are going to be for these functions.

Thanks,

almightybeeij

Re: Request for comments

[John Spray]

We do have a lot of functions that bubble up standard error numbers --
in general callers of these functions have to accommodate the
possibility of any error code (including errors they don't
understand).  I notice that ::mount is a bit unusual in additionally
having some explicit 'magic' return codes to indicate which stage of
init failed.

A pull request to document the magic -1001, -1002 etc returns from
that function would be welcome, it might not be useful to try and
enumerate all possible error numbers for all API calls though -- it
could be hard to prove that the list was comprehensive, and callers
should always handle unexpected codes too.

Cheers,
John

On Fri, Oct 10, 2014 at 5:22 PM, Barclay Jameson
<almightybeeij@gmail.com> wrote:
> When reading code for libcephfs.cc (giant branch) it wasn't apparent
> to me for the lines 95 and lines 101 what the return values was
> expected from the function calls init and mount other than 0.
>
> It was only after tracing a bit of code did I see that error code such
> as: -ENOENT and -EEXIST could be returned as well.
>
> It would be awesome if comments were added for these functions to show
> what the expected return values are going to be for these functions.
>
> Thanks,
>
> almightybeeij
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Request for comments

[Duncan Roe]

Hi Florian,

Recently I submitted patch series
https://patchwork.ozlabs.org/project/netfilter-devel/list/?series=407990 which
converts libnetfilter_queue to not need libnfnetlink.

The series re-implements all the libnfnetlink-wrapper functions so they use
functions from libmnl. I understand from previous correspondence that you had a
shot at doing the same thing a while back. With that in mind, would you be able
to find the time to take a look at the series and comment on it?

Additionally, the series re-implements the nlif_* functions from libnfnetlink.
conntrack-tools and ulogd also use these functions, so I wonder if they belong
in libmnl. Would you have an opinion on that?

Please disregard my use of kernel headers - I now understand the idea of cached
headers is to be able to do standalone builds without them. v3 would fix that.

Cheers ... Duncan.

Re: Request for comments

[Pablo Neira Ayuso]

Hi Duncan,

On Mon, Sep 02, 2024 at 03:38:59PM +1000, Duncan Roe wrote:
> Hi Florian,
> 
> Recently I submitted patch series
> https://patchwork.ozlabs.org/project/netfilter-devel/list/?series=407990 which
> converts libnetfilter_queue to not need libnfnetlink.
> 
> The series re-implements all the libnfnetlink-wrapper functions so they use
> functions from libmnl. I understand from previous correspondence that you had a
> shot at doing the same thing a while back. With that in mind, would you be able
> to find the time to take a look at the series and comment on it?
> 
> Additionally, the series re-implements the nlif_* functions from libnfnetlink.
> conntrack-tools and ulogd also use these functions, so I wonder if they belong
> in libmnl. Would you have an opinion on that?
> 
> Please disregard my use of kernel headers - I now understand the idea of cached
> headers is to be able to do standalone builds without them. v3 would fix that.

I have huge concerns this will break existing applications for the
benefit of nothing? Because other existing libraries rely on
libnfnetlink.

Unless he finds a way to carefully sends us patches to incrementally
move to libmnl.

I think it is more sensible to extend the new API to fill the missing
gaps, I remember people mentioned it is too low level. With a few
helper function it should be possible to make it as easy to use for
simple applications a libnetfilter_queue.