none
server 2019 拔号后DNS问题 RRS feed

  • 问题

  • 一台电脑上安装的是server2019  本地链接DNS是172.16.8.1     建了一个PPPOE拔号链接,拔号后取到的DNS是223.5.5.5    正常情况下拔号后系统应该用223.5.5.5来解析才对,可是不管拔号还是不拔号系统都是用172.16.8.1来解析,已经在2008R2   2012R2上测试过,只要拔号就是走拔号的DNS来解析,这是对的,但是server2019上就不行了,始终是走的本地链接的DNS,求分析解决,谢谢啦
    2020年5月14日 1:41

答案

  • Hi ,

    请理解,我们没有账号和密码去测试PPPOE拨号链接,所以没有办法复现您的问题。但是我尝试创建了一下PPPOE拨号链接,我发现是会生成一张专门的虚拟网卡的。

    所以,基于这个情况,我怀疑是网卡的跃点数导致的。 请您检查08R2或者是12R2上,分别PPPOE生成的这张网卡的跃点数是否是比本地网卡的跃点数要小。然后再对应到server 2019上看看跃点数是不是比本地网卡的跃点数要大,如果是的话,尝试修改到较低的值,保证223.5.5.5的网络优先试试看,看看问题是否可以解决。

    希望可以帮助到您。

    此致

    Candy


    如果回复对您有所帮助的话,请您把回复标记为答复,方便论坛中其他有相同问题的用户快速找到有帮助的回复。

    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com   




    2020年5月14日 7:43
    版主
  • 是挺奇怪的,按道理说跃点数低的话,DNS应该是要走拨号链接的DNS的。如果要找RCA(root cause analyze)的话,从论坛的角度是很难去进行分析的,因为需要去分析网络包,但是由于论坛是不支持抓包分析的,如果要找到根本原因的话,建议还是和微软开case进行深入调查的,以下是微软开case的链接:

    https://support.microsoft.com/en-us/gp/customer-service-phone-numbers

    但是无论如何,结果还算是好的,通过workaround的方式(把跃点数改成固定的数值)解决了问题。

    如果回复对您有所帮助的话,请您把有帮助的回复标记为答复,我将暂停对此贴的追踪。

    如果还有什么其他需要我帮助您的话,请随时在贴下进行更新。

    此致

    Candy


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com   

    • 已标记为答案 tigerok 2020年5月18日 3:52
    2020年5月15日 6:16
    版主

全部回复

  • Hi ,

    请理解,我们没有账号和密码去测试PPPOE拨号链接,所以没有办法复现您的问题。但是我尝试创建了一下PPPOE拨号链接,我发现是会生成一张专门的虚拟网卡的。

    所以,基于这个情况,我怀疑是网卡的跃点数导致的。 请您检查08R2或者是12R2上,分别PPPOE生成的这张网卡的跃点数是否是比本地网卡的跃点数要小。然后再对应到server 2019上看看跃点数是不是比本地网卡的跃点数要大,如果是的话,尝试修改到较低的值,保证223.5.5.5的网络优先试试看,看看问题是否可以解决。

    希望可以帮助到您。

    此致

    Candy


    如果回复对您有所帮助的话,请您把回复标记为答复,方便论坛中其他有相同问题的用户快速找到有帮助的回复。

    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com   




    2020年5月14日 7:43
    版主
  • 拔号链接的跃点数肯定是比其它本地链接小的,奇怪的就是DNS不走拔号链接的DNS,手动把拔号链接的跃点数改成固定的,居然可以了。不知为何
    2020年5月15日 5:54
  • 是挺奇怪的,按道理说跃点数低的话,DNS应该是要走拨号链接的DNS的。如果要找RCA(root cause analyze)的话,从论坛的角度是很难去进行分析的,因为需要去分析网络包,但是由于论坛是不支持抓包分析的,如果要找到根本原因的话,建议还是和微软开case进行深入调查的,以下是微软开case的链接:

    https://support.microsoft.com/en-us/gp/customer-service-phone-numbers

    但是无论如何,结果还算是好的,通过workaround的方式(把跃点数改成固定的数值)解决了问题。

    如果回复对您有所帮助的话,请您把有帮助的回复标记为答复,我将暂停对此贴的追踪。

    如果还有什么其他需要我帮助您的话,请随时在贴下进行更新。

    此致

    Candy


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com   

    • 已标记为答案 tigerok 2020年5月18日 3:52
    2020年5月15日 6:16
    版主