Tom Eastep wrote: > On Sat, 2007-08-18 at 14:59 +1000, James Gray wrote: >> Tom Eastep wrote: >>> On Fri, 2007-08-17 at 13:30 +1000, James Gray wrote: >>>> Can I force traffic down a specific ISP using classification more >>>> reliably than with plain marking? >>> Classification has absolutely nothing to do with ISP selection. It >>> rather selects a class for traffic shaping but the traffic must be going >>> to that interface already (as a result of marking/routing). >> Yep - that's what I thought too (classification happens in POSTROUTING >> so the route selection has already been made). So I am still stuck with >> the original problem: I can't get specific traffic (layer 4) to be >> routed down a specific ISP. Marking didn't work (in the FORWARD chain), >> and marking a packet with the provider mark in PREROUTING seems to >> bypass the traffic shaping. >> >> So three questions: >> >> 1. If I mark a packet with the provider's mark, rather than the mark in >> tcclasses, what happens (specifically with regard to shaping)? > > If the provider mark happens to be the same as one of the tcclass marks > on the interface, then the traffic will be shaped by that class. > Otherwise, it will fall into the default class.
Agreed. > I implemented HIGH_ROUTE_MARKS=Yes to make the two independent. With > that setting, marks used for route selection have values > 255 while > marks used for tcclass selection have values <= 255. With > HIGH_ROUTE_MARKS=Yes, the mark value is cleared before your FILTER rules > so the PREROUTING mark has no effect on tcclass selection. So in order to use classification marks (eg, 1:150) I need to say "Yes" to HIGH_ROUTE_MARKS *and* specify a mark > 255 in the providers file for that ISP. What if I wanted to specify ISP outbound as follows: providers: #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY $ISP1 1 1 main $NET_IF1 $NET_IF1_GW $PROVOPTS $COPY $ISP2 2 2 main $NET_IF2 $NET_IF2_GW $PROVOPTS $COPY tcrules (abridged): (assuming the same tcclasses I posted earlier) #MARK SOURCE DEST PROTO DEST SOURCE USER TEST LENGTH TOS # PORT PORT # Route default traffic to ISP2 2:P $ANY_IP # Route traffic to ISP1 1:P $LAN_NETWORK $ANY_IP tcp 22 1:P $LAN_NETWORK $ANY_IP tcp 80,443 # Shape ISP2 Traffic 50 $ANY_IP $ANY_IP udp $GAMES # Shape ISP1 Traffic 20 $LAN_NETWORK $ANY_IP tcp 80,443 10 $LAN_NETWORK $ANY_IP tcp 22 >> 2. What is the purpose of having a tcclasses mark associate with an >> interface, if you can't guarantee the packets with that mark go out the >> specified interface? (Or can you?) > > You don't seem to be grasping the notion that you must mark the same > packet multiple times. You mark it in PREROUTING for interface selection > then you re-mark it in FILTER (or use CLASSIFY in POSTROUTING) to > specify which tcclass it will be shaped in. I understand the concept, in fact I've asked this question 3 times now (in different forms) over the last 2 weeks and this is the first time someone has explicitly stated what I thought from the beginning; a packet has to be marked for an ISP, then re-marked for shaping. Thanks for clearing it up. :) The file syntax seemed to contradict my understanding - you've made it too easy :P >> 3. If I can't force traffic down an particular ISP with a tcrule mark or >> a provider mark, should I be doing this in the route_rules? (But >> route_rules doesn't provide for layer 4 matching). > > You force traffic to use a particular ISP with PREROUTING marks. You > select which tcclass it falls into with FILTER marks or CLASSIFY rules. The confusion arose from the documentation seeming to suggest routing and shaping could be done on the same line in the tcrules file for any given traffic type and tc class. The reality is, as I suspected, you need to specify route marks in PREROUTING, then shape packets with other marks, BUT they are both done in the tcrules file. Gotcha. Maybe it's worth explicitly stating this somewhere (MultiISP docs perhaps)? Just a thought - I'm happy to contribute if you like. >> Maybe I've been looking at this too long :( >> > > Have you read http://www.shorewall.net/PacketMarking.html ? It might > help. Yep - read that...and re-read it. Makes more sense now that the multiple-marking question has been answered. :) Thanks again. Cheers, James ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
