这很容易变成一场辩论，当然你可以在不同的逻辑系统中进行管理，但是感知到的收益是什么？您仍然需要同样保护主实例。
在我看来，除了增加复杂性之外，您一无所获，这意味着增加了停机风险。

在带有 CMP 的 SUP2T 或 Nexus7k 上情况会有所不同，在那里您确实可以使用单独的带外接口。

我的建议是优化最低复杂度，通过正常的主实例进行带内 ssh 管理，并使用 RS232（唉，必要的邪恶）作为带外备份。

走这条路就行了，会有一些复制软件的不便，不过你可以应付，用'set cli logical-system MGMT'

您需要两种解决方案，一种用于正常的日常工作，另一种用于 OOB，当系统或网络损坏时。OOB 很容易，您需要 RS232，因为 RS232 是您可以使用的唯一解决方案，当 junos 未运行或无响应时尝试重新启动机器（设置系统调试器中断）。
对于你的主要日常工作，更有争议的是，你有三个选择：

1. 使用带上（与生产 INET 相同的路线）
2. 使用路由实例（您将获得路由分离，但使用相同的 RPD 副本，但我猜您使用的是 FXP0，此处不支持）
3. 使用逻辑系统，另一个 RPD 副本只为 MGMT 运行

你提到需要有对称路由。我由此假设，您想将 FXP0 用于 MGMT，并且您有另一条返回流量的竞争路线，这是您需要的，因为 NMS 服务器网络用于其他用途，而不仅仅是 NMS，这有点令人担忧。
在我看来，根本不需要 FXP0，因为它不是 OOB（如 CMP），您甚至无法通过 FW 过滤器保护 FXP0 端口，因为它不是硬件接口。

但是，如果我们假设您想继续使用 FXP0，那么您确实几乎必须将它放在逻辑系统中，即使您没有 NMS 的竞争路线，您仍然需要将 FXP0 放在逻辑系统中，否则，您的 NMS 网络会受到来自带内的攻击，而您无法保护这些攻击，因为您无法在 FXP0 接口中放置 HW FW 过滤器。