Re: [LARTC] Can I Classify Non-IP Traffic?

["Martin A. Brown" <mabrown-lartc@securepipe.com>]

Hello all (and Griff in particular),

I stand corrected!  Thank you for the note, Hannes.  I'll speculate
below and show how I would solve this problem, although I have not
actually tried it.  But an interesting exercise captivates the
imagination!  So let's be off!

 : i just quote what julian wrote some time ago, seems as if it would
 : possible what griff wants to do:

It certainly seems like this should work, according to Julian's
description.  So, I'll take a stab at trying to write a basic rule to
classify IPX (I have no way to test, as I have no IPX network available).
The first thing we'll want to do is identify IPX packets.

On first googling I found one page [1] identifying the ethernet frame type
code for encapsulated IPX packets, 0x8137.  After further googling, I
found a lengthy discussion [2] of the characteristics of IPX data carried
on ethernets.  I will assume (incorrectly, to be sure) that ethernet frame
type 0x8137 identifies an IPX packet.  In that case,

  U32="tc filter add dev $DEV parent 1:0 protocol ip u32"
  $U32 match u16 0x8137 0xffff at -2 flowid 1:1

should classify all all such IPX packets, correct?  (Please note that the
above command fails if "protocol ip" is omitted from the command string.)

If that is the case, then we should be able to select the correct byte
ranges from an IPX packet to classify the IPX packet into the desired
flow/class, correct?  According to the packet structure [3], we should
select on:

      IPX packet field       byte offset
   -------------------       -----------
   destination network           +6
      destination node          +10
        source network          +18
           source node          +22

Now, I cannot assure the reader that my math is correct.  With reference
to the detailed history of IPX encapsulation on ethernet [2], a reader
should be able to locate the initial byte of an IPX packet.  I suspect the
writing of filters will require detailed and accurate knowledge about the
characteristics of the IPX packets on the network.  This knowledge
shouldn't be too difficult to gain with a bit of judicious use of tcpdump
(maybe "tcpdump -nn -e -l -x not ip" or something like that).

I have tested the technique of classifying packets based on MAC
addresses in my own network, with fabulous success, however.  They end up
in the specified queue exactly as I desire.

 : > 	Why not, just use negative offsets with U32 to access
 : > the 14-byte eth frame header before the IP header:
 : >
 : > Decimal Ofs	Description
 : > -----------------------------------
 : > -14:		DST MAC, 6 bytes
 : > -8:		SRC MAC, 6 bytes
 : > -2:		Eth PROTO, 2 bytes, eg. ETH_P_IP
 : > 0:		Protocol header (IP Header)

Thanks very much to Hannes for his gentle prod, and to Julian who posted
the original suggestion.  Maybe if you have success, Griff, you might post
a summary of your method and math for posterity?  You are probably not the
only one out there who wishes to mix bridging, traffic control, and IPX.

-Martin

 [1] http://www.geocities.com/SiliconValley/Haven/4824/ethernet.html
 [2] http://www.ncat.co.uk/Net_Lib/nov_frm.htm
 [3] http://www.novell.com/documentation/lg/nw6p/ipx_enu/data/hc1w6pvi.html


P.S., after reading a bit about IPX, I'm somewhat relieved to return to
      the world of IP.

-- 
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/