Kernel static map entries and kernel options
Recently on some apache reverse proxy servers we have encountered the dreaded /bsd: uvm_mapent_alloc: out of static map entries in the logs. To the point where the system has become unresponsive and died. This has occurred on OpenBSD 3.9 i386 and OpenBSD 4.0 amd64. I am unsure exactly what is causing this although I assume it has something to do with it being quite a heavily loaded server and running a lot of apache virtual hosts. We ran out of file descriptors a while ago and increased maxfiles, maxproc and somaxconn as well as openfiles-cur and openfiles-max. Do these options also affect KMAPENT in any way. To prolong the uptime of the servers I could play with some kernel parameters I suppose. It seems KMAPENT is derived from NPROC and NPROC is derived from MAXUSERS which currently is 32. Changing MAXUSERS to 64 seems to be what others are doing but is there any information around on what these parameters actually affect? Is there better memory management in later/current releases of OpenBSD if this is in fact the problem? Thanks The contents of this email are confidential and may be subject to legal or professional privilege and copyright. No representation is made that this email is free of viruses or other defects. If you have received this communication in error, you may not copy or distribute any part of it or otherwise disclose its contents to anyone. Please advise the sender of your incorrect receipt of this correspondence.
Re: ospfd not resyncing
OpenBSD 4.2, with three routers running ospfd. Two links out of one
router connecting to the other two routers. (em1 and em3 in this case)
ospfd.conf
===
# macros
password=xxx
# global configuration
router-id 0.0.0.1
redistribute connected
redistribute static
redistribute default
auth-key $password
auth-type simple
hello-interval 5
# areas
area 0.0.0.5 {
interface em0 {
passive
}
interface em1 {
}
interface em2 {
passive
}
interface em3 {
}
interface em4 {
passive
}
interface em5 {
passive
}
}
==
router1# ospfctl show neighbor
ID Pri StateDeadTime Address Iface Uptime
0.0.0.3 1 FULL/DR 00:00:37 192.168.253.3 em3 3d04h09m
0.0.0.2 1 FULL/DR 00:00:37 192.168.255.2 em1 3d04h09m
router2# ospfctl show neighbor
ID Pri StateDeadTime Address Iface Uptime
0.0.0.3 1 FULL/DR 00:00:35 192.168.254.3 em3 3d04h19m
0.0.0.1 1 FULL/BCKUP 00:00:35 192.168.255.1 em1 3d04h11m
router3# ospfctl show neighbor
ID Pri StateDeadTime Address Iface Uptime
0.0.0.2 1 FULL/BCKUP 00:00:36 192.168.254.2 em3 3d04h19m
0.0.0.1 1 FULL/BCKUP 00:00:36 192.168.253.1 em1 3d04h10m
Not sure what other information would be helpful. Thought I might have
to assign a metric to each interface but I don't think that will do
anything as each interface is for a route to a separate network.
Cheers
Claudio Jeker wrote:
On Wed, Apr 09, 2008 at 09:53:58AM +0100, Paul Civati wrote:
Linden Varley [EMAIL PROTECTED] wrote:
Bringing up an old-topic here, but just letting everyone know
I have the exact same problem. It occurs quite often.
Surely we can't be the only two people seeing this issue?
It's quite fundamental to ospfd working properly..
Please send some more infos. What version are you useing (did you test
-current). Please show the config and necessary ospfctl output. The last
time I have issues like this was some time ago with point-to-point links
and that got fixed some time ago. There seems something in common with
your setups that others usually don't have.
Re: ospfd not resyncing
Bringing up an old-topic here, but just letting everyone know I have the exact same problem. It occurs quite often. One of my links goes down, the routes change, but when the link comes back up the routes don't go back to the default lower-cost one and I have to restart ospfd in order to force it. It seems like a simple issue but wondered why it happens. I'm glad its not just me! Paul Civati wrote: I have a fairly simple set-up, where I have ospfd announcing a few routes to a Juniper router. Twice now, when the Juniper has been unreachable and has then come back on-line, the ospf routes have not reconverged on the Juniper end. It has taken a restart of the OSPF on the Juniper to resync the routes.. I've not tried restarting the ospfd's on the OpenBSD end but I presume that would also solve the issue. I suppose it's plausible this is a JunOS bug, and I'll look into that, but wondered if this is a known issue? OpenBSD/ospfd 4.2 RELEASE. -Paul-
Routing with ospfd
Hi all Is there any way to force ospfd to use routes with a lower-cost metric? ospfctl reload doesn't work, it still sends packets via a route with a higher cost metric than what is possible with another route. Only restarting the ospfd daemon will make it use the proper routes again. Any ideas? Thanks
ospfd errors
Hi, I was wondering if anyone could offer any solution to this OSPFD error when it starts up: ospfd[11601]: send_packet: error sending packet on interface em0: No route to host It says there is no route to host for every interface defined in ospfd.conf This is using the default config on an OpenBSD 4.0 amd64 install. (Note, ip forwarding and ip multicast forwarding are enabled) Thanks, Linden.
Secure Network File System - Or Lack Thereof
Not sure what you were originally after but I came across this the other day http://fuse.sourceforge.net/sshfs.html - Linden. J.C. Roberts wrote: On Tuesday 17 July 2007, Edd Barrett wrote: HI, On 17/07/07, J.C. Roberts [EMAIL PROTECTED] wrote: Hi Edd, I was curious if you ever found a decent answer for your question on secure network file systems? Not really. I have signed up for free academic licenses of sharity (not light), as sharity-light seemed to be sketchy on file permissions last time i tried it. It will do for now, but in a business situation it would be a VERY expensive solution. At least it has authentication. Linux has some userland SSH mounting facilities, it appears we have no equivalent. I have looked at forwarding the NFS/NIS over a ssh tunnel (ssh -L), but i do not see an option for mount_nfs that allows you to specify the mountd port, so this is not possible. It is possible. How to configure the mount port is in the man page for mount_nfs(8). Each of the various mount_* commands have their own man pages with relevant info for the specific file systems (as noted in the mount(8) man page). You can expect a performance hit for forcing a mixed transport layer protocol (UDP and TCP) like NFS to only use TCP but on the bright side, if portions of your university network are wireless (i.e. packet loss), you're probably better off with TCP anyhow. These guys run NFS over SSH in a mixed environment: http://www.noahk.com/~sparrow/journal/index?user=noahk But there are probably better ways to do it. I have looked into ipsec, but it seems overly complex and overkill for my situation. As for using ipsec, well, the most fair thing I could say is IPSec always looks like overkill. I would never call it easy (although some work is being done to simplify it), but once you get past the learning curve, ipsec VPN's work very well. None the less, your question somewhat implied *not* creating a VPN. I thought that perhaps the OpenBSD developers might have been interested in some sort of OpenSNFS project for example as there is no decent solution, and they did such a great job on OpenBSD/OpenSSH. Thanks for that guys. More than one solution already exists but none of them are simple and all of them have a learning curve. Your question stated a secure network file system and work on such a beast is currently being done... -it's called NFSv4. ;-) http://www.ietf.org/rfc/rfc3530.txt Abstract: The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. You'd have better chances of dividing by zero than getting any useful information out of me about (Le)TeX. I've never studied it, and don't use it, but I must say, I've always been curious about it. Well if you wish to get started with it, drop me a private email and I can suggest some reading materials and websites. Theres a whole lot more to texlive than just latex (context, xetex, xmlex.. the list goes on), but its not really suitable on the openbsd mailing lists :) Please send them off list :-) PS: Who's that on CC? I'm not a fan of NIS, and since NFSv4 has support for kerberos (and other interesting goodies), cc'ing two of the guys who are working on NFSv4 for openbsd seemed wise (see links in previous post). They are in a much better position than me to tell you what NFSv4 can and can not do. kind regards, JCR
pf and route-to rules
Hi all, I can't for the life of me get any route-to rules working with packet filter. i.e pass in on fxp1 route-to (fxp1 $host) inet proto tcp from any to any port 80 This to me implies that any traffic coming in on fxp1, port 80 should be routed to $host ? Am I correct in this assumption or do I have it all wrong? Cheers, Linden.
Re: Load balancing with DSR
We host our own web-servers so DSR shouldn't be a problem. Will probably get rid of the co-located balancers and bring them inside our network as we dont really gain anything from co-locating. Might just use something simple like lbnamed ! Adam wrote: Linden Varley [EMAIL PROTECTED] wrote: Load-balancers were co-located for redundancy reasons I believe. Its just a shame traffic in/out is paid-for so even if web-servers were also co-located then traffic will still be metered. If your web servers and load balancers aren't on the same network then you can't do DSR anyways. ISP_A where your web servers are is (hopefully) not going to let you send out traffic with a source IP belonging to ISP_B (where your load balancers are). Adam
Re: Load balancing with DSR
The only reason we need DSR is our load-balancers are co-located and we have a limit on data usage so the connection needs to be offloaded to the server/client and not proxied as this would get quite expensive with the traffic flowing through our co-location pipe. Might have to move to Linux with BalanceNG for the time-being. Cheers, Linden. Reyk Floeter wrote: On Wed, Jun 13, 2007 at 06:42:24AM +0200, Pierre-Yves Ritschard wrote: On Wed, 13 Jun 2007 10:54:58 +0800 Lars Hansson [EMAIL PROTECTED] wrote: Linden Varley wrote: Anyone know of any load balancing software for OpenBSD that can do direct-server return? (our load balancers (openbsd boxes) are co-located and we pay for all data bandwidth). hoststated? No, hoststated won't do DSR yet, neither will any load balancers on OpenBSD. DSR needs Layer 2 trickery that is not possible with OpenBSD. Maybe someday, it is on my todo-list if I find a clean way to do it. i don't like the idea about DSR, it sounds like an evil hack to get some performance at the wrong place. it is better to focus on improving the pf/network stack performance itself and to be able to do traffic filtering and normalization on the loadbalancers. reyk
Re: Load balancing with DSR
Load-balancers were co-located for redundancy reasons I believe. Its just a shame traffic in/out is paid-for so even if web-servers were also co-located then traffic will still be metered. We could bring the load-balancers into our network to stop this problem but we have two-sites on different subnets and I need the load-balancers to have a common-ip to which they could then proxy to one of the two sites. - Linden Adam wrote: Linden Varley [EMAIL PROTECTED] wrote: The only reason we need DSR is our load-balancers are co-located and we have a limit on data usage so the connection needs to be offloaded to the server/client and not proxied as this would get quite expensive with the traffic flowing through our co-location pipe. Are you actually *stuck* with this messed up setup for some reason? Why can't you just move your web servers behind the load balancers where they belong? Adam
Load balancing with DSR
Hi, Anyone know of any load balancing software for OpenBSD that can do direct-server return? (our load balancers (openbsd boxes) are co-located and we pay for all data bandwidth). Something like BalanceNG (which unfortunately doesnt run on OpenBSD) woudl be ideal. It is generally for http layer requests but I don't think apache re-directs will suffice. Cheers, Linden.
Bad checksum on return tcp packet using rdr
Hi all, We are experiencing the exact same problem as described here http://www.nabble.com/Re:-kernel-5437-t3504800.html Dell 1950, bnx chipset, OpenBSD 4.1 using packet filter with redirect rules. Packets seem to get redirected fine, but the return packets dont get through due to a bad checksum (in a telnet session for example). In particular im trying to do a simple rdr from smtp - spamd Have tried disabling checksum offloading in if_bnx.c - ifp-if_capabilities = IFCAP_VLAN_MTU | IFCAP_CSUM_TCPv4 | - IFCAP_CSUM_UDPv4; + ifp-if_capabilities = IFCAP_VLAN_MTU; Recompiled but still getting checksum errors. Any ideas? Cheers, Linden.
Apache with threads and OpenBSD
Hi all, I've seen this problem crop up before with other people, but can someone please explain to me why compiling apache with the mpm=worker directive (i.e threads) does not work as expected on OpenBSD ? (3.6, 3.9 4.0) Initital connections to the server seem to hang and get no response until something bumps the thread along so to speak. Any reasons for this ? Cheers. - Linden.
procfs and OpenBSD 4.0
I've re-compiled the kernel with option procfs and I still get the error mount_procfs: /proc: Filesystem not supported by kernel when mounting. What else could I be missing ? Cheers, Linden.
