chungcu.edu.vn

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.

Bước 1: Tạo ra Site-List

Mở vManage GUI và điều hướng đến configurations/policies và chọn tab Centralized Policy. Click nút Add Policy.

Hình 5-19: Thêm vào Centralized Policy.

Chọn Site từ list pane bên trái. Click nút New Site List. Tôi đã có cái tên cho site list đầu tiên là Remote-Sites và đã thêm site 10 và 20 vào list.

Hình 5-20: Adding Site Lists.

Cũng bằng cách này chúng ta đã tạo 1 DataCenter site-list. Hình 5-12 hiển thị 2 sites của chúng ta. Để chuyển tiếp đến phần Configure Topology and VPN Membership section, click nút Next ở dưới (không kiển thị trong hình).

Hình 5-21: Site Lists DataCenter and Remote-Sites.

Ví dụ 5-5 cho thấy cấu hình liên quan đến site lists. Cấu hình sẽ được gửi đến vSmart như là một phần cấu hình chính sách hoàn chỉnh khi chúng ta kích hoạt chính sách là bước cuối cùng. Lưu ý rằng ở đây hệ thống cũng tự động tạo ra prefix-list với prefix 0.0.0.0/0 le 32 bao gồm toàn bộ tất cả các subnets bao gồm 172.16.30.0/24.

policy

lists

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

Ví dụ 5-5: Site List Configuration.

Step-2: Create Control Policy

Mở Add Topology drop-down menu và chọn Custom Control (Route & TLOC) option.

Hình 5-22: configure Centralized Policy Step 1: Control Policy TLOC.

Đặt cho nó cái tên và description và chọn nút Sequence Type. Điều này có thể tạo sequence đầu tiên bên dưới Control Policy.

Hình 5-23: Configure Centralized Policy Step 2: Control Policy TLOC.

Chọn TLOC từ cửa sổ pop-up Add Control Policy. Bằng cách làm này sequence đầu tiên sẽ matches với TLOCs.

Hình 5-24: Configure Centralized Policy Step 3: Control Policy TLOC.

Click chọn Action và chọn Accept option.

Hình 5-25: Configure Centralized Policy Step 4: Control Policy TLOC.

Click chọn Match và mở Site List từ cửa sổ Match Conditions. Chọn site list DataCenter.

Hình 5-26: Configure Centralized Policy Step 5: Control Policy TLOC.

Click nút Save Match and Actions.

Hình 5-27: Configure Centralized Policy Step 6: Control Policy TLOC.

Hình 5-28 hiển thị TLOC sequence đầu tiên. Chúng ta đã tạo sequence bên trong Control Policy HUB_AND_SPOKE_POLICY nơi mà chúng ta match với TLOCs của DataCenter và set hành động là permit.

Hình 5-28: Configure Centralized Policy Step 6: Control Policy TLOC.

Tạo thêm sequence mới bên bên dưới Control Policy. Sequence này sẽ match với OMP Routes. Ngoài ra, sequence này cũng matched với default IP prefix bởi vì chúng ta không xác định rõ ràng bất kỳ IP prefix nào.

Hình 5-29: Configure Centralized Policy Step 7: Control Policy OMP Route.

Quá trình của việc tạo 1 route sequence là hoàn toàn giống với những gì chúng ta đã làm với sequence lên quan đến TLOC. Set điều kiện Match and Action.

Hình 5-30: Configure Centralized Policy Step 8: Control Policy OMP Route.

Hình 5-31 cho thấy trình tự liên quan đến TLOC được liệt kê trước trình tự liên quan đến OMP Route.

Hình 5-31: Configure Centralized Policy Step 9: Control Policy OMP Route.

Ví dụ 5-5 cho thấy cấu hình của Control Policy. Prefix-list được tự động tạo ra với prefix 0.0.0.0/0 được thêm bên dưới match route (OMP route) section bởi vì chúng ta không chỉ định rõ subnet nào.

control-policy HUB_AND_SPOKE_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

Ví dụ 5-6: Configuration Related to TLOC/OMP Control-Policy Sequence.

Bằng cách click vào nút Next, bạn sẽ chuyển tiếp cửa sổ Configure Traffic Rules.

Hình 5-31: Configure Centralized Policy Step 10: Control Policy.

Chúng ta không sử dụng bất kỳ traffic rules nào vì vậy click Next để di chuyển đến cửa sổ Apply Policy to Sites and VPN.

Hình 5-32: Configure Centralized Policy Step 11: Control Policy.

Step-3: Apply Control Policy

Đặt cho Centralized Policy một cái tên và vài description. Lưu ý rằng bạn chỉ có thể activate 1 Centralized Policy tại một thời điểm và đó là lý do tại sao tôi sử dụng cái tên định nghĩa là version. Chọn site list Remote-Sites từ Outbound Site List field. Bằng cách làm này chúng ta có thể thêm Control Policy Hub_and_Spoke_Policy đến sites 10 và 20 đã được định nghĩa trong Remote-Sites site-list. Hãy nhớ rằng policy tổng thể là Centralized Policy và Control Policy là chính sách được sử dụng để thiết lập topology. Chọn nút Add.

Hình 5-33: Configure Centralized Policy Step 12: Apply Policy.

Ví dụ 5-7 cho thấy cấu hình CLI đã được tạo ra trong giai đoạn Apply Policies to Sites and VPNs.

apply-policy

site-list Remote-Sites

control-policy HUB_AND_SPOKE_POLICY out

Ví dụ 5-7: Configure Centralized Policy Step 12 from the CLI: Apply Policy

Hình 5-34 cho thấy rằng Control Policy Hub_and_Spoke_Policy đã được attached vào site list Branch-Sites. Bạn có thể kiểm tra cấu hình đã được tạo ra bằng cách click vào nút Preview. Click nút Save Policy.

Hình 5-34: Configure Centralized Policy Step 13: Activating Policy.

Step-4 Activate Centralized Policy

Bước cuối cùng, chúng ta activate Centralized Policy bằng cách chọn Activate từ tùy chọn drop-down menu […]

Hình 5-35: Configure Centralized Policy Step 14: Activating Policy.

Bạn sẽ bị hỏi để confirm the activation. Click nút Activate.

Hình 5-36: Configure Centralized Policy Step 14: Activating Policy.

Hình 5-37 cho thấy rằng Centralized Policy bây giờ đã được áp dụng thành công trên vSmart.

Hình 5-37: Configure Centralized Policy Step 14: Activating Policy.

Policy Verification

Chúng ta có thể xác minh Centralized Policy có hiệu lực từ trong vManage GUI bằng cách xác minh các TLOC và OMP route của vEdge1 nhận được từ vSmart. Hình 5-38 cho thấy rằng ngoài local TLOCs, vEdge1 chỉ nhận được các TLOCs của site 30 (DataCenter).

Hình 5-38: Centralized Policy Verification – TLOC routes.

Chúng ta cũng thấy rằng vEdge1 chỉ nhận được từ site 30 liên quan đến OMP routes từ vSmart.

Hình 5-39: Centralized Policy Verification – OMP routes.

Hình 5-40 xác mình rằng vEdge1 đã cài đặt OMP route 172.16.30.0/24 và VPN10 RIB (Routing Information Base).

Hình 5-40: Centralized Policy Verification – IP routes.

Chúng ta cũng có thể thấy rằng ở đây chỉ có 2 BFD session từ vEdge1 (site 10: Branch-Site) đến vEdge3 (site 30: DataCenter), một là trên mạng Public-Internet transport và một nữa là trên mạng MPLS transport.

Hình 5-41: Centralized Policy Verification – BFD Sessions.

Hình 5-42 minh họa mô hình mà chúng ta đã tạo ra với Centralized Policy. Ở đây không có tunnel nào giữa vEdge1 và vEdge2.

Hình 5-42: Final Topology – Hub and Spoke.

Ví dụ 5-8 cho thấy rằng chúng ta không thể ping đến end-point 172.16.20.20 được nữa nhưng chúng ta có thể ping end-point 172.16.30.30.

PC1-10> ping 172.16.20.20

*172.16.10.1 icmp_seq=1 ttl=64 time=0.140 ms (ICMP type:3, code:0, Destination network unreachable)

*172.16.10.1 icmp_seq=2 ttl=64 time=0.126 ms (ICMP type:3, code:0, Destination network unreachable)

*172.16.10.1 icmp_seq=3 ttl=64 time=0.131 ms (ICMP type:3, code:0, Destination network unreachable)

*172.16.10.1 icmp_seq=4 ttl=64 time=0.128 ms (ICMP type:3, code:0, Destination network unreachable)

*172.16.10.1 icmp_seq=5 ttl=64 time=0.210 ms (ICMP type:3, code:0, Destination network unreachable)

PC1-10> ping 172.16.30.30

84 bytes from 172.16.30.30 icmp_seq=1 ttl=62 time=2.646 ms

84 bytes from 172.16.30.30 icmp_seq=2 ttl=62 time=4.439 ms

84 bytes from 172.16.30.30 icmp_seq=3 ttl=62 time=2.830 ms

84 bytes from 172.16.30.30 icmp_seq=4 ttl=62 time=2.663 ms

84 bytes from 172.16.30.30 icmp_seq=5 ttl=62 time=2.298 ms

Ví dụ 5-8: Data Plane Testing.

Ví dụ 5-9 cho thấy cấu hình vSmart dã hoàn thành.

vsmart# sh run

system

host-name vsmart

system-ip 10.100.100.13

site-id 100

admin-tech-on-failure

organization-name nwkt

vbond 10.100.0.11

aaa

auth-order local radius tacacs

usergroup basic

task system read write

task interface read write

usergroup netadmin

usergroup operator

task system read

task interface read

task policy read

task routing read

task security read

usergroup tenantadmin

user admin

password $6$jKzSSqC2GCJveJV4$VxMCv59Qv2J.lDd2luqXXJ9dUuv3izVKXPEbE3b43AAry3n6 ptI7DqunO0y0TzxaUVRGAUZ7E/ySEiWdyt8/60

user ciscotacro

description CiscoTACReadOnly

group operator

status enabled

user ciscotacrw

description CiscoTACReadWrite

group netadmin

status enabled

logging

disk

enable

ntp

server 10.100.0.14

version 4

exit

omp

no shutdown

graceful-restart

vpn 0

interface eth0

ip address 10.100.0.13/24

ipv6 dhcp-client

tunnel-interface

allow-service all

allow-service dhcp

allow-service dns

allow-service icmp

no allow-service sshd

allow-service netconf

no allow-service ntp

no allow-service stun

no shutdown

ip route 0.0.0.0/0 10.100.0.1

vpn 512

interface eth1

ip dhcp-client

no shutdown

policy

lists

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

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

site-list Remote-Sites

control-policy HUB_AND_SPOKE_POLICY out

vsmart#

Ví dụ 5-9: Conplete vSmart Configuration.

Spoke-to-Spoke traffic

Nếu chúng ta muốn cho phép các traffic flow giữa các spoke sites mà không trực tiếp qua tunneling chúng ta có thể làm OMP route summarization trên Hub site. Trong vú dụ của chúng ta, tôi có thêm null route bên dưới cấu hình VPN10 cho mạng 172.16.0.0/10. Static route này là tự động redistributed vào trong quá trình quảng bá OMP route. Centralized Policy cho phép các OMP routes từ site 30 quảng bá đến sites 10 và 20.

Hình 5-43: Spoke-to-Spoke: OMP Summary Route Advertisement.

Hình 5-44 cho thấy rằng vEdge3 quảng báo OMP Summary route 172.16.0.0/19 đến vSmart.

Hình 5-44: Spoke-to-Spoke: OMP Summary Route Advertisement – vEdge3.

Hình 5-45 cho thấy rằng vSmart lần lượt quảng bá OMP Summary route 172.16.0.0/19 đến cả hai vEdge1 và vEdge2.

Hình 5-45:Spoke-to-Spoke: OMP Summary Route Advertisement – vSmart.

Hình 5-46 và 5-47 xác minh cả hay vEdge1 và vEdge2 đã nhận được OMP Summary route 172.16.0.0/19 từ vSmart.

Hình 5-46: Spoke-to-Spoke: Received OMP Summary Route – vEdge1.

Hình 5-47: Spoke-to-Spoke: Received OMP Summary Route – vEdge2.

Hình 5-48 xác minh rằng chúng ta cũng có kết nối data plane giữa site 10 và site 20 mặc dù chúng ta không có GRE tunnel hoặc BFD Session giữa các sites (hình 5-49 và 5-50).

Hình 5-48: Spoke-to-Spoke: Data Plane Testing.

Hình 5-49: Spoke-to-Spoke: GRE Tunnels of vEdge2.

Hình 5-50: Spoke-to-Spoke: BFD Sessions of vEdge2.

Tóm tắt

Chương này bắt đầu bằng cách giải thích các tác vụ cần thiết để thay đổi vSmart từ CLI managed sang chế độ vManaged. Tiếp theo, nó giải thích cách xây dựng một chính sách tập trung trong đó có Control Policy từ chối các TLOC và OMP routes nhận được từ site 10 quảng bá đến site 20 và ngược lại. Do đó, không có GRE tunnel giữa site 10 và site 20 và chúng bị giới hạn lẫn nhau. Phần cuối cùng mô tả cách chúng ta cho phép lưu lượng truy cập giữa site 10 và site 20 bằng cách sử dụng OMP route summariztion tại site 30.