weird transfer-source problems with one DNS node

[Ian Veach]

I'm having a weird problem where one of our DNS servers is not
communicating on the expected transfer-source IPs (but the rest are).
They're generally configured exact/similar, but there's obviously something
causing a difference on the one node.

We run four slave DNS as public NS (with private masters for mgmt.).  Two
nodes per physical site (two sites).  All run OSPF to provide anycast
addresses as service addresses.  All have an IP for the server/OS itself
(each), and all have an IP dedicated for xfers only.

So, for example (taking one location, obfuscating servers "foo" and "bar")
     10.10.205.240/25     foo (OS IP, eth0)
     10.10.205.230/25     foo-xfer (xfer, eth0:1)
     10.10.205.1/32       service-ns1 (anycast IP, lo:1)
     10.11.205.1/32       service-ns2 (anycast IP, lo:2)

     10.10.205.239/25     bar
     10.10.205.229/25     bar-xfer
     10.10.205.1/32       service-ns1
     10.11.205.1/32       service-ns2

So, on bar, everything works fine.  And when I do a tcpdump on bar-xfer, I
see the xfers occurring (connections to/from master).  However, on foo, I
see no traffic on the xfer IP.  When I tcpdump the main OS IP (or the NS
master address), I see that communication occurring on the OS IP, and not
the transfer-source IP.  And yet, here's the config line in named.conf:

     transfer-source 10.10.205.230;

So, any ideas on why I would see that slave initiate transfers on it's OS
IP versus the transfer-source IP... especially when the other three work
fine?

Same OS, same OS level, same (theoretical) config except for the IP
differences between machines...

Thanks for any pointers!


cheers and thanks,

Ian Veach, Senior Systems Analyst
System Computing Services, Nevada System of Higher Education

-- 
PUBLIC RECORDS NOTICE: In accordance with NRS Chapter 239, this email and 
responses, unless otherwise made confidential by law, may be subject to the 
Nevada Public Records laws and may be disclosed to the public upon request.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160718/924ad147/attachment.html>