net4.0(net4.0安装未成功)

前沿拓展：

net4.0

net4.0是内部Windows组件。

　　再离微福色NETFramewo对类型大不相同的应用程序（如基于Windows的应用程序和基于Web的应用程序）时保持一致。按照工业标准生成所有通信，以确保基于NETFramework的代码可与任何其他代码集细成。

read_timeout的值，如下图所示：

另外，出于兼容性考虑，还可以在字典里将delay_factor_compact设为True，这样Netmiko 4会按照Netmiko 3的模式继续使用fast_cli, delay_factor和global_delay_factor来计算等待时间，如下图所示。

2. send_multiline()和send_multiline_timing()

在《网络工程师的Python之路 — Netmiko终极指南》实验8里曾经提到过如何处理设备交互命令的场景，比如在思科交换机上输入del flash0:/test.txt这个删除flash:下文件的命令后，系统会询问你是否confirm，如下图所示。

或者使用extended ping模式后，系统让你输入一系列的和ping相关的参数，如下图所示。

在《网络工程师的Python之路 — Netmiko终极指南》实验8中我们是通过Netmiko 3中的send_command()配合expect_string来应对这个问题。但是这种做法非常复杂且要写大量代码完成，比如说应对第一个del flash0:/test.txt的场景时，因为该交互场景只需要我们输入一个参数（是否confirm），所以代码相对还比较简洁，如下图所示。

但是遇到extended ping模式这种需要用户输入多个参数的交互场景时，代码量就非常恐怖了，如下图所示。

究其原因就是send_command()函数是基于内容的（pattern-based），它必须要等到用户告诉它等到什么回显内容后才会执行后面的代码。同样应对extended ping的交互命令场景时，如果我们用基于时间（time-based）的send_command_timing()函数来处理的话，代码量会相对小很多，如下图所示。

而在Netmiko 4中加入的send_multiline()和send_multiline_timing()则将类似的需求变得更简单，其中前者为pattern-based，后者为time-based。第一来看怎么用send_multiline()应对第一个del flash0:/test.txt的场景，代码如下图所示。

可以看到，我们在cmd_list这个列表里额外添加了两组子列表，每组子列表的元素为我们输入的命令，以及执行该命令后我们想要Netmiko在回显内容中抓取到的字符（类似send_command()的expect_string）。比如说第一组子列表里，我们输入命令del flash0:/test.txt，希望抓取到的回显内容为"Delete flash0:/test.txt?"]，第二组子列表里我们输入命令n，希望抓取到的回显内容改为confirm，以此类推。

如果用time-based的send_multiline_timing()来做的话，上述代码还能更简洁，如下图所示。

而在extended ping场景中，如果用send_multiline_timing()来做的话，代码如下图所示。

很显然在处理多交互命令的场景时，在Netmiko 4中加入的send_multline()和send_multiline_timing()将Netmiko 3时代的send_command()和send_command_timing()的代码大大简化了。另外我们也注意到send_multiline_timing()的代码比send_multiline()更简单易懂，不过相较于send_multiline()，使用send_multiline_timing()的话有一个劣势，那就是每输入一条命令后，Netmiko会默认固定等待2秒钟才会执行下一条命令（因为send_multiline_timing()是time-based的），而pattern-based的send_multiline()则会在读取到指定的回显内容后立即执行后面的代码。鱼和熊掌不可兼得，一个代码简单脚本但运行速度慢，一个代码稍微复杂但脚本运行速度快，如何取舍完全看用户自己的决定。

3. ConnLogOnly

使用Netmiko 3或之前的版本时，用户需要写很多try/except异常处理来应对各种各样会导致脚本停止工作的错误或异常，比如最常见的因为SSH用户名/密码验证不通过导致的NetmikoAuthenticationException和设备链接超时无响应导致的NetmikoTimeoutException，类似这样的异常处理在设备数量众多大型网络里基本是标配（设备数量越多，发生问题的概率越大），如下图所示。

在Netmiko 4中，我们可以用ConnLogOnly替代ConnectHandler来统一处理这个问题，代码如下图所示。

使用ConnLogOnly时，如果其返回值为None，则Netmiko会直接判定登陆设备失败（如果登陆成功，则和ConnectHandler一样返回一个Netmiko连接对象（Netmiko Connection Object）。如果要查看具体登陆失败的原因的话，可以在运行脚本后Netmiko生成的netmiko.log文件中查看（netmiko.log也是Netmiko 4新引入，Netmiko 3之前没有的功能），netmiko.log文件和脚本文件在同一文件夹下，如下图所示。