public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Request for comments
@ 2001-07-19 15:44 Cornel Ciocirlan
  2001-07-19 16:30 ` Crutcher Dunnavant
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Cornel Ciocirlan @ 2001-07-19 15:44 UTC (permalink / raw)
  To: linux-kernel

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.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Request for comments
  2001-07-19 15:44 Cornel Ciocirlan
@ 2001-07-19 16:30 ` Crutcher Dunnavant
  2001-07-19 17:24 ` Francois Romieu
  2001-07-19 17:29 ` jlnance
  2 siblings, 0 replies; 6+ messages in thread
From: Crutcher Dunnavant @ 2001-07-19 16:30 UTC (permalink / raw)
  To: linux-kernel

++ 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+>*$

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Request for comments
  2001-07-19 15:44 Cornel Ciocirlan
  2001-07-19 16:30 ` Crutcher Dunnavant
@ 2001-07-19 17:24 ` Francois Romieu
  2001-07-19 17:29 ` jlnance
  2 siblings, 0 replies; 6+ messages in thread
From: Francois Romieu @ 2001-07-19 17:24 UTC (permalink / raw)
  To: Cornel Ciocirlan; +Cc: linux-kernel

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Request for comments
  2001-07-19 15:44 Cornel Ciocirlan
  2001-07-19 16:30 ` Crutcher Dunnavant
  2001-07-19 17:24 ` Francois Romieu
@ 2001-07-19 17:29 ` jlnance
  2 siblings, 0 replies; 6+ messages in thread
From: jlnance @ 2001-07-19 17:29 UTC (permalink / raw)
  To: linux-kernel

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Request for comments
       [not found] <Pine.LNX.4.21.0107191757400.17990-100000@groove.rdsnet.ro.suse.lists.linux.kernel>
@ 2001-07-19 17:33 ` Andi Kleen
  2001-07-19 17:52   ` Jakob Østergaard
  0 siblings, 1 reply; 6+ messages in thread
From: Andi Kleen @ 2001-07-19 17:33 UTC (permalink / raw)
  To: Cornel Ciocirlan; +Cc: linux-kernel

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Request for comments
  2001-07-19 17:33 ` Request for comments Andi Kleen
@ 2001-07-19 17:52   ` Jakob Østergaard
  0 siblings, 0 replies; 6+ messages in thread
From: Jakob Østergaard @ 2001-07-19 17:52 UTC (permalink / raw)
  To: Andi Kleen; +Cc: Cornel Ciocirlan, linux-kernel

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}...............:

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2001-07-19 17:52 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <Pine.LNX.4.21.0107191757400.17990-100000@groove.rdsnet.ro.suse.lists.linux.kernel>
2001-07-19 17:33 ` Request for comments Andi Kleen
2001-07-19 17:52   ` Jakob Østergaard
2001-07-19 15:44 Cornel Ciocirlan
2001-07-19 16:30 ` Crutcher Dunnavant
2001-07-19 17:24 ` Francois Romieu
2001-07-19 17:29 ` jlnance

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox