Leadership By Numbers :: Routing Mail without Connection Documents

Category None

"Badges? We ain't got no badges. We don't need no badges.
I don't have to show you any stinking badges!"

In the last year, I have had a few occasions where a client felt they either had too many mail connection documents, or thought their mail routing problems were due to corrupted mail routing. I've never heard of corrupted connection documents (and I double checked the forums, support database, etc.), but the issue stayed with me, nevertheless. Truth is, we don't really need mail connection documents to route mail between Domino servers.

Here's how to do it.

The architecture of Domino is very forgiving, as it was designed for multiple protocols (some, like AppleTalk and BanyanVines have been dropped) and it tolerates intermittent connectivity through modems. Connection documents help identify the precise route and time for batching mail delivery.

However, most current Domino installations are built using uninterrupted TCP/IP connectivity over dedicated lines, or through the Internet. There just may not be a need for connection documents as there has in the past.

Domino mail routing occurs under two conditions, a shared Domino Named Network (DNN) or by a connection document. If we are not going to use the connection document, then we need to turn to the DNN.

All servers belong to a DNN; they can have their own or share it with another server. All servers using the same DNN handle mail routing instantaneously, and any Notes client connecting to a home server (usually their mail server) receives the DNN list as all the servers they can easily view (the file/database/open request).

The DNN configuration is simply a DNN name associated with a port on the server document. The server document has a table under ports in which the DNN (Notes Network entry) is identified. It usually contains a network sounding phrase: â€œTCPIP Networkâ€ or â€œSUBNET10.â€ But, the DNN name could be pig Latinâ€”it doesn't matter what it is called.

Server A

Port	Protocol	Notes Network	Net Address	Enabled
TCPIP	TCP	TCPIP Network	192.168.2.21	ENABLED

Server B

Port	Protocol	Notes Network	Net Address	Enabled
TCPIP	TCP	TCPIP Network	b.bookworld.com	ENABLED

Notice that in the above example the IP address is different for the two server documents, but the DNN is identical. Mail will route automatically between Server A and Server B. This brings up the issue of why don't we simply dump connections documents and put all the servers in to the same DNN? And, some Domino installations actually have 30 or 50 mail servers in the same DNN for instant mail routing.

I'm not fond of putting all the servers into the same DNN because it makes trouble shooting a little more difficult, and it spreads the routing all over the map with a mesh typology. Here's a compromise: use a common DNN has a bridge between other DNNs (or separate servers). This is what it would look like to route mail from Server A through Server B into Server C.

Server A

Port	Protocol	Notes Network	Net Address	Enabled
TCPIP	TCP	DNNONE	192.168.2.21	ENABLED

Server B

Port	Protocol	Notes Network	Net Address	Enabled
TCPIP	TCP	DNNONE	b.bookworld.com	ENABLED
TCPIP	TCP	DNNTWO	b.bookworld.com	ENABLED

Server C

Port	Protocol	Notes Network	Net Address	Enabled
TCPIP	TCP	DNNTWO	c.bookworld.com	ENABLED

Now, my mail is instantaneously routed from Server A to C through Server B, and I don't have any connection documents.

Comments

2 - Remember, though, that DNN (I prefer "NNN" actually) routing zaps cost-based routing, which can negatively affect failover plans. Without cost configuration, routes are determined by number of hops. And when hops between two routes match, Domino arbitrates using the alphabetical order of the common name of the next server in the route. You gotta be careful for that last, because you'll find that you've suddenly created mail routing hubs that send data across trans-Atlantic lines if you're not careful.

*Total* elimination of connection records is superfluous. What should be targetted is entrance and exit points for groups of servers, which should themselves be on a matched DNN. Backbone routing between entrance points can then be established by either connection records (which make for easier analysis, maintenance and failover) or by secondary DNNs as you use above.

By the way, the File-Database-Open list in 6 is determined by what servers you already have desktop icons for, not what's in the DNN (thank god!) The only time the DNN list is reflected for users is when they go the extra mile in searching for a replica by clicking "Other" on the server option.

Posted by Nathan T. Freeman At 10:34:46 PM On 01/14/2005 | - Website - |

1 - Oh, I'm not necessarily recommending flying without connection documents, I just wanted to point out that they are not a requirement for mail routing.

There are plenty of sites that I work with, that have put all of their national mail servers in one DNN and called it good. I think it's a little weird, but they claim no down sides.

However, it would be possible to be creative with the DNN routing and allow multiple routes from one server to another server. Also, in the example that I provided, Server C could be in Europe and Server B is the appropriate server to route through.

Finally, about the File/Open/Database client listing: yes, it does draw on previously connected servers in the bookmark.nsf as well as the DNN. However, in terms of what DNN provides, it's the DNN of the home server. I'm setting up new clients (ND6.5.3) every week, and it's easy to see.

You like tomato and I like . . . Yes, Lotus does not have consistent terminology for the DNN. The "official" term is DNN, but it has been NNN much longer, and the Admin client simply has a bookmark entry for Network (which is very confusing).

I'm certainly not saying, kill all connection documents, but I think it is a useful alternative.

Thanks for your thoughtful comments,
Jack

Posted by Jack Dausman At 11:01:54 PM On 01/14/2005 | - Website - |