NTPv4 IPv6 not responding. IPv4 okay.

[jonathonpuff]

I'm running 122-33.SXJ6 where I want the router to act as a ntp server for both IPv4/IPv6.  Using a dual stack 6.4 linux client I'm successfully able to ntpdate -q v4_gateway no problem, but when querying the v6_gateway I end up,

server fd2b:4deb:4259:164:a00::1, stratum 0, offset 0.000000, delay 0.00000

11 Feb 15:19:38 ntpdate[14868]: no server suitable for synchronization found

"show ip sockets" lists port 123 open and listening on the v6 address.  Even the debug is displaying receive/sent message. 

Feb 11 15:19:34 EST: NTP message received from FD2B:4DEB:4259:164:250:56FF:FE91:429 on interface 'Vlan164', (FD2B:4DEB:4259:164:A00::1), table 0.

Feb 11 15:19:34 EST: NTP Core(DEBUG): ntp_receive: message received

Feb 11 15:19:34 EST: NTP Core(DEBUG): ntp_receive: peer is 0x00000000, next action is 3.

Feb 11 15:19:34 EST: NTP Core(DEBUG): ntp_receive: doing fast answer to client.

Feb 11 15:19:34 EST: NTP IPv6 message sent to FD2B:4DEB:4259:164:250:56FF:FE91:429, from FD2B:4DEB:4259:164:A00::1, table

R1#= 0, interface Vlan164.

Feb 11 15:19:35 EST: NTP message received from FD2B:4DEB:4259:164:250:56FF:FE91:429 on interface 'Vlan164', (FD2B:4DEB:4259:164:A00::1), table 0.

Feb 11 15:19:35 EST: NTP Core(DEBUG): ntp_receive: message received

Feb 11 15:19:35 EST: NTP Core(DEBUG): ntp_receive: peer is 0x00000000, next action is 3.

Feb 11 15:19:35 EST: NTP Core(DEBUG): ntp_receive: doing fast answer to client.

Feb 11 15:19:35 EST: NTP IPv6 message sent to FD2B:4DEB:4259:164:250:56FF:FE91:429, from FD2B:4DEB:

R1#4259:164:A00::1, table = 0, interface Vlan164.

Feb 11 15:19:36 EST: NTP message received from FD2B:4DEB:4259:164:250:56FF:FE91:429 on interface 'Vlan164', (FD2B:4DEB:4259:164:A00::1), table 0.

Feb 11 15:19:36 EST: NTP Core(DEBUG): ntp_receive: message received

Feb 11 15:19:36 EST: NTP Core(DEBUG): ntp_receive: peer is 0x00000000, next action is 3.

Feb 11 15:19:36 EST: NTP Core(DEBUG): ntp_receive: doing fast answer to client.

Feb 11 15:19:36 EST: NTP IPv6 message sent to FD2B:4DEB:4259:164:250:56FF:FE

R1#91:429, from FD2B:4DEB:4259:164:A00::1, table = 0, interface Vlan164.

Feb 11 15:19:37 EST: NTP message received from FD2B:4DEB:4259:164:250:56FF:FE91:429 on interface 'Vlan164', (FD2B:4DEB:4259:164:A00::1), table 0.

Feb 11 15:19:37 EST: NTP Core(DEBUG): ntp_receive: message received

Feb 11 15:19:37 EST: NTP Core(DEBUG): ntp_receive: peer is 0x00000000, next action is 3.

Feb 11 15:19:37 EST: NTP Core(DEBUG): ntp_receive: doing fast answer to client.

Feb 11 15:19:37 EST: NTP IPv6 message sent to FD2B:4D

R1#EB:4259:164:250:56FF:FE91:429, from FD2B:4DEB:4259:164:A00::1, table = 0, interface Vlan164.

Any thoughts on the issue?

[Andrew Yourtchenko]

Given that the debugs seem ok, the first question is: do you see the replies on the physical wire between the two boxes or not ?

If you see them on the wire - then you'd need to further dig why they do not make it to the host stack, if you do not see them on the wire, then the place to dig would be the NTP server side.

Of course this troubleshooting assumes that you have checked that other IPv6 connectivity is ok between the two - i.e. that you can ping6 between them with no problem ?

[jonathonpuff]

Thanks Andrew for the response.

ipv6 icmp connectivity is ok and all firewalls are disabled. 

wireshark is showing the responses on the wire; however the src and dst ports sent from router are the same (123) instead of having the dst port being the original src port from the client.  It's also showing that the router is acting as a NTPv4 server, not symetric active mode.

[Andrew Yourtchenko]

I don't have a readily available c6k in my lab (that's where 122-33.SXJ6 is running on, right?), so I did a sanity check on an 890 box running one of the latest 12.4 builds. For simplicity, I've just configured "ntp master 5", and tried ntpdate -q fe80::%eth0 on the linux box - it worked with no problem.

Also, tcpdump shows the replies directed at the correct (high) port on the client.

So I'd say unless someone chimes in with a known bug ID (my cursory search did not find any), the best course of action could be to go ahead and get the TAC case to have them investigate this behavior and see whether this has been already fixed - or request to fix it.

[jonathonpuff · Accepted solution]

I did end up opening a TAC case and ended up hitting this bug ID, CSCty46031.

The recommendation was to upgrade to 151.1.SY1 and doing that solved this problem. 

[Andrew Yourtchenko]

Excellent! Sorry for myself not being lucky with the search. And good it's all good now - and this reference might be helpful to others.