[LARTC] Activate ingress policies on suse ent erpr ise serv er 9
Title: [LARTC] Activate ingress policies on suse ent erpr ise serv er 9 Hi, The problem is this is my goal to use the policier and not the iptables. Because with the policier i think you can give more rules and restrictions to the incoming tcpip traffic. So I would prefer to use the policier and not the iptables. Thanks Gernot > GRAMES Gernot > __ > SIEMENS AG Austria > PSE SMC AI 21 > * Tel.: +43 (0) 5 1707 24356 > * FAX: +43 (0) 5 1707 54600 > * E-Mail: mailto:[EMAIL PROTECTED] > Siemensstrasse 88 - 92 > A-1210 VIENNA > __ > -Ursprüngliche Nachricht- Von: Andy Furniss [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 25. April 2005 21:49 An: Grames Gernot Betreff: Re: AW: AW: AW: AW: AW: [LARTC] Activate ingress policies on suse ent erpr ise serv er 9 Grames Gernot wrote: > Hello, > > Maybe you can explain me the kernel selections a little bit more detailed! > Where can I find this? How to activate? Kernel Compilation necessary? How > compile? > > Sorry I am a beginner in this section. I think the easiest way for you to do it is not bother using policers to drop packets, but use iptables instead. If you use distros I can not tell you exactly what to do about compiling a new kernel as I use LFS and there are probably differences. If you really need to use policer say and I'll tell you how I do them - but I really think what you want to do is best done with just iptables rules. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Spill over
A little googling tells me 250 ZAR ~ 42 USD. Is this correct? If so, ouch.. that's pricey. 3GB (assuming B in this case is BYTE) comes out to about 9kbit / second over a month, if I did my math correctly. Ouch again. Does the 3GB apply to the total of up and down traffic, or just down? Because you can't control traffic coming to you very well. You can try to control TCP traffic with policing, but UDP traffic does its own thing. Not to mention jokers who decide to flood the link for the hell of it. Given this new info, it sounds more like you shouldn't try to use the 512kbit link at all unless the 64kbit link goes down. If you do try to push "excess" traffic onto it, all that does is encourage the use of applications that will consume the entire bandwidth available. If that is really beyond your budget, it doesn't seem like something you'd want to do. Better to set the expectations at 64kbit so the users don't get the idea of tuning into Internet radio or something. In fact, if the 64kbit link does go down, it could be a good idea to police the 512kbit link down to 64kbit, just so the users don't jump for joy when the 64kbit link goes down... (keeping in mind that policing is no guarantee that you'll actually stay below 64kbit usage, especially if a lot of the traffic is UDP). - Original Message - From: Kenneth Kalmer To: Chris Bennett ; Taylor Grant Cc: lartc Sent: Monday, April 25, 2005 2:48 AM Subject: Re: [LARTC] Spill over Taylor & Chris (and the list)The arguments behind my choice here is cost driven, the 64kbps line is a fixed monthly rate for unlimited use, the 512kbps line costs us roughly ZAR250 per 3GB of usage. This can get quite expensive as the lines in question is for a college and we all know what students do to bandwidth :)Taken the amount we pay every month for the 64kbps line it's more economical to over utilize the link as a primary connection than to have it lying around as a backup. South Africa and data connections don't go well in the same sentence...As Chris suggested, I need something that can detect when Link A is saturated and then redirect the traffic over Link B until there is available bandwidth on Link A again. The rate limit trick of Taylor might work once I get to understand the usage patterns of these students. But for at least the first 3 months I won't have proper data at my disposal.Thanks for your replies! ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] IP2P & Skype question
After doing some reading (http://www1.cs.columbia.edu/~library/TR-repository/reports/reports-2004/cucs-039-04.pdf) it looks like the only easy way to detect and stop Skype communications is through he connection to the Skype login server and treat the traffic coming from that host as if is Skype traffic. If you are wanting to classify Skype traffic I'm not sure how to help. However if you are just wanting to prevent Skype from being able to communicate on your network you may be able to look for the traffic that the Skype client sends to the Skype Login Server as it tries to login to the Skype network. I have a feeling that if you DROPed this traffic the Skype client would not be able to communicate with the Skype network and thus block this traffic. Any thing beyond this is going to be extremely difficult to block as Skype is a generational enhanced protocol from the developers of Kazaa and thus going to be very hard to stop. IMHO Skype will make blocking Yahoo Instant Messenger look easy. This is very scary to me, a network administrator. :( I have a feeling the real way to deal with this will be to write a Skype client that will connect to the network and find as many Skype Super Nodes as it can and add the IPs of the SNs as well as the corresponding port (as it is possibly dynamic) and add them to an IPSet via an external program. unfortunately this is something that will have to be maintained via a cron job or something else and thus not easy. I have a feeling that we are going to see more and more things like this on the net as more and more people are trying to fight security thus we SAs have to work harder and harder. If you try to make the world more idiot proof the universe will build a better idiot. The universe is winning. Grant. . . . Andreas Klauer wrote: Okay. That's details about the protocol I have no clue about. If only one packet can be matched, I'd probably try to squeeze as much information out of this one as possible (source and destination address or whatever can be obtained) and then shape using this criteria. If you're lucky, you know this stuff beforehand, and can use static shaping/filter rules for that, otherwise you'll have to whip up a more dynamic solution. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] filtering ipv6
does the current version of tc support ipv6 filtering? i came accross this web page http://lartc.org/howto/lartc.adv-filter.ipv6.html and wanted to know if this is a round about way and can ipv6 filtering be done on other parameters? thanks. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Spill over
Kenneth Kalmer wrote: Taylor & Chris (and the list) The arguments behind my choice here is cost driven, the 64kbps line is a fixed monthly rate for unlimited use, the 512kbps line costs us roughly ZAR250 per 3GB of usage. This can get quite expensive as the lines in question is for a college and we all know what students do to bandwidth :) Taken the amount we pay every month for the 64kbps line it's more economical to over utilize the link as a primary connection than to have it lying around as a backup. South Africa and data connections don't go well in the same sentence... As Chris suggested, I need something that can detect when Link A is saturated and then redirect the traffic over Link B until there is available bandwidth on Link A again. The rate limit trick of Taylor might work once I get to understand the usage patterns of these students. But for at least the first 3 months I won't have proper data at my disposal. Thanks for your replies! Seeing as you are trying to avoid excessive bandwidth charges you find you self in a rather interesting position. Aside form what ever you end up using to control what route your traffic goes out you will ultimately want to have a fairly tight set up on what type of traffic is allowed. I have a client here in my town that managed to saturate an ADSL connection in the first 72 hours that we had the network in a testing state before we even went live with it. Ultimately we had to keep the traffic under 20 GB worth every month or they incurred extra charges. To this end I ended up setting up the router to only allow outbound traffic if it was destined to the following ports: (20) 21, 22, 23, 25, 53, 80, 110, 119, 143, and 443. I told the client that we would run with that set up until they told me that they needed another port opened for any given reason. I took the mentality of everything else will be shut down unless you can give me a reasonable request that is backed by someone with political authority (House monitor, Board Members, etc) that says that it is ok for you to be using this type of traffic. After I did this things have been GREAT. We have not had any more problems save for the month that they did not pay the ISP. The real problem that I see in trying to keep one link saturated is that you can control the outbound traffic but you have no way to control the inbound traffic. Well there are ways that you can attempt to control the inbound traffic but they are more a responsive control method (which is less likely to succeed) than a proactive control method like you can do if you control the sending end of the connection. A really drastic idea that I have that might not be too hard to implement would be to establish a PPP multilink session out both connections to a server somewhere on the internet that has HIGH bandwidth (more than your aggregate bandwidth). What this will allow you to do is control what link the traffic will come in and out. All your traffic would appear to be coming from the IP of the server out on the net but I don't see that as a problem really. I think if you do this you can set up routing and traffic control to try to use the 64 kbps link as the primary link and role over to the 512 kbps ASDL link if the first is saturated. I'm not sure how to go about doing this as this would be either in side of the PPP set up or some other complex method. You cold have traffic split across both links too as you control both ends and can reassemble it the way that it needs to be before it is sent out to the world or in to your LAN. One really nasty what that I could think to make this work would be to set up a default gateway to the IP of the ISP side of the 64 kbps link with a metric of 1 and a default gateway to the IP of the ISP side of the 512 kbps link with a metric of 2. You would need to watch the rate of traffic flowing out the 64 kbps link and any traffic that would be over it you would need to reject with no route to host which would cause your router to choose the other default route out, in this case the 512 kbps link. One MAJOR draw back to this that I see is that you would need / want to flush your routing cache fairly often, at least once per minute to make sure that your router would not end up learning that the 64 kbps link had problems and thus start using the 512 kbps link as a de-fac-to standard by remembering that the 64 kbps link did not have a route to any specific host. Something else that you should consider is that the subnets directly on the other side of each respective link have the best route to them of that said link vs going out the other link and hopping around on the internet to get back in to the first links IPSs network. Why take the long way around the building around the back to get from one front corner to the other? This is the type of paradigm that you will be creating. If this is not an issue you can disregard this statement. Needless to s
Re: [LARTC] IP2P & Skype question
Sorry it is IPP2P. I see the L7-filter looks like it might suite my needs a lot better. I have received a number of replies on my original request - all very useful. I have an open question with the IPP2P people over Skype and hope they get back to me. I read somewhere it can be used for detection Skype, but I am trying to find confirmation. I will go dig into the L7-filter stuff and see how I get on. Thanks Gary Smith Andreas Klauer wrote: On Monday 25 April 2005 15:08, Gary Smith wrote: I need to detect Skype traffic using (I think it can be done) IP2P. What's IP2P? I only know IPP2P, and I can't find anything about Skype on the official homepage (www.ipp2p.org). It's only for P2P filesharing networks. Maybe you could test Skype support of l7-filter and give the authors some feedback (http://l7-filter.sourceforge.net/protocols lists Skype as supported, but untested). HTH Andreas ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] IP2P & Skype question
On Monday 25 April 2005 16:33, Justin Schoeman wrote: > In some cases, it is possible to block Skype, as the existing pattern > seems to match an important, but not yet encrypted packet. Okay. That's details about the protocol I have no clue about. If only one packet can be matched, I'd probably try to squeeze as much information out of this one as possible (source and destination address or whatever can be obtained) and then shape using this criteria. If you're lucky, you know this stuff beforehand, and can use static shaping/filter rules for that, otherwise you'll have to whip up a more dynamic solution. HTH Andreas ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] IP2P & Skype question
I don't think Skype works very well with any of these. I have tried the l7-filter pattern, with no luck. Apparently, the big problem is that Skype traffic is encrypted, and so it is not possible to match it using fixed patterns. In some cases, it is possible to block Skype, as the existing pattern seems to match an important, but not yet encrypted packet. Shaping is however not possible, as the matched packet makes up very little of the traffic. -justin Andreas Klauer wrote: On Monday 25 April 2005 15:08, Gary Smith wrote: I need to detect Skype traffic using (I think it can be done) IP2P. What's IP2P? I only know IPP2P, and I can't find anything about Skype on the official homepage (www.ipp2p.org). It's only for P2P filesharing networks. Maybe you could test Skype support of l7-filter and give the authors some feedback (http://l7-filter.sourceforge.net/protocols lists Skype as supported, but untested). HTH Andreas ___ LARTC mailing list LARTC@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] IP2P & Skype question
On Monday 25 April 2005 15:08, Gary Smith wrote: > I need to detect Skype traffic using (I think it can be done) IP2P. What's IP2P? I only know IPP2P, and I can't find anything about Skype on the official homepage (www.ipp2p.org). It's only for P2P filesharing networks. Maybe you could test Skype support of l7-filter and give the authors some feedback (http://l7-filter.sourceforge.net/protocols lists Skype as supported, but untested). HTH Andreas ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] TCQ_F_THROTTLED question
Hello Can someone explane to me how the TCQ_F_THROTTLED flag and the watchdog function used in tbf and htb works? To be more specific, (reading tbf code) if there are not enough tokens, a watchdog timer will be "started" and the TCQ_F_THROTTLED flag set. But what happens then the time is up? where is the code reentered? What does the flag "really" mean? If someone could take a moment to answer these question it would be great, or point to documentation or disscussion (if one exists) With regards R.harper _ Find det, du søger på MSN Søg http://search.msn.dk ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] IP2P & Skype question
Hi, I am not sure if this is the correct destination for this email question, so if not, please can someone direct me to the correct mailing list / user. I need to detect Skype traffic using (I think it can be done) IP2P.on a RH Linux 2.4.20 kernel as well as the later fedora platforms. We have built it into your kernel, but are looking for some help in the matching parameters for skype in particular. Can anyone help me with anything to do with Skype and ip2p detection patterns. Thanks Gary -- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] filtering
Grace Baldonasa wrote: Hi, Can I use mac address as classifiers in the filters? Yes for dst mac A1:B2:C3:D4:E5:F6 it's tc filter add dev eth0 parent 1:0 protocol ip prio 1 \ u32 match u16 0x0800 0x at -2 \ match u32 0xC3D4E5F6 0x at -12 \ match u16 0xA1B2 0x at -14 \ flowid 1:1 For src I assume you can just change the offsets - I've not tried it as there is an iptables match for src MAC. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] TC
Grace Baldonasa wrote: Hi, I need the source code of the TC utility, can someone direct me to the site to which I can download it. Thanks. http://developer.osdl.org/dev/iproute2/ Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] TC
hi > I need the source code of the TC utility, can someone direct me to > the site to which I can download it. Search for iproute at freshmeat.net //Jesper ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] filtering
Hi, Can I use mac address as classifiers in the filters? Grace ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] TC
Hi, I need the source code of the TC utility, can someone direct me to the site to which I can download it. Thanks. grace ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] TC
On Monday April 25 2005 01:00, you wrote: > Hi, > > Thanks. > I tried the site you gave me below. Looks like it's a restricted site. > Any chance I can get access to it? Sorry .. I'm wrong give you the url :) You can try http://www.linuximq.net Regards, Daniel ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB stalling
Krystian Antoni wrote: the stalls might last as long as 5 seconds and when they happen, everything including a web browser stops working. ill be back tuesday evening so then i'll try to look at my system. Maybe I should try with a script more like you are using if you don't mind posting. One thought I have is that htb seems to have far longer default queues than it used to. If you have set a default class other than 0 with a low rate then your arp packets may be getting stuck in a very long queue. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] TC
Thanks. Got it correct now. grace ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] TC
Hi, Thanks. I tried the site you gave me below. Looks like it's a restricted site. Any chance I can get access to it? Thanks. regards, Grace On 4/26/05, Daniel Harold L. <[EMAIL PROTECTED]> wrote: > On Monday April 25 2005 00:08, Grace Baldonasa wrote: > > > 1. Is TC works on an interface of a physical device only? > > No. There is an virtual device called imq (http://linuximq.net) > > > 2. My objective is to limit the upload/download rate of each computer > > in our local network attached to CPE. In this case, all PC's are > > attached to common interface (let's sat eth0), will I be able to > > filter or limit individiual PC on their UL/DL rate? > > Yes. You can do it with imq+u32 filter .. > > Regards, > > Daniel > > ___ > LARTC mailing list > LARTC@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] TC
On Monday April 25 2005 00:08, Grace Baldonasa wrote: > 1. Is TC works on an interface of a physical device only? No. There is an virtual device called imq (http://linuximq.net) > 2. My objective is to limit the upload/download rate of each computer > in our local network attached to CPE. In this case, all PC's are > attached to common interface (let's sat eth0), will I be able to > filter or limit individiual PC on their UL/DL rate? Yes. You can do it with imq+u32 filter .. Regards, Daniel ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Immediately drop packet for default class ini htb
On Monday April 25 2005 09:02, you wrote: > Thanks for Andreas Klauer, I have workaround for this problem. > By default..default class in htb has 1000 packets length queue, so I just > attach an sfq qdisc to solve this problem. > > Best regards, > > Daniel ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Help!
On Mon, 2005-04-25 at 15:20 +0800, Grace Baldonasa wrote: > HI all, > > Im kind of new to this Bandwidth Management thing. I want to ask if > this is the right mailing list for me to ask questions regarding TC > for bandwidth shapping? > Thanks. Yep.. -- Ow Mun Heng Gentoo/Linux on DELL D600 1.4Ghz 98% Microsoft(tm) Free!! Neuromancer 16:18:42 up 19:25, 7 users, load average: 0.32, 0.18, 0.24 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] TC
Thanks for the very prompt reply. I've been googling already for a few days now trying to understand how bandwidth management works. I came to understand that TC is a utility that I can use to shape up my local network bandwidth consumption. Im hoping I will be guided here through. Here are my questions: 1. Is TC works on an interface of a physical device only? 2. My objective is to limit the upload/download rate of each computer in our local network attached to CPE. In this case, all PC's are attached to common interface (let's sat eth0), will I be able to filter or limit individiual PC on their UL/DL rate? Seeing those examples in the net, tc works on device interface only. Hope my understanding is not correct. Thanks. More question to come.. grace ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Spill over
Taylor & Chris (and the list) The arguments behind my choice here is cost driven, the 64kbps line is a fixed monthly rate for unlimited use, the 512kbps line costs us roughly ZAR250 per 3GB of usage. This can get quite expensive as the lines in question is for a college and we all know what students do to bandwidth :) Taken the amount we pay every month for the 64kbps line it's more economical to over utilize the link as a primary connection than to have it lying around as a backup. South Africa and data connections don't go well in the same sentence... As Chris suggested, I need something that can detect when Link A is saturated and then redirect the traffic over Link B until there is available bandwidth on Link A again. The rate limit trick of Taylor might work once I get to understand the usage patterns of these students. But for at least the first 3 months I won't have proper data at my disposal. Thanks for your replies! On 4/24/05, Chris Bennett <[EMAIL PROTECTED]> wrote: You can't split a particular IP connection between two links, but can instead only determine which link a particular connection will occur on. Given this, it sounds like you want to have some way to detect that Link A is already saturated and then send all further connections to Link B until Link A is no longer saturated. Maybe someone can tell you how to do that if that's really what you want to do (others here know far more about this than me), but my guess is you really don't want to do that. With the huge bandwidth disparity between the two links, route cacheing, and the inability know how much bandwidth any particular conneciton will consume, I think you'd end up with a giant mess... those people with connections unlucky enough to end up on Link A would probably be very unhappy people indeed. Generally speaking I think it would make more sense to put all traffic over Link B, and then use Link A only for emergencies. Maybe route the most critical traffic over Link A if you really want to feel like its being utilized as something other than a pure backup, but personally I wouldn't even do that. Just because Link A is more reliable and more expensive doesn't mean it makes sense to use it as your primary conduit. With Link B having eight times the bandwidth, it seems the obvious choice as the primary. Use it, and keep the users happy most of the time (instead of making them miserable most of the time). On the rare ocassions it goes down, use bandwidth shaping to make sure the highest priority traffic gets access to Link A first. In all the time I've used DSL, I've had severe outages twice for reasons other than standard maintenance. In both cases (in two separate locations), the cause was the ILEC phone company mistakingly dropping the wire pair while doing other work (freakin took over a week in each case to get my connectivity back!!). This sort of thing could just as easily happen with a leased line though, so I'm not really sure I buy that the leased line is really more reliable than DSL line from a high quality ISP. Although maybe a particular SLA makes it so in some legal sense since you can then sue someone. Personally, if your leased line really costs more than the DSL, I'd get rid of it and get a 2nd DSL line from another provider and use that as your backup instead. Anyway, I guess my main point is that the high cost of your leased line might be clouding your thinking on this. I wouldn't let the comparitive cost be your guiding light here. Go with what makes sense from a technology perspective, and don't guilt yourself into trying to get full utilization out of the slow link just because it costs more. - Original Message - From: Kenneth Kalmer To: lartc Sent: Saturday, April 23, 2005 4:34 PM Subject: [LARTC] Spill over ListI need some help, advice or just a starting point on the following situation:Link A - 64kbps leased lineLink B - 512kbps ADSL lineIs it possible to have Link A saturated constantly and have the excess traffic "spill over" onto Link B? I know it's possible to have packets sent down links in a round-robin fashion and I've read in the howto on load sharing over multiple interfaces (http://lartc.org/howto/lartc.loadshare.html ), but I do not have control over the termination of the link at the ISP's (two different one as well). Also note that splitting different protocols over each of these links are not possible in our case.Reason being, Link A is a more reliable and more expensive link, so I need to over-use it's capacity if it we're, and use the cheaper ADSL (link B) offering to keep al services running when the leased line (A) is saturated.Any tips, suggestions and comments would be welcomed.Regards-- Kenneth Kalmer[EMAIL PROTECTED] http://opensourcery.blogspot.com ___LARTC mailing listLARTC@mailman.ds9a.n
[LARTC] Help!
HI all, Im kind of new to this Bandwidth Management thing. I want to ask if this is the right mailing list for me to ask questions regarding TC for bandwidth shapping? Thanks. Grace ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] HTB stalling
> Kunszt Arpad wrote: > > I use the CPU as timer and I have a dual Xeon box. So I use the SMP but > > I have phisically 2 CPUs. I don't use HyperThreading. > > The TSCs on an SMP box may drift apart. Can you reproduce the problem > with gettimeofday as time source? I'll make a try in the next 2-3 days. Arpad Kunszt signature.asc Description: Ez az =?ISO-8859-1?Q?=FCzenetr=E9sz?= =?ISO-8859-1?Q?_digit=E1lis?= =?ISO-8859-1?Q?_al=E1=EDr=E1ssal?= van =?ISO-8859-1?Q?ell=E1tva?= ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Immediately drop packet for default class ini htb
On Monday 25 April 2005 15:19, Daniel Harold L. wrote: > How to immediately drop packet for default class in htb ? I`m using > kernel 2.6.5+htb+imq ... > I have to immediately drop packet that flow in default class because > that class have queue length 1000 packets before dropping packet ... :(( Well, it all depends on how a packet ends up in your default class. For example, if you use iptables for packet marking, you could let iptables drop all packages that were not marked. This would be the best way to go. If that's not possible, you could probably try to attach another qdisc to your default HTB class (leaf classes can be parents for qdiscs), which then just drops all the packets flowing into it (any rate limiter set to a very low rate should do). However, that's not a very clean solution, and might cause other problems, I'm not sure ;-) HTH Andreas ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
