Các ví dụ ở Phần 2 về L2VPN over VXLAN, Leaf lúc này học được MAC+IP trực tiếp của các Host ở Downlink, Leaf thông qua EVPN Route Type 2 để quảng bá MAC+IP của từng Host một. Flow đơn giản chỉ là Host->Leaf->Leaf->Host. Tuy nhiên, mô hình không phải lúc nào cũng chỉ đơn giản có thế, các Leaf cần phải có khả năng quảng bá được cả các các dải mạng cho nhau (IP-Prefix Route). Lúc này L3VPN EVPN hỗ trợ việc đó

L3VPN over IP Fabric với VXLAN EVPN

Xét trường hợp ở Hình 1, RouterX kết nối trực tiếp với Leaf4 và tham gia định tuyến OSPF. Dải mạng 172.30.2.0/24 được quảng bá vào OSPF Area 0. Khi đó Leaf4 học được dải mạng 172.30.2.0/24 thông qua RouterX như hình bên dưới

Leaf1 kết nối trực tiếp tới Server1(VM1) thông qua interface Xe-0/0/10. VM1 đặt Default Gateway trên Leaf1. Lúc này bài toán đặt ra là làm sao để Backend ở VM1(192.168.169.11) có thể kết nối được tới Database (172.30.2.44)?

Leaf4 bây giờ không kết nối trực tiếp tới dải mạng 172.30.2.0/24, nó chỉ đơn giản học được dải mạng này qua OSPF. Với cơ chế cũ, nó không thể quảng bá từng MAC+IP qua EVPN Route Type 2 cho các Leaf khác được. Do đó, cần phải có một loại EVPN Route Type khác để mang thông tin IP-Prefix và quảng bá giữa các Leaf với nhau. Ở đây, EVPN Route Type 5 sinh ra để làm việc đó. Với mô hình này, Leaf4 sẽ được cấu hình quảng bá Route connected và Redistribute OSPF Route vào miền BGP EVPN.

Đây là EVPN Route Type 5 mà Leaf4 quảng bá cho các Leaf trong miền BGP EVPN. Ở đây ta có thể thấy, Route này mang theo thông tin về dải mạng 172.30.2.0/24, Label VNI 10050, Route Target, cả thông tin cơ bản về Route được học từ protocol OSPF Area 0 như thế nào,….

Đứng trên Leaf1 ta có thể thấy, nó học được Route về dải mạng thông qua BGP EVPN từ Leaf4, sau đó nó Import Route từ EVPN Table sang inet table để phục vụ truyền gói tin qua Underlay.

Tương tự, Leaf1 cũng quảng bá connected IP-Prefix của nó là 192.168.169.0/24 cho Leaf4 được hiển thị trong bảng định tuyến như dưới.

Sau khi quá trình Signaling hoàn tất. Khi nhận được bản tin từ VM1 gửi tới nó đã biết đóng VNI 10050 và gửi tới cho Leaf4

Kết nối thành công từ Backend (192.168.169.11) tới Database (172.30.2.44). Data được đóng VNI 10050

Multicast over IP Fabric với VXLAN EVPN

Ở phần 1, Mình đã nói về VXLAN over Multicast với PIM đúng không, còn bây giờ là Multicast over VXLAN, hai khái niệm này hoàn toàn khác nhau. Multicast ở đây đóng vai trò là Data dịch vụ (như Streaming Data), còn VXLAN đóng vai trò là lớp vận chuyển cho dịch vụ đó.

Multicast với mô hình Single-Homing

Mình sẽ nói tới trường hợp Single-Homing trước, tức là VM chỉ kết nối tới 1 LEAF duy nhất như hình bên dưới

Khi này VM4, VM3, VMR đang chung 1 Broadcast Domain. Nếu VM4 là 1 Multicast Source đang streaming data vào địa chỉ multicast 239.0.0.1 thì lúc này vì là BUM traffic, nó sẽ được Leaf4 Flood ra toàn bộ các Leaf chung miền Broadcast Domain VNI 10001. Các Leaf nhận được sẽ Flood tiếp xuống các VM bên dưới. Tuy nhiên, nếu chỉ có VMR muốn nhận streaming data và VM3 không muốn thì sao? Lúc này vì chung 1 Broadcast Domain nên tất cả các VM cho dù không muốn nhận Streaming Data thì lưu lượng vẫn được Flood tới nó, gây lãng phí băng thông và có thể ảnh hưởng tới các dịch vụ khác của Server. Ở mô hình LAB trên, mình sẽ sử dụng VM4 để phát luồng multicast vào địa chỉ rtp://239.0.0.1:5004 bằng VLC

Sử dụng VLC để streaming data tại VM4 và Capture Streaming Data như bên dưới

Như khi capture Data thực tế, Streaming Data được đóng VNI 10001 và gửi đi khắp các Leaf cùng miền Broadcast Domain

Đứng trên VMR thực hiện join kênh Multicast với địa chỉ rtp://239.0.0.1:5004

Kết quả là VMR xem được Data Streaming từ Multicast Source gửi tới qua miền VXLAN như trong 1 miền Broadcast bình thường. Nhưng như đã nói ở trên, việc Flood lưu lượng ra toàn bộ các Broadcast Domain rõ ràng là không cần thiết và rất tốn băng thông của mạng. Với mạng LAN truyền thống, chúng ta có IGMP-Snooping và MLD-Snooping giải quyết điều này, các bản tin IGMP Report, IGMP Leave Group, IGMP Query được sử dụng để lưu lượng Multicast chỉ được gửi ra những cổng nào có chứa các Host muốn nhận Multicast Data thôi, Switch Layer 2 sẽ quản lý IGMP-Snooping Table. VXLAN EVPN cũng vậy, nó sinh ra EVPN Route Type 6-7-8 để hỗ trợ IGMP-Snooping trong miền EVPN Broadcast Domain.

EVPN Route Type 6 hay còn gọi là SMET Route (Selective Multicast Ethernet Tag Route). Khi VMR muốn tham gia nhận lưu lượng, nó sẽ gửi IGMP Report tới Leaf2 như thực tế bên dưới:

Bản tin IGMP Report chứa thông tin group mà VMR muốn tham gia là gì. Cả Join và Leave đều sử dụng Type: 0x22. Nhưng Record Type sẽ khác nhau:

1. Nếu muốn nhận lưu lượng multicast từ mọi nguồn. IGMPv3 Report sẽ để Record Type sang Mode 4 (Change to Exclude). Nghĩa là nhận lưu lượng ngoại trừ Source chỉ định (Ở đây Source = null vì không có giá trị) cho nên Leaf có thể hiểu là VMR muốn nhận lưu lượng multicast 239.0.0.1 từ mọi Source => Coi như là bản tin Join Group
2. Nếu muốn nhận lưu lượng multicast từ một nguồn cụ thể. IGMPv3 Report sẽ để Record Type sang Mode 3 (Change to Include). Nghĩa là nhận lưu lượng từ Source chỉ định (Ở đây Source = null vì không có giá trị) cho nên Leaf có thể hiểu là VMR không muốn nhận lưu lượng từ Source nào => Coi như là bản tin Leave Group Mọi người có thể tham khảo cơ chế của IGMP v3 ở RFC3367



Leaf2 sau khi nhận được bản tin này, nó biết rằng có 1 Host dưới nó cần nhận lưu lượng này. Leaf2 cũng sẽ dựa vào bảng thông tin về IGMP-Snooping Table để gửi lưu lượng tới những Interface nào mà nó nhận được IGMP Report thôi.

Sau khi có thông tin về IGMP Snooping Membership ở phía Downlink, Leaf2 sẽ quảng bá EVPN Route Type 6 cho các Leaf khác biết. EVPN Route Type 6 sẽ chứa thông tin về nhóm Multicast nó muốn tham gia nhận lưu lượng là gì.

Khi này đứng trên Leaf4, ta có thể thấy sau khi học được EVPN Route Type 6 từ Leaf và import vào bgp.evpn.0, nó sẽ install thông tin này vào EVPN Multicast Snooping Table như hình bên trên. Vậy khi cần Flood lưu lượng Multicast cho 239.0.0.1, nó sẽ chỉ cần gửi tới Leaf2 thôi

Tại VMR đã nhận được lưu lượng mà Leaf gửi xuống và xem được kênh Streaming Data bình thường. Còn khi không muốn nhận Streaming Data nữa, VMR sẽ gửi IGMP Report Leave Group cho Leaf2 biết với Record Type là Mode 3 (Change to Include). Lúc này Leaf2 sẽ thu hồi EVPN Route Type 6 mà nó đã quảng bá trước đó cho Leaf4.

Trên Leaf4 đã không còn có thông tin về member của Group 239.0.0.1 nữa. Streaming Data giờ sẽ không được gửi tới bất kì Member Leaf nào.

Multicast Traffic Over VXLAN Multi-Homing

Ở mô hình Single-Homing như bên trên, ta thấy rằng việc 1 Multicast Receiver chỉ kết nối tới 1 Leaf nên rất đơn giản, Leaf hoàn toàn có thể kiểm soát việc Join hay Leave được bằng EVPN Route Type 6 và thu hồi khi cần. Nhưng tới mô hình Multi-Homing thì khác, cách hành xử của DF và Non-DF đối với BUM traffic sẽ đặc biệt hơn. Cách hành xử của các thiết bị được mô tả như mô hình Multi-Homing bên dưới

Ở đây, ServerR kết nối với cả Leaf1 và Leaf2 với công nghệ ESI và LACP. Khi VMR gửi IGMP Report yêu cầu Join vào nhận lưu lượng của Group 239.0.0.1. Leaf1 lúc này là Non-DF, nó sẽ quảng bá EVPN Route Type 6 như bình thường tới Leaf4. Leaf4 lúc này sẽ chỉ Forward Streaming Data cho Leaf1. Nhưng vì là Non-DF, nên khi nhận được BUM traffic từ Leaf4, nó sẽ Drop và không Forward xuống tiếp cho VMR nữa. Để VMR nhận được lưu lượng Multicast thì VMR đúng ra phải gửi IGMP Report Join Group lên cho DF (Ở đây là Leaf2). Nhưng đã là Multi-Homing, thì Server R sẽ dựa vào LACP để hashing traffic trên 2 đường vật lý tới cả Leaf1 và Leaf2 chứ không thể chỉ chọn lên Leaf2 được.

Lúc này sinh ra EVPN Route Type 7 hỗ trợ việc đồng bộ IGMP-Snooping Table giữa các LEAF trong cùng ESI. IGMP Route Type 7 hay còn gọi là IGMP Join Synch Route. Cơ chế này hoạt động như sau:

1. Khi Non-DF (Leaf1) nhận được IGMP Report Join từ VMR gửi lên, nó sẽ gửi EVPN Route Type 6để thông báo về việc cần nhận lưu lượng Multicast của Group 239.0.0.1 kèm theo giá trị ESI của nó. đồng thời nó gửi cả EVPN Route Type 7 để thông báo cho các ESI Member của nó biết rằng đang có Host ở Downlink ứng với ESI 00:11:22:33:44:55:66:77:88:99 cần nhận lưu lượng.

2. DF (Leaf2) nhận được EVPN Route Type 7 và hiểu rằng ở ESI Downlink, có Host cần nhận lưu lượng Streaming Data của Group 239.0.0.1. Leaf2 sẽ quảng bá EVPN Route Type 6 cho các Leaf khác biết để Pull Streaming Data về nó.
3. Leaf4 gửi Multicast Data cho Leaf2 với VNI 10001, Leaf2 sẽ gỡ VXLAN Header và forward xuống cổng nối với ServerR. Và VMR lúc này đã có thể xem được Streaming Data.

Ở Step 1, Nếu chỉ có DF mới có thể gửi BUM traffic xuống cho Server ở ESI Downlink, thì việc Non-DF gửi EVPN Route Type 6 nhận Multicast là không cần thiết đúng không? vì dù nhận traffic thì nó cũng sẽ Drop và không gửi xuống cho Server mà sẽ để DF làm việc đó. Nhưng xét trong môi trường có 1 DF và nhiều Non-DF, chỉ cần có 1 Non-DF tham gia mới hoặc rời đi thì việc tính toán lại DF lại xảy ra và chắc chắn theo cơ chế Modulo thì DF sẽ thay đổi chứ không thể là DF cũ đang chạy, lúc này DF mới lại phải gửi EVPN Route Type 6 để Pull Streaming Data về, và khi có Data rồi nó mới Forward data xuống cho VM Receiver được, quá trình này sẽ làm cho dịch vụ bị gián đoạn 1 khoảng thời gian.

Mà dịch vụ Streaming thường à dịch vụ yêu cầu tính Real-time cao, để giải quyết vấn đề này thì các Non-DF cũng sẽ đều gửi EVPN Route Type 6 và Pull sẵn Streaming Data về. Khi quá trình bầu DF mới lại xảy ra, DF mới này đã có thể Forward Streaming xuống ESI Downlink được luôn vì Streaming đã được Pull về sẵn nó từ trước rồi. SMET được cả DF và Non-DF quảng bá là vì thế.

EVPN Route Type 8 hay còn gọi là IGMP Leave Synch Route, tương tự như Type 7, nó sinh ra nhằm mục đích để Non-DF báo hiệu cho DF biết rằng có bản tin IGMP Report Leave Group yêu cầu ngưng nhận Streaming Data từ phía Downlink của ESI gửi lên. DF sẽ nắm được thông tin và thu hồi EVPN Route Type 6 mà nó đã quảng bá trước đó

Flow như sau:

1. Khi VMR không còn muốn nhận Multicast Data đó nữa, nó gửi IGMP Report Leave Group tới cho Non-DF là Leaf1. Leaf1 sẽ quảng bá EVPN Route Type 6 & 8 để thông báo rằng không cần nhận lưu lượng của Group 239.0.0.1 nữa kèm theo giá trị ESI.

3. Sau khi nhận được thông tin này, Leaf2 thực hiện gửi IGMP Query xuống Downlink để verify một lần nữa rằng không có ai muốn Join Group 239.0.0.1 này nữa, vì có thể Downlink của nó là Switch nối tới nhiều Host bên dưới chứ không chỉ có 1 mình VMR, đây là cơ chế hoạt động của IGMP Snooping và mình sẽ không nói sâu về cơ chế này nữa. Sau khi verify rằng Downlink không còn ai muốn nhận Multicast Data, nó sẽ thu hồi bản tin EVPN Route Type 6 mà trước đó đã quảng bá. Khi này Leaf4 sẽ không gửi Streaming Data cho Leaf2 nữa. Quá trình rời kênh Multicast kết thúc.

VXLAN Data Center Interconnect EVPN

Trong một POD, khi cần mở rộng Layer2 thì chỉ cần mở rộng thêm Leaf. Nhưng khi số lượng Leaf quá lớn thì cũng có nghĩa là từng Leaf sẽ phải học các MAC+IP từ rất nhiều Leaf khác nhau, số lượng kết nối vật lý giữa Leaf và Spine cũng tăng lên đáng kể. Với DCI, Khi chia nhỏ thành nhiều POD thì các Leaf sẽ luôn chỉ học được MAC của các POD khác qua Super Spine (Có thể là Border Leaf tuỳ từng mô hình). Số lượng Super Spine của 1 POD thường chỉ 2 thiết bị và không quá nhiều.

Thứ 2, trong 1 POD thì VNI ID phải giống nhau cho một miền Layer2. Còn với DCI, thì mỗi POD sẽ quản lý phần VNI riêng, 2 VM thuộc 2 VLAN khác nhau, thuộc 2 VNI khác nhau ở 2 POD khác nhau có thể mở rộng Layer2 sang nhau qua 1 Interconnect VNI duy nhất. Việc SWAP VNI giữa 2 POD chỉ cần thực hiện trên các thiết bị Super Spine.

ECMP cho Underlay IP Fabric

Với những giao thức Tunneling, việc nhiều Host kết nối tới nhau nhưng lại được đóng gói từ cùng Leaf3 tới Leaf2 là bình thường. Lúc này nếu Underlay chỉ vận chuyển gói tin IP với cùng 1 Source và 1 Destination thì traffic luôn đi 1 đường với cơ chế Load Balance Per Flow. Nên nếu dựa vào UDP Port của bản tin VXLAN, thì Underlay Fabric có thêm 1 trường thông tin nữa là L4-Source Port để đưa vào Hashing, do đó Load Sharing được nhiều đường hơn và đều hơn. Ở đây lưu lượng thực tế của các Host đằng sau Leaf3 gửi tới các Host đằng sau Leaf2 luôn được đóng được đóng Tunnel VXLAN với Source IP 3.3.3.3 (Leaf3) tới Destination IP 2.2.2.2 (Leaf2) nhưng L4-Source Port sẽ liên tục thay đổi và dựa vào đó để ECMP trên nhiều đường.

Ngoài ECMP, nếu thiết kế Uplink Leaf-Spine gồm nhiều link vật lý Bundle vào 1 LACP Group thì LACP cũng sẽ sử dụng được L4-Source Port để làm input giúp Hashing đều hơn trên các Link vật lý đó => Tóm lại đóng gói thêm Layer4 Header UDP Port trước khi đóng gói VXLAN Header hỗ trợ các cơ chế cân bằng tải tốt hơn so với việc chỉ có giá trị VNI.

Công nghệ VXLAN còn rất nhiều thứ để tìm hiểu và đào sâu, nhưng cơ bản những cơ chế cốt lõi mình đã trình bày khá đầy đủ và chi tiết thông qua 3 phần của bài viết rồi. Các tài liệu của nhiều hãng lớn như Juniper, Cisco hay Arista, Huawei,... cũng public rất nhiều về công nghệ VXLAN này rồi, nhưng đều là tiếng anh. Hi vọng bài viết bằng tiếng Việt này của mình có thể giúp cả những anh em Newbie đang cần tìm hiểu về VXLAN dễ tiếp cận với công nghệ mới này hơn.