Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
在此页面上
 

已知限制

了解 ACX 系列路由器的 Junos OS Evolved 版本 22.2R1 中的已知限制。

有关已知 Junos OS Evolved 缺陷的最完整和最新信息,请使用瞻博网络在线 Junos 问题报告搜索 应用程序。

通用路由

  • 在某些角落情况下,严格优先级队列之间的流量安排不相同。这种情况可能在以下情景下发生。配置的优先级队列,并正在充分利用带宽,其余队列不足,这些队列上的流量完全丢弃。在此状态中,如果我们配置第二个严格高优先级队列流量在严格优先级队列之间未进行同等安排。这是硬件特定问题,ACX7509 特定。如果我们在优先级队列上有整形程序,此问题将不会发生。此外,如果信息流在配置后启动,则不会出现任何问题。 PR1577035

  • PTP 到 PTP 的噪音传输因频率 1 而失败。0.03125 HZ 2.0.123125 HZ。 PR1608786

  • 在 ACX7100-48L 设备上,同步到 PTP 并同步到 1pps 的噪音传输测试失败,频率 1。0.00781 HZ 2.0.01563 HZ 3。0.03125 HZ 4。0.06156 HZ 5.0.12313 HZ。 PR1608866

  • 与 PTP 的同步和与 1pps 瞬时响应的同步略有失败。当 servo 在一个测量窗口中启动初始 100 纳米秒时,下一个测量窗口中的下一个 100 纳米秒调整较少时,就会发生这种情况。 PR1608934

  • 在 ACX7100-48L 上,启用或禁用 PTP TC 或 BC 会导致所有接口同时翻动。 PR1609927

  • 对于频率 0.03125 HZ,PTP 到 PTP 的噪音传输失败。 PR1611838

  • 在 ACX7100-32C 设备上,与 PTP 的同步和与 1pps 同步的噪音传输测试失败 1.0.00781 HZ 2.0.01563 HZ 3。0.03125 HZ 4。0.06156 HZ 5.0.12313 HZ 频率。 PR1611911

  • clear mpls lsp 操作是一种破坏性操作,它将擦除系统中的所有现有路由和下一跃点并重新安装,16000 l3vpn 路由的流量恢复延迟为 10 秒,可能归因于硬件单元中的编程延迟,以及软件模型和 CPU 容量的组合。 PR1614413

  • 当将主机路由/128 路由下载到 ACX7100 或 ACX7509 中的 LEM 表中时,ACX7509 的学习速率与 ACX7100 相同。只有当规模超过 LEM 表大小时,PR 才报告问题。如果规模在 LEM 表大小内,则 ACX7100 和 ACX7509 中的 FIB 下载速率保持不变。 PR1624365

  • G.8275.1- G.8273.2 1PPS cTE 性能测试在 ACX7100-32C 上为 PTP BC 使用通道化 10G 端口时,可能属于 C 类之外。在每次重新启动时,1PPS cTE 测量值可能都在 C 类测量阈值内,或者随机退出几纳秒。 PR1629819

  • G.8275.1- G.8273.2 1PPS cTE 性能测试在 ACX7100-32C 上使用带 PTP BC PTP BC 100G 端口的通道化 25G 端口时,可能属于 C 类之外。在每次重新启动时,1PPS cTE 测量值可能都在 C 类测量阈值内,或者随机退出几纳秒。 PR1637268

  • Ping 和 Traceroute 将回复模式用作 ip-udp(适用于其他 Junos OS Evolved ACX 系列)。当我们通过 VCCV 支持 BFD 时,其他回复模式(应用程序级别控制通道)工作。对于 ping,MSPW Echo 回复的默认模式是应用程序级别控制通道。因此,MSPW L2VPN ping 需要回复模式作为 ip-udp,以便 ping 工作,因为尚未支持基于 VCCV 的 BFD。对于 traceroute,默认模式是应用程序级别控制通道。因此,MSPW L2VPN traceroute 需要将回复模式作为用于追踪路由工作的 ip-udp,因为不支持基于 VCCV 的 BFD。 PR1642026

  • 如果由于主要的 FEB 电源故障而发生切换,链路可能会短暂翻动(在几毫秒内)。解决方法是在远端路由器上配置接口保持定时器。 PR1652921

  • 1. 为什么除 6VPE 以外的所有案例(L3VPN、IPv4)的 SIP 和 DIP 增量案例都有效?此外,当我们增加 SMAC 和 DMAC 时,所有 CCC 和桥接系列都能正常工作。对于 Ipv4 相关服务,在散列期间配置 BCM 管道时,我们会设置一个称为BRCM_HASH_FIELD_IPV4_ADDRESS的字段。因此,当源 IP 和目标 IP 均存在对称性增加时,此标志会注意负载平衡。对于 IPV6 服务,不支持 BCM 文档中指定的此字段。因此,在 SIP 和 DIP 的对称性增加时,负载平衡是行不通的。2. 为什么选择 6VPE,它不能实现负载平衡?BCM 推理。不是说 6VPE 服务不是负载平衡按照下方输出中指定的完全负载平衡。xmen-s-p1b-d 秒数:6 时间:07:41:10 接口链路输入数据包 (pps) 输出数据包 (pps) ae0 Up 4798 (0) 4153317 (996) esi 上升 0 (0) 0 (0) et-0/0/0 上升 0 (0) 0 (0) et-0/0/1 上升 2238 (0) 1983350 (0) 797) <<==(负载平衡)et-0/0/2 上 2560 (0) 2169967 (199) <<-(负载平衡)et-0/0/3 向上 0 (0) 0 (0) et-0/0/4 Up 0 (0) 0 (0) et-0/0/5 上4286778 (997) 8430 (8)只是对于两者都在递增的特定情况下,由于回应中提供的原因,功能无法正常工作 1。因此,我们不能说该功能不起作用。3. 在软件设置的 6PE 案例中。观察到在 6PE 情况下不工作负载平衡的相同行为。 PR1658411

  • Junos OS Evolved 遵循“先成后断”(MBB) 机制来编程下一跳跃和路由以实现更快的融合。该机制在删除旧转发表条目之前安装新转发表条目,从而最大限度地减少路由融合期间的流量丢失。但是,它会根据短时间内下一跳/路由更改次数,临时增加在数据包转发引擎中编程的转发路径数量。MBB 在链路翻动、平滑重新启动 (ldp)、会话翻动(ldp) 等期间应用。对于在隧道扩展限制的较高端运行网络设备的部署,链路翻动可轻松超过设备的规模。一旦数据包转发引擎超过其转发表容量,隧道添加的任何新跳就会被忽略,从而导致这些 NHS 的流量黑洞。但是链路翻动只会触发与该特定链路关联的隧道的 MBB。如果我们采取最坏的情况是,所有链路一次性翻动,所有隧道因此都进行 MBB,我们必须将隧道限制保持在一半,绝对确保不会超过限制。 PR1660472

路由协议

  • 在具有 BGP 对等方的非转发路由实例的路由器上启用 NSR 时,该实例中的 BGP 对等方将不会成功复制到备份 RPD。 PR1648707