Re: [LARTC] 300mhz fast enough for a 100mbit bridge with filtering
Robert Davidson wrote: On Sunday 03 November 2002 23:59, Michael T. Babcock wrote: I don't know if it can, but remember that there are server machines available with Crusoe chips in them that have no fans too. do you know any company that tells complete Crusoe pcs? any urls? Yes; transmetazone.com (great name) has the FiberCycles WebBunker ... http://www.transmetazone.com/articleview.cfm?articleID=585 Its a bit high-end, but you should be able to find others (the netwinder for example is two servers in a 1U rack case for $2500); The WebBunker Model FC206i - the first of FiberCycle's WebBunker line of servers - will hit the market mid-second quarter this year for around $9,300 USD or about $1500 per CPU blade . The 2U rack-mounting unit has six independent single-cpu servers (it will be able to scale dual Crusoe processors shortly), dual redundant power supplies and IO blades all in one package. The FC206i will rely upon a 20Gb EIDE ATA-100 hard drive for permanent storage, and come equipped with 256Mb of onboard DDR SDRAM. One expansion DIMM slot will enable a maximum up 756Mb memory per CPU. Each of the six CPU bays contains a completely independent TM5600 Crusoe based server, with the CPU and system board up front, and the hard drive in rear. -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] 300mhz fast enough for a 100mbit bridge with filtering
Robert Penz wrote: My questions is now, can this cpu handle that? May some of you have a that slow cpu runing. or we're can I find benchmarks? I don't know if it can, but remember that there are server machines available with Crusoe chips in them that have no fans too. -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Re: [release] ipsysctl tutorial 1.0.1
Oskar Andreasson wrote: My question hence is, how is the state of syn cookies today? How does it actually affect SACK, T/TCP, ECN, and other new extensions? That's what I want to find out before making a more final statement in the document. (erh, ok it sounds kind of final as it looks right now, but I want to check it up at least before doing any final statements). According to the netfilter documentation at <http://logi.cc/linux/netfilter-log-format.php3>, you should always have SYN cookies on with publically accessible TCP ports (log analysis page, fwiw). Paper on advanced TCP algorithms: http://www.google.ca/search?q=cache:vVQeUAOMmnoC:www.ce.chalmers.se/staff/otel/papers-mine/tcp-improvements/TCP-improvements.ps+linux+syn+cookies+ecn+sack&hl=en&ie=UTF-8 Advantages and flaws of T/TCP: http://www.linuxgazette.com/issue47/stacey.html "SYN cookies were implemented in the Linux kernel to combat this attack. It involves sending a cookie to the sender to verify the connection is valid. SYN cookies cause problems with T/TCP as no TCP options are sent in the cookie and any data arriving in the initial SYN can't be used immediately. The CC option in T/TCP does provide some protection on its own, but it is not secure enough." Mailing list discussion on cookies and T/TCP from 1998: http://www.uwsg.iu.edu/hypermail/linux/kernel/9804.1/0650.html FWIW, could the kernel code that uses T/TCP automagically disable SYN cookies for those packets? -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Re: [release] ipsysctl tutorial 1.0.1
bert hubert wrote: Please keep this stuff off lartc.org. There has been enough flaming regarding SYN cookies and whatnot. Put that on the mailing list FAQ then; otherwise its fair game. I actually know some of the people mentioned on DJBs page in real life and they are bone tired of it all too. I'm not quite convinced that my being tired of something or not prevents you from telling me I'm wrong about something or requesting discussion about it -- especially when its material relevant to the subject of the list. PS, assuming they are tired of it, why have I never seen a good (well-prepared / documented) commentary on the issue from any of them? However, So give it a rest. Please do not respond to this message Obviously, I replied -- but I'm sure you expected as much when you sent your message. You're free of course to boot me from the list if you feel that my desiring clarification on a long-standing issue (in two whole messages; three with this one) is too much for you to handle. In case you're wondering, I'm not much of a DJB supporter myself, but I do appreciate (and usually demand) accuracy, especially where it affects my servers and my work. FUD, on either side, is not appreciated, in the least, nor is complete silence. Your Kind List Administrator -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Re: [release] ipsysctl tutorial 1.0.1
Don Cohen wrote: > I'd like to ask for some clarifications, if not quoting, in the tutorial > on page x321.html (not sure of section numbers) re: syn cookies. I don't understand what the question is here. It isn't a question (thus the lack of question mark). I asked for either a clarification or a quotation of the page mentionned in the FAQ to avoid confusion (or add some?) about syn cookies. > Dan Bernstein (everyone's favorite mathematician :-) ) makes it very I was not aware of that. DJB, as he is known, tends to be a bit strong minded and has a habit of thinking that everyone should want what he wants. He also has a tendancy to write secure software and is a pretty good number cruncher too (has his own hash library, does cryptography, etc.) Some love him, some hate him, but if you search for 'DJB' on Google, I'm sure you'll find plenty. I was also not aware of any such controversy, but I think the points below are correct. I have a good feeling they're correct too, since I've been using syn cookies "forever" now without any problems of which I'm aware. I'm surprised those mentionned haven't said anything (or that I haven't read it yet) that contradicts DJB (who was involved in the design of SYN cookies). -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Fair Bandwidth sharing with HTB and EFSQ
Kerschbaumer Samuel wrote: I downloaded the HTB and ESFQ packages and installled the patched kernel and tools. Now can someone give me an example how to configure my system so that the 512Kbit are fairly divided for each computer ? Assume that eth0 is the interface on the WAN side and eth1 on the LAN side. Someone else can give actual code I'm sure, but you basically want: Add htb class to ethx, speed 512kbit. Add esfq to htb class above. Add filter to make all relevant traffic go through esfq qdisc (above). -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Re: [release] ipsysctl tutorial 1.0.1
Oskar Andreasson wrote: However, I notice one _big_ if in the page you are referring to, which by the way is quite old (dated circa 1996). I have a distinct feeling that many IP based protocols don't change a lot within these types of timespans. Look at how long IPv6 is taking to deploy. "4. TCP options such as RFC1323, SACK and T/TCP options cannot be used." Nowhere does the documents explain how these problems can be solved (I haven't read the whole document yet, so I may burst out prematurely... but I wanted to respond to your questions:)). I would assume that those options use bits in the packet header that SYN cookies also use and therefore make unpredictable. I'm not sure either though. FWIW, I've run all my machines 2.2.x and up with SYN cookies turned on with no (known) ill effects; PCs and servers alike. -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Re: [release] ipsysctl tutorial 1.0.1
Oskar Andreasson wrote: may be of interest to some people on the netdev mailinglist as well. Just to inform people who may be interested, the ipsysctl tutorial has been released in a new version at http://ipsysctl-tutorial.frozentux.net. I'd like to ask for some clarifications, if not quoting, in the tutorial on page x321.html (not sure of section numbers) re: syn cookies. Dan Bernstein (everyone's favorite mathematician :-) ) makes it very clear on http://cr.yp.to/syncookies.html that your warnings are primarily FUD. For the sake of quoting: A few people (notably Alexey Kuznetsov, Wichert Akkerman, and Perry Metzger) have been spreading misinformation about SYN cookies. Here are some of their bogus claims: * SYN cookies ``present serious violation of TCP protocol.'' Reality: SYN cookies are fully compliant with the TCP protocol. Every packet sent by a SYN-cookie server is something that could also have been sent by a non-SYN-cookie server. * SYN cookies ``do not allow to use TCP extensions'' such as large windows. Reality: SYN cookies don't hurt TCP extensions. A connection saved by SYN cookies can't use large windows; but the same is true without SYN cookies, because the connection would have been destroyed. * SYN cookies cause ``massive hanging connections.'' Reality: With or without SYN cookies, connections occasionally hang because a computer or network is overloaded. Applications deal with this by simply dropping idle connections. * SYN cookies cause ``serious degradation of service.'' Reality: SYN cookies /improve/ service. They do take a small amount of CPU time to compute, but that CPU time has to be spent anyway for hard-to-predict sequence numbers; see RFC 1948. * SYN cookies cause ``magic resets.'' Reality: SYN cookies never cause resets. These people also have the annoying habit of crediting their bogus claims to other people, such as me. I don't know whether to attribute this to malice or stupidity; either way, I would like the record to be set straight. I invited Kuznetsov to either retract or defend his claims. He refused to do so. I'm sure he's aware by now that his claims are false, and that any attempted defense will be promptly ripped to shreds; but he's still not admitting his errors. It's unfortunate that he doesn't have more respect for the truth. I also invited Akkerman to either retract or defend his claims. He did not respond. -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] why dont packets go where i want?
Kertész Viktor wrote: I think we are out of sync about what outgoing traffic means. :) (and i am sure i am wrong) When traffic goes through the gw, outgoing traffic means to the gw that packets leave it's eth1 nic, isn't it? From wondershaper i just took examples. Of course wondershaper shapes outgoing traffic with htb. Once more, i download on the client machine, not on the gw. Thanks for replies! :) Outgoing traffic to _any_ machine is the traffic that is /leaving/ _any_ of its network interfaces. -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] 'sport' is good but 'dport'?
박정은 wrote: It never works .. !! If I send to 23 port 50kbps It receive 50kbps.. I have no idea .. Did I thought wrong? You should read the FAQ / HOWTO again; it mentions that you can only shape outgoing packets for a variety of reasons. You can limit incoming packets to some degree (not as well controlled, and somewhat pointless in some cases) by dropping the packets you don't want however, with the ingress filter. -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Can't keep up with all these file sharing programs!
Jason Tackaberry wrote: >I'm using HTB to shape traffic for students in our residences. We're an >extremely small college (about 50 Internet users in our residences) and >we don't have a good deal of bandwidth to work with, so I must do what I >can to make what we do have tolerable to our students. > > Shape all the traffic you recognize, then leave the remaining traffic as "other" and give it whatever's left. That way you don't have to know what the other traffic is at all and you can always add more 'known' protocols to your shaping rules as you become aware of them ... "what do you mean you're using WAIS?" -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB or CBQ ?
Robert Penz wrote: >suse linux? if so, reverse lookup doesn't work, for that ip. > > Note the 'ping -n' -- no reverse lookup being done. -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB or CBQ ?
Vladimír Trebický wrote:
>I use ESFQ and it's stable and functional ;-) Really. Read my article about
>not setting perturb too small.
>
>
Yes, I saw that; its a good hint for SFQ as well (and it fixed some neat
oddities too).
Anyone else seen this one?
ping -n {remote host}
{ 6 second delay }
64 bytes from 216.168.105.33: icmp_seq=0 ttl=255 time=6sec
64 bytes from 216.168.105.33: icmp_seq=1 ttl=255 time=5sec
64 bytes from 216.168.105.33: icmp_seq=2 ttl=255 time=4sec
64 bytes from 216.168.105.33: icmp_seq=3 ttl=255 time=3sec
64 bytes from 216.168.105.33: icmp_seq=4 ttl=255 time=2sec
64 bytes from 216.168.105.33: icmp_seq=5 ttl=255 time=1sec
64 bytes from 216.168.105.33: icmp_seq=6 ttl=255 time=242usec
64 bytes from 216.168.105.33: icmp_seq=7 ttl=255 time=250usec
...
--
Michael T. Babcock
C.T.O., FibreSpeed Ltd.
http://www.fibrespeed.net/~mbabcock
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Iptables, SNAT/MASQ, Multiple gateways
Don Cohen wrote: >I actually sent a proposal to this list that I think provides a good >solution to the general problem: an extension to TCP (possibly even >IP) that supports multiple addresses/ports. This would even allow you >to switch addresses in the middle of a connection. I think what I > > SCTP actually supports this already; look it up -- its quite a bit different from TCP but allows you to do all the same types of things, with more options. That said, a Zebra (routing software) plugin that would run iptables scripts would be all you'd need in many cases. -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB or CBQ ?
Stef Coene wrote: >And one of the mose convincing arguments to me : htb is actively maintained. >If there is a bug or performance problem, it will get fixed. > > And, being newer code that many of us have looked at, patches / fixes will probably flow to the maintainer faster than CBQ ones. BTW, how many people are using the patched SFQ (ESFQ?) these days, and how stable is it? -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] 4 nic advanced routing question
Juan Antonio Morillas Cerezo wrote: >Perhaps it's because of my mail reader not properly >opening html documents, but I'd ask you to make a diagram or >even a drawing, with arrows included, that would help a lot. >Please take into account possible NATings between networks too. > I'm not sure why you're having a problem: --_=_NextPart_001_01C258E3.801CD380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable His document was encoded properly ... -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Limit bandwidth for ipsec vpns
On Mon, Aug 19, 2002 at 07:01:32PM +0200, Stef Coene wrote: > > Is there anyone having an idea on how to limit bandwidth on a linux gw > > doing vpns with freeswan, I.E. for a 1Mbit line with 1 ipsec tunnel on > > interface ppp0, limiting vpn traffic (esp) to 512kbit and internet > > traffic (non vpn) to 512kbit. > More info about shaping can be found on www.lartc.org. And I have some extra > information on www.docum.org. > > You have to add a cbq or htb qdisc to your interfaces and create 2 classes. > One for vpn traffic and one for non vpn traffic. I hope that you use fixed > ports for the vpn traffic so you can use the dst/src port as a filter key. > You can share the same 1mbit or you can limit each class to 512kbit. If FreeS/WAN is used, adding a pair of classes to the external interface for 'normal' and 'VPN' traffic should suffice. VPN traffic is identifiable as traffic over UDP port 500 and protocols 50 or 51, although you may wish to give them their own class with high priority as they do key exchanges. If you gave each 512kbps, then add a root class to ipsec0 of 512kbps and work from there on it. -- Michael T. Babcock CTO, FibreSpeed Ltd. (Hosting, Security, Consultation, Database, etc) http://www.fibrespeed.net/~mbabcock/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Anything out there that is similar to Cisco's WFQ?
Don Cohen wrote: > > From: "CIT/Paul" <[EMAIL PROTECTED]> > > Any help would be greatly appreciated :) This is much better than SFQ :> > >Sounds like SFQ to me. Can you tell us what the differences are? > > PRIO'd SFQ. If you had classful PRIO with SFQ on each band, you'd probably have a similar effect to what's been described; just a guess though. It seems the desire is to 'ignore' low-priority bands if high-priority bands have traffic, and to balance between those sessions. -- Michael T. Babcock CTO, FibreSpeed Ltd. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Subnet/routing question
Try: eth0 (external) - > x.y.z.193/27 eth1 (internal) -> x.y.z.225/27 (non-nat) eth2 (internal) -> 192.168.0.0/24 (nat) eth0 -> turn on proxy_arp eth1 -> turn on proxy_arp eth2 -> leave proxy_arp off. This should work just fine. Connections for the eth1-connected addresses will 'forward' through the box (set up your firewall rules appropriately) from eth0 (and vice-versa). To explain what I mean: ipchains -A forward -s x.y.z.255/27 --jump ACCEPT ipchains -A forward -s 192.168.0.0/24 --jump MASQ ... have fun. -- Michael T. Babcock CTO, FibreSpeed Ltd. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Priority Queueing on Linux
Anton Yurchenko wrote: > nope, here it is. > >http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_c/qcprt2/qcdconmg.htm#23965 > From the page (for those who don't follow links, or for the archives of this list): PQ [Priority Queuing] allows you to define how traffic is prioritized in the network. You configure four traffic priorities. You can define a series of filters based on packet characteristics to cause the router to place traffic into these four queues; the queue with the highest priority is serviced first until it is empty, then the lower queues are serviced in sequence. -- Michael T. Babcock CTO, FibreSpeed Ltd. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] which NIC is which
Arthur van Leeuwen wrote: >Unfortunately, in systems with identical cards that are configured using >plug-and-play methods such as those used by PCI random is the best shot you >have... > > 'Deterministic' is more accurate. It seems to be random, on first boot. But it will almost never change after that unless you make hardware changes, in my experience. -- Michael T. Babcock CTO, FibreSpeed Ltd. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Priority Queueing on Linux
bert hubert wrote: >On Tue, Jul 09, 2002 at 12:02:40PM +0800, Patrick Chan wrote: > > >>There is priority queueing in Cisco router. >> >> >Please dig up a link so we can see what 'priority queueing' actually *is*. >But I bet that tc has it. > > I can almost guarantee Patrick is asking about diffserv support. -- Michael T. Babcock CTO, FibreSpeed Ltd. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Re: [OT] non-Virus attachments
'Ard van Breemen' wrote: >You are not the first one accusing me of that. >This is my .signature indented with a # because some mailers (If >I am correct only outlook has this wrong behaviour) have problems >with plaintext remarks, and show them as attachments, although >they really are not. > > It is a great bug for most of my clients; sometimes they even get attachments in their Inbox which they cannot open / double-click :-). Ah well, I'm glad to see that my (Linux-based) spam/virus filter didn't pick it up incorrectly either. -- Michael T. Babcock CTO, FibreSpeed Ltd. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Diferences between HTB and CBQ
Stef Coene wrote: >On Friday 05 July 2002 15:14, Michel Angelo da Silva Pereira wrote: > > >> Hi, what's the diferences between HTB and CBQ? >> >> >HTB is better :) > >Use htb if you can. > I have a feeling they may have been looking for a more theoretical angle or discussion on design perspectives ... :) A lot of that is in the HTB3 documentation though, I've found. -- Michael T. Babcock CTO, FibreSpeed Ltd. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Per-destination MTUs?
bert hubert wrote: >http://lartc.org/HOWTO//cvs/2.4routing/html/lartc.cookbook.mtu-discovery.html > > (Ignoring the fact that I should've looked there in the first place ...) thanks, it works exactly as desired (even on kernel 2.2.19, fwiw). -- Michael T. Babcock CTO, FibreSpeed Ltd. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Per-destination MTUs?
I have some Path-MTU discovery problems it seems; a few sites I deal with can only communicate with us if we use an MTU of 1492 (they're on ADSL of course ...) and another (in Japan) only works for file transfers if we use an MTU of around 1425. Is there any way to tell Linux what the MTU should be on a per-destination basis? -- Michael T. Babcock CTO. FibreSpeed Ltd. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Re: iptables diagram (ex: ipchains + mark in output chain?)
John Telford wrote: >I'd very much like to see this diagram again with all the updates. > I'd be willing to draw it in Dia afterward ... : ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Gigabit Etnernet router
What motherboard hardware did you use? Admissions Office wrote: >Good point . Such was the problem in the first series of Cisco 7000 units. >The company was only able to make them do 21.5MB Having said that there >are still very few people who would be able to use this. In-house we have >built >several of these units using both 3Com and Intel cards. I find that two main >factors >were the most common reason for some sort of failure.. Heat from the cards >and >Intel cards were just problems. With the 3Com cards we never seems to have a >problem. > > > ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Voip QOS
Stef Coene wrote: >What are the requirements for a good VOIP link? Steady bandwidth, low >latency, low jitter, ... > > All of the above, in my experience. Depending on the protocol, good bandwidth (as opposed to perfect) and very low latency are required. Bandwidth equal to the target bandwidth with very low latency and no fragmentation is perfect. Part of the problem is not knowing your maximum number of VOIP links. In a perfect world, one would use PRIO and mark the VOIP packets as "go now ... do not pass go, do not collect $200". -- Michael T. Babcock ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] U32 & 2.2.20
Is there a patch to make U32 filters work properly on 2.2.20? I've had some problems using my U32 filters from 2.4.x on 2.2.x in general, but I haven't worked on it much. I just figured if there was a quick solution, I'd take it :-). -- Michael
RE: [LARTC] SFQ buckets/extensions
For the sake of a play-by-play (and why it wouldn't quite work right initially): 1) we need to dequeue a packet 2) we ask the 11 bit lower SFC for a packet. 3) it asks the upper SFC 4) the upper SFC takes the next bucket, based on IP, and gives us a packet. 5) the lower SFC takes that packet and has nothing else to work with, so it passes it on. ... So you're right :-) The two have to intercommunicate more ... So they have to be one. > Hmm I can't imagine that :) Probably it should be tested > > On Fri, 7 Jun 2002, Michael T. Babcock wrote: > > > > It can't be done. Outer SFC could do nothing with the packet. > > > It could only give it to inner one > > > > ... Ah, but it can choose which packet to give the inner > one. It would > > reorder the packets into a semi-fair order based on IP. > > > > > > ... SFC (8 bit hash against dest ip) > > > > | > > > > \-- SFC (11 bit hash against src ip, port, dest ip, port) > > > > | > > > > \-- dequeue ... ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] SFQ buckets/extensions
> exactly. The discussion should be about how to implement if > efficiently. What about to have N IP buckets and N IP/PORT > buckets. When IP/PORT hash resolves to bucket then we could > (re)link the Consider a new classful queueing discipline "SFC" that behaves exactly as SFQ does and can have only one sub-queue attached to it. ... SFC (8 bit hash against dest ip) | \-- SFC (11 bit hash against src ip, port, dest ip, port) | \-- dequeue ... Is this even possible with how the classes are currently built in the kernel? -- Michael T. Babcock CTO, FibreSpeed Ltd. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] (E)SFQ suggestion
> Isn't it possible to arrange this with cbq and sfq leafs? Yes ... By building a big CBQ/HTB tree with one leaf for each IP ... :) I'm not sure how efficient / inefficient that is. -- Michael T. Babcock CTO, FibreSpeed Ltd. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] SFQ buckets/extensions
> In a long term always droping from the largest subqueue > gives you equal subqueues. And, of course, one could have it drop them using a RED-like algorithm to make the sessions stabilize themselves better. > what they have) is better. May be doing it like the cbq with average > packet size can gave us better results. Calculating average packet size on the fly isn't that hard either. > All started with the so called Download Accelerators, > which do paralel gets and make TCP behave bad. > In normal case TCP adjusts fast and does not create backlogs. > But when you have to change it's bandwidth , you have to create > a backlog to slow it down. It then clears fast. I actually usually download pieces of the same file from multiple mirrors if its truly large and want it fast :-). Ranged downloads make that quite possible ... The only way to equalize bandwidth "fairly" in these scenarios still seems to be to implement the hierarchial approach of hashing against destination IP (the user receiving the packets) and then having sub-queues to those queues based on ports and to drop packets (based on RED?) in each of these sub-queues (because they're closer to the actual TCP sessions involved). > People wanted options to tune hashsize/limits/depths and > the most wanted (needed) was the option to select hash type. > SRC/DST Port hash is in TODO now. And I'm glad it exists for testing at least. -- Michael T. Babcock CTO, FibreSpeed Ltd. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] SFQ buckets/extensions
> I disagree that the goal is to make the subqueues the same length. > The goal is to serve them with the same bandwidth (as long as they > don't become empty.) Not that you need backing-up, but I agree with you. SFQ is there to provide near-fair queuing on a per-session basis. As modified, it could also be used to provide near-fair queuing on a per-IP basis instead, but having different-depthed sub-queues simply indicates why fairness is needed (one sub-queue would otherwise have dominated the available bandwidth). A very long sub-queue however, indicates that perhaps fairness is not being acheived (although, that's why its refered to as being stochastic). This is why I suggested at least being able to tune the size of the hash / number of hash buckets so as to redistribute the streams through more sub-queues. Dealing with bursts properly at Linux timer resolutions is another issue :-). -- Michael T. Babcock CTO, FibreSpeed Ltd. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] (E)SFQ suggestion
> There are attempts to replace hashing routine in SFQ to > consider IPs or ports. > What about to use HRR - roundrobin around bunch of IP > adresses and then smaller WRR for ports per IP ? > It would solve both problems - fairnes between computers > (IP) and between flows on than single computer ... Basically you're suggesting a multi-staged hash bucket ... hash each packet twice; once against the source IPs, then against the same criteria as now. Do a loop through the first hash list, pick a bucket, then use the second hash to pick packets from that bucket. Any thoughts? -- Michael T. Babcock CTO, FibreSpeed Ltd. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] SFQ buckets
> This is often discussed and is on "TODO" for someone > > > SFQ is connection oriented. right? > > Would be a good idea to make the queues per ip rather than per tcp > > flow? So there would be per host fairnes. And all the discussions tend to lead to the conclusion that there should be an sfq option (when the queue is created) for: a) how big the hash is b) whether to take into account source ports or not c) whether to take into account destination ports or not d) etc. :) Maybe someone who's written a qdisc would feel up to this? -- Michael T. Babcock CTO, FibreSpeed Ltd. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] SFQ buckets
Just a thought, after talking to a friend who's doing his master's work on RED and other queueing algorithms ... ... What if SFQ were to start with a minimal number of buckets, and track how 'deep' each bucket was, then go to a larger number of bits (2/4 at a time?) if the buckets hit a certain depth? Theoretically, this would mean that 'fairness' would be achieved more often in current collision situations but that a smaller number of buckets would be necessary to achieve fairness in currently low-collision situations. I haven't looked at the SFQ code in a while, so I don't know how much benefit this would be in terms of processing time, or even how expensive it would be to change hash sizes on the fly, but at a certain level of resolution (+/- 2-4 bits), the changes wouldn't be terribly frequent anyway. I've always been a bit of a fan of self-tuning algorithms anyway :) -- Michael T. Babcock CTO, FibreSpeed Ltd. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] HTB 3 back port to linux 2.2.20
Is is compilable outside the kernel? (As a module in a separate directory)? > I am working on a backport of HTB3 to kernel 2.2.20. > > I am looking for volunteers to test it. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] How to make Linux server transparent to internal machines?
> The pros: it's easier to set-up than the bridge code. there's > no need to patch > kernel code and/or commandline tools > > The cons: slightly lower throughput, slightly lower > security... but easier ;-) I'd like to know why you think using proxy-arp is lower security than bridging ... -- Michael T. Babcock CTO, FibreSpeed Ltd. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] 2 NICS. More Bandwidth?
> I have a Fileserver on my local network. > Is there any way, or is it just possible increase the bandwidth to the > fileserver if it has 2NICS. Look up 'bonding' in newer kernels... -- Michael T. Babcock ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Load-based packet dropping
Has anyone seen / considered a simple queue that would drop packets on the basis of machine load? I'd like to tail-drop packets from specific queues if the machine load is very high, instead of letting them build up ... ... it might make for a good DOS-prevention method too. -- Michael T. Babcock CTO, FibreSpeed Ltd. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] htb_change sfq_change
On Wed, May 15, 2002 at 02:24:54PM +0300, Catalin BOIE wrote: > On Tue, 14 May 2002, Martin Devera wrote: > But you loose counters! This is bad IMHO. If you know when you're dropping it, the counter loss is not relevant; resetting to zero is easy to compensate for, and rrdtool (for example) has built-in support for it. As per the rrdtool developper's recommendations, I have the following in front of my QoS reset script: rrdtool update /var/rrd/qos_office.rrd N:U:U:U:U rrdtool update /var/rrd/qos_office.rrd N:0:0:0:0 ... done for each rrd file. -- Michael T. Babcock CTO, FibreSpeed Ltd. (Hosting, Security, Consultation, Database, etc) http://www.fibrespeed.net/~mbabcock/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Graphing
On Wed, May 01, 2002 at 12:28:51AM +0200, PiotR wrote: > Would be a good idea to have packet count, and other things in /proc? > What do the people with experience in the kernel think? Whatever it is, make sure its easily parsed (tab-delimited, etc.) There should probably be seperate class and queue lists for simplicity. For queuing disciplines: Type of qdisc, handle, packets, dropped packets, borrowed packets Also optionally: time since last dequeue, time since last queue, etc. Any other thoughts? -- Michael T. Babcock CTO, FibreSpeed Ltd. (Hosting, Security, Consultation, Database, etc) http://www.fibrespeed.net/~mbabcock/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Graphing
On Fri, Apr 26, 2002 at 07:52:53PM +0200, PiotR wrote: > > Good, I have written a page with an example using the output of `tc -s > qdisc' to draw graphs with rrdtool. ¿Do you graph other data more > specific than the tc output to test your code?, I mean, if you use debug > code in htb, to output data from its internal functions. And I've done something similar ... what would be nice is a /proc interface for reading these values directly without an exec. -- Michael T. Babcock CTO, FibreSpeed Ltd. (Hosting, Security, Consultation, Database, etc) http://www.fibrespeed.net/~mbabcock/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] DNS [off-topic]
On Fri, Mar 22, 2002 at 09:16:51PM +0700, [EMAIL PROTECTED] wrote: > > is djbdns powerful enough to handle more than 500 domains ? many people If you read up at the cr.yp.to/djbdns.html page, you'll find that some people are using it for _thousands_ of domains. It is very powerful; it uses disk caching to cache responses however, so frequently changing the domain file will decrease performance somewhat; although write-through caching should get you the same benefits if your OS has it. > told me that djbdns is more secure than Bind, is it true ? I've installed It is highly secure (no security bugs yet that I'm aware of; there's a cash reward if you find any though). It is well-written from what I've read of its source although variable naming is quite obscure but being written by a mathematician probably explains that. > djbdns on my development server but don't have courage to install it on my > production server, my consideration is the stability, reliability and > security... It has never crashed for me. It has never failed to respond for me. It is my production DNS server (feel free to hammer away at fibrespeed.net DNS requests if you like) ;-). It has great local diagnostic tools and logging for any user-caused errors. -- Michael T. Babcock CTO, FibreSpeed Ltd. (Hosting, Security, Consultation, Database, etc) http://www.fibrespeed.net/~mbabcock/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] DNS (bind vs dnsmasq for small dsl network)
On Thu, Mar 21, 2002 at 05:02:30PM -0600, Bill Williamson wrote: > I'm setting up a router/firewall/etc to replace my current hardware dsl > router, and installed bind, but this looks much nicer and usable (for > something small like my setup). I recommend you seriously consider using djbdns from http://cr.yp.to/djbdns.html. If you need help setting it up, E-mail me -- its pretty easy and for a small setup, you'll end up editing one line per DNS entry in a text file. > I'll have 5 computers behind my firewall all the time, and up to 10-15 once > every other month or so for lan parties. > > I've got htb/ingress/etc all happy now, just need to decide on the extras :) -- Michael T. Babcock CTO, FibreSpeed Ltd. (Hosting, Security, Consultation, Database, etc) http://www.fibrespeed.net/~mbabcock/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
