nsd users - Mar 2014 - Possible fragmentation issue transferring larger zones over IPv6?

Today I added some records to a zone and it made the AXFR size greater 
than one packet.  At that point, the zone would no longer transfer from 
my hidden master to my slaves (everything is running 4.0.1).

Normally, all of the zone transfers are done over IPv6.  The transfers 
did work when I tested them over IPv4, but I can't reliably use IPv4. 
My kludge was to break the zonefile up into several subzones, making 
each small enough to AXFR in a single packet.

I'm not sure how to document this other than showing you the "operation
timed out: tcp" log entries and zonestatus output that shows the slaves 
are not getting the zone.

Have others run into this issue, or is this a known issue?  The relevant 
terms appear to be too common or vague for an effective search engine query.

On 29/03/14 22:37, Darren Pilgrim wrote:
> Today I added some records to a zone and it made the AXFR size greater
> than one packet.  At that point, the zone would no longer transfer from
> my hidden master to my slaves (everything is running 4.0.1).
>  
> Have others run into this issue, or is this a known issue?  The relevant
> terms appear to be too common or vague for an effective search engine
> query.
Hi,

as you can read from archives of this list I raised this issue last
March 13, but I'm currently experiencing this issue.

After upgrading NSD version (from 4.0.1 to 4.0.3) and after applying
Wouter's suggestion (--disable-recvmmsg configure) nothing has changed.

So I asked VMWare for support because, in my scenario, it happens with
VMs inside a ESXi 5.5 cluster.
I'll come back to the list as soon as the case is solved.

Thank you
--
antonio

On 29/03/2014 22:37, Darren Pilgrim wrote:
> I'm not sure how to document this other than showing you the
"operation
> timed out: tcp" log entries and zonestatus output that shows the
slaves
> are not getting the zone.
If NSD is emitting packets that are bigger than the IPv6 path MTU to the
slave, then a device along the path will send back an ICMP message
asking the source to fragment. If this ICMP message never reaches the
master, it won't know that it needs to fragment the packets, and will
keep sending bigger packets, and result in a timeout.

On the master, run tcpdump, and then send out large packets to the slave
(ping6 will do) and see if you're getting back the relevant ICMP
message, and whether the network stack on the master is adapting itself
to such a notificaiton.

Regards,

Anand Buddhdev
RIPE NCC