Camplus控制器：何时下发？为何重复？
前言
最近一直在看华为的园区网解决方案，看的真是非常抓狂，苦不堪言，原因就是通过以往的知识点无法理解控制器的操作逻辑。有时的操作做了之后，在网络设备上没有任何体现 ，没有任何配置配置下发，但当某一个事件初触发之后又突然下发很多的配置，而且还有一些配置看起来是重复的，不理解为什么要这么操作！不理解为什么要这么设计？后来发现通过开发者的思维方式去理解控制器就会好理解一些，但依然还是很多朦胧感！实在不是我偷懒，华为官方的文档都已经翻烂了，除非能看到开发者写的文档，但是当前网络上不可能找到华为Camplus控制器开发者写的开发文档，哎~！
当然面对客户的需求，然后看着操作文档，还是能把需求能实现的，但是做为一个工程师，逻辑上不能彻底贯通，只知其然，不知其所以然，这种感觉真的是很难受呀！面对这种情况，我只能一遍遍的告诉自己，不要过于追求完美，继续向前即可。下面是最近一两天对比传统配置与控制器下发配置的一些差异，还有一些自我对于华为园区网解决方案的理解。
配置逻辑问题
我的网络知识有一小部分是从学校里面学到的，另外一部分知识是看书学的，还有一部分是看各种培训机构的课程学到的，相当一部分同学的情况跟我差不多。当我接触到控制器时，我发现从这些渠道学到的思维逻辑与控制器的思维逻辑是不一样的！这其中存在着一定的隔阂，我想这是大部分工程师都会面临的问题，除非是华为自己的工程师，可以直接与研发人员进行沟通，才能将自身的思维逻辑与开发者的思维逻辑相互印证。
VXLAN与准入
同时我还发现，华为自己的开发团队，不同的团队对同一个知识点的理解也不是不一样的，那做出来的软件的配置逻辑自然也就不一样，我们来看CX交换机配置接入VXLAN的配置时，如下所示：
bridge-domain 20
vxlan vni 20
evpn
route-distinguisher 20:20
vpn-target 20:20 export-extcommunity
vpn-target 20:20 import-extcommunity
interface GE1/0/1.20 mode l2
encapsulation dot1q vid 20
# 接口上绑定BD，通过BD做为进入VXLAN域的入口
**bridge-domain 20**
我们再来看同样是华为的设备，另一种配置逻辑，这一种是Camplus控制的下发的配置，如下所示：
bridge-domain 11
**# 直接在BD里面绑定VLAN,通过VLAN做为进入VXLN域的入口**
l2 binding vlan 31
vxlan vni 16
evpn binding vpn-instance evpn_11
interface GigabitEthernet0/0/2
port link-type access
port default vlan 31
大家可能会说，这意思看着差不多呀，也没有什么难以理解的呀！但据我来看，不要看这么一点点的差距，如果再引入第三方的东西，比如准入，我们把准入认证引入到VXLAN当中，如果你从一开始就是通过第二种配置逻辑理解的VXLAN，那理解VXLAN+准入认证也会非常的容易，因为假如一个接口是动态VLAN，VLAN不固定，那认证服务器一旦给此接口分配VLAN之后，此VLAN就是进入VXLAN域的关键“钥匙”，这个理解是非常顺畅的；但如果你是通过第一种配置逻辑理解的VXLAN，当它与准入认证结合到一块时，就变得十分让人困惑，要研究很多时间才能反应过来，因为认证服务器通常来说直接给接口推送的是VLAN信息，而非BD信息，那究竟普通的VLAN信息是如何进入VXLAN域的呢？在这个地方就会卡住，你看，虽然这种配置逻辑虽然看着差别不是很大，但是与其它技术结合到一起时，就会发现差之毫厘，失之千里。
BD与EVPN
我们传统的理解的方式是BD当中直接去配置EVPN实例，让EVPN能够获取正常获取到VNI，从而更好的“赋能”VXLAN，如下所示，evpn实例直接嵌入到了BD当中了。
bridge-domain 20
vxlan vni 20
evpn
route-distinguisher 10:1000
vpn-target 10:10
下面是控制器的逻辑，控制器将EVPN实例与BD看作是“等同的”，不再是一种嵌入关系，而是一种绑定关系，也是看差与上述配置逻辑没有什么太大的差别，但是第一次看去就会感觉到很奇怪，怎么EVPN实例自己“独立出来了“？
bridge-domain 35
l2 binding vlan 22
vxlan vni 41
evpn binding vpn-instance evpn_35
evpn vpn-instance evpn_35 bd-mode
route-distinguisher 434:40
vpn-target 0:40 export-extcommunity
vpn-target 0:40 import-extcommunity
OSPF与宣告
我们已经习惯了这种OSPF的配置方式：
# 先配置接口
interface GigabitEthernet0/0/0
ip address 10.0.2.2 255.255.255.0
# 再配置进程
ospf 1
a 0
network 10.0.2.2 0.0.0.0
但是你发现控制器通常不是以network的方式进行宣告的，通常是以import引入的方式进行宣告，如下所示：
ospf 1 router-id 10.2.255.0
import-route direct
area 0.0.0.0
interface GigabitEthernet0/0/0
ip address 10.0.2.2 255.255.255.0
ospf enable 1 area 0.0.0.0
触发：外部网络与业务VN之间
有一些配置在控制器做完之后不会立马下发，比如配置三层独占接口的外部网络时，配置完成之后并不会有任何的配置下发，会在VN实例创建的时候才会下发，也就是说必须满足一定的条件才会触发，为什么呢？其实一旦想明白了之后会发现非常好理解，因为此时外部网络的接口还不知道绑定到哪一个具体的VN上呢！必须等到VN创建完成之后，外部网络所对应的接口才知道要绑定到哪个VN当中，如下所示：
# 这是外部网络
interface Vlanif121
ip binding vpn-instance vnvrf_42c032cc242
ip address 10.2.200.1 255.255.255.252
# 这是VN，VN得先创建出来之后，vlan121才能绑定到此VN当中
ipv4-family vpn-instance vnvrf_42c032cc242
default-route imported
import-route direct
import-route static
maximum load-balancing 8
advertise l2vpn evpn
# 这是内部网络，内部网络就是单独一波配置了，因为VN已经创建好了
# 一旦内部网络创建完成，直接就能绑定到VN当中
interface Vbdif11
ip binding vpn-instance vnvrf_42c032cc242
……
重复：接入管理与有线接入
如上所示，在Fabric网络当中有”接入管理“，我们在接入管理当中可以配置策略联动，要指定接口的认证配置文件，即搞802.1X的认证配置文件或MAC认证配置文件，其实一旦在接口上应用了这些配置文件就意味着此接口就是动态VLAN，VLAN要从认证服务器上获取，而非固定死，这一点很好理解。
但你还会发现，你必须在创建VN的时候指定”有线接口“，在有线接入当中还要选择这些接口并配置成动态VLAN，这很难理解，我前面给接口上设置了802.1x时就隐含了将接口配置为动态VLAN的含义，怎么还要再声明一次？这是怎么回事？岂不是重复了？这个地方怎么理解呢？如下所示：
这个地方也好理解，在这种方案当中通常我们都是需要做业务随行，而业务随行的策略执行点通常都是VXLAN的边缘节点，如下所示：
业务随行的策略执行点是AGG节点，AGG节点也是VXLAN的边缘节点，也就是说业务随行的授权策略只能到达AGG设备，但是现在的问题时，由于我们需要利旧，ACC设备使用的普通交换机，普通交换机不能做VXLAN，否则的话我们直接就把VXLAN的节点直接扩展到ACC设备上了。现在问题是，ACC设备是普通交换机，设备都接在了ACC了， 但VXLAN的边缘节点和业务随行的策略也只下发到AGG，这怎么办呢？所以才有了所谓的”策略联动“，这个策略联动的的工作原理其实就比较简单了，ACC上没有授权策略，那好，那就不再ACC上授权，在ACC上配置一个CAPWAP隧道，直接把物理接口的认证请求直接转发到AGG上不就可以了嘛！所以才有策略联动的配置，即这张图当中的配置，如下所示：
同时,ACC通过CAPWAP把认证请求扔线了AGG，我们也要告知AGG设备需要对哪些接口进行认证，否则ACC把请求直接扔给AGG，AGG也会蒙圈呀，所以我们还要在AGG设备上选择要对ACC的哪些接口发的授权请求进行认证，所以又有了下面这张图的内容，如下所示：
