How to deal with the problem when receive bad NTP packets

Publication Date:  2014-09-15 Views:  2133 Downloads:  0
Issue Description
AR received a lot of bad NTP packets from unknown source like below:
Apr 27 2014 11:18:20+02:00 DST G2EST12-TRID10602 %%01NTP/4/PACKET_LENGTH_WRONG(l)[6]:The received NTP packet is longer than or shorter than a valid packet. (RcvLen=12)
Apr 27 2014 05:17:10+02:00 DST G2EST12-TRID10602 %%01NTP/4/PACKET_LENGTH_WRONG(l)[7]:The received NTP packet is longer than or shorter than a valid packet. (RcvLen=12)
Apr 27 2014 03:12:54+02:00 DST G2EST12-TRID10602 %%01NTP/4/PACKET_LENGTH_WRONG(l)[8]:The received NTP packet is longer than or shorter than a valid packet. (RcvLen=12)
Apr 27 2014 03:06:46+02:00 DST G2EST12-TRID10602 %%01NTP/4/PACKET_LENGTH_WRONG(l)[9]:The received NTP packet is longer than or shorter than a valid packet. (RcvLen=8)
Alarm Information
null
Handling Process
We can use traffic-filter to deny such NTP packets from unknow sources.
ACL 3000
rule 10 permit udp source 10.160.xx.xx 0 source-port eq ntp destination-port eq ntp (3749 matches) // permit normal NTP server
rule 20 permit udp source 10.160.xx.xx 0 source-port eq ntp destination-port eq ntp (3750 matches)
rule 30 deny udp source-port eq ntp (1052 matches)
interface GigabitEthernet0/0/2  // apply the ACL to traffic-filter under interfaces which may receive bad NTP packets.
ip address 101.200.55.1 255.255.255.248
traffic-filter inbound acl 3000

problem resolved.
Root Cause
1. There are some unknow NTP server send  bad NTP packets to AR router. And these packets made no sense.
2. The packets would appear in the log buffer but in fact, it would not affect the Normal NTP service.
Suggestions
null

END