Re: IPv6 Ideas
Nathan Lay wrote: > I started playing with IPv6 on my home network with the intent to > transition over. While many things work quite well, IPv6 technology in > general still seems to have some rough edges. I disagree. I believe the "rough edges" do not belong to IPv6, the "rough edges" are the applications that are not compatible, the network devices that are not compatible, and the ISP's who have the mindset that they will never need IPv6, and refuse to look at it. > To be backward compatible with IPv4, I had a look at faith and faithd > and while these tools are ingenius, I don't think they are good enough > for transitioning to IPv6. I imagine it is possible to write an > IPv6->IPv4 NAT daemon that uses faith to capture and restructure > IPv6/IPv4 packets. Though, it really seems like this is the firewall's job > > A pf rule like: > > nat on $inet4_if inet to any from $lan_if:network6 -> ($inet4_if) > > would be extremely convenient. I'm aware pf doesn't support the token > :network6 ... its just a wishful example. The IPv6 mapped IPv4 > addresses would be the standard :::0:0/96 prefix. I imagine that > this is very difficult to implement but I don't see why it wouldn't be > possible. If a firewall supported this kind of NAT, a home network > could easily deploy IPv6 and be backward compatible. Well, not quite, I > guess BIND would have to serve IPv6 mapped IPv4 addresses to IPv6 queries. My hope is that I never have to deal with anything where IPv6 and NAT are in the same sentence :) > Comments? - ask your ISP about their IPv6 deployment plans, and how soon they can provide it to you - get a tunnel set up to a tunnel broker (sixxs.net, he.net etc) - ask your ISP how soon they can provide it to you - play, play play > Other than that, this has been one hell of a fun experience. A tad bit different, huh ;) Steve ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPv6 Ideas
On Thu, 23 Apr 2009, Nathan Lay wrote: In terms of FreeBSD support, rtadvd and rtsol do not yet support (easily? -O option in rtadvd/rtsold) RFC5006 (Router Advertisements Option for DNS Configuration) which make it inconvenient to use mobile devices (like We'll happily accept a patch;-) Oh yeah, one annoyance on 7-STABLE, it seems like pf is started before IPv6 rc.conf options are processed (including IPv6 address assignment) breaking See http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/130381 -- Bjoern A. Zeeb The greatest risk is not taking one. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Interrupts + Polling mode (similar to Linux's NAPI)
--- On Thu, 4/23/09, Ed Maste wrote: > From: Ed Maste > Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) > To: "Andrew Brampton" > Cc: atti...@freebsd.org, freebsd-net@freebsd.org, "Luigi Rizzo" > > Date: Thursday, April 23, 2009, 3:04 PM > On Fri, Mar 27, 2009 at 11:05:00AM +, Andrew Brampton > wrote: > > > 2009/3/27 Luigi Rizzo : > > > The load of polling is pretty low (within 1% or > so) even with > > > polling. The advantage of having interrupts is > faster response > > > to incoming traffic, not CPU load. > > > > oh, I was under the impression that polling spun in a > tight loop, thus > > using 100% of the processor. After a quick test I see > this is not the > > case. I assume it will get to 100% CPU load if I > saturate my network. > > Yes, polling has a limit on the maximum CPU time it will > use, and also > will use less than the limit if there is no traffic. > > There are a number of sysctls under kern.polling that > control its > behaviour: > > * kern.polling.user_frac: Desired user fraction of cpu time > > This attempts to reserve at least a specified percentage of > available > CPU time for user processes; polling tries to limit its > percentage use > to 100 less this value. > > * kern.polling.burst: Current polling burst size > * kern.polling.burst_max: Max Polling burst size > * kern.polling.each_burst: Max size of each burst > > These three control the number of packets that polling > processes per > call / tick. Packets are processed in batches of > each_burst, up to > burst packets total per tick. The value of burst is capped > at > busrt_max. > > In order to keep the user_frac CPU percentage available for > non-polling, > a feedback loop is used that controls the value of burst. > Each time a > bach of packets is processed, burst is incremented or > decremented by 1, > depending on how much CPU time polling actually used. In > addition, if > polling extends beyond the next tick it's scaled back > to 7/8ths of the > current value. > > Polling was originally implemented as a livelock-avoidance > technique > for the single-core case -- the primary goal is to > guarantee the > availability of CPU time specified in user_frac. The > current algorithm > does not behave that well if user_frac is set low. Setting > it low is > reasonable if the workload is largely in-kernel (i.e., > bridging or > routing), or when running SMP. > > Another downside of the current implementation is that > interfaces will > be polled multiple times per tick (burst / each_burst > times), even if > there are no packets to process. > > At work we've developed a replacement polling algorithm > that keeps track > of the actual amount of time spent per packet, and uses > that as the > feedback to control the number of packets in each batch. > > This work requires a change to the polling KPI: the polling > handlers > have to return the count of packets actually handled. My > hope is to get > the KPI change committed in time for 8.0, even if we > don't switch the > algorithm yet. Attilio (on CC:) and I will make the patch > set for the > KPI change available shortly for comment. > > > -Ed Actually, the "advantage of using interrupts" is to have a per NIC control without having all of the extra code to implement polling. Using variable interrupt moderation is much more desirable and efficient, so polling is only useful for legacy NICs with no controls on interrupt delays. Polling requires that you adulterate the system with the polling function, that you call routines when there is nothing to process, and uses many cpu cycles doing unnecessary things. What happens when you have 4 NICs with different levels of traffic? You'd be better off launching a thread and polling yourself than having a system-wide function with generalized settings. Barney ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPFW MAX RULES COUNT PERFORMANCE
Very good thinking, congratulations, but my need is another. The objective is a Captive Porrtal that each authentication is dynamically created a rule to ALLOW or COUNT IP authenticated, which I'm testing is what is the maximum capacity of rules supported, therefore simultaneous user. Understand ? Thanks, Daniel Julian Elischer escreveu: Daniel Dias Gonçalves wrote: Hi, My system is a FreeBSD 7.1R. When I add rules IPFW COUNT to 254 IPS from my network, one of my interfaces increases the latency, causing large delays in the network, when I delete COUNT rules, everything returns to normal, which can be ? My script: of course adding 512 rules, *all of which hav eto be evaluated* will add latency. you have several ways to improve this situation. 1/ use a differnet tool. By using the netgraph netflow module you can get accunting information that may be more useful and less impactful. 2/ you could make your rules smarter.. use skipto rules to make the average packet traverse less rules.. off the top of my head.. (not tested..) Assuming you have machines 10.0.0.1-10.0.0.254 the rules below have an average packet traversing 19 rules and not 256 for teh SYN packet and 2 rules for others.. you may not be able to do the keep state trick if you use state for other stuff but in that case worst case will still be 19 rules. 2 check-state 5 skipto 1 ip from not 10.0.0.0/24 to any 10 skipto 2020 ip from not 10.0.0.0/25 to any # 0-128 20 skipto 1030 ip from not 10.0.0.0/26 to any # 0-64 30 skipto 240 ip from not 10.0.0.0/27 to any # 0-32 40 skipto 100 ip from not 10.0.0.0/28 to any # 0-16 [16 count rules for 0-15] 80 skipto 1 ip from any to any 100 [16 count rules for 16-31] keep-state 140 skipto 1 ip from any to any 240 skipto 300 ip from not 10.0.0.32/28 [16 rules for 32-47] keep-state 280 skipto 1 ip from any to any 300 [16 count rules for 48-63] keep-state 340 skipto 1 ip from any to any 1030 skipto 1240 ip from not 10.0.0.64/27 to any 1040 skipto 1100 ip from not 10.0.0.64/28 to any [16 count rules for 64-79] keep-state 1080 skipto 1 ip from any to any 1100 [16 rules for 80-95] keep-state 1140 skipto 1 ip from any to any 1240 skipto 1300 ip from not 10.0.0.96/28 to any [16 count rules for 96-111] keep-state 1280 skipto 1 ip from any to any 1300 [16 rules for 112-127] keep-state 1340 skipto 1 ip from any to any 2020 skipto 3030 ip from not 10.0.0.128/26 to any 2030 skipto 2240 ip from not 10.0.0.128/28 to any [16 count rules for 128-143] keep-state 2080 skipto 1 ip from any to any 2100 [16 rules for 144-159] keep-state 2140 skipto 1 ip from any to any 2240 skipto 2300 ip from not 10.0.0.32/28 to any [16 count rules for 160-175] keep-state 2280 skipto 1 ip from any to any 2300 [16 count rules for 176-191] keep-state 2340 skipto 1 ip from any to any 3030 skipto 3240 ip from not 10.0.0.192/27 to any 3040 skipto 3100 ip from not 10.0.0.192/28 to any [16 count rules for 192-207] keep-state 3080 skipto 1 ip from any to any 3100 [16 rules for 208-223] keep-state 3240 skipto 1 ip from any to any 3240 skipto 3300 ip from not 10.0.0.224/28 to any [16 count rules for 224-239] keep-state 3280 skipto 1 ip from any to any 3300 [16 count rules for 240-255] keep-state 3340 skipto 1 ip from any to any 1 #other stuff in fact you could improve it further with: 1/ either going down to a netmask of 29 (8 rules per set) or 2/ instead of having count rules make them skipto so you would have: 3300 skipto 1 ip from 10.0.0.240 to any 3301 skipto 1 ip from 10.0.0.241 to any 3302 skipto 1 ip from 10.0.0.242 to any 3303 skipto 1 ip from 10.0.0.243 to any 3304 skipto 1 ip from 10.0.0.244 to any 3305 skipto 1 ip from 10.0.0.245 to any 3306 skipto 1 ip from 10.0.0.246 to any 3307 skipto 1 ip from 10.0.0.247 to any 3308 skipto 1 ip from 10.0.0.248 to any 3309 skipto 1 ip from 10.0.0.249 to any 3310 skipto 1 ip from 10.0.0.240 to any 3311 skipto 1 ip from 10.0.0.241 to any 3312 skipto 1 ip from 10.0.0.242 to any 3313 skipto 1 ip from 10.0.0.243 to any 3314 skipto 1 ip from 10.0.0.244 to any 3315 skipto 1 ip from 10.0.0.245 to any thus on average, a packet would traverse half the rules (8). 3/ both the above so on average they would traverse 4 rules plus one extra skipto. you should be able to do the above in a script. I'd love to see it.. (you can also do skipto tablearg in -current (maybe 7.2 too) which may also be good.. (or not)) julian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsu
Re: IPv6 Ideas
I was in a similar position to you not that long ago. I got my LAN all dual stack and was a happy camper. I wanted 100% IPv6 and never to see another RFC 1918 address on my network again. Unfortunately it's just not practical. My ReadyNAS doesn't talk v6. My mac doesn't appear to like v6 for the file transfer protocols it supports. My iPhone doesn't do v6. The applications just aren't ready to live in a v6-only world. I suggest leaning on your vendors whenever you can so that they no longer can say "no one is asking for it." A boring, un-bumped thread asking for IPv6 support in the iPhone: http://discussions.apple.com/thread.jspa?threadID=1960260&tstart=0 Getting back to your question. It is my understanding that this IVI proposal is the most likely to become an officially adopted standard: http://tools.ietf.org/html/draft-xli-behave-ivi-01 That's being done as part of the behave working group: http://www.ietf.org/html.charters/behave-charter.html If anyone were to begin working on something like this this they'd probably want to think about following that proposal. I too am interested in working on this. Just haven't sat down to really start thinking about it yet. -Bob Message: 14 Date: Thu, 23 Apr 2009 21:14:50 -0400 From: Nathan Lay Subject: IPv6 Ideas To: freebsd-net@freebsd.org Message-ID: <49f1128a.3080...@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed I started playing with IPv6 on my home network with the intent to transition over. While many things work quite well, IPv6 technology in general still seems to have some rough edges. In terms of FreeBSD support, rtadvd and rtsol do not yet support (easily? -O option in rtadvd/rtsold) RFC5006 (Router Advertisements Option for DNS Configuration) which make it inconvenient to use mobile devices (like laptops) on an IPv6 network. I haven't had much luck with net/radvd. Is this something that could be improved? I'd be willing to implement this support, but I have very little time to spare (writing thesis). To be backward compatible with IPv4, I had a look at faith and faithd and while these tools are ingenius, I don't think they are good enough for transitioning to IPv6. I imagine it is possible to write an IPv6->IPv4 NAT daemon that uses faith to capture and restructure IPv6/IPv4 packets. Though, it really seems like this is the firewall's job A pf rule like: nat on $inet4_if inet to any from $lan_if:network6 -> ($inet4_if) would be extremely convenient. I'm aware pf doesn't support the token :network6 ... its just a wishful example. The IPv6 mapped IPv4 addresses would be the standard :::0:0/96 prefix. I imagine that this is very difficult to implement but I don't see why it wouldn't be possible. If a firewall supported this kind of NAT, a home network could easily deploy IPv6 and be backward compatible. Well, not quite, I guess BIND would have to serve IPv6 mapped IPv4 addresses to IPv6 queries. Oh yeah, one annoyance on 7-STABLE, it seems like pf is started before IPv6 rc.conf options are processed (including IPv6 address assignment) breaking inet6 rules that involve $if:network. Comments? Other than that, this has been one hell of a fun experience. Best Regards, Nathan Lay ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPv6 Ideas
Nathan Lay wrote: I started playing with IPv6 on my home network with the intent to transition over. While many things work quite well, IPv6 technology in general still seems to have some rough edges. In terms of FreeBSD support, rtadvd and rtsol do not yet support (easily? -O option in rtadvd/rtsold) RFC5006 (Router Advertisements Option for DNS Configuration) which make it inconvenient to use mobile devices (like laptops) on an IPv6 network. I haven't had much luck with net/radvd. What are your problems with using radvd? I have used it quite a bit on FreeBSD (6.1) without any hassle. It's even written quite nicely in my experience so working on patches for it should be quite do-able if there are features missing. Is this something that could be improved? I'd be willing to implement this support, but I have very little time to spare (writing thesis). To be backward compatible with IPv4, I had a look at faith and faithd and while these tools are ingenius, I don't think they are good enough for transitioning to IPv6. I imagine it is possible to write an IPv6->IPv4 NAT daemon that uses faith to capture and restructure IPv6/IPv4 packets. Though, it really seems like this is the firewall's job A pf rule like: nat on $inet4_if inet to any from $lan_if:network6 -> ($inet4_if) would be extremely convenient. I'm aware pf doesn't support the token :network6 ... its just a wishful example. The IPv6 mapped IPv4 addresses would be the standard :::0:0/96 prefix. I imagine that this is very difficult to implement but I don't see why it wouldn't be possible. If a firewall supported this kind of NAT, a home network could easily deploy IPv6 and be backward compatible. Well, not quite, I guess BIND would have to serve IPv6 mapped IPv4 addresses to IPv6 queries. Oh yeah, one annoyance on 7-STABLE, it seems like pf is started before IPv6 rc.conf options are processed (including IPv6 address assignment) breaking inet6 rules that involve $if:network. Comments? Other than that, this has been one hell of a fun experience. Best Regards, Nathan Lay ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPFW MAX RULES COUNT PERFORMANCE
In response to Daniel Dias Gonçalves : > Very good thinking, congratulations, but my need is another. > The objective is a Captive Porrtal that each authentication is > dynamically created a rule to ALLOW or COUNT IP authenticated, which I'm > testing is what is the maximum capacity of rules supported, therefore > simultaneous user. > > Understand ? If you're only doing allow, then you'd be better off using a table, which has much better performance than a bunch of separate rules. If you're counting packets, I don't know if that approach will work or not. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmo...@collaborativefusion.com Phone: 412-422-3463x4023 IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPv6 Ideas
What are your problems with using radvd? I have used it quite a bit on FreeBSD (6.1) without any hassle. It's even written quite nicely in my experience so working on patches for it should be quite do-able if there are features missing. He's saying that the router announcements don't contain any DNS server information. There's an extension/option that can be enabled with router advertisements to make it send this information, similar in function to how DHCP sends out extra info like the default gateway, DNS server, NTP server, WINS servers, etc. To my knowledge this wasn't around when the Kame guys were working on this stuff. I don't think a lot of time has been spent updating the v6 support applications since then and that's why we don't have this feature. This isn't a big deal in dual-stack networks because the clients just do DNS over v4 with whatever the DHCP server gave. In a pure-v6 world... In hindsight it's an obvious oversight that it wasn't included in the first place. -Bob ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPFW MAX RULES COUNT PERFORMANCE
You'd almost certainly be better off hacking up an extension to ipfw
which lets you count a /24 in one rule.
As in, the count rule would match on the subnet/netmask, have 256 32
(or 64 bit) integers allocated to record traffic in, and then do an
O(1) operation using the last octet of the v4 address to map it into
this 256 slot array to update counters for.
It'd require a little tool hackery to extend ipfw in userland/kernel
space to do it but it would work and be (very almost) just as fast as
a single rule.
2c,
Adrian
2009/4/23 Daniel Dias Gonçalves :
> Hi,
>
> My system is a FreeBSD 7.1R.
> When I add rules IPFW COUNT to 254 IPS from my network, one of my interfaces
> increases the latency, causing large delays in the network, when I delete
> COUNT rules, everything returns to normal, which can be ?
>
> My script:
>
> ipcount.php
> -- CUT --
> $c=0;
> $a=50100;
> for($x=0;$x<=0;$x++) {
> for($y=1;$y<=254;$y++) {
> $ip = "192.168.$x.$y";
> system("/sbin/ipfw -q add $a count { tcp or udp } from any to
> $ip/32");
> system("/sbin/ipfw -q add $a count { tcp or udp } from $ip/32
> to any");
> #system("/sbin/ipfw delete $a");
> $c++;
> $a++;
> }
> }
> echo "\n\nTotal: $c\n";
> ?>
> -- CUT --
>
> net.inet.ip.fw.dyn_keepalive: 1
> net.inet.ip.fw.dyn_short_lifetime: 5
> net.inet.ip.fw.dyn_udp_lifetime: 10
> net.inet.ip.fw.dyn_rst_lifetime: 1
> net.inet.ip.fw.dyn_fin_lifetime: 1
> net.inet.ip.fw.dyn_syn_lifetime: 20
> net.inet.ip.fw.dyn_ack_lifetime: 300
> net.inet.ip.fw.static_count: 262
> net.inet.ip.fw.dyn_max: 1
> net.inet.ip.fw.dyn_count: 0
> net.inet.ip.fw.curr_dyn_buckets: 256
> net.inet.ip.fw.dyn_buckets: 1
> net.inet.ip.fw.default_rule: 65535
> net.inet.ip.fw.verbose_limit: 0
> net.inet.ip.fw.verbose: 1
> net.inet.ip.fw.debug: 0
> net.inet.ip.fw.one_pass: 1
> net.inet.ip.fw.autoinc_step: 100
> net.inet.ip.fw.enable: 1
> net.link.ether.ipfw: 1
> net.link.bridge.ipfw: 0
> net.link.bridge.ipfw_arp: 0
>
> Thanks,
>
> Daniel
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPv6 Ideas
> To my knowledge this wasn't around when the Kame guys were working on this > stuff. I don't think a lot of time has been spent updating the v6 support > applications since then and that's why we don't have this feature. > > This isn't a big deal in dual-stack networks because the clients just do DNS > over v4 with whatever the DHCP server gave. In a pure-v6 world... In > hindsight it's an obvious oversight that it wasn't included in the first > place. Not necessarily just oversight, also politics. IPv6 RA can't give you DNS info (without the addition you mentioned), and DHCPv6 can't give you a default route. Both pretty bad, actually. It looks like we may get a default route option for DHCPv6 now, but there's still a lot of resistance against it. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPFW MAX RULES COUNT PERFORMANCE
Bill Moran wrote:
In response to Daniel Dias Gonçalves :
Very good thinking, congratulations, but my need is another.
The objective is a Captive Porrtal that each authentication is
dynamically created a rule to ALLOW or COUNT IP authenticated, which I'm
testing is what is the maximum capacity of rules supported, therefore
simultaneous user.
Understand ?
If you're only doing allow, then you'd be better off using a table,
which has much better performance than a bunch of separate rules.
If you're counting packets, I don't know if that approach will work
or not.
if u need to count ip traffic for all clients u can use sipmple and more
performance rule set, like this one:
LOCAL_NET=192.168.0.0/24
ipfw pipe 100 config bw 0 mask src-ip 0x
ipfw pipe 100 config bw 0 mask dst-ip 0x
ipfw add 100 pipe 100 ip from ${LOCAL_NET} to any out
ipfw add 200 pipe 200 ip from any to ${LOCAL_NET} in
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Interrupts + Polling mode (similar to Linux's NAPI)
On Fri, Apr 24, 2009 at 08:03:52AM -0700, Barney Cordoba wrote: > Actually, the "advantage of using interrupts" is to have a per > NIC control without having all of the extra code to implement > polling. Using variable interrupt moderation is much more desirable > and efficient, so polling is only useful for legacy NICs with no > controls on interrupt delays. I'm aware of the advantages and tradeoffs of the various approaches, and the shortcomings of our current polling infrastructure, probably the greatest of which is the lack of any parallelism. That said, in testing some time ago polling with the modifications I alluded to in my email, using em(4), gave the highest throughput of all approaches. (At the expence of latency, as expected.) In addition, having a standardized polling interface allows for use of the interface when the system is not fully running -- network crashdumps, for instance. We can certainly use improvements in the polling infrastructure though, at least allowing it to properly take advantage of SMP. The KPI change proposed here is to allow some of those improvements, should they happen, to be MFC'd to 8. -Ed ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPv6 Ideas
Bob Van Zant wrote: What are your problems with using radvd? I have used it quite a bit on FreeBSD (6.1) without any hassle. It's even written quite nicely in my experience so working on patches for it should be quite do-able if there are features missing. He's saying that the router announcements don't contain any DNS server information. There's an extension/option that can be enabled with router advertisements to make it send this information, similar in function to how DHCP sends out extra info like the default gateway, DNS server, NTP server, WINS servers, etc. Yes but he was also saying that support for the existing RFC to provide the RA option does not seem to be present in any of the tools (from what I gathered). If the RFC is there then surely this functionality could be added. From the original message I thought he was having problems getting radvd to work at all. This could just be me misunderstanding the mail however. From my perspective this is one thing that needs significant improvement for v6. There are many RFC's/ietf drafts out there that add some nifty functionality but support for them in the real world applications seems to be lacking somewhat. To my knowledge this wasn't around when the Kame guys were working on this stuff. I don't think a lot of time has been spent updating the v6 support applications since then and that's why we don't have this feature. This isn't a big deal in dual-stack networks because the clients just do DNS over v4 with whatever the DHCP server gave. In a pure-v6 world... In hindsight it's an obvious oversight that it wasn't included in the first place. -Bob ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPv6 Ideas
Steve Bertrand wrote: Nathan Lay wrote: I started playing with IPv6 on my home network with the intent to transition over. While many things work quite well, IPv6 technology in general still seems to have some rough edges. I disagree. I believe the "rough edges" do not belong to IPv6, the "rough edges" are the applications that are not compatible, the network devices that are not compatible, and the ISP's who have the mindset that they will never need IPv6, and refuse to look at it. While the IPv6 implementation is great, it doesn't seem like it can be used for anything serious yet. If there is to be a transition to IPv6, the applications that assist the management of an IPv6 network appear to need improvement (like rtsol/rtadvd, faith/faithd for example). To be backward compatible with IPv4, I had a look at faith and faithd and while these tools are ingenius, I don't think they are good enough for transitioning to IPv6. I imagine it is possible to write an IPv6->IPv4 NAT daemon that uses faith to capture and restructure IPv6/IPv4 packets. Though, it really seems like this is the firewall's job A pf rule like: nat on $inet4_if inet to any from $lan_if:network6 -> ($inet4_if) would be extremely convenient. I'm aware pf doesn't support the token :network6 ... its just a wishful example. The IPv6 mapped IPv4 addresses would be the standard :::0:0/96 prefix. I imagine that this is very difficult to implement but I don't see why it wouldn't be possible. If a firewall supported this kind of NAT, a home network could easily deploy IPv6 and be backward compatible. Well, not quite, I guess BIND would have to serve IPv6 mapped IPv4 addresses to IPv6 queries. My hope is that I never have to deal with anything where IPv6 and NAT are in the same sentence :) I don't see how my suggestion is difficult to comprehend from the user's perspective (from the programmer perspective, it seems nightmarish). You have a dual-stack router, the objective is to share connectivity over one or more IPv4 router addresses with IPv6 clients. Conceptually its the same as NAT on IPv4/6-only networks. Since there is a standard IPv6 mapped IPv4 address prefix (:::0:0/96) IPv6 clients need only use this prefix to reach IPv4 networks. The only real issue is that a DNS server needs to serve IPv6 mapped IPv4 addresses to IPv6 queries. The nightmarish aspect is this probably involves more than just address translation, IPv4 and IPv6 are apparently very different. If faith(4) works the way I think it does, a program could be made to accomplish similar, but it really seems like a firewall should do this (to be consistent with what firewalls are already assumed to do). The consequence of such a feature is that IPv6-only home networks (minus the dual-stack router) will not only be seamlessly backward compatible with IPv4 Internet, but it will be slightly better than choosing to use 192.168.x.y, 10.x.y.z or 172.x.y.z since it can reach IPv6 Internet too. This would significantly help IPv6 transition and adoption. Best Regards, Nathan Lay ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPv6 Ideas
Matthew Jakeman wrote: Nathan Lay wrote: I started playing with IPv6 on my home network with the intent to transition over. While many things work quite well, IPv6 technology in general still seems to have some rough edges. In terms of FreeBSD support, rtadvd and rtsol do not yet support (easily? -O option in rtadvd/rtsold) RFC5006 (Router Advertisements Option for DNS Configuration) which make it inconvenient to use mobile devices (like laptops) on an IPv6 network. I haven't had much luck with net/radvd. What are your problems with using radvd? I have used it quite a bit on FreeBSD (6.1) without any hassle. It's even written quite nicely in my experience so working on patches for it should be quite do-able if there are features missing. radvd actually does support DNS advertisement (but rtsol doesn't, so it doesn't matter). The problem is, it doesn't work. on 7-STABLE it dumps "Can't assign requested address." I think it has something to do with if_bridge not having a link-local address (apparently the standards are ambiguous about link-local addresses on bridges). To make rtadvd work, I had to tell it to advertise on bridge-member interfaces directly. Best Regards, Nathan Lay ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
VIMAGE (was: Multiple default routes / Force external routing)
> > is VIMAGE fully integrated into FreeBSD 8 CURRENT? (I believe this > > answer is no) > > also is VIMAGE expected to make it into FreeBSD 8? > > not fully but a lot of it is under way Thanks for the pointer, I currently don't get it [1] to build on RELENG_7 which I naively hoped, so the "lot" probably not suffient for me yet. So, w/o patience for August, I probably need to find another way. Anyways, thanks for the comments, Regards, Peter. [1] http://imunes.tel.fer.hr/virtnet/vimage_7_20090401.tgz -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: VIMAGE (was: Multiple default routes / Force external routing)
On Friday 24 April 2009 22:29:23 Peter Cornelius wrote: > > > is VIMAGE fully integrated into FreeBSD 8 CURRENT? (I believe this > > > answer is no) > > > also is VIMAGE expected to make it into FreeBSD 8? > > > > not fully but a lot of it is under way > > Thanks for the pointer, I currently don't get it [1] to build on RELENG_7 > which I naively hoped, so the "lot" probably not suffient for me yet. So, > w/o patience for August, I probably need to find another way. Hmm... tpx32% uname -a FreeBSD tpx32.icir.org 7.1-STABLE FreeBSD 7.1-STABLE #0: Thu Feb 5 22:36:40 CET 2009 ma...@tpx32.icir.org:/u/marko/p4/zec/vimage_7/src/sys/i386/compile/VIMAGE i386 tpx32% pwd /u/marko/tmp tpx32% tar -xzf vimage_7_20090401.tgz tpx32% cd src/sys/i386/conf/ tpx32% config VIMAGE tpx32% cd ../compile/VIMAGE/ tpx32% make depend; make tpx32% sudo make install tpx32% cd ~/tmp/src/usr.sbin/vimage/ tpx32% make clean; make tpx32% sudo make install Let me know if that doesn't work... Good > Anyways, thanks for the comments, > > Regards, > > Peter. > > [1] http://imunes.tel.fer.hr/virtnet/vimage_7_20090401.tgz ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPFW MAX RULES COUNT PERFORMANCE
Daniel Dias Gonçalves wrote: Very good thinking, congratulations, but my need is another. The objective is a Captive Porrtal that each authentication is dynamically created a rule to ALLOW or COUNT IP authenticated, which I'm testing is what is the maximum capacity of rules supported, therefore simultaneous user. Understand ? I think so. do not add rules. have a single rule that looks in a table and add entries to the table when needed. Thanks, Daniel Julian Elischer escreveu: Daniel Dias Gonçalves wrote: Hi, My system is a FreeBSD 7.1R. When I add rules IPFW COUNT to 254 IPS from my network, one of my interfaces increases the latency, causing large delays in the network, when I delete COUNT rules, everything returns to normal, which can be ? My script: of course adding 512 rules, *all of which hav eto be evaluated* will add latency. you have several ways to improve this situation. 1/ use a differnet tool. By using the netgraph netflow module you can get accunting information that may be more useful and less impactful. 2/ you could make your rules smarter.. use skipto rules to make the average packet traverse less rules.. off the top of my head.. (not tested..) Assuming you have machines 10.0.0.1-10.0.0.254 the rules below have an average packet traversing 19 rules and not 256 for teh SYN packet and 2 rules for others.. you may not be able to do the keep state trick if you use state for other stuff but in that case worst case will still be 19 rules. 2 check-state 5 skipto 1 ip from not 10.0.0.0/24 to any 10 skipto 2020 ip from not 10.0.0.0/25 to any # 0-128 20 skipto 1030 ip from not 10.0.0.0/26 to any # 0-64 30 skipto 240 ip from not 10.0.0.0/27 to any # 0-32 40 skipto 100 ip from not 10.0.0.0/28 to any # 0-16 [16 count rules for 0-15] 80 skipto 1 ip from any to any 100 [16 count rules for 16-31] keep-state 140 skipto 1 ip from any to any 240 skipto 300 ip from not 10.0.0.32/28 [16 rules for 32-47] keep-state 280 skipto 1 ip from any to any 300 [16 count rules for 48-63] keep-state 340 skipto 1 ip from any to any 1030 skipto 1240 ip from not 10.0.0.64/27 to any 1040 skipto 1100 ip from not 10.0.0.64/28 to any [16 count rules for 64-79] keep-state 1080 skipto 1 ip from any to any 1100 [16 rules for 80-95] keep-state 1140 skipto 1 ip from any to any 1240 skipto 1300 ip from not 10.0.0.96/28 to any [16 count rules for 96-111] keep-state 1280 skipto 1 ip from any to any 1300 [16 rules for 112-127] keep-state 1340 skipto 1 ip from any to any 2020 skipto 3030 ip from not 10.0.0.128/26 to any 2030 skipto 2240 ip from not 10.0.0.128/28 to any [16 count rules for 128-143] keep-state 2080 skipto 1 ip from any to any 2100 [16 rules for 144-159] keep-state 2140 skipto 1 ip from any to any 2240 skipto 2300 ip from not 10.0.0.32/28 to any [16 count rules for 160-175] keep-state 2280 skipto 1 ip from any to any 2300 [16 count rules for 176-191] keep-state 2340 skipto 1 ip from any to any 3030 skipto 3240 ip from not 10.0.0.192/27 to any 3040 skipto 3100 ip from not 10.0.0.192/28 to any [16 count rules for 192-207] keep-state 3080 skipto 1 ip from any to any 3100 [16 rules for 208-223] keep-state 3240 skipto 1 ip from any to any 3240 skipto 3300 ip from not 10.0.0.224/28 to any [16 count rules for 224-239] keep-state 3280 skipto 1 ip from any to any 3300 [16 count rules for 240-255] keep-state 3340 skipto 1 ip from any to any 1 #other stuff in fact you could improve it further with: 1/ either going down to a netmask of 29 (8 rules per set) or 2/ instead of having count rules make them skipto so you would have: 3300 skipto 1 ip from 10.0.0.240 to any 3301 skipto 1 ip from 10.0.0.241 to any 3302 skipto 1 ip from 10.0.0.242 to any 3303 skipto 1 ip from 10.0.0.243 to any 3304 skipto 1 ip from 10.0.0.244 to any 3305 skipto 1 ip from 10.0.0.245 to any 3306 skipto 1 ip from 10.0.0.246 to any 3307 skipto 1 ip from 10.0.0.247 to any 3308 skipto 1 ip from 10.0.0.248 to any 3309 skipto 1 ip from 10.0.0.249 to any 3310 skipto 1 ip from 10.0.0.240 to any 3311 skipto 1 ip from 10.0.0.241 to any 3312 skipto 1 ip from 10.0.0.242 to any 3313 skipto 1 ip from 10.0.0.243 to any 3314 skipto 1 ip from 10.0.0.244 to any 3315 skipto 1 ip from 10.0.0.245 to any thus on average, a packet would traverse half the rules (8). 3/ both the above so on average they would traverse 4 rules plus one extra skipto. you should be able to do the above in a script. I'd love to see it.. (you can also do skipto tablearg in -current (maybe 7.2 too) which may also be good.. (or not)) julian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" _
FreeBSD 7.1 taskq em performance
Hi all, I have been hitting some barrier with FreeBSD 7.1 network performance. I have written an application which contains two kernel threads that takes mbufs directly from a network interface and forwards to another network interface. This idea is to simulate different network environment. I have been using FreeBSD 6.4 amd64 and tested with an Ixia box (specialised hardware firing very high packet rate). The PC was a Core2 2.6 GHz with dual ports Intel PCIE Gigabit network card. It can manage up to 1.2 million pps. I have a higher spec PC with FreeBSD 7.1 amd64 and Quadcore 2.3 GHz and PCIE Gigabit network card. The performance can only achieve up to 600k pps. I notice the 'taskq em0' and 'taskq em1' is solid 100% CPU but it is not in FreeBSD 6.4. Any advice? Many thanks in advance Joe ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
