Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion transparent DNS load-balancing with a Cisco ACE

Received: by 10.66.90.37 with SMTP id bt5mr732508pab.40.1350673725340;
        Fri, 19 Oct 2012 12:08:45 -0700 (PDT)
Path: s9ni24914pbb.0!nntp.google.com!news.glorb.com!usenet.stanford.edu!not-for-mail
From: Chuck Swiger <cswi...@mac.com>
Newsgroups: comp.protocols.dns.bind
Subject: Re: transparent DNS load-balancing with a Cisco ACE
Date: Fri, 19 Oct 2012 12:08:30 -0700
Lines: 23
Approved: bind-us...@lists.isc.org
Message-ID: <mailman.464.1350673725.11945.bind-users@lists.isc.org>
References: <50819B09.1040701@brandeis.edu>
NNTP-Posting-Host: lists.isc.org
Mime-Version: 1.0
X-Trace: usenet.stanford.edu 1350673725 9615 149.20.64.75 (19 Oct 2012 19:08:45 GMT)
X-Complaints-To: action@cs.stanford.edu
Cc: DNS BIND <bind-us...@isc.org>
To: John Miller <johnm...@brandeis.edu>
Return-Path: <cswi...@mac.com>
X-Original-To: bind-us...@lists.isc.org
Delivered-To: bind-us...@lists.isc.org
X-Proofpoint-Virus-Version: vendor=fsecure
	engine=2.50.10432:5.7.7855,1.0.431,0.0.0000
	definitions=2012-10-19_04:2012-10-19, 2012-10-19,
	1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
	ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0
	classifier=spam
	adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001
	definitions=main-1210190227
In-reply-to: <50819B09.1040701@brandeis.edu>
X-Mailer: Apple Mail (2.1085)
X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,
	MALFORMED_FREEMAIL, RCVD_IN_DNSWL_LOW, SPF_PASS,
	T_RP_MATCHES_RCVD autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mx.ams1.isc.org
X-BeenThere: bind-us...@lists.isc.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: BIND Users Mailing List <bind-users.lists.isc.org>
List-Unsubscribe: <https://lists.isc.org/mailman/options/bind-users>,
	<mailto:bind-users-requ...@lists.isc.org?subject=unsubscribe>
List-Archive: <https://lists.isc.org/pipermail/bind-users>
List-Post: <mailto:bind-us...@lists.isc.org>
List-Help: <mailto:bind-users-requ...@lists.isc.org?subject=help>
List-Subscribe: <https://lists.isc.org/mailman/listinfo/bind-users>,
	<mailto:bind-users-requ...@lists.isc.org?subject=subscribe>
Content-Type: text/plain; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Hi--

On Oct 19, 2012, at 11:25 AM, John Miller wrote:
> Hello everyone,
> 
> Perhaps a Cisco list is a better destination for this, but I've seen a similar post here in the past couple of months, so posting here as well.
> 
> I'm trying to get our Cisco ACE set up appropriately to handle DNS traffic.  So far, I've gotten it working using NAT (each rserver has a public and a private IP) and using transparent load-balancing (ACE talks directly to the public IP), aka direct server return.

IMO, the only boxes which should have IPs in both public and private netblocks should be your firewall/NAT routing boxes.

> Here's a question, however: how does one get probes working for a transparent LB setup?  If an rserver listens for connections on all interfaces, then probes work fine, but return traffic from the uses the machine's default IP (not the VIP that was originally queried) for the source address of the return traffic.

That's the default routing behavior for most platforms.  Some of them might support some form of policy-based routing via ipfw fwd / route-to or similar with other firewall mechanisms which would let the probes get returned from some other source address if you want them to do so.

> What have people done to get probes working with transparent LB?  Are any of you using NAT to handle your dns traffic?  Not tying up NAT tables seems like the way to go, but lack of probes is a deal-breaker on this end.

The locals around here have the luxury of a /8 netblock, so they can setup the reals behind a LB using publicly routable IPs and never need to NAT upon DNS traffic.  Folks with more limited # of routable IPs might well use LB to reals on an unrouteable private network range behind NAT, but in which case they wouldn't configure those boxes with public IPs.

Regards,
-- 
-Chuck