在 SD-WAN 的部署中我们有两种管理模式: Out-of-Band (OOB) 和 In-band。OOB 的模式很直接，就是将 EC 的 MGMT0 接口接入一个 OOB 的网络，例如一个 LTE，类似的解决方案有 opengear 等。
使用这类的方案将会增加成本，比较推荐的是进行 In-band 的管理。进行 In-band 管理又需要讨论两个问题：
- 管理数据使用 underlay 还是 overlay
- 用什么接口进行管理 （在 In-band 的情况下 MGMT0 已经不再连接在网络里了）
对于第一个问题，推荐将管理数据放入 overlay 中，其优点是在有多个 underlay （例如 Internet + MPLS + LTE) 的 SD-WAN 中只要有任何一个 underlay 可达那么我们的 overlay 就是处于 up 的状态，我们不会失去管理连接。反之如果使用某一个特定的 underlay 对设备进行管理就会造成一个 single point of failure。这里出现一个悖论，把管理数据放入 overlay 的前提是要对 EC 进行管理配置，然而我们说最好把管理数据放入 overlay （先有鸡还是先有蛋的问题）。其实这不是一个问题，因为在初始化配置的时候我们要么会暂时性的使用 MGMT0 或者让 EC 的一个 WAN 接口接入互联网并和 Cloud Portal 建立连接，Orchestrator 将 Cloud Portal 作为 proxy 来管理 EC。当初始化配置完后，即 overlay 建立后这个问题自然就不存在了。
第二个问题在没有 loopback 功能之前对于 Silver Peak 来说是比较头痛的，因为产品的设计太过灵活使得 EC 会尝试用不同的接口去和 Orchestrator 建立连接，这反而在某些情况下造成了不确定性。使用 loopback 接口作为管理接口无论何时 EC 对外发出的管理数据包源 IP 都是这个 loopback 接口的地址。
我们使用下面的拓扑来看一下应该怎么设计和配置：
从设计上来讲 Orch 放在 DC 里面，但并不和 ECV-DC-1 直连，只是三层可达。每一个 EC 都没有将 MGMT0 接入网络。
配置的第一步是创建一个 Label 给 loopback 接口使用，系统将会把 loopback 当作一个 LAN 接口看待，所以我们的 Label Type 也要是 LAN，名称无所谓。
然后我们使用 Loopback Orchestration 功能创建一个地址池，系统会根据这个地址池自动的给 EC 的 loopback 接口分配一个 /32 的 IP 地址 （一定要勾选 Management 选项）。
在这里我创建的地址池是 10.0.0.0/24。接着系统会给所有的 EC 自动分配地址，我们可以进入 Loopback Interface 选项进行查看：
最后一步，断开 MGMT0 的连接，这非常非常重要，只有 MGMT0 处于 down 的状态 EC 才会将管理数据切换到 loopback 接口上。在 Orch 上 EC 会显示失去连接，几分钟后 EC 会重新上线并且可以直接在导航菜单里看到它们的 loopback IP：
我们查看一下 Flow 可以看到所有去往 Orch 的数据包都使用了 loopback 接口 IP 地址：
并且这些地址会自动的被宣告进入 SD-WAN 的路由表：
