[LARTC] deleting 1 filter deletes all (under same class)
I am creating three u32 filters with different dst addresses. When I delete one of those filters, all three are deleted. Why all 3 filters are deleted even though in 'tc filter del' command I give exactly all parameters of filters creation. Is this expected behaviour, that all other filters are deleted also ? Thanks Yakov Lerner Here is sample script that reproduces how single 'tc filter del' command deletes 3 filters: - # create qdisc and classes tc qdisc del dev eth0 root handle 1:0 htb tc qdisc add dev eth0 root handle 1:0 htb tc class add dev eth0 parent 1:0 classid 1:1 htb rate 2048kbit tc class add dev eth0 parent 1:0 classid 1:21 htb rate 512kbit tc class add dev eth0 parent 1:0 classid 1:22 htb rate 512kbit tc class add dev eth0 parent 1:0 classid 1:23 htb rate 512kbit # create 3 filters tc filter add dev eth0 parent 1:1 protocol ip prio 1 u32 match ip dst 1.1.1.1/32 flowid 1:21 tc filter add dev eth0 parent 1:1 protocol ip prio 1 u32 match ip dst 2.2.2.2/32 flowid 1:22 tc filter add dev eth0 parent 1:1 protocol ip prio 1 u32 match ip dst 3.3.3.3/32 flowid 1:23 tc filter show dev eth0 parent 1:1 # here, we see 3 filters that we created # del 1 filter tc filter del dev eth0 parent 1:1 protocol ip prio 1 u32 match ip dst 1.1.1.1/32 flowid 1:21 tc filter show dev eth0 parent 1:1 # here, we see all 3 filters deleted -- -- [EMAIL PROTECTED] -- http://www.fastmail.fm - Email service worth paying for. Try it for free ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Limited quantity of filters.
gypsy wrote: Konrad, Specify a prio in each 'filter add' line. The SAME prio for each filter. Not specifying any filter won't work, but with a prio you can load at least 64K filter lines. Search this mailing list for please document in July 2004. Thank You. It's working. I've found this message. I'm sorry, because I've not used list's archive to find answer :/ Is it possible to use any search engine (like groups.google.com) to searching only on this list? ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [lartc] Virtual Interface
Mike,
Thanks. I will try it..
I have not explained the puspose for this doing this - just to give you an idea I want to create around 200 virtual interfaces and send traffice through all the interfaces simulating traffic comming from different networks. Do youthink this approach will scale to that level?
Roger
On 2/3/06, list user [EMAIL PROTECTED] wrote:
Hi Roger,[big snip: lost o.p.]There are a couple of different approaches you might try.One is to use
uml-utilities' tunctl to create an ethernet tap. Another is to use thedummy interface.With either method you can bridge, route, configure asyou would a physical device using ifconfig and/or ip.The following methods work for me.I use Fedora Core 4.Its network
setup methods are in /etc/sysconfig/network-scripts.cd /etc/sysconfig/network-scriptsln -s ifup-eth ifup-tapln -s ifdown-eth ifdown-tapecho 'ip link show tap0 | grep tap0 21 /dev/null ||tunctl -t tap0
DEVICE=tap0TYPE=ethernet>BOOTPROTO=staticMACADDR=5a:5a:5a:5a:5a:5aNETWORK=192.168.0.0IPADDR=192.168.0.1BROADCAST=
192.168.0.255NETMASK=255.255.255.0' ifcfg-tap0ifup tap0ln -s ifup-eth0 ifup-dummyln -s ifdown-eth ifdown-dummyecho 'ip link show dummy0 | grep dummy0 21 /dev/null || {
ip link set dummy0 upip link set dummy0 arp onip link set dummy0 multicast on}DEVICE=dummy0TYPE=ethernet>BOOTPROTO=staticMACADDR=a4:a5:a5:a5:a5:a5NETWORK=
192.168.0.0IPADDR=192.168.0.2BROADCAST=192.168.0.255NETMASK=255.255.255.0' ifcfg-dummy0ifup dummy0
If all went well there should now be two new virtual ethernet devices,tap0 and dummy0.Hope this information is useful to you,Mike Wright :m)___
LARTC mailing listLARTC@mailman.ds9a.nlhttp://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] p2p marking, again
in the out chain you're marking them as mark 5, but only saving it as mark 7, that would cause you to possibly miss some tcp streams, but depending on the protocol a lot might be marked just from the incomming data. as for how much data was marked, look at the incomming counters, of the 100,854 packets, 78,910 had a mark restored, and 2904 were newly marked, that means 81814 out of 100,854 incomming packets were marked as p2p, that's 80% and a lot more than 625k. Beyond the mrk 5/7 mixup in the outgoing marking, you also didn't mention the IMQ rule in the previous email. Normally the
iptables -t mangle -A DSL-IN -p tcp -m mark ! --mark 0 -j ACCEPTrule is good as it makes sure the mark doesn't get rechanged after its been saved once and later restored. However in this case, it means it was leaving your chain before reaching the IMQ target. So for your case it should be safe to remove that rule. This will likely fix the problem you were really having of the incomming data not all going to the IMQ
- JodyOn 2/7/06, Vaidas [EMAIL PROTECTED] wrote:
Allright...tc qdisc add dev $DEV root handle 2:0 htb default 20 r2q 2tc class add dev $DEV parent 2:0 classid 2:10 htb rate ${RATETOTAL}kbittc class add dev $DEV parent 2:10 classid 2:20 htb rate ${RATETOTAL}kbit
ceil ${RATETOTAL}kbit prio 0tc class add dev $DEV parent 2:10 classid 2:21 htb rate 1kbit ceil${RATEUP}kbit prio 1tc qdisc add dev $DEV parent 2:20 handle 20:0 sfq perturb 10tc qdisc add dev $DEV parent 2:21 handle 21:0 sfq perturb 10
tc filter add dev $DEV parent 2:0 prio 1 protocol ip handle 5 fw flowid 2:21iptables -t mangle -N DSL-OUTiptables -t mangle -I POSTROUTING -o $DEV -j DSL-OUTiptables -t mangle -A DSL-OUT -p tcp -j CONNMARK --restore-mark
iptables -t mangle -A DSL-OUT -p tcp -m mark ! --mark 0 -j ACCEPTiptables -t mangle -A DSL-OUT -m ipp2p --edk --dc --bit --soul -j MARK--set-mark 5iptables -t mangle -A DSL-OUT -p tcp -m mark --mark 7 -j CONNMARK
--save-markip link set imq0 uptc qdisc add dev imq0 root handle 2:0 htb default 20 r2q 2tc class add dev imq0 parent 2:0 classid 2:10 htb rate ${RATETOTAL}kbittc class add dev imq0 parent 2:10 classid 2:20 htb rate ${RATETOTAL}kbit
ceil ${RATETOTAL}kbit prio 0tc class add dev imq0 parent 2:10 classid 2:21 htb rate 2kbit ceil${RATEDN}kbit prio 1tc qdisc add dev imq0 parent 2:20 handle 20:0 sfq perturb 10tc qdisc add dev imq0 parent 2:21 handle 21:0 sfq perturb 10
tc filter add dev imq0 parent 2:0 prio 1 protocol ip handle 7 fw flowid 2:21iptables -t mangle -N DSL-INiptables -t mangle -I PREROUTING -i $DEV -j DSL-INiptables -t mangle -A DSL-IN -p tcp -j CONNMARK --restore-mark
iptables -t mangle -A DSL-IN -p tcp -m mark ! --mark 0 -j ACCEPTiptables -t mangle -A DSL-IN -m ipp2p --edk --dc --bit --soul -j MARK--set-mark 7iptables -t mangle -A DSL-IN -p tcp -m mark --mark 7 -j CONNMARK --save-mark
iptables -t mangle -A DSL-IN -j IMQ --todev 0still not working :I don't know what to do else, tried everythink :/The uTorrent have downloading for half an hour, but the counters are...
Chain DSL-OUT (1 references)pktsbytes target prot opt in out sourcedestination 805155464493 CONNMARK tcp--anyany anywhereanywhereCONNMARK restore 525013402390 ACCEPT tcp--anyany anywhere
anywhereMARK match !0x03593 464055 MARK all--anyany anywhereanywhereipp2p v0.8.0 --edk --dc --bit --soul MARK set 0x5 00 CONNMARK tcp--anyany anywhere
anywhereMARK match 0x7 CONNMARK saveChain DSL-IN (1 references)pktsbytes target prot opt in out sourcedestination100854 97487345 CONNMARK tcp--anyany anywhere
anywhereCONNMARK restore 78190 92347437 ACCEPT tcp--anyany anywhereanywhereMARK match !0x02904 625681 MARK all--anyany anywhereanywhereipp2p
v0.8.0 --edk --dc --bit --soul MARK set 0x7 27439048 CONNMARK tcp--anyany anywhereanywhereMARK match 0x7 CONNMARK save 307596358180 IMQall--anyany anywhere
anywhereIMQ: todev 0Only 625681 bytes marked as p2p :(---Original Message-From: Jody Shumaker [mailto:[EMAIL PROTECTED]]Sent: 2006 m. vasario 6 d. 21:23
To: VaidasCc: lartc@mailman.ds9a.nlSubject: Re: [LARTC] p2p marking, againBah, I don't know why I didn't notice this before in your previousemail. It's obvious now that you gave the states output:
iptables -t mangle -A DSL-IN -p tcp -m ipp2p --ipp2p -j CONNMARK--restore-markthat line is horribly wrong, it should be:iptables -t mangle -A DSL-IN -p tcp -j CONNMARK --restore-markThe whole point is that ipp2p can't match on every packet! so you save
the mark and then restore it.However, you were conditionallyrestoring the mark only when ipp2p matched, which completely defeatsthe purpose. There's also no reason to have the -m ipp2p --ipp2p
when saving the mark, as this adds more work than is neccasary.Instead of:iptables -t mangle -A DSL-IN -p tcp -m ipp2p --ipp2p -j CONNMARK --save-markI'd suggets:iptables -t mangle -A DSL-IN -p tcp -m mark ! --mark 0 -j CONNMARK
--save-markAs this match would be much faster, and would mean no redundant workon matching ipp2p.I'd also suggest combining your tcp
RE: [LARTC] failover routing
Hi, our network has a hand full of 2k servers that use silent rip. We use 2 Linux gateways with separate isp's. Each gateway does a ' default-originate' to advertise its default route in ripv2(with on having a different metric). The main gateway has a ping script written in shell that will ping the gateway, determine if its up or down; With either result it checks its history of the last 3 intervals, and will only stop rip if or start rip if there is/was 3 concurrent ups or downs. I have been running this for 2 years with no problems. I hope this helps ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] unable to get download restrictions working on an interface
I am using the following commands to restrict download on an interface vm01/sbin/tc qdisc add dev vm01 root handle 11: cbq bandwidth 100Mbit avpkt 1000 mpu 64/sbin/tc class add dev vm01 parent 11:0 classid 11:1 cbq rate 1.5Kbit weight 1.5Kbit allot 1514 prio 1 avpkt 1000 bounded/sbin/tc filter add dev vm01 parent 11:0 protocol ip handle 4 fw flowid 11:1When i do a qdisc show and class show, it shows me the information. tc -s -d qdisc show dev vm01; tc -s -d class show dev vm01qdisc cbq 11: rate 100Mbit cell 8b mpu 64b (bounded,isolated) prio no-transmit/8 weight 100Mbit allot 1514blevel 1 ewma 5 avpkt 1000b maxidle 2us Sent 0 bytes 0 pkts (dropped 0, overlimits 0 requeues 0) borrowed 0 overactions 0 avgidle 65 undertime 0class cbq 11: root rate 100Mbit cell 8b mpu 64b (bounded,isolated) prio no-transmit/8 weight 100Mbit allot 1514b level 1 ewma 5 avpkt 1000b maxidle 2usSent 0 bytes 0 pkts (dropped 0, overlimits 0 requeues 0) borrowed 0 overactions 0 avgidle 65 undertime 0class cbq 11:1 parent 11: rate 187bit cell 8b (bounded) prio 1/1 weight 192bit allot 1514b level 0 ewma 5 avpkt 1000b maxidle 2usSent 0 bytes 0 pkts (dropped 0, overlimits 0 requeues 0) borrowed 0 overactions 0 avgidle 0 undertime 0When traffic flows through the interface vm01 and a watch is placed on the above results, it shows traffic is flowing however the restrictions placed by the commands don't seem to be working. No matter what i use, the interface is able to get the max bandwidth available. Can anyone please help me in getting this right ?Thanks.-- regards,Anand Gupta ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Please help in choosing the right patches
Sandeep Agarwal wrote: I have gone through http://www.ssi.bg/~ja/nano.txt AND further http://www.ssi.bg/~ja/ got confused in choosing the right patch. Please suggest if I will choose Jumbo Patch patch-2.4.20-ja1.diff , is any other patches also required after this? If yes, is there any sequence in applying these patches? For your purpose, you need to choose one of the patches at http://www.ssi.bg/~ja/#routes depending on your kernel. You dont need the Jumbo patch for load balancing and failover. The routes patch should suffice. -- Manish Kathuria http://www.tuxspace.com/ ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] failover routing
sounds good, do your run ripv2 with zebra or quagga?, your idea sounds exactly what I have in mind. Mind explaining a bit more technical and sharing some usefull bits in your config?ThanksSew On 2/7/06, comp.techs [EMAIL PROTECTED] wrote: Hi, our network has a hand full of 2k servers that use silent rip. We use 2 Linux gateways with separate isp's. Each gateway does a ' default-originate' to advertise its default route in ripv2(with on having a different metric). The main gateway has a ping script written in shell that will ping the gateway, determine if its up or down; With either result it checks its history of the last 3 intervals, and will only stop rip if or start rip if there is/was 3 concurrent ups or downs. I have been running this for 2 years with no problems. I hope this helps ___LARTC mailing listLARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] failover routing
Hi, yes we run ripv2 and both quagga and zebra. The script on the primary gateway just pings the nexthop. The return value is formated. and stored in a log file. Next the script checks the last three values in the log, if current value 100 (down) or 0 (up) matches the last three values in the log file determines the outcome of either stopping rip or starting it. For example: logfile values 100 100 100 current value 100 --this would stop ripd In order for ripd to start we would need: 0 0 0 in the logfile and a current value 0, this would then start ripd ! this is what is in my secondary gateway ripd.conf router ripdefault-information originateoffset-list 1 out 4 eth0network eth0 access-list 1 permit 0.0.0.0 !this is what is in my primary gateway ripd.conf router ripdefault-information originatenetwork eth0 Jason From: the sew [mailto:[EMAIL PROTECTED]Sent: Tue 2/7/2006 1:58 PMTo: comp.techsCc: lartc@mailman.ds9a.nlSubject: Re: [LARTC] failover routing sounds good, do your run ripv2 with zebra or quagga?, your idea sounds exactly what I have in mind. Mind explaining a bit more technical and sharing some usefull bits in your config?ThanksSew On 2/7/06, comp.techs [EMAIL PROTECTED] wrote: Hi, our network has a hand full of 2k servers that use silent rip. We use 2 Linux gateways with separate isp's. Each gateway does a ' default-originate' to advertise its default route in ripv2(with on having a different metric). The main gateway has a ping script written in shell that will ping the gateway, determine if its up or down; With either result it checks its history of the last 3 intervals, and will only stop rip if or start rip if there is/was 3 concurrent ups or downs. I have been running this for 2 years with no problems. I hope this helps ___LARTC mailing listLARTC@mailman.ds9a.nlhttp://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Divisor
What is the difference between lines below? $TC filter add dev imq0 parent 1:0 prio 5 handle 1: protocol ip u32 divisor 1 $TC filter add dev imq0 parent 1:0 prio 5 handle 2: protocol ip u32 divisor 256 What divisor is doing? And the last problem... $TC filter add dev imq0 protocol ip parent 1:0 prio 5 u32 ht 800:: match ip src 10.0.0.0/16 hashkey mask 0x00ff at 12 link 2: Why after ht should be 800? When 801:: is correct value? When this value should be different. Please help me understand this. -- Konrad aka Lenthir ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Divisor
Not sure about the divisor; but your number 800 can be any hexadecimal number (within reason). This value is the name of the hash table, so each hash table should have it's own name (i.e. 800::, 801::, etc.) Someone can correct me if I am wrong, because I don't have a lot of experience with HTs. Devanshu Konrad wrote: What is the difference between lines below? $TC filter add dev imq0 parent 1:0 prio 5 handle 1: protocol ip u32 divisor 1 $TC filter add dev imq0 parent 1:0 prio 5 handle 2: protocol ip u32 divisor 256 What divisor is doing? And the last problem... $TC filter add dev imq0 protocol ip parent 1:0 prio 5 u32 ht 800:: match ip src 10.0.0.0/16 hashkey mask 0x00ff at 12 link 2: Why after ht should be 800? When 801:: is correct value? When this value should be different. Please help me understand this. -- Konrad aka Lenthir ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- Devanshu Mehta Advanced Networks and Applications Group MIT Lincoln Laboratory ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Limited quantity of filters.
Konrad wrote: gypsy wrote: Konrad, Specify a prio in each 'filter add' line. The SAME prio for each filter. Not specifying any filter won't work, but with a prio you can load at least 64K filter lines. Search this mailing list for please document in July 2004. Thank You. It's working. I've found this message. I'm sorry, because I've not used list's archive to find answer :/ Is it possible to use any search engine (like groups.google.com) to searching only on this list? google (no groups.google, just google.com) LARTC keywords here works for me. You could use the ADVANCED search, putting LARTC and mailman.ds9a.nl into the ALL field, but I think you would still get hits from other places also. FWIW, free news server gmane carries LARTC as gmane.linux.network.routing and my newsreader, although the search phrasing syntax is a pain to deal with, returns the relevant articles. news.gmane.org -- gypsy ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Please help in choosing the right patches
Manish Kathuria wrote: Sandeep Agarwal wrote: I have gone through http://www.ssi.bg/~ja/nano.txt AND further http://www.ssi.bg/~ja/ got confused in choosing the right patch. Please suggest if I will choose Jumbo Patch patch-2.4.20-ja1.diff , is any other patches also required after this? If yes, is there any sequence in applying these patches?For your purpose, you need to choose one of the patches athttp://www.ssi.bg/~ja/#routes depending on your kernel. You dont need the Jumbo patch for load balancing and failover. The "routes" patch should suffice.--Manish Kathuriahttp://www.tuxspace.com/ Thanks Manish. I have download routes-2.4.20-9.diff as I have RHEL3.0 (Kernel 2.4.21-9EL) apply the same. But the output as follows. Is this normal or any problem? # patch -p1 routes-2.4.20-9.diffpatching file linux/include/linux/netfilter_ipv4/ip_nat.hpatching file linux/include/linux/rtnetlink.hHunk #1 succeeded at 231 (offset 3 lines).patching file linux/include/net/ip_fib.hHunk #1 FAILED at 162.Hunk #2 succeeded at 180 with fuzz 1 (offset 5 lines).1 out of 3 hunks FAILED -- saving rejects to file linux/include/net/ip_fib.h.rejpatching file linux/include/net/route.hHunk #1 FAILED at 49.Hunk #2 succeeded at 120 with fuzz 2 (offset -8 lines).Hunk #3 FAILED at 140.2 out of 3 hunks FAILED -- saving rejects to file linux/include/net/route.h.rejpatching file linux/net/ipv4/arp.cpatching file linux/net/ipv4/fib_frontend.cHunk #3 succeeded at 212 with fuzz 2.Hunk #4 FAILED at 222.Hunk #5 FAILED at 244.Hunk #6 succeeded at 583 (offset -7 lines).2 out of 7 hunks FAILED -- saving rejects to file linux/net/ipv4/fib_frontend.c.rejpatching file linux/net/ipv4/fib_hash.cHunk #2 FAILED at 313.Hunk #3 succeeded at 461 (offset 24 lines).Hunk #5 succeeded at 653 (offset 22 lines).1 out of 5 hunks FAILED -- saving rejects to file linux/net/ipv4/fib_hash.c.rejpatching file linux/net/ipv4/fib_rules.cHunk #1 FAILED at 307.Hunk #2 succeeded at 376 with fuzz 2.1 out of 2 hunks FAILED -- saving rejects to file linux/net/ipv4/fib_rules.c.rejpatching file linux/net/ipv4/fib_semantics.cHunk #4 succeeded at 365 (offset -1 lines).Hunk #5 FAILED at 383.Hunk #6 succeeded at 438 (offset 2 lines).Hunk #7 FAILED at 637.Hunk #8 succeeded at 905 (offset -1 lines).Hunk #9 succeeded at 954 (offset 2 lines).Hunk #10 succeeded at 1007 (offset -1 lines).Hunk #11 succeeded at 1025 with fuzz 1 (offset 2 lines).Hunk #12 succeeded at 1070 (offset -1 lines).2 out of 12 hunks FAILED -- saving rejects to file linux/net/ipv4/fib_semantics.c.rejpatching file linux/net/ipv4/ip_nat_dumb.cHunk #1 FAILED at 124.1 out of 1 hunk FAILED -- saving rejects to file linux/net/ipv4/ip_nat_dumb.c.rejpatching file linux/net/ipv4/netfilter/ip_fw_compat_masq.cHunk #2 FAILED at 67.Hunk #3 succeeded at 104 (offset 1 line).1 out of 3 hunks FAILED -- saving rejects to file linux/net/ipv4/netfilter/ip_fw_compat_masq.c.rejpatching file linux/net/ipv4/netfilter/ip_nat_core.cHunk #1 succeeded at 959 (offset 6 lines).patching file linux/net/ipv4/netfilter/ip_nat_standalone.cpatching file linux/net/ipv4/netfilter/ipt_MASQUERADE.cHunk #1 FAILED at 88.1 out of 1 hunk FAILED -- saving rejects to file linux/net/ipv4/netfilter/ipt_MASQUERADE.c.rejpatching file linux/net/ipv4/route.cHunk #1 succeeded at 928 (offset 78 lines).Hunk #2 FAILED at 1352.Hunk #3 FAILED at 1366.Hunk #4 succeeded at 1328 with fuzz 2.Hunk #5 FAILED at 1348.Hunk #6 succeeded at 1456 (offset 77 lines).Hunk #8 succeeded at 1485 (offset 77 lines).Hunk #9 FAILED at 1524.Hunk #11 succeeded at 1577 with fuzz 2 (offset 81 lines).Hunk #12 FAILED at 1590.Hunk #14 succeeded at 1625 (offset 81 lines).Hunk #15 succeeded at 1580 with fuzz 2 (offset 2 lines).Hunk #16 FAILED at 1593.Hunk #17 succeeded at 1737 (offset 80 lines).Hunk #18 FAILED at 1753.Hunk #19 succeeded at 1723 (offset 3 lines).Hunk #20 FAILED at 1760.Hunk #21 FAILED at 1850.Hunk #22 FAILED at 1858.Hunk #23 FAILED at 1901.Hunk #24 FAILED at 1909.Hunk #25 FAILED at 1972.Hunk #26 FAILED at 2053.14 out of 26 hunks FAILED -- saving rejects to file linux/net/ipv4/route.c.rejpatching file linux/net/netsyms.cHunk #1 succeeded at 259 (offset 11 lines).# Thankyou, Sandeep Agarwal ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Limit bandwidth per IP
On Mon, Feb 06, 2006 at 10:06:36PM -0600, Rob Kobiske wrote: I would like to limit the amount of bandwidth each IP in a network gets. For example I have a network that runs at 10mbit. I have a class C 192.168.1.0/24 that makes up this network. Is there any simple way I can say each IP in that class C gets 56k with out making a rule for each IP? I would write a script to fill a hash. (I guess there is another solution, but nobody have posted it yet) Thanks, Rob Kobiske -- _,-=._ /|_/| `-.} `=._,.-=-._., @ @._, `._ _,-. ) _,.-' `G.m-^m`m'Dmytro O. Redchuk ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Please help in choosing the right patches
Sandeep Agarwal wrote: Manish Kathuria wrote: Sandeep Agarwal wrote: I have gone through http://www.ssi.bg/~ja/nano.txt AND further http://www.ssi.bg/~ja/ got confused in choosing the right patch. Please suggest if I will choose Jumbo Patch patch-2.4.20-ja1.diff , is any other patches also required after this? If yes, is there any sequence in applying these patches? For your purpose, you need to choose one of the patches at http://www.ssi.bg/~ja/#routes depending on your kernel. You dont need the Jumbo patch for load balancing and failover. The routes patch should suffice. -- Manish Kathuria http://www.tuxspace.com/ Thanks Manish. I have download routes-2.4.20-9.diff as I have RHEL3.0 (Kernel 2.4.21-9EL) apply the same. But the output as follows. Is this normal or any problem? # patch -p1 routes-2.4.20-9.diff Hunk #1 FAILED at 162. Hunk #2 succeeded at 180 with fuzz 1 (offset 5 lines). 1 out of 3 hunks FAILED -- saving rejects to file linux/include/net/ip_fib.h.rej patching file linux/include/net/route.h Hunk #1 FAILED at 49. Hunk #2 succeeded at 120 with fuzz 2 (offset -8 lines). Hunk #3 FAILED at 140. 2 out of 3 hunks FAILED -- saving rejects to file linux/include/net/route.h.rej patching file linux/net/ipv4/arp.c patching file linux/net/ipv4/fib_frontend.c Hunk #3 succeeded at 212 with fuzz 2. Hunk #4 FAILED at 222. Hunk #5 FAILED at 244. The Red Hat kernels are not just plain vanilla kernels. They already have a number of patches applied by Red Hat and it is likely that the patch being applied by you is conflicting by one of those. You can either try some other kernel version or download a plain vanilla kernel from http://www.kernel.org/ and apply the routes patch on it. -- Manish http://www.tuxspace.com/ ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
