Khi thiết kế mạng, chúng ta thường phải cẩn thận trong việc thực hiện cấu hình cũng như là đấu nối thiết bị phù hợp. Những việc này sẽ giúp giảm thiểu các rủi ro sau này, cũng như là việc cập nhật các tính năng mới sau này trở nên dễ dàng hơn.
Tuy nhiên, trong số chúng ta vẫn thường vấp phải một số sai lầm trong lắp đặt mạng, vì thường chúng ta rất ít khi nào để ý tới. Đặc biệt trong mạng lớp 2. Trên thực tế, để mạng của chúng tôi hoạt động bình thường, một trong những điều kiện là không có lỗi nào xảy ra ở Lớp 2. Việc định cấu hình sai ở Lớp 2 có thể gây ra một số vấn đề, bao gồm sự suy giảm ngẫu nhiên trong hiệu suất mạng, sự cố của dịch vụ trên mạng, dữ liệu bị thất lạc đến các phân đoạn nhất định không hoạt động ổn định, hoặc thậm chí có thể dẫn đến mạng của chúng tôi không hoạt động chút nào.
Sau đây là tổng hợp các trường hợp lỗi cấu hình thường xảy ra ở lớp 2. Đặc biệt là trong Bridging and Switching trên thiết bị Mikrotik. Một số trường hợp bao gồm các cấu hình phổ biến, được sử dụng thường xuyên và ít phổ biến hơn có thể gây ra sự cố trên mạng của bạn.
Trường hợp 1. Sử dụng nhiều Bridge trên cùng một Switch Chip.
Trên bộ định tuyến Mikrotik (một số) hoặc bộ chuyển mạch Mikrotik được trang bị Switch Chip ( hay gọi chip chuyển mạch). Chức năng của chip này là cho phép giảm tải phần cứng trên bridge (Cầu). Và lưu lượng sẽ được chuyển đến chip này để giảm tải cho CPU. Hãy xem xét tình huống sau, bạn có một bộ chuyển mạch Mikrotik, có chip chuyển đổi tích hợp và bạn cần tạo ra nhiều hơn một bridge, vì lý do này, bạn đã tạo nhiều bridge và kích hoạt tính năng giảm tải phần cứng trên chúng. Vì mỗi bridge nằm trên một miền Layer2 khác nhau, nên các frame Layer2 sẽ không được chuyển tiếp giữa các bridge này, do đó, các cổng trong mỗi bridge bị cô lập với các cổng khác trên một bridge khác.
Cấu hình sẽ như thế này. /interface bridge add name=bridge1 add name=bridge2 /interface bridge port add bridge=bridge1 interface=ether1 add bridge=bridge1 interface=ether2 add bridge=bridge2 interface=ether3 add bridge=bridge2 interface=ether4
Hậu quả Sau một khoảng thời gian, bạn nhận thấy rằng một bridge chuyển tiếp lưu lượng truy cập ở tốc độ tối đa, trong khi bridge thứ hai, thứ ba, v.v. không thể chuyển tiếp dữ liệu ở tốc độ tối đa như bridge đầu tiên. Một triệu chứng khác nữa là một số gói tin truyền tải trong mạng có độ trễ cao. Sau khi kiểm tra nhanh, bạn nhận thấy rằng CPU luôn ở trạng thái tải đầy, điều này là do tính năng giảm tải phần cứng không khả dụng trên tất cả các bridge mà chỉ khả dụng trên một bridge duy nhất. Bằng cách kiểm tra trạng thái các giao diện trong bridge, bạn sẽ nhận thấy rằng chỉ có một bridge có hoạt động với giảm tải phần cứng (Cờ H):
Giải pháp Bởi vì giảm tải phần cứng chỉ có thể được kích hoạt trên 1 bridge, do đó chúng ta có thể chỉ giảm tải phần cứng đến bridge1 thì bridge2 sẽ được chuyển đến CPU vì nó không sử dụng phần cứng giảm tải đồng thời. Nếu chúng ta thực sự cần hai phân đoạn khác nhau trong cùng một chip giảm tải, chúng ta có thể sử dụng các bộ chuyển mạch đã hỗ trợ cách ly cổng (Port Isolation), chẳng hạn như thiết bị dòng CRS1xx / CRS2xx. Hoặc xây dựng hệ thống với một giải pháp thay thế, chúng tôi có thể triển khai các VLAN trong những phân đoạn mạng này.
Trường hợp 2. Sử dụng Packet Flow trong Hardware Offling với MAC Learning.
Dễ thấy nhất trong trường hợp này là việc do thám/phân tích các dữ liệu trong mạng, trong khi vẫn sử dụng tối đa hiệu suất của giảm tải phần cứng. Bạn có một bridge và đã bật giảm tải phần cứng để đạt được thông lượng tối đa. Và thiết bị đó của bạn đã hoạt động như một switch thông thường, nhưng bạn muốn sử dụng kèm theo các công cụ Sniffer hoặc Torch cho mục đích gỡ lỗi mạng hoặc có thể bạn muốn lưu lại toàn bộ các nhật ký mà gói đi qua giao diện đó.
Cấu hình sẽ trông như thế này. /interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 hw=yes interface=ether1 learn=yes add bridge=bridge1 hw=yes interface=ether2 learn=yes
Hậu quả Khi chạy các công cụ Sniffer hoặc Torch để thu thập các gói, bạn có thể nhận thấy rằng hầu như không có bất kỳ gói nào thu được cả, chỉ một số gói unicast, nhưng chủ yếu là các gói quảng bá / đa hướng được ghi lại, trong khi các giao diện khác vẫn có rất nhiều lưu lượng lớn đang hoạt động. Kể từ RouterOS v6.41 nếu bạn thêm hai hoặc nhiều giao diện Ethernet vào một cầu nối và bật giảm tải phần cứng , thì chip chuyển đổi sẽ được sử dụng để chuyển tiếp các gói giữa các cổng với nhau mà thôi. Để hiểu tại sao bạn chỉ bắt được một số gói, trước tiên chúng ta xem qua sơ đồ khối bo mạch, cách mà chip chuyển mạch kết nối với CPU, trong ví dụ này, chúng ta có thể sử dụng sơ đồ khối từ bộ chuyển mạch có 5 cổng Ethernet:
Đối với thiết bị trên dựa trên sơ đồ phía trên, mỗi cổng Ethernet được kết nối với Chip chuyển mạch và chip chuyển đổi được kết nối với CPU bằng cổng CPU (hay thường được gọi là cổng chuyển mạch-cpu). Để các công cụ Sniffer hoặc Torch có thể nhìn thấy các gói tin , gói tin đó phải được di chuyển từ cổng Ethernet đến cổng CPU, theo nghĩa là đích của gói phải là cổng CPU đó (địa chỉ MAC của đích của gói phải khớp với địa chỉ Mac của bridge) hoặc địa chỉ mac của gói không được nhận dạng trong bảng host của bridge.
Chip chuyển mạch lưu giữ một danh sách các địa chỉ MAC và các cổng, lưu trữ ở bảng Host (Menu Bridge - Host) · Bất cứ khi nào một gói tin cần được chuyển tiếp, chip chuyển mạch sẽ kiểm tra địa chỉ MAC đích của gói tin so với bảng host này để tìm cổng tương ứng để chuyển tiếp gói tin. Nếu chip chuyển mạch không thể tìm thấy địa chỉ MAC đích, thì gói tin sẽ bị tràn vào tất cả các cổng (bao gồm cả cổng CPU). Trong các tình huống này, ví dụ: gói tin di chuyển từ ether1 đến ether2 và địa chỉ MAC của máy chạy công cụ Sniifer ở đằng sau ether2, thì gói tin đó sẽ không bao giờ được gửi đến CPU và do đó Sniffer sẽ không hiển thị được.
Giải pháp Trừ khi gói tin không có trong bảng host, gói tin được chuyển tiếp đến tất cả các cổng và cổng CPU. Đối với trường hợp này, chúng ta cần thêm một quy tắc mới làm quy tắc chuyển đổi hoặc thêm vào ACL. Thực tế, cách này sao chép trực tiếp gói tin hoặc chuyển hướng chúng đến CPU. Sau đó, bạn có thể phân tích gói bằng Sniffer hoặc Torch. Dưới đây là ví dụ về cách cấu hình để gửi một bản sao của gói tin dành cho địa chỉ mac = 4C:5E:0C:4D:12:4B (Trong đó, địa chỉ MAC 4C:5E:0C:4D:12:4B là địa chỉ MAC của máy tính cần đọc gói tin) /interface ethernet switch rule add copy-to-cpu=yes dst-mac-address=4C:5E:0C:4D:12:4B/FF:FF:FF:FF:FF:FF ports=ether1 switch=switch1 Chú ý: Nếu gói tin gửi đến CPU, thì gói đó phải được xử lý bởi CPU, điều này làm tăng tải của CPU.
Trường hợp 3. Sử dụng LACP và cân bằng tải trên các giao diện.
Hãy xem xét tình huống sau, bạn tạo một giao diện LAG để tăng tổng băng thông giữa 2 bộ chuyển mạch (hoặc giữa 2 node mạng). Ngay sau đó, để đảm bảo rằng giao diện LAG hoạt động bình thường, bạn đã gắn hai máy chủ truyền dữ liệu, và sử dụng công cụ kiểm thử, phổ biến nhất là công cụ đo hiệu suất mạng nổi tiếng https://en.wikipedia.org/wiki/Iperf. Ví dụ: bạn có thể đã tạo giao diện LAG từ hai cổng Gigabit Ethernet, cung cấp cho bạn giao diện tổng hợp lên tới 2Gbps trong khi các máy chủ được kết nối bằng giao diện 10Gbps, ví dụ: cổng SFP+ trên dòng sản phẩm CRS326-24G-2S+RM là một ví dụ.
Cấu hình sẽ trông như thế này. /interface bonding add mode=802.3ad name=bond1 slaves=ether1,ether2 /interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 interface=bond1 add bridge=bridge1 interface=sfp-sfpplus1
Hậu quả
Sau các thử nghiệm ban đầu, bạn ngay lập tức nhận thấy rằng thông lượng mạng của bạn không bao giờ vượt quá giới hạn 1Gbps mặc dù tải CPU trên các máy chủ vẫn thấp cũng như trên hai bộ chuyển mạch, nhưng thông lượng vẫn bị giới hạn ở mức chỉ 1Gbps. Lý do đằng sau điều này là vì LACP (802.ad) sử dụng chính sách băm để xác định xem lưu lượng có thể được cân bằng qua nhiều giao diện LAG hay không, trong trường hợp này, giao diện LAG tổng không tạo ra giao diện 2Gbps.
Trong trường hợp này, hàm băm là giống nhau vì bạn đang gửi các gói đến cùng một địa chỉ MAC đích, cũng như cùng một địa chỉ IP và Iperf cũng sử dụng cùng một cổng, điều này sẽ chỉ tạo ra cùng một băm truyền cho tất cả các gói, kết quả dĩ nhiên là tất cả các frames sẽ di chuyển qua một giao diện con mà thôi.
Lưu ý rằng không phải lúc nào các gói cũng được cân bằng qua các giao diện LAG mặc dù đích đến là khác nhau, điều này là do chính sách băm truyền tiêu chuẩn có thể tạo ra cùng một kết quả, dù cho các điểm đến khác nhau, ví dụ: 192.168.0.1/192.168.0.2 sẽ được cân bằng qua các giao diện con, nhưng 192.168.0.2/192.168.0.4 sẽ KHÔNG được cân bằng trong trường hợp chính sách băm truyền là sử dụng địa chỉ MAC đích giống nhau - layer2-and-3 .
Giải pháp
Chọn chính sách băm truyền phù hợp và kiểm tra thông lượng mạng của bạn đúng cách. Cách đơn giản nhất để kiểm tra các thiết lập như vậy là sử dụng nhiều máy chủ cùng lúc, thay vì chỉ sử dụng 2 máy chủ để kiểm tra, ví dụ: thay vì chỉ gửi dữ liệu đến một máy chủ, thay vì gửi dữ liệu đến nhiều máy chủ, điều này sẽ tạo ra nhiều băm truyền khác nhau cho mỗi gói và sẽ thực hiện cân bằng tải giữa các giao diện con LAG trong giao diện LAG tổng.
Ngoài ra, bạn cũng có thể thay đổi chế độ hoạt động trong LAG thông qua các chế độ mà Mikrotik hỗ trợ thêm, chẳng hạn, balance-rr ...
Trên thực tế có rất nhiều trường hợp có thể xảy ra khi thực hiện cấu hình một hệ thống mạng, đặc biệt là ở lớp 2 và lớp 3. Dù là lỗi vật lý hay lỗi cấu hình, chúng ta phải tinh ý và cẩn thận trong việc xây dựng cấu trúc liên kết mạng hiện có. Đồng thời kiểm tra một số thông số và cấu hình sót, có thể sẽ là là sự cố trên mạng trong tương lai. Bạn có thể xem một số thông tin tham khảo trên internet hoặc wiki.mikrotik.com để có được cấu hình lý tưởng nhất. Cũng cần chú ý đến cách đấu nối các giao diện và ánh xạ cổng... để tránh lặp lại trong mạng. Mikrotik đã có một số tính năng để tránh lặp mạng như Spanning Tree Protocol, Loop Protect, v.v. Đối với các cấu hình sai trên mạng VLAN, chúng ta sẽ thảo luận trong phần tiếp theo.