題記：SDWAN提供了很多的工具，用不用的好卻是一門藝術下面是一個真實案例來給大家介紹一下思科意圖網絡如何將意圖擴展到多域環境,實現SDA、SDWAN和ACI以及雲網絡的基於意圖的多域融合SDWAN的策略一直是非常難的一個話題，最近解一個客戶的bug藉助以前關於意圖網絡聲明式策略框架《
意圖網絡的語言學思考》的研究，把這事想明白了，順便通過這個案例來給大家做一個SDWAN策略的串燒~一個案例基本上把很多的策略都用全了。
網絡是由多個域組建而成的，數據中心有BGP-EVPN或者ACI的解決方案，甚至是在雲端，我們的策略是以應用為中心。而在園區網的策略通常是UCI，即以用戶為中心的策略。對於SDWAN的策略，就成了下面這樣...但是我們仔細看看用戶對於策略的意圖，實際上是很簡單的，本質上和安全相關的是一些訪問控制的策略。
但是另一方面流量調度策略需要多個Segment，如下圖所示：
但是像下面這種解決方案，您用起來肯定心驚膽戰吧：）
所以說，我一直都在針對報文如何標記做闡述，一定要把多租戶、安全、流量工程這三個標籤分離才行。但是現階段很多SDWAN僅支持一層標籤，怎麼辦呢？那麼就把三個東西映射在一個標籤上，然後在不同的策略點實施策略就好：）我們來看一個需求，很多企業有業務出海多雲連接的需求，通常會安裝如下拓撲構建SDWAN網絡。
業務需求也非常明確，國內的Internet線路用於和國內的PoP點傳輸公有雲的業務，例如Office365.而原有的MPLS網絡由於等保合規等要求，承載私網業務，並且要隔離。當然同時還伴生著某些用戶能夠訪問應用，某些不能訪問的需求。
我們利用一個特殊的VPN-ID來代表用戶和應用之間的Contract，然後針對這個VPN做路由洩露，將UserVPN和應用Vxlan中的路由洩露進這個VPN，自然就把它們連通了，這樣相對於ACL訪問控制的方案更加直觀，能訪問就有路由。另一方面，我們針對這個VPN做基於VPN的流量工程或者FEC、QoS，或者Service-Chaining到firewall，這樣就完成了整個基於意圖的策略控制。那麼接下來咱們進入實戰環節，用戶側路由器為ZartbotLTE和ISR-Home，中間的PoP點為Cedge-MPLS-PE，應用側為兩臺C8KV_DMZ_1/2
首先，我們定義一些以後要用到的list，如前文所述，我們需要定義一些站點組
site-list O365Service site-id 101site-list UserSite site-id 201 site-id 202 tloc-list O365_ServicePoP tloc 102.0.0.1 color biz-internet encap ipsec然後我們定義承載Office365的應用VPN列表，您可以認為這是應用端的EPG對應的，可以根據Application組來劃分。
vpn-list Office365 vpn 365以及用戶側可以訪問O365資源的VPN列表，例如對應SDA中的SGT
vpn-list O365_ALLOWED_VPN_LIST vpn 200 vpn 201app-list Office365app excel_onlineapp grooveapp hockeyappapp live_groupsapp live_hotmailapp live_meshapp livemail_mobileapp lyncapp lync_onlineapp microsoftapp ms-live-accountsapp ms-lyncapp ms-lync-audioapp ms-lync-controlapp ms-lync-videoapp ms-office-365app ms-office-web-appsapp ms-servicesapp ms-teamsapp ms-teams-audioapp ms-teams-mediaapp ms-teams-videoapp ms-updateapp ms_communicatorapp ms_onenoteapp ms_plannerapp ms_swayapp ms_translatorapp office365app office_docsapp onedriveapp outlookapp outlook-web-serviceapp owaapp powerpoint_onlineapp share-pointapp sharepointapp sharepoint_adminapp sharepoint_blogapp sharepoint_calendarapp sharepoint_documentapp sharepoint_onlineapp skydriveapp skydrive_loginapp skypeapp windows_marketplaceapp windowsliveapp word_onlineapp yammer然後我們在應用側節點，也就是Site101中添加兩個控制策略：apply-policy site-list O365Service control-policy O365_To_USER_IN in control-policy O365_TO_USER_OUT outin代表的是路由進入到vsmart控制器的時候需要做的策略，也就是說，當應用側需要往控制器發布路由的時候，我們期望它將路由信息通告到能夠訪問的業務側VPN中： control-policy O365_To_USER_IN sequence 10 match route vpn 365 action accept export-to vpn-list O365_ALLOWED_VPN_LIST default-action acceptout代表的是控制器公告路由給其它節點，我們定義了這些需要訪問O365業務的Site-list中節點看到的路由下一跳資源都會被指向O365_ServicePoP的TLOC中，由此可以約束流量僅走Internet的color
control-policy O365_TO_USER_OUT sequence 10 match route site-list UserSite vpn 365 action accept set tloc-list O365_ServicePoP default-action accept針對用戶側節點的策略有2個，但有一個是Datapolicy
site-list UserSite control-policy USER_TO_O365_IN in control-policy USER_TO_O365_OUT out data-policy O365_Optimize from-service用戶側通告給控制器的路由策略如下, 將自己的客戶端相應VPN並且走Internet的路由通告給控制器時導出到Contract定義的VPN365中，這樣就實現了應用側和用戶側通過VPN365互通。
control-policy USER_TO_O365_IN sequence 10 match route color public-internet vpn-list O365_ALLOWED_VPN_LIST action accept export-to vpn 365 default-action accept最後定義流量如何進入這個Contract就是用了DataPolicy，匹配應用，導入流量到VPN365.當然我們還做了一些針對DNS的特殊的處理，例如Office365的DNS全部走內網的伺服器，而網際網路應用的其它DNS則本地BreakOut出去，這樣的做法可以防止一些隱私的洩露。最後很簡單的將匹配到的Office365流量列表(app-list）設置下一跳TLOC資源和VPN到365 就搞定了。data-policy O365_Optimize vpn-list O365_ALLOWED_VPN_LIST sequence 5 match dns-app-list Office365 action accept count o365dns sequence 6 match dns request action accept count normal nat use-vpn 0 redirect-dns 192.168.1.1 sequence 10 match app-list Office365 action accept count o365_opt set vpn 365 tloc-list O365_ServicePoP default-action accept 最後當然是驗證策略呢~這麼多跳，都還加密的驗證起來不費力麼？而且哪個策略管用哪個不管用你看的清麼？思科中國研發中心的一群大神同事們做了一個非常牛逼的軟體功能，在控制器上可以輕鬆實現多跳關聯和轉發日誌解析，在vManage中點「Monitor-》Network Wide Path Insight」，選擇你所在的SiteID和VPN點擊Start就好
然後下面的Flow列表中過濾搜索你感興趣的應用，就能看到轉發的詳情了：