WAN link manger fails to test after link restore

Hello rfcat_vk,

Is WAN link restored after you restarted XG115w? Or is it still in same state where IPv6 is not working?

Can you please elaborate what kind of connection method you are referring which requires UTM to be deployed in front of ISP? And how did you restored XG link?

If IPv6 is not working right now and appliance is in same state, please PM access id of the appliance.

Regards,

Sanket Shah

Hi Sanket,

The reason for the UTM is because the XG in its current form does not support IPv6 PD for address assignment. My proposed ISP/RSP uses PD to assign IPv6 addresses.

I power on the UTM and let is stabilise before before disconnecting the XG from the NBN modem and connecting the UTM.

When I finish my testing on the UTM I restore the XG connection to the NBN modem. Neither IP4 or IPv6 restore on the XG.

The WAN interface is edited which is previous version of XG usually resulted in all addresses working correctly. After the edited interface is saved the IP4 address (WAN link manager) shows as active, the IPv6 does not, after a short while the IPv6 address is displayed on the WAN interface, but the WAN link manager still sows IPv6 as failed.

The only way to fix this is to restart the XG115W and hope the WAN interface does not die completely as a couple of nights previously. The restart time is very long and eventually the WAN link manger  indicates both IP4 and IPv6 are working.

I hope this provides the details you are seeking?

Ian

Hello Ian,

Remote access is still not expired and accessible.

Let me look at 2nd occurrence logs and will ask any follow up questions on PM.

Regards,

Sanket Shah 

Thank you.

Ian

Hi Sanket,

I ran the test this afternoon. Before I restored the connection to the XG I started the tcpdump capture and both links showed as down in wan link manager.

The disappointing thing about this exercise is that the UTM only picks up a /128 IPv6 address whereas the XG picks up a /64 from  the same /56 range.

I had to restart the XG to regain internet access.

Ian

Hi Sanket,

I have found part of the problem with the testing is the keyboard sends strange characters to the XG console etc when using bluetooth, using the USB connection and the entered command work.

Next the host should be 2001:4860:4860::64.

Next the edit of the interface causes the ping6 to be sent, but not a DHCP request so the connection is not re-established.

there is more of this dump if you want to review it.

Ian

Thanks Ian for capturing TCPDUMP. Is it possible to share it over PM or here?

"Next the edit of the interface causes the ping6 to be sent, but not a DHCP request so the connection is not re-established" - Following TCPDUMP capture won't help you confirm whether DHCP request was sent or not.

Can you please try with following?

tcpdump -n host 2001:4860:4860::64 or port 546 or port 547 -vv

Tomorrow's challenge, makes good activity, weather forecast is rain, rain, rain.

I will copy today'y result before starting testing tomorrow and sent it to you in PM. Should not having any parameters for port allowed the capture of all traffic?

Ian

TCPDUMP which you have taken earlier will only capture traffic destined to host 2001:4860:4860::64. DHCP6 traffic won't have this as source or destination so it won't be capture.

On a second thought, I suggest to save pcap on appliance itself so that it can be reviewed later. Please use following command (verified on your appliance) which will save pcap file in /var/sanket-logs folder.

XG115w_XN03_SFOS 19.5.0 EAP1-Build144# tcpdump -n host 2001:4860:4860::64 or port 546 or port 547 -vv -b -w /var/sanket-logs/icmp6_dhcp6.pcap

Regards,

Sanket Shah

Okay, will do.

ian

Hi Sanket,

thinking about the command line, it will not produce the results you are after because the IPv6 address is a google one and not a telstra network server.

Ian

I sent you a PM.

Ian

I sent you a PM.

Ian

Hello Ian,

After doing investigation from the logs and pcaps gathered on your setup, it sounds like defect.

There might be some race condition happening between DHCP IPv6 address assignment and gateway.

Issue is being tracked against NC-108057 internally and we will try to fix it as soon as possible.

Meanwhile only workaround in such scenario is - reboot the appliance :-(

Thanks a lot for all your support and cooperation. And sorry for the inconvenience caused.

Regards,

Sanket Shah