16.4. Loopback Prevention
When all of your Usenet articles come in through one router, life is simple. The path an article takes is clear, if it came into your network, it came through your border router, if it left, it left from the same.
Grow your network a bit and you'll have multiple border article routers. Each of them peer with their set of peers, unique or redundant. With enough experience, you're sure to have a night of embarrassment where you realize you're sending 100Mbps right back to your own network. Blame it on a Fat Tire on the keyboard… but it's happened. How you looped articles back to yourself is usually due to assuming articles sent out from your border routers won't be offered back in. They won't… at least to the router that offered the article to begin with. However, you now have other routers that look like their own autonomous host to any peer feeding articles to it.
The key to avoiding looping articles back to yourself is to - Understand why it occurs - Take measures to prevent it
16.4.1. How Articles Spread
The NNTP protocol is a Flood-Fill protocol. Meaning that any host that has an article, will offer that article to all hosts determined to potentially want it. The mechanisms for determining if a host wants an article or not and the associated NNTP criteria are:
Knowing the article hasn't already been to the host (Path)
Asking if the hosts wants it (IHAVE Message-ID)
Sending the article and seeing what happens (TAKETHIS Message-ID).
The first method is the "cheapest" to test, the second requires network resources to open a connection, ask the host, and process the response - minimal, but more than doing nothing. The last one sends the entire article without asking the host, an important optimization when the host does want the article, but a costly mistake when the host does not want the article. Articles sent to a host who does not want them are referred to as Rejected articles.
16.4.2. The Path Header
Every Usenet article has a Path header. According to NNTP, every host that receives an article prepends its own Path stamp to the existing string of Path stamps. Each Path stamp is traditionally a hostname, but doesn't have to be.
For example, suppose Cyclone is feeding articles to the feed below:
<Feed>
OutgoingFeedName Skunkworks
OutgoingHostName io.CUSTOMER.net
</Feed>
|
After a while, the following article is examined:
Path: io.CUSTOMER.net!news.gilderoy.com.POSTED!not-for-mail From: "Test" <test@net.com> Newsgroups: alt.test Message-ID: <vvK2b.15601$Ih1.5194502@news.gilderoy.com> Date: Tue, 26 Aug 2003 14:53:15 GMT Subject: Testing Testing . |
By examining the Path header, we can see the article was posted on news.gilderoy.com and was then sent to io.CUSTOMER.com. Cyclone examines the OutgoingHostName against each entry in the Path separated by !. If a match is found, the article is skipped and not offered to the OutgoingHostName.
As you can see, no resources were expended to determine the remote host didn't want the article minus those used for matching the path.
16.4.3. Configuring to Prevent Loopback
The key to preventing articles from being sent back into your network is to alias all of your border routers so that if any one router has seen the article, peers can assume that all aliased hosts don't need to receive a copy of the article. Making sure all internal hosts actually get the article is up to you. The logic is, if one host has seen it, they all have.
Figure 3 illustrates the -alias and Aliases directives.
.External Loopback Prevention
Figure 3 - High Resolution
-alias stamps an entry in the Path if it is not already there. For example: Suppose -alias MYNETWORK.com and Cyclone examines the following Path header:
Path: io.MYNETWORK.com!news.gilderoy.com.POSTED!not-for-mail |
Cyclone does not find an exact match, so the path is modified to become:
Path: MYNETWORK.com!io.MYNETWORK.com!news.gilderoy.com.POSTED!not-for-mail |
On the other hand, suppose -alias io.MYNETWORK.com and Cyclone examines the same Path header - the Path will not be modified.
The Aliases directive indicates that any article that has this pathstamp is equivalent to the token in OutgoingHostname.
For example:
<Feed>
OutgoingHostName io.MYNETWORK.com
...
Aliases MYNETWORK.com
</Feed> |
Given the above feed object, articles with any of the following Paths will not be offered to io.MYNETWORK.com
Path: MYNETWORK.com!io.MYNETWORK.com!news.gilderoy.com.POSTED!not-for-mail Path: MYNETWORK.com!news.gilderoy.com.POSTED!not-for-mail Path: io.MYNETWORK.com!news.gilderoy.com.POSTED!not-for-mail Path: news.abc.com!hope.net!network.customer.com!MYNETWORK.com!news.gilderoy.com.POSTED!not-for-mail |
Each border router should stamp the same string in the Path (`-alias MYNETWORK.com`) and your peers should be informed of your network alias. So your peers don't waste traffic, they should configure Aliases MYNETWORK.com on all of their feeders that peer with your feeders. Other NNTP server software has similar type directives.