Re: 5.1r Bridge with one ip - no access from non-ip side - WORKS
On Tue, 6 Jan 2004, 06:33+0100, Bjorn Eikeland wrote: > P? Tue, 6 Jan 2004 07:41:26 +0300 (MSK), skrev Maxim Konovalov > <[EMAIL PROTECTED]>: > > > Try sysctl net.inet.ip.check_interface=0. > > > > Well that did the trick! >Thank you very much! We really have to document that knob somewhere in bridge.4. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Polling CPU usage
On Mon, 5 Jan 2004, Alexander Langer wrote: > Also sprach Markus Oestreicher ([EMAIL PROTECTED]): > > > Is there a way to get the real processor usage including > > the time spent on polling? 1. No. 2. Use kernel profiling (preferably high resolution kernel profiling). Measurement will affect the usage significantly but it should be possible to get a good idea of the usage provided it is small. 3. Record timestamps on entry and exit in the profiling routines and analyze them. This is what high resolution kernel profiling does, except it records timestamps in _all_ routines and this costs more. 4. Use -current and put all the polling routines in low priority threads if they are not already (poll_idle already is, and it may be the most important one here -- in RELENG_4, the time spent doing work in the idle loop is counted as purely idle time and is indistinguishable from time spent doing nothing in the idle loop). This will also record timestamps on entry and exit to the profiling routines, but in a very inefficient way. > What machine do you use? > When bridging approx. 25 MB/s (so 200 MBit/s; 1 MB of traffic roughly > estimates to 1500 packets here) on a Duron 700 with ~2800 ipfw rules > in polling mode, we have ~15.0 system load, so it might be your load > is actually in fact so low ;) real/user/sys times don't give the overhead here, since most of it may be in "idle" time. > I once did a timed buildworld when the system was saturated like this, > and compared to an almost idle CPU (in the night with < 100 kb/s) the > build only took 5% longer or so. This is another way, but it will affect the usage a lot unless buildworld is your main application. buildworld should have no idle time on a perfectly tuned machine (with very fast disks), so polling should rarely occur in idle time. It will have to compete with buildworld and might end up not getting done, so all the network traffic might be handled at interrupt time. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
splnet() and time slowing
I have a relatively loaded router with permanent load of ~ 200Kb/s. Its system time is a bit slowed down: Jan 6 10:45:30 gw-f ntpd[274]: time reset 4.212716 s Jan 6 11:00:52 gw-f ntpd[274]: time reset 3.682535 s Jan 6 11:15:50 gw-f ntpd[274]: time reset 2.881445 s Jan 6 11:32:42 gw-f ntpd[274]: time reset 3.130731 s Jan 6 11:49:26 gw-f ntpd[274]: time reset 2.78 s It has some netgraph nodes with permanent traffic flow thru them. When I insert another node (which is considered to cause even more CPU load ), time I slowed down even more: Jan 6 12:04:39 gw-f ntpd[274]: time reset 16.165271 s Jan 6 12:20:20 gw-f ntpd[274]: time reset 27.880482 s Jan 6 12:37:30 gw-f ntpd[274]: time reset 30.759668 s Jan 6 12:53:19 gw-f ntpd[274]: time reset 27.591937 s Does this mean that spending much time at splnet() causes system clock to slow? Or may be the problem hides somwhere else? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VLAN MTU problem in 4.9 ?
[EMAIL PROTECTED] wrote: > > > To answer your question; the Intel Etherexpress Pro/100 as it is > > supported by the fxp driver accepts and sends the 4-byte VLAN enhanced > > ethernet frames. > > Do you know does dc driver accepts and sends the 4-byte VLAN enhanced > ethernet frames? The dc driver supports it. > I have not this ethernet now to test but can change > some of my xl's for dc in near future. -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
IPENCAP Problem
The problem I have 5 buildings that are connected via point-to-point wireless. The cost of dedicated lines within this town were so high that wireless was an excellent option. The wireless is in place and working however we are going back to secure the wireless cloud so that it cannot be used by unauthorized people. The internet connection for all buildings is located at Building A so all machines need to route across the wireless to the internet. The solution 5 PCs running FreeBSD 5.1-Release using 2 network cards apiece and running IP-ENCAP between nodes with the tunnel being encrypted with IPSEC. Routing on each gateway that sends its traffic to the headend at Building A I have all this working except for this problem The PROBLEM Certain websites are not accessible sears.com msnbc.com microsoft.com drudgereport.com Other websites will work normally freebsd.org slashdot.org ebay.com What seems to be the problem Each of the websites that I listed have round-robin DNS enabled and have multiple A records for the website What I have done Recompile kernel back to GENERIC with options IPSEC options IPSEC_ESP options IPFIREWALL Disable IPSEC rc.conf ipsec_enable="NO" Open IPFW rules wide open firewall_enable="YES" firewall_type="OPEN" Summary I have slimed this configuration back to 2 machines(Building A and Building B) Building A External IP: 192.168.0.3/27 Internal IP: 10.114.252.1/22 Building B External IP: 192.168.0.6/27 Internal IP: 10.114.96.1/20 Removed IPSEC tunneling between machines now IP-ENCAP is the only thing that travels between machines. Opened the ruleset on both machines IPFW installation to OPEN Does anyone have any suggestions? Thanks Tom ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPENCAP Problem
On Tue, Jan 06, 2004 at 04:20:25PM -0500, [EMAIL PROTECTED] wrote: > The problem > I have 5 buildings that are connected via point-to-point wireless. The > cost of dedicated lines within this town were so high that wireless was an > excellent option. The wireless is in place and working however we are > going back to secure the wireless cloud so that it cannot be used by > unauthorized people. The internet connection for all buildings is located > at Building A so all machines need to route across the wireless to the > internet. > > The solution > 5 PCs running FreeBSD 5.1-Release using 2 network cards apiece and running > IP-ENCAP between nodes with the tunnel being encrypted with IPSEC. > Routing on each gateway that sends its traffic to the headend at Building A > > I have all this working except for this problem > The PROBLEM > Certain websites are not accessible > sears.com > msnbc.com > microsoft.com > drudgereport.com > > Other websites will work normally > freebsd.org > slashdot.org > ebay.com > > What seems to be the problem > Each of the websites that I listed have round-robin DNS enabled and have > multiple A records for the website I'd suspect MTU issues rather than multiple A records. Try setting the MTU of the link to the Internet to 1400. If that works you can fine tune it. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPENCAP Problem
On Tue, Jan 06, 2004 at 05:03:31PM -0500, Barney Wolff wrote: > I'd suspect MTU issues rather than multiple A records. Try setting the > MTU of the link to the Internet to 1400. If that works you can fine > tune it. i mailed the original author privately, but for the archive this is the most likely reason. msn/microsoft blocks icmp wholesale from their site and yahoo^Wfreebsd.org has no such filter. this would break pmtud. none of this belonged on -net, though... -- - bill fumerola / [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
netgraph and kqueue together - socket problems
Hi, I'm trying to use netgraph and kqueue together and ran into some problems. I hope someone can enligthen me what I'm missing. I register EVFILT_READ and EVFILT_WRITE on a netgraph-socket connected to a netgraph echo-node. The EVFILT_WRITE-filter returns immediately from the kevent call saying there is 20480 bytes remaining in the write buffer (in the event data field). Then I write 20480 using NgSendData. NgSendData encounters an error: "No buffer space available". When I write fewer but smaller chunks of data, say ~3000 bytes, the next call to kevent returns the same amount of remaining space in the write buffer. The kqueue event data field never change from 20480 for the EVFILT_WRITE-filter. Now I understand that there are some overhead in the NgSendData. It's not just my data that are written through the socket. The addressing data adds some data when NgSendData calls sendto. Right? But, how do I calculate the true amount of remaining buffer space available for me when I call NgSendData? And, why does kevent EVFILT_WRITE always say 20480 on repeated calls to kevent on a netgraph-socket, even if I have successfully written some data between the calls to kevent? The netgraph-node the programming is talking to is a echo-node set up with: #ngctl mkpeer echo dummy foo Regards, Jonas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: netgraph and kqueue together - socket problems
On Wed, 7 Jan 2004, Jonas Bulow wrote: > Hi, > > I'm trying to use netgraph and kqueue together and ran into some > problems. I hope someone can enligthen me what I'm missing. I'm not sure that anyone has ever looked at netgraph and kqueue as a pair. > > I register EVFILT_READ and EVFILT_WRITE on a netgraph-socket connected > to a netgraph echo-node. The EVFILT_WRITE-filter returns immediately > from the kevent call saying there is 20480 bytes remaining in the write > buffer (in the event data field). Then I write 20480 using NgSendData. > NgSendData encounters an error: "No buffer space available". WHat does it mean "write buffer"? The netgraph socket will pass th edat adirectly to whatever is connected. There is no buffer. The echo node in turn passes it back to the socket node (though there maybe a lock.. not sure) so eventually the data will be put in the receive buffer, so for this case the receive buffer is the send buffer but the socket can not know this.. > > When I write fewer but smaller chunks of data, say ~3000 bytes, the next > call to kevent returns the same amount of remaining space in the write > buffer. The kqueue event data field never change from 20480 for the > EVFILT_WRITE-filter. No it is returning some default value.. I doubt it is related in any way to much of importance. tell me, does a write of 20479 bytes work? > > Now I understand that there are some overhead in the NgSendData. It's > not just my data that are written through the socket. The addressing > data adds some data when NgSendData calls sendto. Right? > nope. that is out of band data.. I don't count that.. (I don't count anything really.). > But, how do I calculate the true amount of remaining buffer space > available for me when I call NgSendData? you can't.. there is no transmit buffer.. that is a reponsibility of the node that eventually decides to queue the data (maybe never). > > And, why does kevent EVFILT_WRITE always say 20480 on repeated calls to > kevent on a netgraph-socket, even if I have successfully written some > data between the calls to kevent? probably some default value. > > The netgraph-node the programming is talking to is a echo-node set up with: > > #ngctl mkpeer echo dummy foo > I suggest 'following' the data in the source code... starting in ng_socket.c start at: http://snapshots.jp.freebsd.org/tour/current/kernel/S/3328.html#338 for -current and: http://snapshots.jp.freebsd.org/tour/releng4/kernel/S/2566.html#182 for -stable. > Regards, > Jonas > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
