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/
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/
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/
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/
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/
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/
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/
Some of you may remember that back in January I enquired about the possibility of matching non-IP packets in general and IPX packets in particular. Due to a shortage of resources I''ve only recently been able to my goal of a combined bridge/IPX traffic shaper, the results of which I hope to be able to share in the next few weeks. or so In the meantime, I''ve a problem trying to explicitly drop unwanted IPX packets. Background What I''m trying to achieve is a filter broadly similar the following iptables example, in which unmatched packets are discarded. iptables -t mangle -A somechain -s some-addr -j ACCEPT ... iptables -t mangle -A somechain -s some-other-addr -j ACCEPT iptables -t mangle -A somechain -j DROP Thanks mostly to Martin Brown''s response to my previous question, I have written the u32 filters to do the equivalent of "-s some-addr -j ACCEPT" for the IPX packets but I''m stuck on the equivalent for "-j DROP". I''m using prio as the root qdisc, with a pfifo attached to the first class, 1:1, htb attached to the second class, 1:2, and the third class, 1:3, is the one I''ve been using to experiment with. The filter attached to the root, prio, qdisc directs all non-IPX traffic to the pfifo attached to 1:1 and all matching IPX traffic to 1:2. Problem My first attempt to drop the remaining packets was to make the last entry in the filter tc filter ... u32 match u16 0x8137 0xffff at -2 police drop flowid 1:3 which tc -s filter ls dev eth0 shows as ... filter parent 1: protocol ip ... police 3 action drop rate 0bps burst 0b mtu 4096Mb match 00008137/0000ffff at -4 This had no effect, with the unwanted IPX traffic still being passed. My second attempt was to remove the "police drop" from the above filter spec. and add a zero length pfifo to the third class, 1:3 as follows tc qdisc add dev eth0 parent 1:3 handle 30: pfifo limit 0 which tc -s qdisc ls dev eth0 shows as ... qdisc pfifo 30: limit 0 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) Again this has no effect, all the unwanted IPX traffic passes via pfifo 30:. Any ideas? Griff. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/