Weird performance issue.

[Cedric Lejeune]

Tom Greaser wrote:
> IF so.
> What dose the upstream NS servers say is your NS servers are for your domain ?
> When  you do a dig what dose the output show ?
Currently, upstream servers point to the right IP address of the 
production server. That is why I am trying to move this address to the 
new server. That way, I thought I could switch thoses two servers 
without anything but a very short DNS service failure.

> Or 
> 
> Are you just trying to point your local users to use the newer 9.5.0.dfsg.P1-2 package box ?
Kinda. Once more, I am only trying to move the official IP address from 
the old server to the new one and remove network from old server to make 
new server the official one.

May this help?

Current situation:
+---------------------+       +-----------------+
| current bind server |       | new bind server |
| official address    |       | address         |
+---------------------+       +-----------------+
            |                           |
-------------------------------------------------

Desired situation:
+---------------------+       +------------------+
| current bind server |       | new bind server  |
| address             |       | official address |
+---------------------+       +------------------+
            |                            |
--------------------------------------------------

One thing I cannot understand is why the new server is running fine with 
our mail server pointing at it as a resolver and it starts to timeout 
and processes number increases as soon as I change its IP address to the 
official one (of course disabling this address on the old server).

Thanks for your help,

Kind regards,

cedric.

>>>> Cedric Lejeune <cedric.lejeune at arcelormittal.com> 08/21/08 5:21 AM >>> 
> Unfortunately, MAC address are not 'hardcoded' in our firewall, at least 
> not thoses regarding DNS servers. One thing I have forgotten in my 
> previous post is that our mail router _is_ currently running pretty fine 
> using the new server. But as soon as we switch IP address, everything 
> goes wrong =/
> Thanks for your help.
> 
> Kind regards,
> 
> cedric.
> 
> Fr34k wrote:
>> Is your firewall set to arp for different MAC addresses?
>> If so, was that updated to reflect the changes you are trying to make?
>> I did Checkpoint in a former life, and I can remember defining static arp entries for some of the NAT setup we had.
>> Is is all I can think of or remember.
>> HTH
>>
>>
>>
>> ----- Original Message ----
>> From: Cedric Lejeune <cedric.lejeune at arcelormittal.com>
>> To: bind-users at isc.org
>> Sent: Wednesday, August 20, 2008 10:08:40 AM
>> Subject: Weird performance issue.
>>
>> Hello list,
>> We currently running two instances of bind9, each one on a different 
>> host. Both hosts have their own IP address and basic tests work perfectly:
>> - ping of external server(s) work fine (FQDN and IP address)
>> - host resolution works fine
>> - named processes number is quite low (~16)
>>
>> The problem occurs when we try to move IP address from master server to 
>> slave server:
>> - ping of external server(s) failed (FQDN and IP address)
>> - host resolution take a huge time to complete or do not complete at all 
>> (timeout)
>> - processes number increases significantly (~1000, which seems to 
>> correspond to recursive-clients default value)
>>
>> We have taken care of everything we can think of:
>> - bind9 configuration
>> - network configuration
>> - arp resolution
>> - firewall configuration (although being a CheckPoint firewall, Smart 
>> Defense does not seem to cause any issue since only logging is 
>> activated, cf 
>> http://groups.google.com/group/comp.protocols.dns.bind/browse_thread/thread/cfa8c63ec6bd08d6 
>> . Firewall log does not show anything weird too.)
>>
>> Log do not show anything relevant to me, except the well known "too many 
>> timeouts resolving 'ns2.highergroundtech.com/AAAA' (in 
>> 'highergroundtech.com'?): disabling EDNS" message.
>>
>> We currently running BIND9 on Linux Debian:
>> - the one running perfectly is a quite outdated 9.2.1-2.woody.1 package
>> - the one causing problem is a quite up to date 1:9.5.0.dfsg.P1-2 package
>>
>> Configuration files have only been updated to reflect releases changes.
>>
>> Do you have any hint or advice so I can at least look at where the issue 
>> comes from and then try to solve it?
>>
>> Thanks for your help,
>>
>> Kind regards,
>>
>> cedric.
>>
> 
> 
> 
> 
>