BorderManager Configuration Tips
Novell Cool Solutions: Feature
Digg This -
Posted: 28 Apr 2005
Note: This article is derived from the BrainShare 2005 presentation TUT346 - "BorderManager Configuration and Troubleshooting - Best Practices." To download the original presentation, visit:
Best Practices for NBM Configuration
The best practices for your NBM configuration depend on a number of factors, such as:
- Number of users
- Intended use (mostly proxy? VPN?)
- Internet bandwidth
- Other software running on server (dedicated, small business server with GroupWise?, etc...)
- Security concerns
- Other firewalls in use
- NDS design
Craig Johnson's Approach to Configuration
Here are some of the best practices that BorderManager expert Craig Johnson uses and recommends:
- Make sure that NetWare is installed with only the private NIC first, and only partitions about 6GB for SYS. The rest should be unpartitioned.
- Each NBM Server should be in its own OU.
- Rename your NICs to PUBLIC and PRIVATE before installing NBM.
- Generally, you should follow the proxy tuning explained in TID 10018669.
- Customize filter exceptions extensively, as needed.
- Get current on the latest NBM patch releases (often including beta patches).
- Avoid Mail Proxy and Transparent Proxy.
- Typically, use Static and Dynamic NAT.
- Craig prefers BorderManager to be the only product running on the server (though it is not essential) - plus iManager on NetWare 6.5.
- Use dedicated CACHE and LOG volume(s).
Having BorderManager in its Own OU is a good thing, especially for handling filters and licenses. Filters are stored in NBMRuleContainer in the server OU. Having each server in its own OU means there is one NBMRuleContainer for each server. That makes it easy to manually delete filter exceptions if you need to repeat a FILTSRV MIGRATE procedure.
Also, the NBM Server wants to read licenses from the Master of the replica ring. Therefore, having a small OU for NBM lets BorderManager control its own license reading for fastest startup - especially for S2S VPN.
Modern server hardware is generally more than fast enough for all but the heaviest loads. Still, the hardware will need tuning - so here are some things you'll need to consider. First, you probably don't need or want multiple CPU's. Also, you should disable hyperthreading (see TID 10096716).
The bottleneck areas might be CPU and disk I/O. CPU usage would be a problem for very heavy VPN usage with high (10Mbps or greater) bandwidth. Disk I/O would be a problem for very heavy browsing usage (10-100Mbps bandwidth, several thousand users). RAM is not likely to be much of an issue, if you have 2GB or more; neither should bandwidth be much of an issue.
There are three basic ways to implement BorderManager, each with its own set of risks or advantages.
Upgrading In Place (riskiest method)
The old hardware may be slow or unreliable, and that can pose a problem for running the new NBM version. There will also be some downtime, and perhaps a lot of it, if something goes wrong. On the plus side, this method maintains the VPN, filters, access rules, and configuration in general.
Across-the-wire (less risky)
This method should maintain your current configuration. However, it will probably require some cleanup after the migration.
Replace with Parallel Server (preferred method)
This method generally has the least risk - you can take as much time as you want to get it right. The changeover can be very quick when you're ready, and you can easily change back to old server, if needed. This approach lends itself well to clustering.
This method does require additional public (and private) IP addresses, and you must recreate the VPN on new public IP address.
For BorderManager clustering, you do not need SAN / shared media. However, you must use SET FILTER SUBNET BROADCAST PACKETS = OFF to avoid filtering stopping heartbeat communications.
Basically, you set up everything twice for the cluster - NAT, filters, rules, proxies, and patches. There is free software available: NetWare 6.x allows a free two-node cluster; NBM 3.6 and later is not licensed per server.
You do not have to match each server - they can run different hardware and different versions of BorderManager. You can even use a PC (with 1GB of RAM and two NICs) as the second node. Once two servers are configured for BorderManager, it only takes about 30 minutes to cluster and test them.
There are five areas to consider in performance tuning:
- General issues
- Disk I/O
- Percent utilization
For cache tuning, you absolutely, positively must have a traditional Cache Volume - no NSS, no compression, and no suballocation. You can use either 8k or 16k block size. Remember that there should be nothing on this volume but cache!
You can remove the LONG name space to save some RAM. Try to keep cache volumes at 8GB or less. The proper cache capacity should be able to hold about one week of browsing. Multiple cache volumes should be on individual spindles (disks).
General Tuning IssuesThere are numerous SET statements in TID 10018669 that are designed to improve performance. You can also find these SETs in Craig Johnson's TUNEUP.NCF file - see tip #23 at www.craigjconsulting.com.
Here are some additional tuning suggestions:
- Flag the SYS:ETC\PROXY directory for immediate purge.
- Set several NWADMN32 parameters (per TID 10018669).
- Set .CFM extension as non-cachable (this helps with Cold Fusion login page issues).
- Consider reducing the cache balance percentage, if you have NSS volumes along with cache, to perhaps as low as 5-15% (depending on the server).
- Use a customized PROXY.CFG file (see tip #63 at Craig's website).
- Keep up to date on patches, including LAN drivers.
- Be very careful to avoid duplex mismatches.
Disk I/O Issues
If you have a very busy server and a lot of Internet bandwidth, follow these suggestions:
- Make sure you are not hitting the Maximum Hot Node Limit. The default is 7,000, and the proxy tuning TID raises that to 50,000.
- Watch the Maximum Hot Unreferenced Time - the default is 30 minutes. (Note that the TID sets this value to one hour. You may want to lower the value to keep from maxing out hot nodes.) The maximum hot node number is about 2/3rds of the maximum number of file locks (100,000).
- Don't use RAID5 for cache volumes. It's best to have multiple cache volumes, each on its own drive. You may need to load balance across multiple proxies, using the DNS round-robin technique.
If you have a very busy server, and you see utilization is high, try the following ideas:
- Reduce Access Rule and Indexed Logging as much as possible. Typically you would only log Deny URL rules in the Access Logs.
- Be sure not to load IDE CD-ROM drivers.
- If you are using Transparent HTTP Proxy, configure all internal web sites as exceptions, especially related to Static NAT web sites through the same server. This prevents looping.
- You might need to kill Java processes - scm.ServiceConfigurationManager (VPN change manager).
- Check for the presence of viruses (Welchia, Korga) causing massive Internet traffic requests.
NBM 3.7 started using all stateful filter exceptions by default, for best security. However, there are issues with this. First, it's not a flexible approach. For example, use Google :8080 to pick a website that uses port 8080. You'll find you cannot access it with the default 3.7/3.8 filter exceptions - you have to add custom stateful exceptions for every custom web site. Second, there are performance issues. Note that the Stateful Filtering Bug (loss of communications) is supposed to be fixed now with the latest BM 3.7 and 3.8 patches.
The BorderManager 3.7 and 3.8 filter exception defaults are secure, but not flexible. The BorderManager 3.0, 3.5, and 3.6 defaults are flexible, but have some security holes (inbound TCP). However, a compromise can be reached (which seems to work well for Craig Johnson's clients). The solution is similar to NBM 3.6, except you replace Dynamic/TCP with an identical exception that has the addition of ACK bit filtering, as shown here:
Name: DYN/ACK/TCP, Protocol: TCP, Source Ports: Any, Destination Ports: 1024-65535, ACK Bit: enabled
Custom Filter Exceptions
The goal of custom filter exceptions is to be as flexible as BorderManager 3.6, but more secure, with greatly reduced exposure to stateful filtering issues.
Here are some suggestions:
- Allow All IP from Public to Public interfaces, with source IP address = NBM server public IP.
- Allow Dynamic/UDP from Public to Public interfaces, with destination IP address = NBM server public IP.
- Allow Dyn/ACK/TCP from Public to Public interfaces, with destination IP address = NBM server public IP. (This is just like Dynamic/TCP, but with the ACK bit enabled.)
- Clean up any unneeded stateful exceptions for proxies and VPN.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com