i.e. I am seeing:
client sport=5000 dport=53 query id=2346 hostname A
client sport=5000 dport=53 query id=4646 hostname AAAA
server dport=5000 sport=53 reply id=2346 A=192.168.x.y
...and that's it. The 2nd reply is dropped. If the client makes the
queries "slowly" they work fine:
Just a follow-on.
Bah. Stupid mailer. Apologies for the partial send:
The specific issue seems to be that the ACE *requires* at least one UDP
reply packet from the server before fully "opening" the UDP session.
Monitoring at the "rserver" end shows for the above:
client sport=5000 dport=53 query id=2346 hostname A
server dport=5000 sport=53 reply id=2346 A=192.168.x.y
i.e. the 2nd *request* is dropped.
Once that 1st reply is sent, you can send as many queries as you want:
client sport=5000 dport=53 query id=2346 hostname A
server dport=5000 sport=53 reply id=2346 A=192.168.x.y
client sport=5000 dport=53 query id=2347 hostname1
client sport=5000 dport=53 query id=2348 hostname2
client sport=5000 dport=53 query id=2349 hostname3
server dport=5000 sport=53 reply id=2347 A=192.168.c.d
server dport=5000 sport=53 reply id=2348 A=192.168.w.v
server dport=5000 sport=53 reply id=2349 A=192.168.a.b
So, it seems to be some kind of analogous feature to TCP SYN protect or
such like, to protect a client flooding a server.
Many thanks for all the suggestions; I have tried many combinations:
* an "ip only" VIP i.e. not UDP-specific in the policy-map
* UDP fast age
* different application port/protocol
None helped. I have not yet been willing to make the (per-vlan) change
to UDP boost since the box is in (critical) service, but it could well
solve the problem.
So, in summary - the issue is not DNS-specific, it's some kind of UDP
session-awareness that requires 1 reply packet before permitting
subsequent request packets.
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
