On Jan 26, Michael S. Kazmier wrote: > Hello Alex, > > Perhaps I missed something below which ties eth0 and eth1 to the PPP pipe, > or its just my unfamiliarity with PPP. > sorry I should of made it cleaner. If you read up on Advanced Routing HOWTO, its hopefully easy to understand. lets say: ------------ alex@inskipp:~$ cat /etc/iproute2/rt_tables # # reserved values # 255 local 254 main 253 default 0 unspec # # local # 1 inr.ruhep # inskipp 32 ppp-upstream 33 ppp-downstream ------------ you then type (something along the lines of): --------- ip route add default dev ppp1 table ppp-upstream ip route add default dev ppp0 table ppp-downstream ip rule add from 10.0.0.0/8 iif eth1 table ppp-upstream ip rule add to 10.0.0.0/8 iif eth0 table ppp-downstream ip route flush cache --------- In summary, this setups linux to do exactly what is in the diagram (below). The nice thing is after the above is setup you treat it as if its a physical interface, its a real ppp session. Any traffic that goes into ppp0 appears on ppp1 and vice versa; treat it like a fancy wormhole :) The advantage here over the IMQ-ng that is being made, from what I uderstand, is here the only patch you need is to bypass connection tracking on the Internet bound traffic from eth1 (for techie reasons), when it 'appears' from ppp1 then the connection tracking should be allowed to continue. This is where the RAW netfilter patch comes into play. Although you are swapping one kernel patch for another, the RAW one looks like its going to be around much longer and actually maintained, the other very important fact is that you can now (if you think about it, I will leave it as an exercise for you) use it to simulate those IP-Aliasing interfaces and actually now shape on that basis per pipe. The clue is true _source_ based routing ;) > Regardless, an interesting methodology. Do you think you could do the > following: > > <eth0>----<ppp0>----<standard linux bridging / routing>---<ppp1>---<eth1> > > The reason I ask is that I would like to, at the PPP level, apply CBQ or HTB > rate shaping to my each end user (ie, limit traffic to 256K or something > like that). And then, after each customer has their rate shaping, at the > ETH level I would like to priorize traffic (ie, all www prio 3, ssh - > telnet, prio 1, ftp prio 4, everything else prio 7) > > Thoughts? > in theory I guess you could setup a linu bridge over the ppp-pipe, however there is no point (from what I can see) as you are NATing, so the box is the default gateway for the other machines, plus more importantly, if you want a bridge why not just forget about the ppp-pipe and bridge over eth0<->eth1. This is what my jdg-qos-script[1] from more or less day one. Anyway, feedback would be great on the above idea. Regards Alex [1] http://www.digriz.org.uk/jdg-qos-script/ -- _________________ / Genius is pain. \ | | \ -- John Lennon / ----------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || ||
Attachment:
signature.asc
Description: Digital signature
