NeTraMet Rules for broadcast IP packets

nevil@ccu1.auckland.ac.nz Thu, 09 December 1993 04:50 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25111; 8 Dec 93 23:50 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25103; 8 Dec 93 23:50 EST
Received: from wugate.wustl.edu by CNRI.Reston.VA.US id aa27611; 8 Dec 93 23:50 EST
Received: by wugate.wustl.edu (5.67a+/WUSTL-0.3) with SMTP id AA22719; Wed, 8 Dec 1993 22:47:28 -0600
Message-Id: <199312090447.AA22719@wugate.wustl.edu>
Date: Thu, 09 Dec 1993 17:46:19 +1300
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: nevil@ccu1.auckland.ac.nz
X-Orig-Sender: "ONC List Processor V0.2" <listserv@wugate.wustl.edu>
Reply-To: accounting-wg@wugate.wustl.edu
To: accounting-wg@wugate.wustl.edu
Errors-To: accounting-wg-errors@wugate.wustl.edu
Subject: NeTraMet Rules for broadcast IP packets

Les Hill asked for help in writing NeTraMet rules to tally IP
Broadcast packets.  Herewith a copy of the response ..

Cheers, Nevil

Date: Thu, 9 Dec 1993 17:43:57 +1300 (NDT)
In-Reply-To: <9312061512.AA22950@kaizen.devonshire> from "Les Hill" at Dec 6, 93 10:12:41 am
X-Mailer: ELM [version 2.4 PL21]

> Do you have an example of how to grab broadcast IP packets?  I have been
> trying to get a rules set written to do so and am not succeeding!
>
> Here is a sample excerpt:
> 
> #broadcasts first 1s & 0s
> DestPeerAddress & 255.255.255.255 = 255.255.255.255 : Tally, 4; # 35 bs
> DestPeerAddress & 255.255.255.255 = 0.0.0.0 : Tally, 4; # 36 bs
> #

I didn't have until you asked the question, but I've worked on it!
It turns out to be a bit non-trivial; here's the story ..

First, the following tallies all ethernet broadcast packets.

RULES
#
DestAdjacentAddress & FF-FF-FF-FF-FF-FF = FF-FF-FF-FF-FF-FF: Tally, 1;
Null & 0 = 0 :  Fail, 0;  #  Try other direction
#
#  Mustn't Succeed - this ignores packets in their second compare!
#
ACTIONS
#
SourcePeerTypeMask=255,  #  1  Tally broadcasts
   SourceAdjacentMask=FF-FF-FF-FF-FF-FF,
   DestAdjacentMask=FF-FF-FF-FF-FF-FF,
   SourcePeerMask=255.255.255.255, DestPeerMask=255.255.255.255;

The tricky thing is the second rule.  It is needed because of the way
tallies are handled.  Consider an incoming packet.  If rule 1 matches
it is a broadcast packet and is tallied.  If this flow is already in
the tally it is counted, and the job is done.  If it's not, Tally
doesn't put it in immediately, because it may already be there with
its source and destination swapped - in that case the match fails.
The packet is matched again - rule 1 fails, so rule 2 is executed, and
fails.  In this situation the meter remembers that it was a tally
which caused the first failure, and matches a third time, this time
forcing the tally to add the flow.  

Another feature of the above example is that it tallies all the
broadcast packets by protocol type (SourcePeerTypeMask=255).  If you
only want to tally the IP ones, use SourcePeerType=IP.

It's also possible to do it for IP without looking at the adjacent
(ethernet) address, as follows:

RULES
#
SourcePeerType & 255 = ip :     Pushto, ip_pkt;
Null & 0 = 0 :    Succeed,   0;  #  Ignore
#
ip_pkt:
DestPeerAddress & 0.0.0.255 = 0.0.0.255 :   Tally, broadcasts;
SourcePeerAddress & 0.0.0.255 = 0.0.0.255 :   Fail, 0;  #  Try other direction
#
Null & 0.0.0.0 = 0.0.0.0 :  aggregate, ip_other;
#
ACTIONS
#
broadcasts:
SourcePeerType=ip,
   SourcePeerMask=255.255.255.255, DestPeerMask=255.255.255.255;
#
ip_other:
SourcePeerType=ip,
   SourcePeerAddress=1.2.0.0, DestPeerAddress=3.4.0.0,
   SourcePeerMask=255.255.255.255, DestPeerMask=255.255.255.255;

Non-IP packets are ignored by the first two rules.  If the packet is
IP the rule at label ip_pkt will be tested next. (Version 2.1, with
labels, will be ready in another week or two).

The next rule tests the least significant byte of the IP address to
see if it is 255, in which case the packet is tallied as a broadcast.
(You could add a following rule to test for 0 as a broadcast address,
but I haven't any of those on my network, so I couldn't test it).
If it wasn't a broadcast packet, it's source address is tested - this
will fail for a proper broadcast packet, but will succeed for a proper
broadcast with its addresses swapped.  This is very similar to the
'Fail' rule in the first example, but it allows us to aggregate the
rest of the IP packets, as in the example, or to count/tally/aggregate
them in other ways.

This all seems to have taken a lot of space to explain, but I hope its
clear now.  Thankyou very much for the feedback - it's very, very
helpful to me.  Let me know how you get on.

Cheers, Nevil

+----------------------------------------------------------------------------+
|  Nevil Brownlee:        n.brownlee@auckland.ac.nz         Deputy Director  |
|     FAX: 64 9 373 7425        Computer Centre, The University of Auckland  |
|   Phone: 64 9 373 7599 x8941     Private Bag 92019, Auckland, New Zealand  |
+----------------------------------------------------------------------------+