Tweet
MÔ HÌNH HUB AND SPOKE VỚI CÁC SITE SPOKE BỊ GIỚI HẠN
Giới thiệu
Giải pháp Cisco SD-WAN mặc định xây dựng một mô hình full-mesh giữa các thiết bị vEdge khi không có triển khai các chính sách điều khiển Control Policies. Điều này có nghĩa là vEdges cố gắng xây dựng một IPSec/GRE tunnel đến mọi TLOC public IP addresses có thể truy cập được bất kể TLOC thuộc về site hoặc color nào (transport network). Chúng ta đã thay đổi hành vị mặc định bằng cách sử dụng tùy chọn restrict (Chương 2) bên dưới tunnel interfaces. Bằng cách này, các tunnels chỉ thiết lập giữa các TLOCs có cùng color. Ở chương này, chúng ta sẽ tạo mô hình Hub và Spoke bằng cách triển khai Control Policy nơi mà vSmart quảng bá TLOC/OMP routes giữa site 10 và 20. Site 10 và 20 là Branch/Remote sites và site 30 sẽ là Hub/DataCenter site.
Hình bên dưới tóm tắt lại hoạt động của Overlay Management Protocol (OMP). vEdge1 trong site 10 quảng bá TLOC route advertisement đến vSmart nơi nó mô tả System ID, thuộc tính transport color, và phương pháp đóng gói cũng như Public/Private IP và các thuộc tính khác của nó. vSmart sẽ chuyển các TLOC routes vừa nhận được từ vEdge1 đến cả hai vEdge2 (site 20) và vEdge3 (site 30). vEdge1 cũng quảng bá các OMP routes trong đó nó mô tả thông tin về khả năng truy cập đến local subnet 172.16.10.0/24 của chính nó được liên kết với VPN10.
Hình: Cách thức quảng bá TLOC Route
Khi vEdge2 và vEdge3 nhận TLOC route advertisement, chúng sẽ thiết lập GRE tunnels giữa các TLOC cùng màu (restrict option) bằng cách sử dụng địa chỉ IP Public làm địa chỉ đích tunnel destination. Chúng cũng sẽ khởi động các phiên BFD trên tunnel để giám sát tình trạng đường truyền. Khi các tunnel là đạt trạng thái up, các vEdges đang chạy sẽ gửi dữ liệu bằng cách sử dụng địa chỉ IP Public là địa chỉ đích trong tunnel header. Hình bên dưới minh họa cách vEdges thiết lập các các đường hầm có cùng nhãn màu với nhau. vEdge1 đã có 1 mpls-to-pmls tunnel với cả hai vEdge2 và vEdge3 cũng như internet-to-internet tunnel giữa các vEdges. vEdge2 và vEdge3 cũng có tunnel với nhau.
Hình 5-2: Full Mesh Tunnels Between vEdges.
Hình 5-3 hiển thị các TLOC routes nhận được bởi vEdge1. Bạn có thể xác minh thông tin real-time của vEdge1 bằng cách chọn nó từ danh sách thiết bị trong cửa sổ Monitor Network trên vManage GUI. Chọn OMP Received TLOCs từ Device Option field trong order để xem các TLOC routes đã nhận được. Như ví dụ, chúng ta có thể thấy rằng vEdge1 đã nhận được 2 TLOC routes từ vSmart (10.100.100.13) có nguồn gốc từ vEdge2 10.100.100.102.
Hình 5-3: Received TLOCs from vEdge1 Perspective.
Hình 5-4 xác minh vEdge cũng có BFD sessions giữa vEdge2 và vEdge3 trên cả hai transport networks.
Hình 5-4: BFD sessions of vEdge1.
Hình 5-5 hiển thị rằng vEdge1 đã nhận được OMP routes cụ thể của VPN10 từ cả hai sites trên cả hai mạng transport.
Hình 5-5: received OMP routes from vEdge1 Perspective.
Chúng ta có thể thấy rằng vEdge1 đã installed OMP routes cụ thể của VPN 10 vào trong VPN 10 FIB (Forwarding Information Base).
Hình 5-6: VPN10 related IP Routes from vEdge1 Perspective.
Ví dụ bên dưới xác minh rằng chúng ta có kết nối IP từ host 172.16.10.10 (site 10) đến host 172.16.30.30 (site 30) và đến host 172.16.20.20 (site 20).
Ví dụ 5-1: Connectivity Verification.
vSmart – from CLI Mode to vManaged mode.
Chế độ quản trị mặc định của vSmart là CLI. Chúng ta không thể sử dụng NETCONF để đẩy các chính sách trên vManage đến vSmart trừ khi chúng ta thay đổi chế độ này thành chế độ vManage. Hình 5-7 hiển thị thông báo lỗi khi có gắng activate Centralized Policy trong khi vSmart trong chế độ CLI.
Hình 5-7: Failure Notification.
Chúng ta có thể xác minh chế độ quản trị từ vSmart CLI hoặc bằng cách điều hướng đến configuration/devices và chọn tab Controllers từ vManage GUI. Ví dụ 5-2 hiển thị trạng thái vManaged là false và Configuration Template được set là None.
Ví dụ 5-2: Verifying Manage Mode Used in vSmart by Using the Device CLI.
Hình 5-8 hiển thị rằng chế độ vSmart là CLI và ở đây không có template nào được assigned.
Tạo các CLI
Để thay đổi chế độ CLI thành chế độ vManaged, hãy điều hướng đến cửa sổ configuration/templates trên vManage GUI. Sau đó chọn tab Device và từ đó chọn CLI Template từ Create Template drop-down menu.
Hình 5-9: Changing vSmart to the vManaged Mode – Step#1.
Sau đó chọn vSmart từ Device Model drop-down menu và điền Template Name và Description fields. Bạn có thể copy cấu hình vSmart từ vSmart CLI hoặc chọn vSmart từ Load Running config from the reachable device drop-down menu. Click nút Add khi hoàn thành xong.
Hình 5-10: Changing vSmart to the vManaged Mode Step#2.
Attach CLI Template to vSmart
Attach CLI template cho vSmart bằng cách chọn Attach Device từ tùy chọn template menu […].
Hình 5-11: Changing vSmart to the vManaged Mode – Step#3.
Chọn vSmart từ cột Available Devices và nhấn nút Arrow để chuyển nó đến cột Selected Devices. Sau đó nhấn nút Attach.
Hình 5-12: Changing vSmart to the vManaged Mode – Step#4.
Bước cuối cùng, chọn nút Configure Devices.
Hình 5-13: Changing vSmart to the vManaged Mode – Step#5.
Hình 5-14 hiển thị việc cài đặt template đã hoàn thành.
Hình 5-14: Changing vSmart to the vManaged Mode – Verification: Success.
Failure hiển thị ở hình 5-15 có thể xảy ra nếu bạn thêm cấu hình CLI template thủ công.
Hình 5-15: Changing vSmart to the vManaged Mode – Verification: Failure.
Chúng ta có thể xác minh việc thay đổi từ CLI (Ví dụ: 5-3) hoặc từ vManage GUI (hình 5-16).
Ví dụ 5-3: Verifying Manage Mode Used in vSmart by Using the vSmart CLI.
Policy Configuration
Hình 5-17 minh họa SD-WAN Policy model. Nó có 2 loại policy chính, a) Localized Policies, và b) Centralized Policies. Ở chương này chúng ta sẽ tập trung vào Centralized Policies. Centralized Policies có 2 loại nhỏ, a) Data Policies và Control/Topology policies. Mục đích chính của chúng ta là hạn chế lưu lượng giữa site 10 và site 20 vì vậy chúng ta sẽ xây dựng 1 Centralized Policy trong đó chúng ta sử dụng Control Policy để xây dựng 1 mô hình hub và Spoke nơi mà site 10 và 20 bị hạn chế lẫn nhau bằng cách kiểm soát các TLOC/OMP route advertisements.
Hình 5-17: SD-WAN Policy Model.
Hình 5-18 minh họa các hướng quảng bá TLOC/OMP route. vSmart sẽ quảng bá TLOC/OMP routes đã nhận được tự Branch Sites (site 10 và site 20) đến DataCenter (site 30). Ngoài ra, vSmart cũng quảng bá các TLOC/OMP routes từ DataCenter đến Branch Sites. Tuy nhiên, vSmart sẽ không quảng bá TLOC/OMP routes đã nhận được từ site chi nhánh này đến site chi nhánh kia. Bằng cách này chúng ta tạo mô hình Hub và Spoke nơi mà các Branch Sites restricted từ site kia và giữa chúng sẽ không thể gửi data. Toàn bộ chính sách về định tuyến chỉ dựa trên routing control và chúng ta không sử dụng bất kỳ bộ lọc data traffic nào.
Hình 5-18: TLOC/OMP Routes Advertisement Direction.
Ví dụ 5-4 hiển thị cấu hình mà chúng ta xây dựng bằng cách sử dụng vManage GUI. Nó cũng cho thấy cấu trúc và cấu hình flow của Centralized Policy. Lưu ý rằng Centralized Policy không có bất kỳ tên nào, chúng ta chỉ có thể sử dụng 1 Central Policy. Trong bước đầu tiên, chúng ta tạo ra 1 tổ hợp danh sách trong đó chúng ta định nghĩa Group of Interest. Một danh sách bao gồm application, color, data prefix, policer, prefix, site, SLA class, TLOC, hoặc VPN. Chúng ta sẽ sử dụng 2 site lists và 1 prefix list. 1 site list cho DataCenter (site 30) và 1 cái kia cho Remote-sites (site 10 và site 20). The prefix list matches với tất cả các networks. Trong bước thứ 2, Chúng ta tạo ra 1 Control Policy có tổ hợp của sequences nơi mà chúng ta muốn match TLOCs và OMP routes từ site 30 đã được listed bên dưới site list DataCenter và nơi mà chúng ta muốn set hành động Accept. Ở phần cuối của Control Policy, chúng ta có 1 dòng reject ngầm. Bước cuối cùng, chúng ta áp dụng Control Policy đến sites listed trong site-list Remote-sites như là outbound policy. Bằng cách làm này, chúng ta cho phép vSmart gửi TLOC và OMP routes gốc từ DataCenter đến Remote-sites mà không phải TLOC và OMP routes từ site 10 đến site 20 và những cách khác. Ở đây không có policy nào được áp dụng cho site 30, vì vậy vSmart sẽ chuyển tiếp tất cả các TLOC và OMP routes đến site 30.
Policy # Centrlazied Policy
Lists # Group of Interest
site-list DataCenter
site-id 30
!
site-list Remote-Sites
site-id 10
site-id 20
!
prefix-list _AnyIpv4PrefixList
ip-prefix 0.0.0.0/0 le 32
!
!
control-policy HUB_AND_SPOKE_POLICY # Control Policy
sequence 1
match tloc
site-list DataCenter
!
action accept
!
!
sequence 11
match route
prefix-list _AnyIpv4PrefixList
site-list DataCenter
!
action accept
!
!
default-action reject
!
!
apply-policy # Apply Policy
site-list Remote-Sites
control-policy HUB_AND_SPOKE_POLICY out
Ví dụ 5-4: Verifying Manage Mode Used in vSmart by Using the vSmart CLI.
Giới thiệu
Giải pháp Cisco SD-WAN mặc định xây dựng một mô hình full-mesh giữa các thiết bị vEdge khi không có triển khai các chính sách điều khiển Control Policies. Điều này có nghĩa là vEdges cố gắng xây dựng một IPSec/GRE tunnel đến mọi TLOC public IP addresses có thể truy cập được bất kể TLOC thuộc về site hoặc color nào (transport network). Chúng ta đã thay đổi hành vị mặc định bằng cách sử dụng tùy chọn restrict (Chương 2) bên dưới tunnel interfaces. Bằng cách này, các tunnels chỉ thiết lập giữa các TLOCs có cùng color. Ở chương này, chúng ta sẽ tạo mô hình Hub và Spoke bằng cách triển khai Control Policy nơi mà vSmart quảng bá TLOC/OMP routes giữa site 10 và 20. Site 10 và 20 là Branch/Remote sites và site 30 sẽ là Hub/DataCenter site.
Hình bên dưới tóm tắt lại hoạt động của Overlay Management Protocol (OMP). vEdge1 trong site 10 quảng bá TLOC route advertisement đến vSmart nơi nó mô tả System ID, thuộc tính transport color, và phương pháp đóng gói cũng như Public/Private IP và các thuộc tính khác của nó. vSmart sẽ chuyển các TLOC routes vừa nhận được từ vEdge1 đến cả hai vEdge2 (site 20) và vEdge3 (site 30). vEdge1 cũng quảng bá các OMP routes trong đó nó mô tả thông tin về khả năng truy cập đến local subnet 172.16.10.0/24 của chính nó được liên kết với VPN10.
Hình: Cách thức quảng bá TLOC Route
Khi vEdge2 và vEdge3 nhận TLOC route advertisement, chúng sẽ thiết lập GRE tunnels giữa các TLOC cùng màu (restrict option) bằng cách sử dụng địa chỉ IP Public làm địa chỉ đích tunnel destination. Chúng cũng sẽ khởi động các phiên BFD trên tunnel để giám sát tình trạng đường truyền. Khi các tunnel là đạt trạng thái up, các vEdges đang chạy sẽ gửi dữ liệu bằng cách sử dụng địa chỉ IP Public là địa chỉ đích trong tunnel header. Hình bên dưới minh họa cách vEdges thiết lập các các đường hầm có cùng nhãn màu với nhau. vEdge1 đã có 1 mpls-to-pmls tunnel với cả hai vEdge2 và vEdge3 cũng như internet-to-internet tunnel giữa các vEdges. vEdge2 và vEdge3 cũng có tunnel với nhau.
Hình 5-2: Full Mesh Tunnels Between vEdges.
Hình 5-3 hiển thị các TLOC routes nhận được bởi vEdge1. Bạn có thể xác minh thông tin real-time của vEdge1 bằng cách chọn nó từ danh sách thiết bị trong cửa sổ Monitor Network trên vManage GUI. Chọn OMP Received TLOCs từ Device Option field trong order để xem các TLOC routes đã nhận được. Như ví dụ, chúng ta có thể thấy rằng vEdge1 đã nhận được 2 TLOC routes từ vSmart (10.100.100.13) có nguồn gốc từ vEdge2 10.100.100.102.
Hình 5-3: Received TLOCs from vEdge1 Perspective.
Hình 5-4 xác minh vEdge cũng có BFD sessions giữa vEdge2 và vEdge3 trên cả hai transport networks.
Hình 5-4: BFD sessions of vEdge1.
Hình 5-5 hiển thị rằng vEdge1 đã nhận được OMP routes cụ thể của VPN10 từ cả hai sites trên cả hai mạng transport.
Hình 5-5: received OMP routes from vEdge1 Perspective.
Chúng ta có thể thấy rằng vEdge1 đã installed OMP routes cụ thể của VPN 10 vào trong VPN 10 FIB (Forwarding Information Base).
Hình 5-6: VPN10 related IP Routes from vEdge1 Perspective.
Ví dụ bên dưới xác minh rằng chúng ta có kết nối IP từ host 172.16.10.10 (site 10) đến host 172.16.30.30 (site 30) và đến host 172.16.20.20 (site 20).
Ví dụ 5-1: Connectivity Verification.
vSmart – from CLI Mode to vManaged mode.
Chế độ quản trị mặc định của vSmart là CLI. Chúng ta không thể sử dụng NETCONF để đẩy các chính sách trên vManage đến vSmart trừ khi chúng ta thay đổi chế độ này thành chế độ vManage. Hình 5-7 hiển thị thông báo lỗi khi có gắng activate Centralized Policy trong khi vSmart trong chế độ CLI.
Hình 5-7: Failure Notification.
Chúng ta có thể xác minh chế độ quản trị từ vSmart CLI hoặc bằng cách điều hướng đến configuration/devices và chọn tab Controllers từ vManage GUI. Ví dụ 5-2 hiển thị trạng thái vManaged là false và Configuration Template được set là None.
Ví dụ 5-2: Verifying Manage Mode Used in vSmart by Using the Device CLI.
Hình 5-8 hiển thị rằng chế độ vSmart là CLI và ở đây không có template nào được assigned.
Tạo các CLI
Để thay đổi chế độ CLI thành chế độ vManaged, hãy điều hướng đến cửa sổ configuration/templates trên vManage GUI. Sau đó chọn tab Device và từ đó chọn CLI Template từ Create Template drop-down menu.
Hình 5-9: Changing vSmart to the vManaged Mode – Step#1.
Sau đó chọn vSmart từ Device Model drop-down menu và điền Template Name và Description fields. Bạn có thể copy cấu hình vSmart từ vSmart CLI hoặc chọn vSmart từ Load Running config from the reachable device drop-down menu. Click nút Add khi hoàn thành xong.
Hình 5-10: Changing vSmart to the vManaged Mode Step#2.
Attach CLI Template to vSmart
Attach CLI template cho vSmart bằng cách chọn Attach Device từ tùy chọn template menu […].
Hình 5-11: Changing vSmart to the vManaged Mode – Step#3.
Chọn vSmart từ cột Available Devices và nhấn nút Arrow để chuyển nó đến cột Selected Devices. Sau đó nhấn nút Attach.
Hình 5-12: Changing vSmart to the vManaged Mode – Step#4.
Bước cuối cùng, chọn nút Configure Devices.
Hình 5-13: Changing vSmart to the vManaged Mode – Step#5.
Hình 5-14 hiển thị việc cài đặt template đã hoàn thành.
Hình 5-14: Changing vSmart to the vManaged Mode – Verification: Success.
Failure hiển thị ở hình 5-15 có thể xảy ra nếu bạn thêm cấu hình CLI template thủ công.
Hình 5-15: Changing vSmart to the vManaged Mode – Verification: Failure.
Chúng ta có thể xác minh việc thay đổi từ CLI (Ví dụ: 5-3) hoặc từ vManage GUI (hình 5-16).
Ví dụ 5-3: Verifying Manage Mode Used in vSmart by Using the vSmart CLI.
Policy Configuration
Hình 5-17 minh họa SD-WAN Policy model. Nó có 2 loại policy chính, a) Localized Policies, và b) Centralized Policies. Ở chương này chúng ta sẽ tập trung vào Centralized Policies. Centralized Policies có 2 loại nhỏ, a) Data Policies và Control/Topology policies. Mục đích chính của chúng ta là hạn chế lưu lượng giữa site 10 và site 20 vì vậy chúng ta sẽ xây dựng 1 Centralized Policy trong đó chúng ta sử dụng Control Policy để xây dựng 1 mô hình hub và Spoke nơi mà site 10 và 20 bị hạn chế lẫn nhau bằng cách kiểm soát các TLOC/OMP route advertisements.
Hình 5-17: SD-WAN Policy Model.
Hình 5-18 minh họa các hướng quảng bá TLOC/OMP route. vSmart sẽ quảng bá TLOC/OMP routes đã nhận được tự Branch Sites (site 10 và site 20) đến DataCenter (site 30). Ngoài ra, vSmart cũng quảng bá các TLOC/OMP routes từ DataCenter đến Branch Sites. Tuy nhiên, vSmart sẽ không quảng bá TLOC/OMP routes đã nhận được từ site chi nhánh này đến site chi nhánh kia. Bằng cách này chúng ta tạo mô hình Hub và Spoke nơi mà các Branch Sites restricted từ site kia và giữa chúng sẽ không thể gửi data. Toàn bộ chính sách về định tuyến chỉ dựa trên routing control và chúng ta không sử dụng bất kỳ bộ lọc data traffic nào.
Hình 5-18: TLOC/OMP Routes Advertisement Direction.
Ví dụ 5-4 hiển thị cấu hình mà chúng ta xây dựng bằng cách sử dụng vManage GUI. Nó cũng cho thấy cấu trúc và cấu hình flow của Centralized Policy. Lưu ý rằng Centralized Policy không có bất kỳ tên nào, chúng ta chỉ có thể sử dụng 1 Central Policy. Trong bước đầu tiên, chúng ta tạo ra 1 tổ hợp danh sách trong đó chúng ta định nghĩa Group of Interest. Một danh sách bao gồm application, color, data prefix, policer, prefix, site, SLA class, TLOC, hoặc VPN. Chúng ta sẽ sử dụng 2 site lists và 1 prefix list. 1 site list cho DataCenter (site 30) và 1 cái kia cho Remote-sites (site 10 và site 20). The prefix list matches với tất cả các networks. Trong bước thứ 2, Chúng ta tạo ra 1 Control Policy có tổ hợp của sequences nơi mà chúng ta muốn match TLOCs và OMP routes từ site 30 đã được listed bên dưới site list DataCenter và nơi mà chúng ta muốn set hành động Accept. Ở phần cuối của Control Policy, chúng ta có 1 dòng reject ngầm. Bước cuối cùng, chúng ta áp dụng Control Policy đến sites listed trong site-list Remote-sites như là outbound policy. Bằng cách làm này, chúng ta cho phép vSmart gửi TLOC và OMP routes gốc từ DataCenter đến Remote-sites mà không phải TLOC và OMP routes từ site 10 đến site 20 và những cách khác. Ở đây không có policy nào được áp dụng cho site 30, vì vậy vSmart sẽ chuyển tiếp tất cả các TLOC và OMP routes đến site 30.
Policy # Centrlazied Policy
Lists # Group of Interest
site-list DataCenter
site-id 30
!
site-list Remote-Sites
site-id 10
site-id 20
!
prefix-list _AnyIpv4PrefixList
ip-prefix 0.0.0.0/0 le 32
!
!
control-policy HUB_AND_SPOKE_POLICY # Control Policy
sequence 1
match tloc
site-list DataCenter
!
action accept
!
!
sequence 11
match route
prefix-list _AnyIpv4PrefixList
site-list DataCenter
!
action accept
!
!
default-action reject
!
!
apply-policy # Apply Policy
site-list Remote-Sites
control-policy HUB_AND_SPOKE_POLICY out
Ví dụ 5-4: Verifying Manage Mode Used in vSmart by Using the vSmart CLI.