Re: CARP interfaces randomly stop answering ARP requests
On 03/04/12 10:32, Camiel Dobbelaar wrote: On 3-4-2012 11:13, Ian Chard wrote: I have an OpenBSD box acting as a NATting firewall. It has 59 CARP interfaces defined, all identical apart from the IP address and vhid. At the moment there is no failover pair, so all the interfaces are in MASTER mode. Every so often, one of these interfaces will suddenly stop answering ARP requests. With tcpdump I can see the ARP requests coming in, but they are never answered. ifconfig output for the interface is no different to any of the other CARP instances; most notably, it is still in MASTER mode. I have net.inet.carp.log set to 7, but nothing is logged when this happens: no state changes, no other messages. Recovery is simple: I just 'ifconfig carpxx down; ifconfig carpxx up'. The interface recovers in a second or two. I had this problem with 4.9-stable, and today I migrated the config to a fresh 5.0-stable installation with the same results. Any help much appreciated! I assume all your carp interfaces have the same carpdev (physical interface) ? I suspect you may run into this limit (in sys/netinet): if_ether.c: IFQ_SET_MAXLEN(arpintrq, 50); /* XXX hate magic numbers */ Can you raise that number to 100 and compile a new kernel? I've now had this running since your suggestion, and the problem hasn't come back. Thanks again! - Ian -- Ian Chard, Systems Architect | E: ian.ch...@bodleian.ox.ac.uk Bodleian Libraries | T: 80587 / (01865) 280587 University of Oxford | F: (01865) 242287
CARP interfaces randomly stop answering ARP requests
Hi, I have an OpenBSD box acting as a NATting firewall. It has 59 CARP interfaces defined, all identical apart from the IP address and vhid. At the moment there is no failover pair, so all the interfaces are in MASTER mode. Every so often, one of these interfaces will suddenly stop answering ARP requests. With tcpdump I can see the ARP requests coming in, but they are never answered. ifconfig output for the interface is no different to any of the other CARP instances; most notably, it is still in MASTER mode. I have net.inet.carp.log set to 7, but nothing is logged when this happens: no state changes, no other messages. Recovery is simple: I just 'ifconfig carpxx down; ifconfig carpxx up'. The interface recovers in a second or two. I had this problem with 4.9-stable, and today I migrated the config to a fresh 5.0-stable installation with the same results. Any help much appreciated! Cheers - Ian -- Ian Chard, Systems Architect | E: ian.ch...@bodleian.ox.ac.uk Bodleian Libraries | T: 80587 / (01865) 280587 University of Oxford | F: (01865) 242287
Re: CARP interfaces randomly stop answering ARP requests
On 03/04/2012 10:32 AM, Camiel Dobbelaar wrote: On 3-4-2012 11:13, Ian Chard wrote: I have an OpenBSD box acting as a NATting firewall. It has 59 CARP interfaces defined, all identical apart from the IP address and vhid. At the moment there is no failover pair, so all the interfaces are in MASTER mode. Every so often, one of these interfaces will suddenly stop answering ARP requests. With tcpdump I can see the ARP requests coming in, but they are never answered. ifconfig output for the interface is no different to any of the other CARP instances; most notably, it is still in MASTER mode. I have net.inet.carp.log set to 7, but nothing is logged when this happens: no state changes, no other messages. Recovery is simple: I just 'ifconfig carpxx down; ifconfig carpxx up'. The interface recovers in a second or two. I had this problem with 4.9-stable, and today I migrated the config to a fresh 5.0-stable installation with the same results. Any help much appreciated! I assume all your carp interfaces have the same carpdev (physical interface) ? All but one, yes. I suspect you may run into this limit (in sys/netinet): if_ether.c: IFQ_SET_MAXLEN(arpintrq, 50); /* XXX hate magic numbers */ Can you raise that number to 100 and compile a new kernel? I'll try that -- thanks. Alternatively, you can combine IP addresses (using alias) on the carp interfaces so you have less of those. Now why didn't I think of that :) Amazing what a fresh pair of eyes can do. Many thanks again - Ian -- Ian Chard, Systems Architect | E: ian.ch...@bodleian.ox.ac.uk Bodleian Libraries | T: 80587 / (01865) 280587 University of Oxford | F: (01865) 242287
Monitoring DHCP pool state
Hi, I'm using the stock OpenBSD dhcpd, and I'd like to monitor the state of the pool (how many addresses in use/available). Is there any way of doing this without writing a parser for /var/db/dhcpd.leases? Would I be better off using a different dhcpd? Thanks - Ian -- Ian Chard, Senior Unix and Network Gorilla | E: ian.ch...@sers.ox.ac.uk Systems and Electronic Resources Service | T: 80587 / (01865) 280587 Oxford University Library Services | F: (01865) 242287
Logging when interfaces go down
Hi, Is it possible to log, or in some other way capture the event, when network interfaces go down? Thanks - Ian -- Ian Chard, Senior Unix and Network Gorilla | E: ian.ch...@sers.ox.ac.uk Systems and Electronic Resources Service | T: 80587 / (01865) 280587 Oxford University Library Services | F: (01865) 242287
Re: Logging when interfaces go down
Everyone said: ifstated Thanks to everyone :-) - Ian -- Ian Chard, Senior Unix and Network Gorilla | E: ian.ch...@sers.ox.ac.uk Systems and Electronic Resources Service | T: 80587 / (01865) 280587 Oxford University Library Services | F: (01865) 242287
Outbound RST not seen by tcpdump?
Hi, I'm troubleshooting a very strange problem, where my ssh connection to a few different OpenBSD machines drops suddenly, with the client machine receiving a TCP RST from the server. I've taken tcpdump captures on both sides (in different sessions, so the tcpdump process doesn't die with my shell), and the OpenBSD machine's capture doesn't log the RST it apparently sends. Now the machines are in a complex network, so it's possible that the packet is being generated spuriously by something else. My question is: is there any way that the OpenBSD kernel could sent a TCP RST that is always missed by tcpdump running on the same machine? Thanks for any help - Ian -- Ian Chard, Senior Unix and Network Gorilla | E: ian.ch...@sers.ox.ac.uk Systems and Electronic Resources Service | T: 80587 / (01865) 280587 Oxford University Library Services | F: (01865) 242287
Re: Authentication method fallback not working
On 27/08/09 13:44, Schvberle Daniel wrote: Hi, I'm using OpenBSD 4.5-stable, and I'm trying to configure RADIUS authentication. What I want is for the system to try the RADIUS server, and if it fails, fall back to the local password file. In login.conf I have auth-defaults:auth=radius,passwd:radius-server=my.radius.server If the RADIUS server isn't there for whatever reason, the system doesn't fallback to password file authentication. The same happens if I specify the methods the other way round: the RADIUS server is never tried even if the password-file-based login fails. I need to make sure that I can always log in even if the RADIUS server has gone away. Is it possible to configure the system in this way? Thanks - Ian Why not make a new login class for radius users and make yourself backup users in default class? Normally you'd login with users from the radius class and if that fails you'd use a user form the default class. Of course, that way you'd have to use different login names for the two classes. That's a good workaround, thanks. Do you know if it's a bug that this doesn't work, or is it just not implemented? I assumed from the manpages that being able to specify more than one style implies that there's some kind of fallback mechanism. I just wanted to know whether it was worth filing a bug for this. Thanks - Ian -- Ian Chard, Senior Unix and Network Gorilla | E: ian.ch...@sers.ox.ac.uk Systems and Electronic Resources Service | T: 80587 / (01865) 280587 Oxford University Library Services | F: (01865) 242287
Authentication method fallback not working
Hi, I'm using OpenBSD 4.5-stable, and I'm trying to configure RADIUS authentication. What I want is for the system to try the RADIUS server, and if it fails, fall back to the local password file. In login.conf I have auth-defaults:auth=radius,passwd:radius-server=my.radius.server If the RADIUS server isn't there for whatever reason, the system doesn't fallback to password file authentication. The same happens if I specify the methods the other way round: the RADIUS server is never tried even if the password-file-based login fails. I need to make sure that I can always log in even if the RADIUS server has gone away. Is it possible to configure the system in this way? Thanks - Ian -- Ian Chard, Senior Unix and Network Gorilla | E: ian.ch...@sers.ox.ac.uk Systems and Electronic Resources Service | T: 80587 / (01865) 280587 Oxford University Library Services | F: (01865) 242287
