[LARTC] route to a host behind and ipsec tunnel
Hi there, I have a client who has several branch offices, they are adding a system that uses a PC in the main office to create a PPTP connection to the Applications host. So, locally I specify a route on my gateway to handle this. ip route add 1.2.3.4/20 via 192.168.24.4 (Firewall 192.168.24.1/24) 192.168.24.4 is the PC with the PPTP connection. This works wonderfully for the local lan, however, I'm not sure how to route, or what route to set on the remote firewalls to push this traffic to the host? ip route add 1.2.3.4/30 via 192.168.24.4 nexthop 10.10.10.1? (Assumes the remote locations lan is 10.10.10.1) Can this be done? Do I need to bring OSPF into the mix? |Remote Workstations | REMOTE LAN 10.10.10.0/24 10.10.10.1 Firewall | Real IP | | Ipsec Tunnel (StrongSwan) | | Real IP Primary LAN 192.168.24.1 Firewall 192.168.24.0/24 | | (Application Provider's REAL ip) |192.168.24.4 --shared PPTP-- 1.2.3.4/30 | |Other Workstations ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] CryptNET Peer Cache Daemon
Hi Anyone has tested "CryptNET Peer Cache Daemon" ?? http://cryptnet.net/fsp/cpcd/ I've heared that by using a Peer Cache Daemon I can lower p2p traffic over my internet link, and provide better rates over p2p downloads to LAN users. I would like to know if somebody has tested it ... is a Peer Cache server really useful ? Best regards, Andres. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: [PATCH] HTB O(1) class lookup
On Thursday 01 February 2007 12:30, Andi Kleen wrote: > Simon Lodal <[EMAIL PROTECTED]> writes: > > Memory is generally not an issue, but CPU is, and you can not beat the > > CPU efficiency of plain array lookup (always faster, and constant time). > > Actually that's not true when the array doesn't fit in cache. > > The cost of going out to memory over caches is so large (factor 100 and > more) that often algorithms with smaller cache footprint can easily beat > algorithms that execute much less instructions if it has less cache misses. > That is because not all instructions have the same cost; anything > in core is very fast but going out to memory is very slow. > > That said I think I agree with your analysis that a two level > array is probably the right data structure for this and likely > not less cache efficient than the hash table. Good point. The 2-level lookup generates 3 memory accesses (including getting at the htb_class struct). List traversal will generate many more memory accesses, unless the lists have 3 or fewer entries (currently that only holds true for up to 48 classes, uniformly distributed). It is difficult to judge if the tables will be in cache or not. The tables are clearly extra baggage for the cachelines, compared to only having the htb_class structs (they are going to be fetched anyway). On the other hand, if you have 10k classes, they are usually (real world) allocated for individual users, of which at most half are active at any time. With hashing, all 10k classes are fetched into cachelines all the time, only in order to traverse lists. That is >150k wasted cache (5000 x 32 bytes); plenty for 10k pointers in lookup tables. Regards Simon ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: [PATCH] HTB O(1) class lookup
On Monday 05 February 2007 11:16, Jarek Poplawski wrote: > On 01-02-2007 12:30, Andi Kleen wrote: > > Simon Lodal <[EMAIL PROTECTED]> writes: > >> Memory is generally not an issue, but CPU is, and you can not beat the > >> CPU efficiency of plain array lookup (always faster, and constant time). > > Probably for some old (or embedded) lean boxes used for > small network routers, with memory hungry iptables - > memory could be an issue. Sure, but if they are that constrained they probably do not run HTB in the first place. We are talking about 4k initially, up to 256k worst case (or 512k if your router is 64bit, unlikely if "small" is a priority). > > And the worst memory consumption case considered by Patrick should > > be relatively unlikely. > > Anyway, such approach, that most users do something > this (reasonable) way, doesn't look like good > programming practice. The current hash algorithm also assumes certain usage patterns, namely that you choose classids that generate different hash keys (= distribute uniformly across the buckets), or scalability will suffer very quickly. Even at 64 classes you would probably see htb_find() near the top of a profiling analysis. But I would say that it is just as unlikely as choosing 64 classids that cause my patch to allocate all 256k. In these unlikely cases, my patch only wastes passive memory, while the current htb wastes cpu to a point where it can severely limit routing performance. > I wonder, why not try, at least for a while, to do this > a compile (menuconfig) option with a comment: > recommended for a large number of classes. After hash > optimization and some testing, final decisions could be > made. I decided not to do it because it would mean too many ifdefs (ugly+unmaintanable code). Regards Simon ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Shape incoming & outgoing multiple-backbone traffic
Hi, On Monday 05 February 2007 03:43, Rio Martin wrote: > Dear all, > I have 3 backbones for my local network. > > 1st backbone: down 1024kbps, up 1024kbps through eth1 > 2nd backbone: down 2048kbps, up 2048kbps through eth2 > 3rd backbone: down 1024kbps, up 128kbps through eth3 > Local network: 192.168.0.0/16 through eth0 > Router: Linux Slakware 11 with iproute2 > > Please let me know how to shape both incoming and outgoing traffic for > this case. > LARTC doc only showing just 1 backbone. > Any idea to use HTB ? If shapping the outgoing traffic and policing the incoming traffic (rate limiting only) is enough, take a look at this: http://downloads.angulosolido.pt/QoS/HTB_shaper_basic.sh the HTB_shape and limit_incoming functions already do what you need. After you get familiar with, you can adapt as needed. Regards Gustavo > > Thanks before. > > - Rio.Martin - > ___ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- Angulo Sólido - Tecnologias de Informação http://angulosolido.pt ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Problems with HTB. Help!
Hello list. I've configured a very simple script to slow down packets coming from a particular IP Address. I've used IPTABLES to mark traffic coming from this IP Address, but it does not appear to be working as expected. Let me first describe my system as maybe what I'm doing is beyond what NETFILTER can do. I have one machine that runs all my servers as VM's. The P2P WinXP box and the router are virtualized. So too is the Windows 2003 DNS server. Please have a look at the traffic control script below and let me know if I've done something wrong! Cheers, tkb. Below is the script. You'll note that I've even tried using a filter (attached to eth0 - LAN) linking parent at eth0 going to a class on eth1 - is this even valid? tc did not seem to complain about it so I figured it must be okay. #*** #!/bin/bash # Whole purpose of this is to slow the P2P WinXP box down! ### # Reset everything to known state # ### tc qdisc del dev eth0 root tc qdisc del dev eth1 root # Setup the qdiscs # tc qdisc add dev eth0 parent root handle 1: htb default 10 tc qdisc add dev eth1 parent root handle 2: htb default 10 ## # Setup the root classes # ## tc class add dev eth0 parent 1: classid 1:1 htb rate 10mbit \ ceil 10mbit tc class add dev eth1 parent 2: classid 2:1 htb rate 384kbit \ ceil 384kbit burst 15k ### # Setup the child classes # ### tc class add dev eth0 parent 1:1 classid 1:10 htb rate 10mbit \ ceil 10mbit prio 0 tc class add dev eth1 parent 2:1 classid 2:10 htb rate 224kbit \ ceil 384kbit prio 0 tc class add dev eth1 parent 2:1 classid 2:11 htb rate 100kbit \ ceil 100kbit prio 1 tc class add dev eth1 parent 2:1 classid 2:12 htb rate 60kbit \ ceil 60kbit prio 2 # # Setup the filters # # # match acks the hard way, # IP protocol 6, # IP header length 0x5(32 bit words), # IP Total length 0x34 (ACK + 12 bytes of TCP options) # TCP ack set (bit 5, offset 33) ACK="tc filter add dev eth1 protocol ip parent 2:0 prio 0 u32" $ACK match ip protocol 6 0xff \ match u8 0x05 0x0f at 0 \ match u16 0x 0xffc0 at 2 \ match u8 0x10 0xff at 33 \ classid 2:11 #**U32_0="tc filter add dev eth0 protocol ip parent 1:0 u32" #**$U32_0 match ip src 192.168.200.163 classid 2:12 #U32_1="tc filter add dev eth1 protocol ip parent 2:0 u32" P2P="tc filter add dev eth1 protocol ip parent 2:0 prio 10" $P2P handle 1 fw classid 2:12 # Setup the queue discipline for the child classes # tc qdisc add dev eth1 parent 2:10 handle 10: sfq perturb 10 tc qdisc add dev eth1 parent 2:11 handle 11: sfq perturb 10 tc qdisc add dev eth1 parent 2:12 handle 12: sfq perturb 10 # ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: [PATCH] HTB O(1) class lookup
On 01-02-2007 12:30, Andi Kleen wrote: > Simon Lodal <[EMAIL PROTECTED]> writes: >> Memory is generally not an issue, but CPU is, and you can not beat the CPU >> efficiency of plain array lookup (always faster, and constant time). Probably for some old (or embedded) lean boxes used for small network routers, with memory hungry iptables - memory could be an issue. > Actually that's not true when the array doesn't fit in cache. > > The cost of going out to memory over caches is so large (factor 100 and more) > that often algorithms with smaller cache footprint can easily beat > algorithms that execute much less instructions if it has less cache misses. > That is because not all instructions have the same cost; anything > in core is very fast but going out to memory is very slow. > > That said I think I agree with your analysis that a two level > array is probably the right data structure for this and likely > not less cache efficient than the hash table. Strange - it seems you gave only arguments against this analysis... > And the worst memory consumption case considered by Patrick should > be relatively unlikely. Anyway, such approach, that most users do something this (reasonable) way, doesn't look like good programming practice. I wonder, why not try, at least for a while, to do this a compile (menuconfig) option with a comment: recommended for a large number of classes. After hash optimization and some testing, final decisions could be made. Regards, Jarek P. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: tc filter matches ip fileds inside pppoe frames
Resent using text insted of html. - Original Message - From: Ming-Ching Tiew To: lartc@mailman.ds9a.nl Sent: Monday, February 05, 2007 9:28 AM Subject: tc filter matches ip fileds inside pppoe frames I have a requirement which I guess it is not too unusually, however I haven't quite figured out how to do it and couldn't find any examples which handle that. I have made myself a Linux-based bridge, eth0 bridged with eth1 to form br0. In this bridge, I run 'tc' script to handle QoS. So far nothing unusual. However, what's different is that this bridge is sitted in between a pppoe client and pppoe server, ie pppoe frames are bridge between the Linux bridge, and I am interested to perform QoS on the pppoe frames, based on the ip tos setting of the ppp packets ( encapsulated inside the pppoe frames ). For example, normal tc script :- tc filter add dev ppp0 parent 1:0 prio 10 u32 \ match ip tos 0x10 0xff \ flowid 1:4 This will work on a ppp0 device because the ppp0 has ip packets flowing through it. Now in my bridge, there is no such device, I only have access to eth0 or eth1, how could I perform the same thing on devices such as eth0 or eth1, but matching the ip TOS setting inside the pppoe frame ? Best regards. ** Message from InterScan E-Mail VirusWall NT ** ** No virus found in attached file noname.htm ** No virus found in attached file noname.htm This mail has been scanned by InterScan. * End of message *** ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
