[LARTC] Can I Classify Non-IP Traffic?

[LARTC] Can I Classify Non-IP Traffic?

[Griff@BP3Web]

Background: Thanks to the LARTC howto, this list and Stef Coene's and
devik's excellent web sites I now have an ethernet bridge (patch
bridge-nf.0.0.7)  happily prioritising traffic (12Mbit) into 10 queues
(9 for IP and 1 for non-IP) using a combination of  iptables (fwmark)
and htb3 and sfq. Many thanks.

At the moment I'm filtering all non-IP traffic by setting the default
queue on the htb root qdisc to my non-IP class and having my last rule
in iptables (POSTROUTING) marks all IP packets such that htb places
these packets into my lowest priority IP queue (note this is different
from the default).

My question is can classify the non-IP traffic? Ideally I'd like to be
able create a queue for IPX traffic.I know the tc filters command has a
protocol statement but I can't find any information about setting this
to anything but ip or ipv6.

Griff


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

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

[Ivo De Decker]

On Thu, Jan 02, 2003 at 04:40:34PM +0000, Griff@BP3Web wrote:
> Background: Thanks to the LARTC howto, this list and Stef Coene's and
> devik's excellent web sites I now have an ethernet bridge (patch
> bridge-nf.0.0.7)  happily prioritising traffic (12Mbit) into 10 queues
> (9 for IP and 1 for non-IP) using a combination of  iptables (fwmark)
> and htb3 and sfq. Many thanks.
> 
> At the moment I'm filtering all non-IP traffic by setting the default
> queue on the htb root qdisc to my non-IP class and having my last rule
> in iptables (POSTROUTING) marks all IP packets such that htb places
> these packets into my lowest priority IP queue (note this is different
> from the default).
> 
> My question is can classify the non-IP traffic? Ideally I'd like to be
> able create a queue for IPX traffic.I know the tc filters command has a
> protocol statement but I can't find any information about setting this
> to anything but ip or ipv6.

Using ebtables, it is possible to filter non-ip traffic.

It is merged into the 2.5 kernel. For the 2.4, you need patches.

http://users.pandora.be/bart.de.schuymer/ebtables/

Greetings,

Ivo De Decker

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

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

[Jose Luis Domingo Lopez]

On Thursday, 02 January 2003, at 16:40:34 +0000,
Griff@BP3Web wrote:

> My question is can classify the non-IP traffic? Ideally I'd like to be
> able create a queue for IPX traffic.I know the tc filters command has a
> protocol statement but I can't find any information about setting this
> to anything but ip or ipv6.
> 
Well, you seem to be already using "iptables" and the "fw" filter to
mark and categorize traffic. "iptables" can also match non-IP
protocols, using "--protocolo PROTOCOL". You can't go deeper into these
non-IP packets, but you can mark them by protocol, using any of the
protocols in the "/etc/protocols" file.

Hope it helps.

-- 
Jose Luis Domingo Lopez
Linux Registered User #189436     Debian Linux Woody (Linux 2.4.20-xfs)
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

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

[Martin A. Brown]

Jose,

If I read his query correctly, he wants to classify IPX or something else.

/etc/protocols is a mapping of identifiers for the contents of IP
packets, so in this case, /etc/protocols doesn't help him.

Seems like he needs a "protocol generic" (or better yet for him, "protocol
ipx"), which would allow him to count byte offsets in the manner of u32.

I know of no such tool.

-Martin

 : > My question is can classify the non-IP traffic? Ideally I'd like to be
 : > able create a queue for IPX traffic.I know the tc filters command has a
 : > protocol statement but I can't find any information about setting this
 : > to anything but ip or ipv6.
 : >
 : Well, you seem to be already using "iptables" and the "fw" filter to
 : mark and categorize traffic. "iptables" can also match non-IP
 : protocols, using "--protocolo PROTOCOL". You can't go deeper into these
 : non-IP packets, but you can mark them by protocol, using any of the
 : protocols in the "/etc/protocols" file.
 :
 : Hope it helps.
 :
 :

-- 
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/

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

[Hannes Ebner]

hi martin,

Martin A. Brown wrote:
> Seems like he needs a "protocol generic" (or better yet for him, "protocol
> ipx"), which would allow him to count byte offsets in the manner of u32.
> 
> I know of no such tool.

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

--snip--

> 	Hello,
> 
> On Sun, 22 Dec 2002, Nickola Kolev wrote:
> 
> 
>>>> > I need to classified the traffic by looking at the packet destination
>>>> > and source MAC address. Can anyone here suggest ways to do this.
>>>> >
>>>> > I have read through the HOWTO documentation, from there I know that
>>>> > U32 filter can only filter out IP or higher layer. May I know why U32
>>>> > filter did not support datalink layer (MAC address)? Is it that when
> 
> 
> 	This is a lie.
> 
> 
>>>> > packet entering TC, the datalink layer no longer there? Are there any
>>>> > filter which can filter the MAC address?
> 
> 
> 	You can filter with U32 by src/dst MAC on ingress and
> by dst MAC on egress. On egress the src MAC is replaced with
> new one and there is no good reason to apply U32 filters for sender's
> MAC.
> 
> 
>>>> > Before this, I have successfully implement QoS through source and
>>>> > destination IP address using CBQ. Here I would like to thanks LARTC
>>>> > for the help.
>>>> >
>>
>>>
>>> Yes, you can do this, but using fw marking, not u32 classifier. Just
> 
> 
> 	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)
> 
> 
>>> search through the various
>>> netfilter extensions - you really can do miracles with them :))
>>>
>>> E-gards,
>>> Nickola
> 
> 
> Regards
> 
> --
> Julian Anastasov <ja@ssi.bg>

--snap--

regards,
   hannes

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

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

[Martin A. Brown]

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/

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

[Julian Anastasov]

	Hello,

On Thu, 2 Jan 2003, Martin A. Brown wrote:

>  : > 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)

	Yes, I'm using sort of:

Egress (match Dst MAC):
... match u16 0xPPPP 0xFFFF at -2 match u32 0xM2M3M4M5 0xFFFFFFFF at -12 match u16 0xM0M1 0xFFFF at -14

Ingress (match Src MAC):
... match u16 0xPPPP 0xFFFF at -2 match u16 0xM4M5 0xFFFF at -4 match u32 0xM0M1M2M3 0xFFFFFFFF at -8

Where PPPP is the Eth Proto Code (from linux/include/linux/if_ether.h):

0800	ETH_P_IP

and M0..M5 are the 6 bytes of the MAC address

Example for matching ETH_P_IP for MAC 00:11:22:33:44:55

Egress:
... match u16 0x0800 0xFFFF at -2 match u32 0x22334455 0xFFFFFFFF at -12 match u16 0x0011 0xFFFF at -14

Ingress:
... match u16 0x0800 0xFFFF at -2 match u16 0x4455 0xFFFF at -4 match u32 0x00112233 0xFFFFFFFF at -8

Regards

--
Julian Anastasov <ja@ssi.bg>

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