Cisco HyperFlex 多区域上联（Disjoint Networks Upstream）
Deploy Layer 2 Disjoint Networks Upstream in End Host Mode for HyperFlex
一般意义上的HX平台是部署在大二层环境中，不同vlan跑不同的功能（data，mgt，vmotion，storage），但都在一个大二层，
由于用户这里网络结构不是这样，该网络结构是将多个区域用防火墙严格隔离，割裂开，但却不能每个区域部署一套FI，要求FI上联多个区域，如果是fi+刀片在自定义模板的情况下相对好解决，但HX平台自动化程度比较高，认为修改容易造成各种错误和遗漏，
在实验中出现过如下问题：
1，vnic的vlan和上联vlan不一致，导致vnic是down，
2，添加vinc后，多个vswitch网络不稳定，有的通，有点一个up一个down，有的是down down，影响业务都没啥，存储down了（可能跟vnic重新排序或其他原因有关，未能重现故障）
3，在匹配给rack的profile中删除特定vnic 导致所有vnic被删除 甚至包括root下母模板中的computer模板也没了，所有的都删除了，很奇怪只是删除一个在用机架节点模板的vnic，导致母版中计算节点的模板也删除了
4，vnic始终乱序，奇怪的是intaller生成的vnic，一般都能正确判断上联，虽然vmware重新排序了（也有出错的时候），但自己添加的多区域上联，每次都是vmware排序，直接就是错误上联（这里猜测一下：是因为后面的mac-pool是自己添加的，而不是采用install自动生成的mac，取mac的时候，FI按照自己算法一上一下去取，然后vmware又重新排列，因为mac大小缘故（参照macpool的定义对比），每次添加vnic都不一样的排序，）

有为法皆是无常的，无常的皆是不真实的，认识和知识只是在一定的地域范围和时间范围对某些事物是有效的或者是勉强正确，而不是永远正确，都是会变化的，很多厂商和设备在功能上有自己的特殊地方，例如山石防火墙可以更改二层vlan tag等等，但特殊的用法用多了对后面的事务，包括扩展，合并，更新，添加，其他需求会造成一定影响，也许因为大二层的产品设计假设，导致HX平台不像dell机架服务器那样，灵活的变更多区域上联端口。

所以个人觉得适合自己的解决方案是最好，在适合自己的解决方案中选择最靠近最佳实践的，这样才能取得最大化收益。最高境界应该是优秀顶层设计下解决方案，而不是在技术上的过度复杂。

在installer上面 添加vlan

vlan却被添加到vm-network上面，这是因为自动化脚本根本不会判断多上联，要自己在此交换机上删除这些vlan，以后吧portgroup添加到正确的交换机上面去

FI上面vlan因为执行installer的缘故，已经加好了，你的一切操作尽量靠install这些自动化脚本 合规执行 不要手动配置，一方面是有可能改不了，另一方面是改变关联多个地方，可能自己不知道

添加mac-pool 之所以用单独的mac-pool是因为好识别，而且这样修正以后vnic在vmware中的顺序变更了，导致网络根本不同，我需要根据mac识别vnic重新调整vswitch的uplink

添加vnic-temp 注意我的路径LAN/POLICY/ROOT/SUB-ORAGANIZATIONS/LZTLJ/VNIC 是在root下的组里而不是直接在root下

继续看路径，在root下的lztlj组里的lan connectivity policies添加vnic 因为新增三个上联区域所以添加6块vnic，uplink的vlan和vnic中vlan以及uplinmanager中的vlan 都要一致，否则会down down 后面补图两张

添加完成后会告警要求重启（模板加减vnic会导致重启），重启后模板里面查看已经添加成功

VMware中vnic的顺序已经变更，可能导致部分网络不通，甚至是最重要的网络，可能需要你手动调整，


最后添加新增三个上联区域的vswitch 和 vlan portgroup ，我喜欢在esxi中添加 因为可以自定义交换机名字

手动调整工作量确实比自动大多了 主要是容易添错