Hello, I have a linux box sitting between (and bridging/firewalling) 2 LAN segments. I''m using Bridge/Netfilter/IMQ/tc(htb) to control (shape) mail/web traffic that traverses the 2 networks. The networks also have some VLAN tagged traffic flying around. My linux box behaves OK with VLAN traffic except that the shaping doesn''t seem to work. Normal http shapes alright but as soon as the http is encapsulated with VLAN, shaping doesn''t work - IPtables "sees" that it is http (so firewalling works) and marks it as such in readiness for shaping, but it doesn''t seem to be picked up by htb. IMQ doesn''t seem to be the problem. I removed IMQ and just tried to shape on the interfaces and i had the same problem. Can anyone help? Thanks, John _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: lartc.org
Hi Trevor, My linux box has 2 interfaces (eth0 and eth1). These are bridged to form br0. All web/email traffic is sent to IMQ (via netfilter) and shaped. The VLAN traffic just has a 4-byte 802.1Q header between the ethernet header and the IP header (which is stripped off by br_netfilter.c so iptables can "see" the underlying IP packet). The problem is the VLAN packets (which contain web/email traffic) are seen and marked by netfilter and pass through IMQ but are not shaped (whereas regular web/email traffic is shaped). At the moment i''m trying to strip the VLAN header before it enters the scheduler and then restore it after it is dequeued (in a similar way that br_netfilter.c does). However, i''m not confident that this will make much difference as it appears that when the skbuff enters the scheduler, skbuff->data already points to the same place as skbuff->nh.raw which is correctly pointing to the IP header. So as far as the scheduler is concerned, it "sees" an IP packet. What was the problem you had with IPSec traffic and how did you overcome it? Regards, John Quoting Trevor Cordes <trevor@tecnopolis.ca>:> On 8 Sep, John Bothe wrote: > > Hello, > > > > I have a linux box sitting between (and bridging/firewalling) 2 LAN > segments. > > I''m using Bridge/Netfilter/IMQ/tc(htb) to control (shape) mail/web traffic > that > > traverses the 2 networks. > > > > The networks also have some VLAN tagged traffic flying around. My linux box > > behaves OK with VLAN traffic except that the shaping doesn''t seem to work. > > Normal http shapes alright but as soon as the http is encapsulated with > VLAN, > > shaping doesn''t work - IPtables "sees" that it is http (so firewalling > works) > > and marks it as such in readiness for shaping, but it doesn''t seem to be > picked > > up by htb. > > Forgive my ignorance, but what do you mean by "VLAN"? I know that term > can have a couple of different meanings. What''s the interface called? > (ie: eth0) > > The reason I ask is perhaps you''re getting a similar problem to what I > just posted about regarding not being able to shape traffic going into > IPSEC. > >_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: lartc.org
> My linux box has 2 interfaces (eth0 and eth1). These are bridged to form > br0. > All web/email traffic is sent to IMQ (via netfilter) and shaped. > > The VLAN traffic just has a 4-byte 802.1Q header between the ethernet > header and > the IP header (which is stripped off by br_netfilter.c so iptables can > "see" the > underlying IP packet). > > The problem is the VLAN packets (which contain web/email traffic) are seen > and > marked by netfilter and pass through IMQ but are not shaped (whereas > regular > web/email traffic is shaped). >John, Did you find an answer??? I have the same problem, sort of. My LAN interface has 10 VLANs, and I mark the packets in IPTABLES based off of source MAC address. This mark is holding fine and when passed to the IMQ I have for Internet based traffic, the traffic is shaping fine (I can post the code if you need me to). The problem I am having is on downstream data (from internet to VLANS). On a non-VLAN interface, I use the following filer to put the traffic into the correct users "bucket": filter parent 1: protocol ip pref 1 u32 fh 800::8b3 order 2227 key ht 800 bkt 0 flowid 1:10b5 match 47b60401/ffffffff at -12 match 00000003/0000ffff at -16 This works great on non-vlan interfaces, but not so on the VLANs, so I figured with the 4 byte VLAN header appended AFTER the Ethernet frame and BEFORE the IP frame, I could do this: filter parent 1: protocol ip pref 1 u32 fh 800::8b3 order 2227 key ht 800 bkt 0 flowid 1:10b5 match 47b60401/ffffffff at -16 match 00000003/0000ffff at -20 But that is not matching a darn thing. Any thoughts? I am stumped - of course, I don''t know if the VLAN header is on the packets as they are handed off to the IMQ, but it would appear so as they do not match the "old" filter which works without any VLAN tagging. --Mike _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: lartc.org
Success! If you put the traffic shaping qdiscs on the physical interface and change ONE thing on the filter statement, everything works as advertised. Just change the "protocol ip" to "protocol 802.1q" on the filter commands and Viola - VLAN traffic shaping... I have not tested other rules, but our destination mac address rule with u32 matches works as follows: $TC filter add dev eth1 parent 1:0 prio 1 protocol 802.1q \ u32 match u32 0x$mymac3$mymac4$mymac5$mymac6 0xFFFFFFFF at -12 \ match u32 0x0000$mymac1$mymac2 0x0000FFFF at -16 \ classid 1:$myclassid Hope this helps someone. --Mike> -----Original Message----- > From: lartc-admin@mailman.ds9a.nl [mailto:lartc-admin@mailman.ds9a.nl] On > Behalf Of Michael S. Kazmier > Sent: Tuesday, September 28, 2004 2:33 PM > To: ''lartc mailing list'' > Subject: RE: [LARTC] Help! VLAN tagged traffic not shaping :-( > > > My linux box has 2 interfaces (eth0 and eth1). These are bridged to form > > br0. > > All web/email traffic is sent to IMQ (via netfilter) and shaped. > > > > The VLAN traffic just has a 4-byte 802.1Q header between the ethernet > > header and > > the IP header (which is stripped off by br_netfilter.c so iptables can > > "see" the > > underlying IP packet). > > > > The problem is the VLAN packets (which contain web/email traffic) are > seen > > and > > marked by netfilter and pass through IMQ but are not shaped (whereas > > regular > > web/email traffic is shaped). > > > > > John, > > Did you find an answer??? I have the same problem, sort of. My LAN > interface has 10 VLANs, and I mark the packets in IPTABLES based off of > source MAC address. This mark is holding fine and when passed to the IMQ > I > have for Internet based traffic, the traffic is shaping fine (I can post > the > code if you need me to). > > The problem I am having is on downstream data (from internet to VLANS). > On > a non-VLAN interface, I use the following filer to put the traffic into > the > correct users "bucket": > > filter parent 1: protocol ip pref 1 u32 fh 800::8b3 order 2227 key ht 800 > bkt 0 flowid 1:10b5 > match 47b60401/ffffffff at -12 > match 00000003/0000ffff at -16 > > This works great on non-vlan interfaces, but not so on the VLANs, so I > figured with the 4 byte VLAN header appended AFTER the Ethernet frame and > BEFORE the IP frame, I could do this: > > filter parent 1: protocol ip pref 1 u32 fh 800::8b3 order 2227 key ht 800 > bkt 0 flowid 1:10b5 > match 47b60401/ffffffff at -16 > match 00000003/0000ffff at -20 > > But that is not matching a darn thing. Any thoughts? I am stumped - of > course, I don''t know if the VLAN header is on the packets as they are > handed > off to the IMQ, but it would appear so as they do not match the "old" > filter > which works without any VLAN tagging. > > --Mike > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: lartc.org_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: lartc.org