UC Unleashed

Recently, a client had a user who received an NDR they had not seen before. The NDR included, among other info, the following text:

#5.0.0 smtp; 5.1.0 – Unknown address error 550-‘Error: ACL header_checks_bogon Message contains a Received: header containing a forbidden “bogon” IP address from an unassigned Class A/B network. See http://www.cymru.com/Documents/bogon-list.html, IP = “[169.254.]”‘ (delivery attempts: 0)> #SMTP#

Note the partial IP address, 169.254.. You’ll no doubt recognize that as the first two octets of the Automatic Private IP Addressing (APIPA) address range. That’s not something we generally see being used in an enterprise messaging environment, and the receiving side was right for wanting to bounce messages with that in the headers. Further testing confirmed that messages coming from any mailbox on any of the CCR implementations did include that address in the message headers. All of the clusters were built on Windows 2008. An example is:

Received: from EMB20.domain.edu ([169.254.1.96]) by EHB02.domain.edu
([230.112.41.38]) with mapi; Thu, 17 Sep 2009 17:53:24 -0700

That’s not good. When we investigated, we checked the network adapters on both nodes of the clusters. Each node had multiple NICs, including those for the public network, those for the private (heartbeat) network, and those for a dedicated log shipping network. All of the IP addresses were as built, and not APIPA addresses. However, from an active node, when we would ping the same box by name, we would get the APIPA address. The plot thickens!

When doing an IPConfig from the active node, we saw this adapter pop up:

Ethernet adapter Local Area Connection* 8:

Connection-specific DNS Suffix  . :
IPv4 Address. . . . . . . . . . . : 169.254.1.96
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . :

This is the Microsoft Cluster Virtual Adapter that is present in cluster implementations on Windows Server 2008. Simple enough, we’ll just move it further down the bind list, right? Nope. The Microsoft Cluster Virtual Adapter does not show in the Adapters and Bindings property page – so we can’t adjust that. Time to roll up the sleeves.

The solution? Editing the hosts file. By placing an entry in the hosts file of each CCR node, the problem went away. Only an entry for the local host is required and should point to the address assigned to the public NIC for itself. An example on one we used:

230.112.41.35 emx21.domain.edu emx21

Once this was completed on each node, the problem stopped, and headers indicate the proper address now.

Received: from EMB20.domain.edu ([230.112.41.35]) by EHB02.domain.edu
 ([230.112.41.38]) with mapi; Thu, 1 Oct 2009 09:16:02 -0700

If you’ve deployed Exchange 2007 on CCR, check the message headers coming from mailboxes on those clusters. A 2 minute fix is all you’ll need.