Được rồi - đã chiến đấu với điều này trong ít nhất 20 giờ liên tục .. Xin lỗi nếu điều này có vẻ như là một bài hát dài, hoặc một bài đăng trên blog, nhưng tôi đang đến mức kiệt sức.
Vì vậy, đây là thỏa thuận. Chúng tôi đang sử dụng bộ cân bằng tải KEMP, người sử dụng UCpeg (bản sao CARP của Linux, là bản sao VRRP) cho nhịp tim HA và trạng thái bền bỉ. Chúng tôi muốn sử dụng IGMP trong môi trường của chúng tôi để ngăn chặn lũ lụt trên trung tâm dữ liệu.
Chúng tôi có hai công tắc Dell PowerConnect 8124F chạy SW 5.1.1.7 hoạt động như một thiết bị hàng đầu. Hai cái này được kết nối với một cặp Cisco 3750-X xếp chồng, là lõi của chúng tôi.
Các vấn đề bắt đầu khi chúng tôi nâng cấp lên PowerConnect 5.1.x, nơi chúng dường như được mặc định để IGMP rình mò trừ khi bạn nói khác. Và kìa - bộ cân bằng tải của chúng tôi đã đi vào não bộ, gây ra tất cả các loại vui vẻ mờ nhạt ấm áp.
- Nếu tôi tắt IGMP rình mò trên Vlan nơi các bộ cân bằng tải thực hiện phát đa hướng thì không có gì xảy ra, phát đa hướng vẫn chết
- Nếu tôi thiết lập IP PIM trên lõi của chúng tôi, các công tắc PowerConnect sẽ thấy nó trên cùng một Vlan, nhưng vẫn không có lưu lượng phát đa hướng
- Nếu tôi cho phép làm ngập tất cả lưu lượng truy cập phát đa hướng chưa đăng ký, nó vẫn không làm gì cả.
- Nếu tôi tắt IGMP rình mò trên toàn cầu trên các công tắc PowerConnect, tất cả lưu lượng truy cập phát đa hướng đều hoạt động. Nó hoạt động rất tuyệt vời, đến nỗi chúng tôi nhận được lưu lượng truy cập phát đa hướng đến mọi cổng duy nhất có cùng Vlan được gắn thẻ. Tuyệt vời.
Tôi nhận thấy một số mục địa chỉ MAC lạ trên Vlan ở lõi của chúng tôi:
coresw#sh mac address-table vlan 367 | include 5e00
367 0000.5e00.0101 DYNAMIC Po13 seq_no:0
Và tôi nghĩ rằng .. Không phải đó là địa chỉ multicast sao? Tại sao điều này không có trong "multicast bảng địa chỉ sh mac"?
coresw#sh mac address-table multicast vlan 367
Vlan Mac Address Type Ports
---- ----------- ---- -----
coresw#
Và sau đó tôi đọc phần này trong hướng dẫn PowerConnect CLI:
Lưu lượng truy cập đa luồng là lưu lượng được dành cho một nhóm máy chủ. Các nhóm máy chủ được xác định bởi địa chỉ MAC đích, tức là phạm vi 01: 00: 5e: 00: 00-01: 00: 5e: 7f: ff: ff: ff cho lưu lượng truy cập phát đa hướng IPv4 hoặc 33: 33: xx: xx : xx: xx cho lưu lượng phát đa hướng IPv6.
Có vẻ như chúng ta đang thiếu "01" ở đầu địa chỉ MAC, phải không? Mục MAC động ở trên bắt đầu bằng "00". Tại thời điểm này tôi đang suy nghĩ về việc gọi KEMP và cho họ biết rằng sản phẩm của họ bị định cấu hình khủng khiếp. Nhưng sau đó tôi đi đọc RFC cho VRRP - và kìa:
Địa chỉ MAC của bộ định tuyến ảo được liên kết với bộ định tuyến ảo là Địa chỉ MAC của IEEE 802 theo định dạng sau:
Trường hợp IPv4: 00-00-5E-00-01- {VRID} (ở dạng hex, theo thứ tự bit chuẩn Internet)
Được rồi - vì vậy các công tắc thường không nhận dải địa chỉ mac phát đa hướng cho VRRP. Tốt thôi, hãy cấu hình một nhóm máy chủ tĩnh trên các thiết bị chuyển mạch Dell. Không.
Đầu vào không hợp lệ: Địa chỉ MAC Multicast phải có định dạng 01XX: XXXX: XXXX
OK rồi .. Bước tiếp theo, hãy thử thêm một mục mac tĩnh:
osl-sys-swrack03(config)#mac address-table multicast ?
forbidden forbid adding specific multicast addresses to
specific ports.
osl-sys-swrack03(config)#
Vì vậy - không có cách nào để định cấu hình mục MAC đa hướng tĩnh. Nếu tôi cố gắng làm tương tự với một mục MAC tĩnh thông thường, tôi chỉ có thể liên kết nó với một cổng - cụm cân bằng tải này chạy trên 4 cổng 10gig khác nhau.
Cập nhật : Dường như có một số nhầm lẫn về địa chỉ MAC. 172.30.1.0/24 là mạng loadbalancer phía trước. 172.30.1.6 là VIP được chia sẻ mặc định cho cụm, .7 là IP quản lý cho bộ cân bằng tải đầu tiên và .8 dành cho bộ cân bằng tải thứ hai. Tất cả các địa chỉ khác (30, 40, 70, 80, v.v.) đều là VIP với các dịch vụ khác nhau trên đó. Khi chuyển đổi dự phòng xảy ra, tất cả các VIP sẽ thay đổi địa chỉ MAC của họ thành địa chỉ MAC vật lý của LB thứ hai. Địa chỉ multicast trong bảng dưới cùng không thay đổi.
coresw#sh ip arp vlan 367
Protocol Address Age (min) Hardware Addr Type Interface
Internet 172.30.1.6 78 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.40 204 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.80 167 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.70 38 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.66 12 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.35 185 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.60 97 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.30 80 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.61 33 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.7 27 0050.56b4.5004 ARPA Vlan367 <- Management - Loadbalancer1 physical MAC
Internet 172.30.1.8 21 0050.56b4.08c2 ARPA Vlan367 <- Management - Loadbalancer2 physical MAC
osl-sys-coresw#sh mac address-table dynamic vlan 367
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
367 0000.5e00.0101 DYNAMIC Po13 seq_no:0 <- multicast HA mac (UCARP)
367 0050.56b4.08c2 DYNAMIC Po13 seq_no:0 <- Loadbalancer1 physical MAC
367 0050.56b4.5004 DYNAMIC Po13 seq_no:0 <- Loadbalancer2 physical MAC
Và đó là câu chuyện. Tôi sẽ làm gì với điều này?
What on earth am I going to do with this?<- Tequila. Rất nhiều của nó.