Re: OT: IPv6 packet generator/flood test
On Tue, 9 Nov 2004, James wrote: Does anybody know of any IPv6 traffic generators, to stress test v6 routers? No need for setting hop by hop options, 6to4 tunneling, etc options. just plain unicast v6 packet generator. Web Polygraph[1] supports IPv6 addresses[2]. Polygraph is designed to test HTTP intermediaries (including L4-7 routers) and does not work on a packet level. Thus, hopefully, it is not the best tool available for low-level IPv6 router testing. On the other hand, it can generate [a lot of] realistic L7 traffic for your tests and can be configured to create DoS or DDoS attack conditions (which justifies this selfish plug). HTH, Alex. [1] http://www.web-polygraph.org/ [2] http://www.web-polygraph.org/docs/reference/pgl/types.html#type:docs/reference/pgl/types/addr ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPComp question
On Thu, 1 Feb 2001, Yu-Shun Wang wrote: > Another (sort of) related question: I've got the bandwidth > measurements for different algorthms using netperf. I was > really surprised that IPComp did so bad. Any ideas? AFAIK, netperf TCP_STREAM test (and may be others) is extremely susceptible to network delays. For example, for a fast Ethernet connection with, say, 30msec packet delay, netperf may show less than 10Mbits/sec bandwidth instead of the usual 90+Mbits/sec. Clearly, bandwidth and response times are orthogonal measurements, but netperf design ties them together. Depending on your test environment and purposes, netperf throughput results may be very misleading. $0.02, Alex. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IPComp question
On Fri, 2 Feb 2001, Yu-Shun Wang wrote: > What you pointed out below is true. But I am more > interested in the relative performance since the number > I measured were under exactly the same setup and traffic > condition. I believe it is a common pitfall to assume that same conditions allow for relative comparisons even when the measurement tool or methodology is "broken". The relative results may amaze you, but I would not trust them. :) > I am just curious why IPComp was _relatively_ > (and signigicantly) slower than most of the encryption > algorithm. If by "slower" you mean "yields lower throughput" under netperf, then keep in mind that your test probably did not measure throughput correctly. Here is an example. Let's assume that algorithm A delays every packet by 1msec and algorithm B delays every packet by 2msec. For simplicity, let's also assume that packet sizes do not change. Under correct testing conditions, both algorithms should yield the same throughput (X Mbits/sec). With netperf's TCP_STREAM, the throughput of A will be times 2 higher than the throughput of B! > So I guess bandwidth is probably not the best > pointer since what I end up comparing was really the > implementations of different encryption/compression > algorithms which are CPU-bound in this case. I would suggest to define exactly what you want to compare first (i.e., decide what your primary metrics are; why you are running these tests) and only then design the test and choose an appropriate benchmark. Alex. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Quick question about IP aliasing
On Wed, 28 Feb 2001, Luigi Rizzo wrote: > the source of confusion is just the fact that when you ifconfig an > interface, you really give two distinct pieces of information: > 1. an ip address that the machine recognises as its own > 2. an address for a subnet connected to that interface. > With aliases you can assign multiple instances of 1 and 2, as long > as they are distinct. In your example the subnet address that > you try to set with the alias is the same as the one you have > already set with the primary ip, so the info is already there and > you get the warning/error. Luigi, Can you be more specific please? Is it just a harmless warning message or a true error? In other words, will anything break if I use a.b.c.2/24 alias on the interface with the a.b.c.1/24 primary address? I hate to admit, but this thread is very confusing to me -- several people are claiming opposite things with confidence. Unfortunately, I cannot simply ignore the discussion. For benchmarking purposes, we routinely use thousands of IP aliases that belong to the same subnet on one interface without any known problems. I want to know if we are doing something wrong. I do not care about the ifconfig warning by itself. We do not even use ifconfig to manage aliases. I care about the actual run-time code that handles the addresses. Could you please clarify whether there is anything wrong with using, say, 10.0.0-3.1-250/16 aliases on the same interface? Thanks a lot, Alex. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Quick question about IP aliasing
On Wed, 28 Feb 2001, Tobias Fredriksson wrote: > No you will be able to bind normaly to a.b.c.1, but i have had the > problems where if i specify anything to bind a.b.c.2 and it has bound on > all ip's aliased on the computer. Tobias, I know that I can bind to any (and all) of the 1000+ aliases without any visible problems. We are running thousands of simulated HTTP clients and servers that way, each sending from or listening on its own alias... That is exactly why I am asking for a definitive answer based on how things are implemented in the kernel rather than case studies. Thanks, Alex. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Quick question about IP aliasing
On Wed, 28 Feb 2001, Luigi Rizzo wrote: > if you do care about this, you may want to restructure the data structure > used to store/match interface addresses. At the moment it is a linear list, > so the matching of incoming packets is probably Very Time Comsuming! We have a patch (posted to this list long time ago) that optimizes the lookup for incoming packets: http://polygraph.ircache.net/Tips/FreeBSD-3.3/ip_addr_hash.patch You are right that an unpatched kernel cannot handle more than ~500 aliases efficiently: http://www.ircache.net/~wessels/Junk/aliases/ Alex. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: ipfw
On Wed, 7 Mar 2001, Andy [TECC NOPS] wrote: > Just built a new kernel with > > options IPFIREWALL > options IPDIVERT > > and all went in ok. However, when I > user the ipfw command to add a rule > (or when rc.firewall does) I get the > following error message:- > > ipfw: getsocketopt(IP_FW_ADD): Invalid argument > > Can anyone point out the obvious mistake > I must be making? I can only point out really obvious ones: - you forgot to "make depend" when building a new kernel - you forgot to "make install" after building a new kernel - you forgot to reboot after installing a new kernel - you built a kernel with a config file different from the config file you modified. Alex. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: proper way to test for INET/INET6?
On Mon, 26 Mar 2001, Jun-ichiro itojun Hagino wrote: > what are you planning to do after checking IPv6 support in the kernel? > applications should be written so that it would work on both > IPv4-only, IPv6-only and IPv4/v6 dual stack kernels, by using > getaddrinfo(3) and getnameinfo(3). you do not need to check if you > write applications properly. Yes, in the ideal world that might be true. In the real world, one has to rely on ./configure and other awful hacks to just declare a couple of innocent-looking address-related variables (and to compile on more than one platform). Alex. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: why cannot bind to someipaddress:port when something else has*:port bound?
On Wed, 30 May 2001 [EMAIL PROTECTED] wrote: > The following program binds *:1000 to a socket, and then tries to > bind 200.47.36.254:1000 to another socket, the error i gets is > "Address already in use". Why? *:1000 includes 200.47.36.254:1000 by definition of bind(2). Binding two sockets to one address (200.47.36.254:1000 in your case) cannot be allowed because it is unclear which of the two sockets should recieve packets destined to 200.47.36.254:1000. There may be other reasons. Alex. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Connect(2) problem
Are you running out of ephemeral ports? See net.inet.ip.portrange sysctl or do your own port management. Alex. On Tue, 9 Oct 2001, Nguyen-Tuong Long Le wrote: > Hi all, > > I have a software that simulates web clients and servers to create > network congestion (for the purpose of doing research in network > congestion). In our experiment, a client opens an HTTP connection > to a server, fetches a number of objects, and then closes the > connection. A problem I seem to have right now is that a client > machine cannot simulate more than 3000 connections. When my client > machine simulates more than 3000 connections, it's able to open > a socket but then connect(2) fails with errno 35 (Resource > temporarily unavailable). Another interesting notice is that the > connect(2) system call blocks for a few miliseconds before it > fails although fcntl(2) was used to make the socket non-blocking. > The OS version I am using is FreeBSD 4.3-release. > > I used sysctl to bump up kern.maxfiles and kern.maxfilesperproc to > 16384. I also bumped up kern.ipc.somaxconn to 8192 on the server > side. I recompiled the kernel with option NMBCLUSTERS=65536 to > increase the number of mbufs. I guess that CPU is not the bottleneck > since I have the same problem regardless whether I use a 300 MHz or > a 1 GHz machine. > > Does anyone have any suggestion what kind of resources my client machine > runs out and how I can fix it? > > Thanks, > Long > > P.S. Please kindly email your reply to me since I am not on the list. > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Connect(2) problem
On Wed, 10 Oct 2001, Nguyen-Tuong Long Le wrote: > Just our of curiosity, what is the use of > net.inet.ip.portrange.hifirst and net.inet.ip.portrange.hilast ? Even FreeBSD gurus/committers are unsure :-) http://people.freebsd.org/~adrian/sysctl.descriptions The answer is in "man ip". Alex. > On Tue, 9 Oct 2001, Alex Rousskov wrote: > > > > > Are you running out of ephemeral ports? See net.inet.ip.portrange > > sysctl or do your own port management. > > > > Alex. > > > > On Tue, 9 Oct 2001, Nguyen-Tuong Long Le wrote: > > > > > Hi all, > > > > > > I have a software that simulates web clients and servers to create > > > network congestion (for the purpose of doing research in network > > > congestion). In our experiment, a client opens an HTTP connection > > > to a server, fetches a number of objects, and then closes the > > > connection. A problem I seem to have right now is that a client > > > machine cannot simulate more than 3000 connections. When my client > > > machine simulates more than 3000 connections, it's able to open > > > a socket but then connect(2) fails with errno 35 (Resource > > > temporarily unavailable). Another interesting notice is that the > > > connect(2) system call blocks for a few miliseconds before it > > > fails although fcntl(2) was used to make the socket non-blocking. > > > The OS version I am using is FreeBSD 4.3-release. > > > > > > I used sysctl to bump up kern.maxfiles and kern.maxfilesperproc to > > > 16384. I also bumped up kern.ipc.somaxconn to 8192 on the server > > > side. I recompiled the kernel with option NMBCLUSTERS=65536 to > > > increase the number of mbufs. I guess that CPU is not the bottleneck > > > since I have the same problem regardless whether I use a 300 MHz or > > > a 1 GHz machine. > > > > > > Does anyone have any suggestion what kind of resources my client machine > > > runs out and how I can fix it? > > > > > > Thanks, > > > Long > > > > > > P.S. Please kindly email your reply to me since I am not on the list. > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > with "unsubscribe freebsd-net" in the body of the message > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
funding TCP stack rewrite
On Fri, 30 Nov 2001, Jonathan Lemon wrote: > On Fri, Nov 30, 2001 at 09:01:21AM -0600, mark tinguely wrote: > > Too bad there are not companies throwing money around to fund a good > > rewrite...of course there is some competative advatange to do so only > > for themselves. > > Anyone want to fund a network hacker to do all of these? Seriously? :-( What kind of sum of money are we talking about here? Can you estimate what hacker/month effort is required? Would it make sense to setup a [paypal] fund of some kind, hosted on freebsd.org to raise the required sum? That way small companies and even individuals can contribute even if the total is more than they can afford... Is there a guru with enough unallocated time to concentrate on the rewrite? Will the dedicated work of the said guru get a high priority as far as review and commit steps are concerned? A public semi-formal commitment or encouragement from FreeBSD core group may be in order to raise support from the community. Otherwise, folks may worry that these big changes, once implemented, will get stuck in the commit queue forever. Thanks, Alex. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: 64 bit counters again
On Mon, 14 Jan 2002, Terry Lambert wrote: > This is getting way off topic, but here is a business case > illustration. > > Are you perhaps doing what the Q/A people at a previous job were > doing, and stress-testing the crap out of a machine on a Gigabit > LAN, at or near wire speeds, when in the field, the equipment is > *NEVER*, *EVER* going to have to handle anywhere near even 1/40th > of the load you are placing on it? > In fact, this assumes linear amplification: "multiply the data > rate by 40, and you multiply the failure rate by 40"; in the > real world, this relationship is exponential: something you see > at the stress breaking point of your product will be almost > impossible to repeat in the field. In my experience, this logic and conclusion do not hold in general. Yes, there are cases where beating the crap out of a machine is useless. However, in many cases, stress-testing at performance limits is one of the fastest and simplest ways of finding bugs that would otherwise be exposed under real (and possibly less stressful) conditions. And not just performance-related bugs, I must add! This kind of testing is never sufficient, of course. Disclaimer: I beat the crap out of machines for a living. This probably makes me biased (but Terry is probably biased the other way around since it is "his" box that is being beaten). This also makes me exposed to real-world cases where beating has been very useful... Alex. P.S. I am not implying that 32 bit counters is a bug. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Forcing packets to the wire
Hi there, I have two Ethernet NICs inside a PC. I want TCP/IP packets to leave one NIC, go on the wire, and eventually arrive at the other NIC. I do not want the kernel to be smart and shortcut the path. I want the outside world to see the packets and to think that my two NICs are two PCs talking to each other. Could any networking guru answer the following questions: - Is it possible without kernel modifications? How? - If kernel modifications are required, how extensive would they be (e.g., how many hours would it take a guru to implement the required functionality)? I am flexible as far as IP addressing scheme is concerned, though I would prefer to be able to put both NIC IP addresses on one and on separate subnets (from the outside world point of view). Again, I want the outside world think that these NICs are inside two PCs. If you want to know a "use case" for this strange requirement, here it is: I am building an appliance to test HTTP proxies. I want an appliance to have one NIC for the "client side" and one NIC for the "server side". I want to be able to run no-proxy test through the networking gear (a baseline experiment testing hubs/switches for bottlenecks), and I want to test "transparent proxies" (clients think they send requests directly to servers). Thank you, Alex. P.S. So far, all attempts to make this work have failed. Even jail environment does not go far enough and lets the "jailed" packet to traverse the kernel instead of using the wires... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Forcing packets to the wire
On Sat, 6 Apr 2002, Nick Rogness wrote: > I had a brief thought of using an upstream device that could route > the appropriate nat'd addresses to each interface. This is not an option, unfortunately. The required functionality has to be implemented inside one PC (appliance). No external devices. I want to ship that PC to a customer with one NIC labeled "client side", the other NIC labeled "server side". The customer should be able to plug in the wires and test their "explicit" proxies (works now because client packets are addressed to the proxy), their transparent (aka TCP hijacking) proxies (does not work because client packets are addressed to servers and do not leave the appliance), and their networking gear (does not work for the same reason). Thank you, Alex. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Forcing packets to the wire
Hi, Thanks a lot to all those who replied on and off the list! The winner is Andrew R. Reiter . Here is a possible solution to the problem, inspired by his response: ifconfig fxp1 fxp1_IP netmask 255.255.255.255 ifconfig fxp2 fxp2_IP netmask 255.255.255.255 route add fxp1_IP -iface -link fxp2:fxp1_MAC_address route add fxp2_IP -iface -link fxp1:fxp2_MAC_address The subnet doesn not have to be /32 as long as the two IPs are in different subnets. We are now testing the throughput limits of the above configuration and contemplating its effect on the rest of our setup. Thank you, Alex. On Fri, 5 Apr 2002, Alex Rousskov wrote: > Hi there, > > I have two Ethernet NICs inside a PC. I want TCP/IP packets to > leave one NIC, go on the wire, and eventually arrive at the other NIC. > I do not want the kernel to be smart and shortcut the path. I want the > outside world to see the packets and to think that my two NICs are two > PCs talking to each other. > > Could any networking guru answer the following questions: > > - Is it possible without kernel modifications? How? > > - If kernel modifications are required, how extensive > would they be (e.g., how many hours would it take a guru > to implement the required functionality)? > > I am flexible as far as IP addressing scheme is concerned, > though I would prefer to be able to put both NIC IP addresses on one > and on separate subnets (from the outside world point of view). Again, > I want the outside world think that these NICs are inside two PCs. > > If you want to know a "use case" for this strange requirement, > here it is: I am building an appliance to test HTTP proxies. I want an > appliance to have one NIC for the "client side" and one NIC for the > "server side". I want to be able to run no-proxy test through the > networking gear (a baseline experiment testing hubs/switches for > bottlenecks), and I want to test "transparent proxies" (clients think > they send requests directly to servers). > > > Thank you, > > Alex. > > P.S. So far, all attempts to make this work have failed. Even jail > environment does not go far enough and lets the "jailed" packet to > traverse the kernel instead of using the wires... > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Squid filtering
Ivo, Looks like your question is specific to Squid rather than FreeBSD. Please see Squid FAQ at www.squid-cache.org and ACL-related comments in the default squid.conf file. The info you need is there. If you need further help, please post to squid-users mailing list, after searching its archive. Good luck, Alex. On Wed, 22 May 2002, Ivailo Tanusheff wrote: > Hi, > > I need to filter some kind of traffic - mp3, .avi and so on for the my > network users. I'd try to find some info on that, but with no success. > Is there some kind of acl or other rule that can help? Can you help me > with this problem, please? > Thank you in advantage > > Ivo > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: increasing throughput
On Tue, 2 Jul 2002, John Angelmo wrote: > I was thinking of cunstructing a small routerbox in my sparetime. > Now since FreeBSD is my choise of OS i was thinking of a small box > silent box. > > So how can I combine speed, size, silence and price? > > I was thinking of vias small buget systems (via Eden) and to that > an extra intel pro 10/100 NIC You may also consider Soekris boxes, especially if you need a fan-less configuration. People use them for routers and firewalls. Some OpenBSD and FreeBSD documentation and software is available. You can probably find some performance measurements as well or ask on Soekris mailing list: http://www.soekris.com/ I am not associated with Soekris; we are just happy customers. Alex. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: programatically list all local IP addresses ?
On Thu, 18 Jul 2002, Chuck T. wrote: > Yes portablity is a concern, unfortunately my program will > probably be used on Linux more than FreeBSD, sigh. I starting to > read about ioctl() and SIOCGIFADDR which appears to be portable > (and a pain). We had to write portable local address detection for Web Polygraph. In my experience, ioctl/SIOCGIFADDR is not portable at all and is a lot of pain. Linux uses them differently from FreeBSD, and the exact interface/behavior is often OS-version specific (e.g., for Solaris IIRC). Looking at existing code helps. I would suggest using getifaddrs(3) where available (./configure can detect that, of course) and delve into ioctl() and other OS-specific methods where getifaddrs(3) is not supported. Stockpile some pain relieve medication first. $0.02, Alex. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: DHCP and media selection on bootup
On Thu, 10 Oct 2002, Damian Gerow wrote: > I've tried setting to ifconfig_fxp0 lines in /etc/rc.conf, the first > for the media selection and the second for the DHCP instruction, but > that didn't work -- the card stayed in autoselect. > > Is there any way to manually set the NIC media, while retreiving the > IP address via DHCP? You may want to put the media-changing ifconfig command into /etc/start_if.fxp0. You see, /etc/start_if.* scripts are executed by rc before ifconfig_fxp0 settings in rc.conf are acted on. The trick works for me; I have to change MAC address, not media options, but it probably does not matter. HTH, Alex. -- | HTTP performance - Web Polygraph benchmark www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite | all of the above - PolyBox appliance To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Programmatically obtaining interface hardware addrs
On Mon, 10 Feb 2003, Martin Stiemerling wrote: > See man getifaddrs: > > >http://www.freebsd.org/cgi/man.cgi?query=getifaddrs&sektion=3&apropos=0&manpath=FreeBSD+4.7-RELEASE > > You can obtain l2 addresses with this system call. I was not aware of the "l2 addresses" limit(?), and the man page does not seem to mention it. Will getifaddrs() fail if there are more than 12 aliases? If yes, anybody care to explain why? Thank you, Alex. -- | HTTP performance - Web Polygraph benchmark www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite | all of the above - PolyBox appliance To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
