Posted by Tres
Fri, 21 Jul 2006 07:05:00 GMT
If you’re using nssldap and pamldap in FreeBSD, chances are, you’ve run into the dreaded LDAP stall. If you’ve never run into it, it usually goes something like this: everything comes to a stop while the host attempts to reach the LDAP server. Nothing seems to work–you can’t log in remotely, you can’t even log in locally. And even when you get logged in, things like top just sit and wait for five minutes before it actually runs.
The man pages don’t really help, and even Google proved to be frustratingly unhelpful regarding this one. For FreeBSD issues surrounding LDAP timeouts, Google seems invariably to point toward the useless TIMELIMIT directive. This is good for limiting how long your host will wait for a response from the LDAP server once it’s made a connection, but is absolutely useless for defining how long the host will wait before timing out.
To get FreeBSD to play nicely when the LDAP servers aren’t reachable, just add the following to your ldap.conf:
bind_policy soft
This seemingly undocumented directive is the ldap client’s reconnect policy. If it is set to hard it will attempt to reconnect with exponential backoff. If it is set to soft, the reconnect policy is to fail immediately.
Posted in FreeBSD, Sysadmin | Tags FreeBSD, LDAP, timeout | no comments
Posted by Tres
Tue, 04 Jul 2006 01:55:00 GMT
I’ve found that sometimes, especially with newer NICs on older switches, the host’s DHCP client times out before the port initialization completes. The switch flashes an orange light while the DHCP client keeps trying to send advertisements. This isn’t so bad when you’re just trying to get a DHCP address, most modern operating systems will eventually keep trying until they get one. This really gets frustrating when you’re trying to use BOOTP for PXE booting. You can’t do the install because the system never gets an IP address.
To me this seemed like some kind of port speed or duplex negotiation problem. But even when I turned off auto-negotiation and set all port speed and duplex parameters manually, it still didn’t fix the problem. That’s because the problem isn’t port negotiation, it’s STP (Spanning Tree Protocol).
STP is what Cisco uses to allow for redundant pathways between switches. STP will put a switchport into one of two normal operating states: forwarding or blocking. Because any switchport could potentially cause a loop if the port were suddenly switched from the blocking state to forwarding state, STP uses two other intermediate states to ensure that a loop will not occur: listening and learning.
In the listening state, the port ensures that there doesn’t already exist a better pathway. In learning state, the switch learns MAC addresses for connected devices without allowing a loop to occur. Once the switchport has passed through these two modes, then it will finally be in the forwarding state, where it will forward DHCP broadcasts.
So, to make a long story short, in order to get switchports up and running quickly, use:
spanning-tree portfast
when configuring ports.
For the most part, this is safe to use, but if it gets set up on an uplink port to another layer 2 device, it can cause loops – things will stop working in a hurry. So like IOS says, “Use with CAUTION.”
Posted in Cisco | Tags BOOTP, DHCP, PXE, timeout | no comments