Như đã nói ở cuối phần 1, Multicast Signaling là cơ chế Signaling dựa vào Data Plane, cho nên nó có những yếu điểm khiến BGP EVPN là lựa chọn tốt hơn hẳn. Multicast Signaling không có một loại Route chuyên biệt để quảng bá thông tin mà nó học thông tin trực tiếp từ Data thật đi qua nó. BGP EVPN có nhiều loại Route với các Type khác nhau hỗ trợ quảng bá nhiều loại thông tin về Network khác nhau, quá trình này xảy ra trước khi Data thực sự được đi qua, nói còn gọi là quá trình hội tụ

BGP EVPN Signaling

Với BGP EVPN, nó có các loại EVPN Route chuyên biệt để quảng các loại thông tin về Network. Lúc này, chỉ cần Leaf học được MAC mới, nó sẽ tự gửi BGP Update với EVPN Route Type 2 để update thông tin MAC đó cho các Leaf khác, nghĩa là các Leaf dựa vào đó để học MAC chứ không cần phải học từ ARP Request hay ARP reply. Còn khi một địa chỉ MAC bị mất đi khỏi Leaf, ví dụ VM bị remove khỏi Host chẳng hạn, BGP EVPN sẽ dùng EVPN Route Type 2 được gửi trong BGP Update Withdraw Message để thu hồi lại thông tin MAC mà nó đã quảng bá. Route Type linh hoạt như thế này giúp cho EVPN hỗ trợ và đáp ứng tốt các loại nhu cầu hiện tại và cả khi cần mở rộng trong tương lai tốt hơn là Multicast Signaling.

Ngoài MAC, BGP EVPN có thể quảng bá EVPN Route Type 1-4 để hỗ trợ mô hình Multi-Homing với ESI, EVPN Route type 3 cho miền Broadcast, EVPN Route Type 5 để quảng bá IP-Prefix Route, EVPN Route Type 6-7-8 hỗ trợ các giao thức IGMP-Snooping và MLD-Snooping được định nghĩa trong RFC 7432 và nhiều loại Route nữa vẫn đang được phát triển và đề xuất cho IETF để phục vụ nâng cao functionality và performance cho VXLAN Overlay.

Tóm lại, giao thức BGP EVPN hỗ trợ tốt hơn trong việc quản lý, filter policy cho route, mở rộng tốt, có khả năng triển để hỗ trợ thêm các loại giao thức mới trong tương lai cho nên BGP EVPN đang là giao thức tiêu chuẩn và hiệu quả nhất được áp dụng cho VXLAN Overlay. Vậy là ta có Underlay dùng BGP và Overlay cũng dùng BGP nốt 😁

L2VPN over IP Fabric với VXLAN EVPN

Như cái tên của nó VLAN (Virtual eXtensible LAN), tính năng cơ bản và phổ biến nhất của VXLAN là dùng để mở rộng Layer2 hay còn gọi là L2VPN thông qua EVPN Route Type 2 và 3, ngoài ra VXLAN còn hỗ trợ cả L3VPN thông qua EVPN Route Type 5, chút nữa mình sẽ có bài lab riêng về tính năng này. Mình đã dựng bài LAB L2VPN sau với thiết bị ảo hoá Juniper vQFX.

Ở mô hình này, với Underlay sử dụng eBGP Peering bằng IP Connected giữa Leaf và Spine, và quảng bá IP Loopback. Với Overlay, sử dụng iBGP Peering bằng IP Loopback, sau đó quảng bá EVPN Route cho VXLAN. iBGP chung 1 AS Number cho nên nó sẽ chống Loop bằng cơ chế Split Horizon, nghĩa là Leaf quảng bá EVPN Routetới Spine, Spine sẽ không quảng bá tiếp cho các Leaf khác. Lúc này thay vì phải triển khai mô hình iBGP Fullmesh thì ta sẽ cấu hình Spine1 và Spine2 làm RR (route reflector), các Leaf đảm bảo chỉ cần Peering với Spine là đủ. 2 RR này sẽ bảng bá tiếp các bản tin EVPN Route cho các Leaf còn lại. OK, giờ mình sẽ Lab tính năng Layer2 Extend giống bài LAB dùng Multicast Signaling như bên trên. Tuy nhiên lần này sẽ là BGP EVPN Signaling.

Với mô hình trên, khi chưa có traffic thực tế nào đi qua, khi các Leaf cấu hình VXLAN VNI 10001 mapping với VLAN 10, chúng sẽ tự quảng bá với nhau qua EVPN Route Type 3.

EVPN Route Type 3hay còn gọi là Inclusive Multicast Route, dùng để xử lý BUM traffic. Ở ví dụ trên, Leaf1 đang muốn quảng bá cho các Leaf còn lại biết rằng nó đang tham gia vào miền Broadcast VNI 10001 và "Nếu cần gửi BUM traffic thì hãy gửi cho cả tôi".

Với BGP EVPN, Route gửi đi sẽ kèm theo RD(Route Distinguisher) và RT(Route Target). RD để định danh cho Instance quảng bá Route, mỗi VRF (hay Routing Instance) phải có 1 giá trị định danh RD riêng biệt. Còn RT cho VNI 10001 là 10001:1 nằm trong trường Extended Communities đại diện cho Route trong miền quảng bá của MP-BGP, giá trị RT phải được Leaf Export vào trong Route mà nó quảng bá đi thông qua Export Policy. Còn các Remote Leaf dựa vào Import Policy để xác định xem nó có học Route này và Install vào Route Table của mình hay không.

EVPN Route được quảng bá nhờ MP-BGP Extensions [RFC 4760] với AFI là 25 (Layer-2 VPN) và SubAFI là 70 (EVPN) được định nghĩa trong [RFC 7432]

Khi các Leaf đã nhận được các EVPN Route Type 3 của nhau, đứng trên 1 Leaf bất kì (Ở đây là Leaf), mình show được với miền Broadcast Domain VNI 10001, nó nhìn thấy 2 Remote Leaf tham gia là Leaf1(1.1.1.1) và Leaf1(3.3.3.3). Từ giờ, khi Leaf nhận được BUM traffic từ VLAN 10 nó sẽ đóng VXLAN Header và gửi tới địa chỉ của 2 Leaf này, tương tự ở chiều ngược lại.

Khi VM1 gửi ARP Request ra toàn VLAN 10. Leaf1 nhận được và lúc này nó đồng thời làm 2 việc:

• Flow 1: Encapsulation Data với VXLAN Header và Forward ở Data Plane
• Flow 2: Quảng bá EVPN Route Type 2 (MAC+IP) qua vào miền BGP bên trong Core

Flow 1: Vì đây là BUM traffic, hơn nữa nhờ EVPN Route Type 3 mà nó biết được cần phải Broadcast tới Leaf2 và Leaf3 như đã show ở trên Hình 6. Cho nên nó đóng gói Data và gửi thẳng tới Leaf2 và Leaf3, việc này thực hiện ở Data Plane, VM2 và VM3 sẽ nhận được bản tin ARP Request và hành xử bình thường như ví dụ ở phần trước mình đã nêu. Nhưng lúc này, VM2 và VM3 đã học được MAC của VM1, còn Leaf2 và Leaf3 thì không học bằng cách đó.

Flow 2: Leaf1 học được MAC mới của VM1 qua ARP Requestở VLAN 10, nó thực hiện quảng bá EVPN Route Type 2 (Chứa MAC+IP của VM1) cho các Leaf còn lại thông qua Control Plane Signaling.

EVPN Route Type 2 hay còn gọi là MAC/IP advertisement Route. Route này sẽ mang thông tin về địa chỉ MAC hoặc MAC+IP mà nó đã học được. Với cơ chế này các Leaf sẽ đều học được các MAC của các VM trong miền Broadcast Domain đó, quá trình Signaling kết thúc và lúc này các Leaf đề có thể đóng gói được bản tin Known Unicast với VXLAN Header cụ thể bao nhiêu, gửi tới ai. EVPN Route Type 2 Signaling thực tế capture như hình dưới:

Ở Hình 9, EVPN Route Type 2 sẽ mang thông tin MAC+IP của VM1 là 00:50:79:66:68:20 + 192.168.1.11 (ứng với AAA mô tả trên hình 7), Ethernet Tag ID = VNI = 10001. Tất nhiên các thống số về RD + RT cũng tương tự như Type 3 thôi. Ở đây có trường ESI=00:00:00:00:00:00:00:00:00:00 do mình đang chưa cấu hình sử dụng tính năng này. Nói qua thì ESI phục vụ cho môi trường Multi-Homing, cơ chế cho Multi-Homing mình sẽ trình bày ở dưới sau.

Trên Leaf2 có thể show được MAC+IP (VM1) học được qua Leaf1(1.1.1.1) và MAC+IP của VM2 được học qua local là 00:50:79:66:68:21 + 192.168.1.12

Các Leaf học MAC+IP lẫn nhau thông qua BGP EVPN ở Control Plane, Các VM học được MAC+IP của nhau thông qua ARP Broadcast ở Data Plane.

Như vậy, ta thấy Control Planevà Data Plane được tách biệt hoàn toàn, rất rõ ràng và tường minh. Khi MAC local không còn được học trên Leaf nữa, các Leaf sẽ chủ động thu hồi lại thông tin MAC nó đã quảng bá trước đó. BGP Update Message (Withdraw Message) như hình dưới

VXLAN Gateway

Các bài LAB đã trình bày ở trên, VXLAN chỉ dùng để mở rộng miền Layer2, các Leaf ở Overlay không tham gia vào quá trình định tuyến, chỉ Switching gói tin theo MAC qua VXLAN Tunnel. Nhưng thực tế, nhiều Server dịch vụ sẽ không nằm trong cùng 1 VLAN mà phải nằm ở các VLAN khác nhau, lúc này Leaf cần phải đóng vai trò làm L3 Gateway cho dải mạng và phải thực hiện được Inter-Vlan Routing.

Mô hình thiết kế VXLAN L3 Gateway chủ yếu có 3 loại:

1. CRB (Centrally-Routed Bridging): Với thiết kế kiểu này, L3 Gateway của 1 miền Broadcast Domain sẽ được đặt tập trung ở Spine. Nghĩa là Leaf chỉ đóng vai trò làm L2 GW và vận chuyển gói tin Layer2 đến Spine. Tại đây, Spine thực hiện định tuyến, SWAP VNIvà forward bản tin đến đích.
   • Ưu điểm: Gateway tập trung tại một phân vùng nên dễ quản lý, giảm tải phần định tuyến cho toàn bộ Leaf.
   • Nhược điểm:
     • Đặt gánh nặng lên Spine. Như đã nói về thiết kế Underlay ở Phần 1, Spine thậm chí không cần phải hiểu gói tin VXLAN vì nó chỉ cần định tuyến cho Underlay theo IP. Nhưng để Spine làm L3 GW cho VXLAN thì Spine phải dùng thêm tính năng VXLAN nữa. Nếu tăng số lượng Leaf và tăng lưu lượng cần phải định tuyến giữa các VLAN thì cũng cần phải tính toán đến tăng năng lực của Spine.
     • Nếu Routing Issue xảy ra trên Spine thì mức độ ảnh hưởng lớn, ảnh hưởng tới toàn mạng.
     • Với Traffic East-West đi trong cùng 1 Leaf, sẽ phải đi vòng lên Spine rồi định tuyến và đi xuống, gây tốn thêm băng thông trong Core (Băng thông tiêu tốn này là không cần thiết)
2. ERB (Edge-Routed Bridging): L3 Gateway được đặt trên tất cả các Leaf (Gọi là Anycast Gateway).
   • Ưu điểm:
     • Năng lực Routing được chia nhỏ và phân bổ trên các Leaf, Spine sẽ lại quay về vai trò làm Underlay Routing và không cần phải dùng tính năng VXLAN nên sẽ giảm tải cho Spine, số lượng Spine trong hạ tầng thường ít hơn nhiều so với Leaf. Nếu cần mở rộng thêm Leaf sẽ hiệu quả hơn vì không cần phải tính toán nhiều về khả năng định tuyến gói tin VXLAN của Spine.
     • Tối ưu được băng thông khi có nhiều Traffic East-West đi trong cùng Leaf. Định tuyến ngay tại Leaf thì traffic sẽ không phải đi vào trong Core, lỡ lãng phí băng thông trong Core
     • Routing Issue được cô lập trên từng cụm Leaf. Dễ dàng khoanh vùng và mức độ ảnh hưởng nhỏ hơn CRB
   • Nhược điểm: Phức tạp hơn trong việc cấu hình và quản lý Anycast Gateway
3. Gateway Offload: Cái này là mình tự gọi theo ý hiểu chứ không phải thuật ngữ chính thống. Leaf và Spine đều không cần định tuyến mà chỉ mở rộng VXLAN Layer 2. Thay vào đó, chức năng định tuyến được đặt ở một L3-Switch hoặc 1 Router không hề tham gia vào cụm VXLAN. Vị trí của nó như 1 Swich TOR kết nối tới Leaf và nhận lưu lượng không chứa VXLAN Header, nó sẽ thực hiện định tuyến bằng công nghệ Routing và Switch truyền thống.
   • Nhược điểm:
     • Đây đúng ra cũng là một loại CRB, gánh nặng sẽ đặt lên 1 thiết bị Gateway.
     • Nếu Routing Issue xảy ra thì mức độ ảnh hưởng lớn như CRB.
     • Không tối ưu được traffic East West do bất kì traffic nào cần định tuyến cũng cần đi qua Leaf rồi tới Gateway đó.
   • Ưu điểm:
     • Gateway định tuyến gói tin IP thông thường chứ không định tuyến gói tin với VXLAN Header. Mà công nghệ IP Routing truyền thống đã được phát triển hơn nửa thế kỉ rồi cho nên mình đánh giá giải pháp này kiểu gì cũng ổn định hơn VXLAN Routing vì VXLAN mới ra đời chắc được hơn chục năm
     • Đơn giản, dễ dàng trong việc quản trị hạ tầng VXLAN. hạ tầng VXLAN lúc này chỉ mở rộng về mặt Layer 2, không cần phải tham gia vào quá trình định tuyến, giảm thiểu được gánh nặng cho miền VXLAN và khi cần Tshoot cũng đỡ phức tạp hơn.

Với DC nhỏ, lưu lượng East-West ít hoặc gần như không có, chủ yếu là traffic North-South thì mô hình CRB khá phù hợp. Với mô hình cần sự mở rộng mạnh về chiều ngang, traffic East-West lớn thì ERB lại phù hợp hơn. Còn với ai muốn sự ổn định nhất có thể nhưng vẫn tận dụng được ưu điểm của công nghệ VXLAN thì có thể cân nhắc về mô hình Offload Gateway.

Tóm lại mỗi loại thiết kế sẽ đều có ưu/nhược điểm và phù hợp với từng loại nhu cầu về mô hình DC khác nhau. Sau đây mình sẽ LAB mô hình thiết kế theo kiểu ERB

Ở hình 13, L3 Gateway của các VLAN được đặt trên tất cả các Leaf, Vì Gateway là giống nhau trên tất cả các Leaf nên còn được gọi là Anycast Gateway, IP Gateway này sẽ được quảng bá giữa các Leaf cho nhau với cùng giá trị Virtual MAC và cùng giá trị ESI.

Thông tin về MAC+IP Gateway được các Leaf quảng bá với EVPN Route Type 2 được capture như sau:

Giống như VM1 mà ở ví vụ trên đã phân tích, EVPN Route Type 2 mang về thông tin MAC+IP của Gateway cũng vậy. Ở đây là Gateway 192.168.2.1 dành cho VLAN 20 ứng với VNI 10002. ESI ở đây không còn giá trị bằng 0 nữa, thay vào đó nó được sinh ra một giá trị theo RFC7432

Ngoài ra, thông tin ESI được các Leaf quảng bá với EVPN Route Type 1 được capture như sau:

EVPN Route Type 1 này sinh ra với mục đích quảng bá cho các Remote Leaf khác biết rằng mình đang nắm giữ những giá trị ESI nào. Các Leaf khi nhận được EVPN Route Type 1, chúng sẽ biết được rằng Leaf1 đều đang nắm giữ giá trị ESI 05:00:00:00:00:00:00:27:11:00 và ESI 05:00:00:00:00:00:00:27:12:00.

Show trên Leaf 4 ta thấy, MAC+IP của Gateway 192.168.1.1 học được từ ESI 05:00:00:00:00:00:00:27:11:00. Tương tự với GW 192.168.2.1.

Vậy ở đây có nghĩa là, những EVPN Route Type 2 với giá trị ESI = 0 thì nó chọn Active Source là từ Source Leaf mà nó học được bản tin EVPN Route Type 2. Còn với những EVPN Route Type 2 mà ESI != 0 thì nó sẽ chọn Active Source là từ giá trị ESI đó. ESI cũng có nghĩa là 1 Group nào đó chứ không phải chỉ 1 Leaf.

Trong trường hợp L3 Gateway không được cấu hình trên Leaf1 thì dựa vào Hình 17 nó vẫn sẽ biết forward bản tin tới Gateway nào do đã học được trước đó.

Khi nhận được ICMP Request và đây là Unicast Data, nên nó sẽ chỉ chọn 1 trong số các Gateway để gửi tới, ở đây nó chọn Gateway là Leaf2 và đóng VNI 10001

Leaf2 thực hiện Intervlan-Routing tại đây và đóng gói VNI 10002rồi gửi tới Leaf4. Như vậy để đường đi không bị vòng vèo thì nên đặt Anycast Gateway trên tất cả các Leaf, lúc này Leaf sẽ thực hiện định tuyến và Forward Data thẳng tới Leaf luôn mà không cần Random đi qua Leaf2, tránh được traffic overhead.

Quay lại mô hình LAB Leaf1 là L3 Gateway, nó sẽ lookup EVPN Database và biết MAC của VM4 nằm tại Leaf4. Nó thực hiện định tuyến và SWAP VNI sang 10002 để gửi thẳng tới Leaf4 luôn.

Leaf4 nhận được VXLAN Data từ Leaf1 sẽ thực hiện gỡ VXLAN Header và Forward xuống VM4. VM4 phản hồi ICMP Reply cũng sẽ tương tự. Quá trình truyền Data ICMP thành công giữa 2 VM thuộc 2 dải mạng khác nhau nhờ có VXLAN Gateway.

EVPN VXLAN hỗ trợ Multi-Homing

Trong Data Center, để đảm bảo khả năng dự phòng về mặt kết nối, các Server kết nối tới Switch thường sử dụng nhiều Link vật lý và Bundle lại làm 1 Link logic, phổ biến nhất là dùng LACP. Nhưng nếu Server kết nối nhiều đường vật lý tới 1 Leaf Switch duy nhất thì Leaf đó vẫn được tính là SOF (Single Point of Failure), thiết kế này mới chỉ đáp ứng được Link-Level Redundancy. Khi Leaf này Down, toàn bộ kết nối dịch vụ tới Server này cũng mất. Cho nên để đảm bảo về cả Node-level Redundancy, VXLAN EVPN hỗ trợ cơ chế Multi-Homing để một Server kết nối tới nhiều Leaf Switch

Xét mô hình Multi-Homing ở hình 24 (hay còn gọi là Dual-Homing vì Server kết nối vật lý tới 2 Leaf).

Đứng ở góc độ của ServerX, nó không biết là nó kết nối tới 2 Leaf khác nhau, nó chỉ biết là nó kết nối tới 1 Leaf duy nhất với 1 Bundle duy nhất (LACP), cho nên traffic sẽ được Load Sharing qua cơ chế cân bằng tải của LACP (thường dựa vào Hash). Để mô tả cụ thể về cơ chế này, đứng từ phía Leaf mình tách ra làm 2 phần như sau:

1. Server-facing: Kết nối tới Server
2. Core-facing: Kết nối vào miền BGP EVPN

1.Server-facing:

Ở đây, Leaf1 và Leaf2 là hai thiết bị hoàn toàn độc lập, không chạy STACK cũng không chạy HA như MC-LAG hay VPC gì. Vậy để ServerX hiểu nó đang kết nối tới là 1 Leaf duy nhất thì trên Leaf1 và Leaf2 phải cấu hình giá trị System-id: 00:01:02:03:04:05 giống nhau.

Trong bản tin LACPDU, để Negotiate được giữa ServerX và Leaf, ServerX sẽ dựa vào giá trị System-id (Chính là Partner System) để định danh cho đối phương

Cả Leaf1 và Leaf2 quảng bá cùng 1 Partner System (System-id) nên LACP Negotiate thành công ở cả 2 port. Lúc này traffic có thể truyền được trên cả 2 port cùng lúc

Tương tự show thông tin về LACP trên Leaf cũng đều up với ServerX

2. Core-facing:

Về mặt Facing vào trong Core, các Leaf khác cũng phải nhìn Leaf1 và Leaf2 như là một Leaf đối với lưu lượng của ServerX. Lúc này sinh ra EVPN Route Type 1 để làm việc này. EVPN Route Type 1 hay còn gọi là Ethernet Auto-Discovery (A-D) route. Mục đích của nó sinh ra là để nói cho các Leaf khác biết rằng nó đang nắm giữ giá trị ESI nào đó. Ở đây, Leaf1 và Leaf2 đều đang nắm giữ giá trị ESI 00:11:22:33:44:55:66:77:88:99 và đều quảng bá EVPN Route Type 1 cho nhau và cho các Leaf khác biết.

Leaf3 nhận được Route này từ Leaf1 và Leaf2, trong ESI Table của nó sẽ được thêm thông tin về ESI 00:11:22:33:44:55:66:77:88:99 gồm Remote Leaf1 (1.1.1.1) và Leaf2 (2.2.2.2). Vậy khi nào cần dùng tới giá trị ESI này?

Khi Leaf1 và Leaf2 cùng quảng bá địa chỉ MAC của VMX: 00:50:79:66:68:30 bằng EVPN Route Type 2, thì giá trị ESI được thêm vào trong EVPN Route Type 2 như sau:

Khi nhận được EVPN Route Type 2 với giá trịESI != 0, Leaf 3 sẽ để nguồn mà nó học được là ESI thay vì Remote Leaf cụ thể nào đó.

Bây giờ, nếu nó cần đóng gói và vận chuyển một bản tin từ VM3 (192.168.3.13) gửi tới VMX (192.168.3.102). Leaf3 sẽ biết rằng cần gửi tới địa chỉ là ESI 00:11:22:33:44:55:66:77:88:99. Khi này nó sẽ tiếp tục Lookup vào ESI Table để xem là phân giải địa chỉ ESI này ra Remote Leaf nào

Ở đây nó thấy ESI 00:11:22:33:44:55:66:77:88:99ứng với 2 Remote Leaf1 và Leaf2, nó sẽ chọn 1 Leaf để gửi gói tin VXLAN tới đó. Vì cả Leaf1 và Leaf2 đều có thể tới được VMX cho nên giá trị ESI này còn giúp Load Sharingđược traffic. Ví dụ:

Dựa vào ESI, Leaf có thể Load Sharing được traffic từ cùng 1 nguồn tới cùng 1 đích giúp tối ưu được băng thông đường truyền và do đó còn được gọi là Active-Active Multi-Homing (Hoặc All-Active). Còn nếu 1 Server chỉ kết nối tới 1 Leaf Switch thì được gọi là Single-Homing.

Muli-Homing hỗ trợ 1 Server kết nối vật lý tới nhiều Leaf khác nhau. Đối với Core, 1 Leaf cũng có thể gửi traffic tới nhiều Leaf khác nhau với cùng 1 ESI. Vậy tóm lại, cơ chế này tăng khả năng Redundancy và tận dụng tốt băng thông của hạ tầng mạng

BGP EVPN Route Type 4

Nói lại về mô hình Multi-Homing sử dụng ESI. Với Unicast traffic thì ta thấy không có vấn đề gì cần bàn thêm, nhưng nếu các Leaf nhận được BUM traffic thì sao?

1. TH1 (Leaf to ESI Leaf): Khi Leaf3 nhận được BUM traffic từ Server gửi lên, nó sẽ nhân bản và gửi cho tất cả các Leaf. Theo cơ chế chống Loop Split Horizon của VXLAN, các Leaf sẽ chỉ Forward xuống miền VLAN là Server và sẽ không Forward tới các Leaf khác nữa.

Leaf1 và Leaf2 cùng miền ESI, thì traffic cần forward xuống cho Server sẽ bị Duplicate, gây lãng phí tài nguyên đường truyền và tăng tải xử lý cho Server. Một số Data dịch vụ mà Duplicate thì còn dẫn đến lỗi hoặc treo. Như Streaming Data Multicast mà bị duplicate xuống đầu máy nhận thì máy nhận không xem được Stream luôn, case này mình đã từng gặp.

2. TH2 (Server to ESI Leaf): Khi Server gửi BUM traffic cho 1 Leaf, theo cơ chế bình thường Leaf1 sẽ nhân bản và gửi tới toàn bộ các Leaf khác thuộc VXLAN Tunnel đó.

Lúc này, vô tình có cả Leaf2 có kết nối trực tiếp xuống Server mà sinh ra bản tin đó, nên Leaf2 sẽ gỡ VXLAN header và tiếp tục gửi traffic xuống cho Server. Tất nhiên ở đây có thể thấy nếu Server kết nối lên 2 Leaf Switch và cấu hình vào 1 Bundle thì chắc chắn sẽ không Loop nhưng vẫn gây ra lãng phí băng thông và tăng thêm tải cho server, ảnh hưởng dịch vụ tương tự trường hợp 1.

Để xử lý trường hợp này, EVPN Route Type 4 sinh ra để hỗ trợ quá trình bầu chọn DF(Designated Forwarder) và Non-DF. Nếu các thiết bị cùng tham gia một ESI

• Ở TH1, DF sẽ thực hiện việc forward BUM traffic, Non-DFsẽ drop BUM traffic nhận được từ Leaf khác.
• Ở TH2, Khi DF nhận được BUM traffic từ Non-DF gửi lên từ Server, nó sẽ check source của gói tin và so sánh với các source mà nó học được trên các Local Interface ứng với ESI đó. Nếu trùng thì nó sẽ drop traffic đó, đây gọi là cơ chế Local Bias. Vậy để bầu chọn ra DF, các thiết bị cấu hình cùng một giá trị ESI sẽ sinh ra EVPN Route Type 4 để quảng bá cho nhau. EVPN Route Type 4 được Leaf1 và Leaf2 quảng bá ra ứng với ESI 00:11:22:33:44:55:66:77:88:99

Leaf1 và Leaf2 sau khi nhận được các bản tin này của nhau nó sẽ thực hiện bình chọn ra xem ai là DF, còn các Leaf khác nhận được bản tin EVPN Route Type 4 với giá trị ESI 00:11:22:33:44:55:66:77:88:99 không nằm trên nó thì sẽ Drop và không học cũng như không tham gia vào quá trình bầu chọn DF. Quá trình bầu chọn được định nghĩa như trong RFC7432 - Page28

Cơ bản được định nghĩa đơn giản như sau:

Khi nhận được các EVPN Route Type 4, với các Leaf tham gia vào quá trình bầu chọn DF, nó sẽ tạo ra một list các IP của Remote Leaf tính luôn cả Local Leaf đó (ở đây là 1.1.1.1 và 2.2.2.2). Sau đó, nó sắp xếp thứ tự từ bé đến lớn rồi đánh số “i” từ 0 cho đến N-1. Ở ví dụ này 1.1.1.1 tương ứng với i=0, 2.2.2.2 tương ứng với i=1.

Với cấu hình thông thường dựa theo VLAN-based service, VLAN ID là V, thì Leaf i sẽ là DF khi VmodN = i Tức là, Vlan (30) chia (N) Leaf dư 0 (30Mod2 = 0). Do đó Leaf với i=0 sẽ được chọn là DF. Ở đây i=0 tương ứng với Leaf1(1.1.1.1)

Còn đây là khi show Interface Bundle ae1 nối xuống Server của thiết bị DF, trạng thái sẽ là Forwarding

Còn đây là khi show Interface Bundle ae1 nối xuống Server của thiết bị Non-DF, trạng thái sẽ là Blocking BUM Traffic to ESI

Cơ chế bầu chọn DF như trên gọi là MOD based vì nó dựa vào phép tính Modulo. Tuy nhiên cơ chế này cũng có những điểm yếu vì cách tính Modulo trên chưa tối ưu được việc chia đều các DF cũng như khi có thêm thiết bị Leaf tham gia vào hoặc giời đi khỏi ESI.

Mình thấy có một bản Internet-Draft-IETF được đề xuất cho các thuật toán bầu chọn DF khác để giải quyết các yếu điểm của thuật toán Modulo, tham khảo ở draft-ietf-bess-evpn-df-election

Cơ chế Core Isolation ESI-LAG

Với Multi-Homing, nếu Leaf1 bị Down toàn bộ Uplink hoặc Down toàn bộ phiên BGP với phân vùng Core EVPN bên trong, khi đó ServerX gửi request và hashing traffic sang cổng Xe-0/0/8 để đẩy lên Leaf1 thì Leaf1 lúc này trở thành BlackHole vì không thể đưa lưu lượng đi được tiếp. Do đó VXLAN sinh ra cơ chế Core Isolation cho ESI-LAG.

Khi toàn bộ phiên BGP EVPN của nó bị Down, Leaf1 sẽ gửi bản tin LACPDU với cờ Synchronization = 0 (Out of Sync) để chủ động thông báo không nhận Data ở Downlink ESI nữa

Capture bản tin của Leaf gửi xuống Server1, LACPDU với State 0x07 để Negotiate la trạng thái cổng Xe-0/0/8 không tham gia và quá trình truyền Data cho LACP Bundle nữa.