Blogs

We have encountered a strange problem sending email to @comcast.net users at several sites running Microsoft Exchange and OpenDNS. No SMTP errors were seen in the logs other than that the emails wit stay in the queue and time out and generate a basic NDR - unable to contact server message.

Symptoms:

Intermittent success reaching a website, or high numbers of TCP retransmits when looking at a packet dump. Possible problems with IPSEC client vpns running over UDP or even TCP.

This does not seem to be as much of an issue with site to site IPSEC vpns behind Cisco ASAs and OpenBSD firewalls (as of yet) but we are still tracking this issue.

Goto the SMC router web admin tool:
http://10.1.10.1
login with the username cusadmin passwd highspeed

Disable Gateway Smart Packet Detection

More info:

In Debian Lenny (stable as of 2009) this file contains mappings for ethernet drivers that will be persistent across boots:

/etc/udev/rules.d/70-persistent-net.rules

If you change nics (netgear natsemi for an intel e100) for example, you will need to edit this file and remove the stanza (1 comment and 1device line that begins with SUBSYSTEM=="net",....)

Reboot, and the new nic should be detected as eth0

Customer has 2 physical circuits, Comcast Business Cable with 1 static IP, and a multi-t1 bundle to Verizon Business. Comcast will be used as the primary egress for internet browsing. Inbound email, web, and RDP services are mapped via static nats on a Cisco ASA that handles the Verizon connection. The Comcast connection has its own ASA for firewalling. Traffic needs to be sticky (i.e. it must go back out the same firewall it came in on or else the stateful packet inspection on the ASAs as well as the outbound NATs will break and the traffic will drop.

Ran into a strange issue with crypto maps and ipsec tunnel failover on an 1841. We had a t1 link between the HQ site and the remote site. EIGRP routing protocol was running across the WAN link. A backup DR ipsec tunnel was configured using a crypto ma (standard config, no tunnel interface) across a comcast cable link. DR tunnel came up as soon as the t1 went down, and traffic failed over. But when the t1 was restored, the specific ip address that had been used as a test case on the 1841 router would not flow back across the ipsec tunnel.

Had a situation on debian stable sgw firewall running rinetd tcp proxy to redirect smtp, rdp and web traffic on a backup t1 connection where millions of log entries like this were being created:

Dec 1 19:40:21 server-name.domain.com rinetd[28467]: accept(0): Socket operation on non-socket

A hyperthreaded processor has the same number of function units as an older, non-hyperthreaded processor. It just has two execution contexts, so it can maybe achieve better function unit utilization by letting more than one program execute concurrently. On the other hand, if you're running two programs which compete for the same function units, there is no advantage at all to having both running "concurrently." When one is running, the other is necessarily waiting on the same function units.

enable_dl = Off
max_execution_time = 15
max_input_time = 15
memory_limit = 32M
log_errors = On
track_errors = On
error_log = /var/log/apache2/error.log
post_max_size = 32M
upload_max_filesize = 32M
mysql.allow_persistent = Off
mysql.connect_timeout = 10
session.save_path = /var/lib/php5
register_globals = Off

sendmail_path = /usr/sbin/sendmail -t -i -f www@www.thissite.com

Apache settings to match nginx reverse proxy:
ServerRoot "/etc/apache2"
AcceptMutex flock
LockFile /var/lock/apache2/accept.lock
PidFile /var/run/apache2.pid
Timeout 10

KeepAlive Off

We have been rolling out nginx to help scale up our websites that use apache and php:

http://www.richweb.com/nginx

Setup/installation instructions:
http://www.richweb.com/postfix_dovecot_ssl

Works well for a small to medium sized installation (5 to 50 accounts). A database backend would be better for larger installations to make provisioning easier. This is good for clients that want a small mail server + web site.