NETCONF和OpenFlow差异性比较：
特点
OpenFlow
NETCONF
协议类型
远程访问协议
网络管理协议
主要用途
允许对网络交换机或路由器的转发平面进行远程访问。
使网络管理系统能够发送编辑和移除网络设备的配置。
配置的持久性
创建的转发表条目基本上是临时的，不会出现在设备设置中，在设备重载或连接丢失时会丢失。
NETCONF协议调整设备配置。使用NETCONF配置的内容会显示在设备配置中，并且可以在选择保存更改时从运行保存到永久（或启动）配置。
简易性和独立性
与NETCONF相比，更为简单，特别是因为它独立于供应商和设备。
与供应商和设备的依赖性流程紧密相关，涉及安装基于策略路由的路由图、静态MPLS进出标签映射、访问列表等。
对SDN的支持
非常有助于SDN，因为它可以简单地实现控制平面和数据平面的分离。
与控制平面和数据平面的分离不一致。
设备通用性和特定性
允许通过OpenFlow在任何支持OpenFlow的交换机上安装相同类型的转发条目。
可以在Junos交换机或路由器上创建ACL，但相关NETCONF消息的实际数据将是特定于供应商的。
OpenFlow侧重于简化网络设备的远程访问和转发规则的管理，适用于SDN环境中的控制平面和数据平面分离。
而NETCONF则专注于提供详细的网络设备配置管理，支持广泛的配置任务，但其与设备和供应商的依赖性较强，不适合执行控制与数据平面的分离。
调研NETCONF管理平台需要考虑哪些因素，为什么？选择NETCONF平台时需要考虑功能性、扩展性、兼容性以及社区和技术支持的重要性。
1. 功能性
假设某电信运营商需要部署一个大规模的网络自动化系统来管理其跨国的网络设备。该公司需要确保所选的NETCONF平台能够支持广泛的网络配置任务，如自动部署、配置更新、监控和故障恢复。如果平台的功能不全，可能无法满足公司的全面需求，导致必须依赖多个工具和系统，这样不仅增加了复杂性，还可能导致管理上的漏洞和效率低下。
2. 扩展性
借鉴一个快速增长的云服务提供商场景，其基础设施不断扩展，新的服务器和网络设备不定期加入。如果NETCONF平台缺乏足够的扩展性，最初的部署可能很快就无法处理新增的设备和配置需求。平台的扩展性确保了即使在设备数量大幅增加的情况下，也能保持高效的配置和管理。
3. 兼容性
设想一个具有多种不同硬件和遗留系统的企业网络环境，选择的NETCONF平台需要能够与这些多样化的设备兼容。如果平台只支持特定厂商或新设备，那么企业可能需要额外投入大量资金更换设备，或者无法全面实施网络自动化，从而无法实现预期的网络管理效率和成本效益。
4. 社区和技术支持
想象一个初创公司，他们在部署第一个基于NETCONF的网络管理系统。由于他们可能缺乏深入的专业知识，因此一个活跃的开源社区和强大的技术支持对他们至关重要。社区可以提供实用的建议和解决方案，而可靠的技术支持则能确保在遇到技术难题时得到快速解决。没有这些支持，初创公司可能会遇到连续的停机和配置错误，这将对业务造成严重影响。
可以用传统的CLI方式和NETCONF同时配置一台设备吗？可以。但是虽说技术上可行，但这种混合配置方法需要谨慎处理，以避免潜在的配置冲突和一致性问题。
互补使用：可以选择根据配置任务的复杂性和自动化需求来决定使用CLI或NETCONF。例如，可能使用CLI进行简单的、临时的更改，而使用NETCONF进行需要高度自动化的、批量的配置任务。同步机制：需要确保在使用CLI和NETCONF进行配置更改时，设备的配置状态是同步的。一些网络设备和管理系统能够检测和同步通过不同方法所做的配置更改，但这通常依赖于设备的支持和配置。版本控制和审计：使用版本控制系统记录所有配置更改可以帮助管理通过CLI和NETCONF进行的修改。这有助于跟踪更改历史并在出现问题时进行故障排除。配置验证：在执行任何配置任务后（无论是通过CLI还是NETCONF），都应验证设备的操作状态和性能，确保新配置没有引入问题。注意事项：
配置覆盖：使用NETCONF推送的配置可能会覆盖通过CLI手动设置的配置，反之亦然。这可能导致意外的网络行为和故障。冲突解决：在某些设备上，如果通过CLI和NETCONF对同一配置项进行更改，可能需要特定的策略来解决冲突。这可能涉及到设置优先级规则或最后写入者优先的原则。自动化与手动操作的界定：建议为使用CLI和NETCONF的操作建立清晰的指南，指明何时使用每种方法，以及如何处理由此引起的潜在冲突。
通过CLI变更交换机的配置后，新配置会自动同步给NETCONF管理平台吗？是否能够自动将通过CLI变更的交换机配置同步到NETCONF管理平台取决于几个因素，包括网络设备的支持能力、NETCONF服务器的实现方式以及管理平台的具体配置。
设备和平台的能力设备支持：一些网络设备能够跟踪并记录通过任何接口（包括CLI）所做的配置更改，并将这些更改反映到设备的全局配置状态中。这意味着不管是通过CLI还是NETCONF进行的更改，都会更新到设备的当前配置中。NETCONF服务器实现：NETCONF服务器需要能够识别这些变化，并将变更的配置数据提供给请求的NETCONF客户端。如果NETCONF服务器和设备的实现支持这种动态更新，那么通过CLI所做的更改可以被NETCONF客户端在下一次交互时看到。同步机制主动查询：如果设备或NETCONF实现不支持自动更新更改，管理平台可能需要定期或在特定操作前主动查询设备状态，以获取最新的配置信息。这可以通过设置定时任务来完成，例如，定期发送<get-config>请求到设备。事件通知：一些高级设备和NETCONF实现支持事件通知（如YANG的notification机制）。如果配置通过CLI更改，设备可以生成一个通知事件，该事件通过NETCONF传递给管理平台，从而实时更新配置状态。建议一致性检查：定期进行配置一致性检查，确保管理平台的配置视图与设备上的实际配置保持一致。这可以通过脚本或自动化工具实现，对比管理平台记录的配置和设备当前配置的差异。配置备份与恢复：定期备份设备配置，以便在出现不一致或错误配置时可以快速恢复。
NETCONF管理平台与设备是如何交互的？主动拉取（Pull）：配置获取：管理平台主动发送<get>或<get-config>请求来拉取设备的当前配置或状态信息。配置修改：通过发送<edit-config>、<copy-config>、<delete-config>等请求来修改设备的配置。这种方式要求管理平台知道何时需要查询或修改配置，通常基于特定的网络管理策略或响应某些外部触发的事件。通知推送（Push）：尽管NETCONF本身是基于请求/响应模式设计的，但它通过NETCONF通知机制支持某种形式的“推送”模式。这需要设备配置以支持并发送通知。事件通知：在YANG模型中定义的通知类型可以被设备用来主动向管理平台报告特定事件或状态更改，这些通知是在NETCONF会话中推送的。所以，大多数情况下，NETCONF管理平台需要定期或基于特定事件主动查询设备状态，以确保管理系统的配置视图与实际设备状态同步。
配置实时更新或事件驱动更新可以部分依赖设备发出的NETCONF通知，但这通常补充而非替代主动查询机制。
建议：为了实现更动态和响应式的网络管理，可以结合使用主动查询和事件通知：
定时同步任务：设置周期性任务，定期从设备获取最新配置和状态，适用于不支持或未配置通知的设备。事件订阅：配置设备和管理平台以支持事件通知，使得设备在检测到定义的事件或条件变化时，可以自动向管理平台发送通知。
<附>OpenFlow的主要优势：控制平面和数据平面的分离：① 在传统网络中，控制平面（决定数据如何流动）和数据平面（实际转发数据）通常紧密集成在同一网络设备中。
② OpenFlow通过将控制平面（网络决策）从数据平面（数据转发）分离出来，使得网络决策可以从一个集中的地方进行，即SDN控制器。这使网络更灵活，可以从中心点动态调整网络流量。
适应性强：OpenFlow使网络控制器能够根据业务需求的变化动态地调整网络配置。例如，根据数据流量的增减、应用优先级的变化或安全需求的更新，控制器可以实时更新转发规则。硬件和软件的分离：通过使用OpenFlow，网络的硬件设备（如交换机和路由器）仅仅作为转发数据的平台，而所有的控制逻辑都由软件（SDN控制器）处理。这不仅减少了对昂贵专用硬件的依赖，还增强了网络管理的灵活性和创新能力。物理和逻辑配置的分离：OpenFlow允许更高层次的网络设计和配置，逻辑上的网络可以独立于物理网络设计。这意味着可以虚拟化网络，创建多个逻辑网络在同一物理网络基础设施上运行，每个逻辑网络都可以有不同的、定制化的网络行为。！！！【点赞】、【关注】不走丢^_^
！！！【点赞】、【关注】不走丢^_^
