traffic share ring core mane.pdf

Hải Quân P a g e | 1 NOC2

Tối ưu lưu lượng RING-MANE thông qua kỹ thuật

“traffic share” giữa các Tunnel

1. Cơ sở lý thuyết

1.1 Khái niệm về RIB, FIB, adjacency tables trong kỹ thuật CEF Bảng định tuyến RIB (Routing Information Base) được hình thành dựa trên kết quả tính toán từ

các thuộc tính của các giao thức. Thông thường, bảng RIB sẽ lưu trữ toàn bộ route tới cùng một

destination, những route với giá trị AD (administrative distance), cost (hoặc metric) nhỏ nhất trong

bảng định tuyến được gọi là best-path và sẽ được sử dụng để chuyển tiếp gói tin.

Tuy nhiên, trong một số trường hợp, sẽ tồn tại những route có cùng giá trị AD và COST. Khi đó,

những route này đều được gọi là best-path và cùng được sử dụng để chuyển tiếp gói tin.

Thông tin next-hop của những best-path này trong bảng RIB sẽ được chuyển xuống bảng FIB (Forwarding

information based) dung để forward gói tin hay còn gọi là forwarding table. Hay nói một cách khác. Bảng

FIB sẽ chỉ ra một cách chính xác nơi mà gói tin đi ra khỏi router để đi tới đích (interface)

KGG00RGA#show ip route 10.95.0.4

Routing entry for 10.95.0.4/30

Known via "isis", distance 115, metric 20, type level-1

Redistributing via isis kiengiang

Last update from 123.29.63.3 on Tunnel101, 05:52:31 ago

Routing Descriptor Blocks:

123.29.63.3, from 123.29.63.3, 05:52:31 ago, via Tunnel101

Route metric is 20, traffic share count is 1

* 123.29.63.3, from 123.29.63.3, 05:52:31 ago, via Tunnel102


Bảng FIB, là một thành phần trong kỹ thuật CEF (Cisco Express Forwarding) dùng để chuyển tiếp

gói tin trong Router Cisco. CEF là nền tảng cho MPLS và hoạt động trên các bộ định tuyến của

Cisco. Và trong kỹ thuật CEF, bảng FIB được xây dựng dựa trên hai thông tin next-hop và interface

engress để đi tới đích.

KGG00RGA#show ip cef 10.95.0.4

10.95.0.4/30

nexthop 123.29.63.3 Tunnel101

nexthop 123.29.63.3 Tunnel102

Không giống như RIB, bảng FIB chỉ chứa thông tin destination và next-hop để tới destination. Và

Ngoài bảng FIB, CEF còn sử dụng adjacency tables để gắn thêm thông tin địa chỉ Layer 2.

Adjacency table duy trì địa chỉ Layer 2 của next-hop cho tất cả các entries trong bảng FIB. Những

node trong mạng được gọi là có quan hệ adjacency nếu chúng có thể đến được nhau thông qua 1

hop.

Lưu ý: Trong kỹ thuật MPLS Traffic Engineering Tunnel các interface tunnel sẽ được đưa vào

bảng định tuyến như là một interface engress dùng để tính toán đường đi.


Khi một đường đi được xác định, nó chỉ ra next-hop và adjacency entry tương ứng. Nó được dùng

để đóng gói trong khi CEF chuyển mạch gói tin. Một route có thể có nhiều đường đi đến đích. Với

mỗi đường đi này, một con trỏ được thêm vào bảng adjacency chỉ ra next-hop interface tương ứng

với đường đó. Cơ chế này được sử dụng để cân bằng tải trên nhiều đường.

KGG00RGA#show adjacency tunnel 101

Protocol Interface Address

IP Tunnel101 point2point(33)

TAG Tunnel101 point2point(18)

KGG00RGA#show adjacency tenGigabitEthernet 1/1

Protocol Interface Address

IP TenGigabitEthernet1/1 10.95.0.9(15)

TAG TenGigabitEthernet1/1 10.95.0.9(7)

IP TenGigabitEthernet1/1 225.0.0.0(5)

Giao thức MPLS hoạt động dựa trên sự kết hợp giữa chuyển mạch lớp 2 và định tuyến lớp 3. Để sử dụng

MPLS, trên router CISCO, ta phải sử dụng kỹ thuật CEF. Khi bộ định tuyến sử dụng CEF, nó duy trì tối

thiểu 1 FIB và Adjacency table.

Việc cân bằng tải không được thực hiện bởi MPLS hoặc IGP. Mà việc cân bằng tải được thực hiện

dựa trên kỹ thuật CEF.

Hiện tại trong kỹ thuật CEF ở router Cisco, việc cân bằng tải được thực hiện theo phương pháp

mặc định là per-destination, ngoài ra chúng ta có thể sử dụng phương pháp khác là per-packet.

1.2 Tìm hiểu về cân bằng tải per-destination trong kỹ thuật CEF. Để hiểu rõ hơn về quá trình cân bằng tải trong kỹ thuật CEF dung trong MPLS. Khái niệm về traffic share

sẽ được đề cập.










Traffic share couter chính là giá trị chỉ định tỉ lệ share traffic trên hai đường đi tới cùng một

destination. Ở đây, tỉ lệ này là 1:1. Nghĩa là tỉ lệ share traffic dựa theo phương pháp cân bằng tải

per-destination đang là bằng nhau trên 2 path.

Vậy tỉ lệ traffic share hay là giá trị traffic share count sẽ được sử dụng như thế nào trong quá

trình thực hiện cân bằng tải trong kỹ thuật CEF.

Khi một gói tin đi vào Router, một giá trị hash (từ 1~16) sẽ được tính dựa trên địa chỉ IP nguồn

và đích (per-destination). Giá trị hash này chỉ định đường đi giống nhau cho tất cả các gói tin có

cùng địa chỉ IP nguồn và đích này.


Trong rrường hợp có hai path với tỉ lệ share traffic bằng nhau

KGG00RGA#show ip cef 10.95.0.4 internal

10.95.0.4/30, epoch 19, flags need ps clean, RIB[I], refcount 6, per-destination sharing

2 hash buckets

< 0 > IP midchain out of Tunnel101 215A9780 label implicit-null FRR 1 IP adj out of

TenGigabitEthernet1/1, addr 10.95.0.9 215AACA0

< 1 > IP midchain out of Tunnel102 215AF760 label implicit-null FRR 1 IP adj out of

TenGigabitEthernet8/3, addr 10.95.0.17 1F1D8080

Subblocks:

None

Để hình dung rõ hơn, ta có thể tham khảo sơ đồ sau:

Hình 1: Quá trình tạo hash bucket trong traffic share

Giả sử tỉ lệ traffic là 3:2.












Router sẽ tạo ra 15 hash bucket (0-14) để phân bổ các tuyến đường.

KGG00RGA# show ip cef 10.95.0.4 internal


15 hash buckets





















<10 > IP midchain out of Tunnel102 215AF760 label implicit-null FRR 1 IP adj out of


<11 > IP midchain out of Tunnel101 215A9780 label implicit-null FRR 1 IP adj out of








Và cụ thể các tuyến đường được chọn như sau:

KGG00RGA# show mpls forwarding-table 10.95.0.4 detail

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

3258 Pop Label 10.95.0.4/30 0 Tu102 point2point

MAC/Encaps=14/14, MRU=9196, Label Stack{}, via Te8/3

0024C4C0BA4000258429F6008847

No output feature configured

Per-destination load-sharing, slots: 0 2 4 6 8 10

Pop Label 10.95.0.4/30 0 Tu101 point2point

MAC/Encaps=14/14, MRU=9196, Label Stack{}, via Te1/1

0024C4C0BA4000258429F6008847

No output feature configured

Per-destination load-sharing, slots: 1 3 5 7 9 11 12 13 14

Tỉ lệ số hash bucker giữa hai đường qua Tu101 và Tu102 đúng bằng 9:6 = 3:2


2. Hiện trạng lưu lượng trong mạng MANE Để nâng cao hoạt động ổn định của mạng thông qua việc tối ưu hóa thời gian hội tụ khi xảy ra sự

cố về link/node trên mạng, ta sử dụng kỹ thuật MPLS Traffic Engineering với giao thức định

tuyến IGP là giao thức ISIS và khai báo Tunnel hop-by-hop trên các kết nối này. Tuy nhiên,

hiện tại, lưu lượng đang chạy trong mạng MANE có một số khiếm khuyết như:

2.1 Lệch tải Ring Core Đa số các Ring-core MANE các tỉnh đều được trang bị các kết nối tối thiếu là 2x10GE. Qua giám sát lưu

lượng trên PRTG thấy phần lưu lượng đang được phân bổ không đều nhau giữa hai link, lệch tải,

làm cho trong 2 link có một link có lưu lượng cao và link còn lại có lưu lượng thấp

Ví dụ : Mane KGG: Link KGG00RGA (Te1/1) – KGG00BHN (Te1/2) bị nghẽn trong khi lưu lượng trên

link Link KGG00RGA (Te8/3) – KGG00BHN (Te7/1) đang ở mức thấp.

Hình 2. Ring core Mane Kiên Giang:


2.2 Link trong Ring có lưu lượng cao trong khi các Link khác vẫn có lưu lượng thấp.

Hướng KGG00RGA -> KGG00RGA có lưu lượng cao 7.5Gbs/10Gbs

Hướng KGG00RGA -> KGG00CTH -> KGG00BHN –> KGG06BHN đang có lưu lượng thấp.

KGG00RGA -> KGG00CTH


KGG00CTH -> KGG00BHN

KGG00BHN –> KGG06BHN

2.3 Cân bằng tải và tỉ lệ traffic share. Từ KGG00RGA tới KGG00BHN



Known via "isis", distance 115, metric 10

Tag 1000, type level-1






Route tag 1000



Route tag 1000

Pương pháp cân bằng tải đang sử dụng hiện tại đang là per-destination như bên dưới

KGG00RGA#show cef state

CEF Status:

RP instance

common CEF enabled

IPv4 CEF Status:

CEF enabled/running

dCEF disabled/not running

CEF switching enabled/running

universal per-destination load sharing algorithm, id 5F4A493A


Thuật ngữ per-destination được hiểu là cân bằng tải dựa trên một cặp source – destination (không phải chỉ

là destination). Với cơ chế cân bằng tải per-destination, một giá trị hash được tính dựa trên địa chỉ IP nguồn

và đích. Giá trị hash này chỉ định đường đi giống nhau cho tất cả các gói tin có địa chỉ IP nguồn và đích

này

Cơ chế tạo hash bucket để phân bổ các tuyến đường. Tạo ra 2 hash bucket

KGG00RGA#show ip cef 123.29.63.3 internal


……………………………………………………………………………………………..

………………………………………………………………………………………………

2 hash buckets





Tỉ lệ traffic share trên hai Tunnel để đến 123.29.63.3 là 1:1 nên việc load-sharing cũng được thực hiện

theo tỉ lệ 1:1. Tức là tất cả các gói tin được phân loại theo cặp Source – Destination được phân phối luân

phiên trên hai Tunnel 101 và Tunnel 102 theo tỉ lệ 1:1.

Ta có thể dung câu lệnh show ip cef exact-route để biết chính xác

KGG00RGA# show ip cef exact-route 192.168.1.1 123.29.63.3

192.168.1.1 -> 123.29.63.3 => label implicit-null IP adj out of TenGigabitEthernet1/1, addr 10.95.0.9

KGG00RGA# show ip cef exact-route 192.168.1.2 123.29.63.3

192.168.1.2 -> 123.29.63.3 => label implicit-null IP adj out of TenGigabitEthernet8/3, addr 10.95.0.17

Từ kết quả trên ta thấy:

Tất cả các gói tin có source là 192.168.1.1 và destination là 123.29.63.3 sẽ đi trên Tunnel 101.

Tất cả các gói tin có Source là 192.168.1.2 và destination là 123.29.63.3 sẽ đi trên Tunnel 102.

Để giảm bớt sự lệch tải này. Chúng ta có thể sử dụng kỹ thuật traffic share trên 2 Tunnel để phân bổ lại

lưu lượng. Ưu tiên tỉ lệ cao trên Tunnel có lưu lượng thấp.

3. Giải pháp và cấu hình thử nghiệm

Có hai phương pháp để thay đổi tỉ lệ traffic share trên hai tunnel

Sử dụng tham số bandwith cấu hình Interface Tunnel

Sử dụng tham số load share trong cấu hình Interface Tunnel

Lưu ý: Thực hiện đối với lưu lượng chiều OUT.

Nếu chiều OUT từ KGG00RGA tới KGG00BHN phân bố không đều. Thì ta cấu hình traffic share trên

KGG00RGA.


3. 1. Cấu hình sử dụng tham số bandwith để thay đổi tỉ lệ giữa Tunnel 101 và Tunnel 102 interface Tunnel101

description KGG00RGA-T101-P-TO-KGG00BHN

ip unnumbered Loopback0

logging event link-status

mpls ip

tunnel mode mpls traffic-eng

tunnel destination 123.29.63.3

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 7 7

tunnel mpls traffic-eng bandwidth 20

tunnel mpls traffic-eng path-option 10 explicit name T101-P-TO-KGG00BHN

tunnel mpls traffic-eng fast-reroute

end

---------------------------------------------------------------------------------------------------------------------- interface Tunnel102




mpls ip








end

3.2. Cấu hình sử dụng tham số load share để thay đổi tỉ lệ giữa Tunnel 101 và Tunnel 102 interface Tunnel101




mpls ip






tunnel mpls traffic-eng load-share 20

end

-------------------------------------------------------------------------------------------------------------------------------

interface Tunnel102




mpls ip








tunnel mpls traffic-eng load-share 30

end


Cả hai cấu hình đều cho kết quả traffic share giống nhau:










Route tag 1000



Route tag 1000

Kết quả: Lưu lượng trên hướng nghẽn đã giảm trên Tunnel 101 (Te1/1) và tăng trên Tunnel 102 (Te8/3)

3.3 Khai báo thêm Tunnel, kết hợp với kỹ thuật điều chỉnh tỉ lệ traffic share

1. Thu thập Base line:

KGG00RGA -> KGG00CTH

KGG00RGA#show isis neighbors | include 00CTH

KGG00CTH L1 Te2/1 10.95.0.2 UP 29 00

KGG00CTH L1 Te8/2 10.95.0.50 UP 28 0B

KGG00CTH -> KGG00BHN

KGG00CTH#show isis neighbors | include 00BHN

KGG00BHN L1 Te2/1 10.95.0.6 UP 22 03

KGG00BHN L1 Te8/1 10.95.0.54 UP 26 0E


KGG00BHN –> KGG06BHN

KGG00BHN#show isis neighbors | include 06BHN

KGG06BHN L1 Te1/1 10.95.1.106 UP 28 04

KGG06BHN L1 Te3/3 10.95.1.54 UP 28 01

2. Khai báo Explicit path đi theo đường có lưu lượng thấp.

KGG00RGA#show ip explicit-paths name T206-RGA-UPE-BHN-VIA-CTH

PATH T206-RGA-UPE-BHN-VIA-CTH (strict source route, path complete, generation 86855)

1: next-address 10.95.0.2



3. Khai báo tunnel 208 để đi từ KGG00RGA về KGG06BHN theo Explicit Path đã khai

interface Tunnel208

description "T208RGA-UPE-BHN-VIA-CTH"



mpls ip




tunnel mpls traffic-eng path-option 10 explicit name T206-RGA-UPE-BHN-VIA-CTH

end

Chú ý khai báo load share trên hai Tunnel đang đi từ KGG00RGA về KGG06BHN để phân bổ lưu lượng










Route tag 1000



Route tag 1000

Kết quả: Lưu lượng hướng KGG00RGA -> KGG06BHN đã giảm


3.4 Khai báo Tunnel với [explicit path] cho các dịch vụ cần ưu tiên. Ví dụ: Dịch vụ VTV Cab MANE KGG hiện đang đi theo tuyến: KGG00RGA – KGG00BHN – KGG99PQC

Giả sử ta muốn chuyển sang đi theo hướng KGG00RGA - KGG00CTH - KGG00BHN – KGG99PQC

1. Khai báo explicit path

KGG00RGA#show ip explicit-paths name UNGCUUVTVCAP

PATH UNGCUUVTVCAP (loose source route, path complete, generation 87337)

1: next-address loose 123.29.63.2

2: next-address loose 123.29.63.3

3: next-address 10.95.1.97.

2. Khai báo Tunnel

KGG00RGA#show running-config interface tunnel 2000

interface Tunnel2000

description UNGCUUVTVCAP



load-interval 30

mpls ip



tunnel mpls traffic-eng path-option 10 explicit name UNGCUUVTVCAP

end

3. Khai báo pw-class

pseudowire-class PQC-TE2/1-CTH

encapsulation mpls

preferred-path interface Tunnel2000

4. Dịch vụ VTV Cab trên KGG00RGA đang chạy L2 với VC-ID là 2015.

KGG00RGA#show mpls l2transport vc 2015

Local intf Local circuit Dest address VC ID Status

------------- -------------------------- --------------- ---------- ----------

Gi9/19 Eth VLAN 2015 123.29.63.27 2015 UP

Được khai báo trên cổng Gi9/19 với Service Instance là 2015. Để ưu tiên Tunnel 2083 ta khai báo

như sau:

service instance 2015 ethernet

description "VTVCAB-700M"

encapsulation dot1q 2015

xconnect 123.29.63.27 2015 encapsulation mpls pw-class PQC-TE2/1-CTH


4. Áp dụng Bằng cách thay đổi tỉ lệ traffic share giữa các Tunnel, khai báo thêm Tunnel tới cùng một HOP

kết hợp với tỉ lệ traffic share ta có điều chỉnh lưu lượng một cách dễ dàng trong mạng MANE đối

với các trường hợp sau:

1. Lệch tải Ring Core: Chuyển traffic qua lại giữa các Tunnel khi có sự lệch tải.

2. Link trong Ring có lưu lượng cao trong khi các Link khác vẫn có lưu lượng thấp: Khai

thêm tunnel đi vòng qua hướng có lưu lượng thấp Sau đó sử dụng khai báo tỉ lệ traffic share

hợp lý để phân bổ traffic.

3. Xử lý nhanh đối với các dịch vụ cần ưu tiên khi xảy ra nghẽn. Sử dụng Khai báo Tunnel

với [explicit path] để lưu lượng đi theo đường đi mong muốn qua các hướng có lưu lượng

thấp

traffic share ring core mane.pdf

Documents