Thực hành tốt nhất cho sự kết hợp của HSRP và ECMP

Sự kết hợp giữa ECMP (hoặc các nguyên nhân khác của đường dẫn không đối xứng) và HSRP bị phá vỡ theo mặc định trong Cisco IOS; hành vi mặc định với thiết kế này tràn ngập lưu lượng truy cập unicast quá mức.

Cách thực hành tốt nhất để sử dụng HSRP với ECMP để ngăn chặn lũ lụt không xác định là gì?

Chi tiết / Bối cảnh

Chúng tôi có một cấu trúc liên kết HSRP tương tự như sơ đồ đầu tiên bên dưới cho nhiều cơ sở của chúng tôi. Các bộ định tuyến Cisco WAN của chúng tôi có các tuyến chi phí bằng nhau đến tất cả các trang web khác; do đó chúng ta có thể thấy các hiệu ứng định tuyến không đối xứng mọi lúc. Thông thường, chúng tôi chỉ định R1 là HSRP chính, nhưng ECMP cho phép lưu lượng truy cập trở lại thông qua R1 hoặc R2.

Vấn đề là khi PC1 gắn ổ iSCSI từ xa qua mạng WAN, lưu lượng truy cập rời khỏi trang web qua R1, nhưng có thể quay lại qua R2. Miễn là lưu lượng iSCSI trả về qua R1, không có vấn đề gì.

Sự cố xảy ra khi lưu lượng của PC1 trở lại qua R2. Giả sử phiên iSCSI bắt đầu lúc 8:00:00 và cả hai bộ định tuyến và cả hai thiết bị chuyển mạch đều học mac của PC1. Từ 8:00:00 đến 8:00:05, không có vấn đề ngập lụt vì cả hai thiết bị chuyển mạch vẫn có địa chỉ mac của PC1 trong bảng CAM của chúng.

Năm phút sau khi phiên iSCSI bắt đầu, mục nhập CAM của PC cho mac của PC1 hết hạn khỏi bảng CAM và S2 tràn vào lưu lượng của PC1 trong tất cả các cổng (trong trường hợp này là Po1, Gi0 / 3 và Gi0 / 4). Nếu phiên iSCSI của PC1 tiêu tốn nhiều băng thông, thì lũ unicast không xác định này có thể hút dung lượng không tầm thường từ các liên kết đến PC3 và PC4.

Thiết bị chuyển mạch Cisco IOS có bộ hẹn giờ CAM mặc định là 300 giây ...

S2# show mac address-table aging-time
Vlan Aging Time
---- ----------
1    300
17   300

Tuy nhiên, bộ đếm thời gian ARP giao diện mặc định của Cisco IOS là 4 giờ ...

R2# show interface gi0/0
GigabitEthernet0/0 is up, line protocol is up 
  Hardware is AmdP2, address is 000a.dead.beef (bia 000a.dead.beef)
  Internet address is 172.17.1.252/24
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  ARP type: ARPA, ARP Timeout 04:00:00       <--------------

Do đó, S2 bắt đầu làm ngập lưu lượng iSCSI của PC1 sau năm phút.

Câu trả lời đơn giản là làm cho bộ định thời CAM bằng hoặc dài hơn một chút so với bộ hẹn giờ ARP giao diện tương ứng , nhưng có ít nhất ba tùy chọn khác nhau để chọn từ ...

Tùy chọn 1: Hạ thấp tất cả các bộ đếm thời gian ARP giao diện

Tùy chọn này hoạt động tốt nhất nếu bạn có mạng chuyển đổi layer2 có kích thước phù hợp, số lượng mục ARP hợp lý và một vài giao diện được định tuyến. Phương pháp này cũng thích hợp hơn nếu bạn muốn thấy các mục PC mac bị loại khỏi cấu trúc liên kết một cách nhanh chóng.

• Trên tất cả các giao diện ethernet IOS phải đối mặt với một chuyển đổi ethernet: arp timeout 240
• Trên tất cả các giao diện ethernet IOS phải đối mặt với chuyển đổi ethernet: hold-queue 200 invà hold-queue 200 outđể tránh làm rơi các gói ARP trong quá trình làm mới ARP định kỳ (các giới hạn này có thể cao hơn hoặc thấp hơn tùy thuộc vào số lần làm mới ARP mà bạn nghĩ rằng bạn sẽ cần xử lý cùng một lúc). Nếu bạn đang điều chỉnh các giá trị Loại bỏ gói chọn lọc , thì bạn nên làm theo các hướng dẫn trong bài báo tôi liên kết.

Điều này buộc Cisco IOS phải làm mới bảng ARP trong vòng bốn phút, nếu điều đó không xảy ra nếu không có mục ARP cụ thể. Nhược điểm rõ ràng là điều này không mở rộng tốt nếu bạn có nhiều mục ARP ... các giới hạn khác nhau tùy theo nền tảng. Tôi đã sử dụng điều này với vài trăm ARP trên mỗi bộ định tuyến trên Catalyst 4500/6500 (SVI lớp 3) mà không gặp vấn đề gì.

Tùy chọn 2: Tăng công tắc hẹn giờ CAM

Tùy chọn này hoạt động tốt nhất nếu bạn có số lượng lớn các mục ARP (ví dụ: hàng ngàn, chẳng hạn như môi trường VMWare cường độ cao có thể thấy).

• Trên tất cả các thiết bị chuyển mạch iOS : mac address-table aging-time 14400, hoặc mac address-table aging-time 14400 vlan <vlan-id>cho bất kỳ Vlan nào đáng quan tâm.

Thay đổi này điều chỉnh bộ hẹn giờ mà hầu hết mọi người cho là cố định ở mức 300 giây (trên Cisco IOS), do đó hãy chắc chắn đưa điều này vào các tài liệu liên tục. Tác dụng phụ của việc này là các mục trong bảng CAM nán lại trong 4 giờ sau khi PC bị xóa (có thể là tốt hoặc xấu, tùy thuộc vào PoV của bạn). Nếu 4 giờ quá dài, hãy xem tùy chọn tiếp theo ...

Tùy chọn 3: Thay đổi cả bộ định thời ARP giao diện và công tắc Bộ hẹn giờ CAM

Tùy chọn này tránh các bộ định thời CAM dài vô cùng trong Tùy chọn 2 với chi phí cấu hình cao hơn. Bạn có thể chọn xem bạn cần 900 giây, 1800 giây hay bất cứ điều gì ... chỉ cần đảm bảo bộ định thời CAM và ARP của bạn khớp với nhau; do đó, bạn sẽ cần định cấu hình cả Tùy chọn 1 và Tùy chọn 2 trong cấu trúc liên kết của mình.

Đối với tôi, ECMP là vấn đề thực sự ở đây - vì vậy ngoài các bước trên để hạn chế lũ lụt không xác định, bạn cũng có thể điều chỉnh các số liệu tuyến đường về mạng WAN để R1 được ưu tiên hơn R2 cho lưu lượng truy cập trở lại. Một cách để đạt được điều này là thông qua danh sách phân phối trên R2 như sau: (Chỉ sử dụng EIGRP, có thể đạt được điều tương tự với OSPF hoặc BGP với các lệnh khác)

!
tiền tố ip-list R1-PREAX seq 5 cho phép 172.17.1.0/24
!
bản đồ lộ trình R1-TRƯỚC-MAP cho phép 10
 phù hợp với địa chỉ IP tiền tố-danh sách R1-TRƯỚC
 đặt số liệu 1 1 1 1 1
... (cho phép tất cả các tuyến khác)
!
bộ định tuyến eigrp 1
 ....
 phân phối danh sách lộ trình bản đồ R1-PREAX-MAP ra Ser1 / 0
 ....
!

Điều này sẽ dẫn đến việc mạng LAN chuyển tiếp tất cả lưu lượng truy cập từ 172.17.1.0 sang R1. Nếu R1 Se1 / 0 không thành công, tuyến đường sẽ được cài đặt về phía R2. Bạn có thể điều chỉnh thêm các số liệu này để tuyến dự phòng đến R2 thực sự là một kế thừa khả thi để chuyển đổi dự phòng nhanh hơn. HSRP và theo dõi sẽ chăm sóc lưu lượng đi ra.

Ý tưởng nếu không sử dụng ECMP nếu HSRP đang được sử dụng có thể được chấp nhận cho các DỊCH VỤ nơi lưu lượng truy cập có thể cao hơn lưu lượng truy cập, trong tình huống PC IN lưu lượng truy cập vào từ mạng (phản hồi) cao hơn lưu lượng truy cập đi vào (xâm nhập). Chúng tôi thích hầu hết mọi người chỉ cần đặt bộ hẹn giờ ARP. bạn có thể gây rối với bộ định thời CAM NHƯNG nếu bạn nói rằng máy có công tắc lớp 3 và IDF có 2 công tắc bộ sưu tập và nói 5 công tắc truy cập, đó là một công cụ dễ dàng hơn để định cấu hình trên L3 SVI so với thực hiện tất cả các công tắc truy cập.

Người ta có thể sử dụng một chồng các công tắc để giảm thiểu vấn đề này khi hết hạn nhập địa chỉ MAC trong công tắc thứ hai.

Ah, tôi nhớ cái này Nhiều tuần vui vẻ đã giải quyết việc này một vài công việc trước đây. Một điều khó chịu là các sự kiện STP sẽ đưa vlans vào chế độ lão hóa nhanh, do đó, việc đặt bộ hẹn giờ MAC lâu hơn bộ hẹn giờ ARP không giúp ích gì

Tôi đã giải quyết vấn đề bằng cách buộc ECMP trở lại từ các máy chủ, bằng cách tạo hai cổng HSRP nổi, với một cổng chính trên mỗi bộ định tuyến. Sau đó chúng tôi cấu hình cả hai cổng trên mỗi máy chủ. Bằng cách buộc lưu lượng máy chủ lưu trữ cho cả R1 và R2 theo cách này, chúng tôi sẽ chắc chắn rằng R2 sẽ không bao giờ bị lỗi địa chỉ MAC.

Lý tưởng nhất, điều này sẽ không thành vấn đề nếu L2 / 3 chuyển các mục ARP bị xóa liên quan đến các địa chỉ MAC đã cũ. Gói tiếp theo tới IP sau đó sẽ dẫn đến một yêu cầu ARP mới, điền vào cả bộ đệm ARP và bảng MAC. Tôi nghĩ rằng Cisco cuối cùng đã thực hiện điều này, nhưng tôi không thể chắc chắn.

Tóm tắt: MC-LAG hoặc HSRP GARP

Tôi chưa bao giờ là một fan hâm mộ của bộ điều chỉnh thời gian. Bộ hẹn giờ được đặt theo một cách nhất định thường vì nhiều lý do. Thay đổi chúng:

• có khả năng hoạt động chuyên sâu để duy trì mọi nơi như nhau
• làm cho mọi thứ phức tạp hơn và khó khắc phục sự cố
• như một bình luận gần đây cho thấy, có thể có tác dụng phụ không mong muốn
• có thể không "chơi đẹp" với các cải tiến của Cisco trong tương lai

Luân phiên:

1. Sử dụng MC-LAG (còn gọi là "MEC" trong tài liệu của Cisco). Đây là tùy chọn tốt nhất của bạn, mặc dù bạn nên hiểu các kịch bản triển khai có thể sử dụng MC-LAG (đây không phải là giải pháp phổ quát và chỉ nên được triển khai sau khi nghiên cứu và thử nghiệm thích hợp). Các biến thể MC-LAG phụ thuộc vào phần cứng. Ví dụ là:

   a. Xếp chồng (Cát 3k)

   b. VSS (Cat4k / 6k)

   c. VPC (Nexus)

   d. Giả giả mLACP (ASR1k)

   e. MC-LAG (ASR9k)

   f. Phân cụm (ASA)

2. Cho phép HSRP gửi định kỳ các gói ARP miễn phí . Cấp, điều này tương tự như thay đổi bộ định thời, nhưng đó là một sự thay đổi duyên dáng hơn nhiều so với thao tác với bảng CAM và bộ định thời ARP. (Lưu ý rằng điều này phụ thuộc vào sự kết hợp phần cứng và phần mềm của bạn, không phải tất cả các triển khai HSRP đều cung cấp điều này.)

   Theo mặc định, HSRP gửi 3 Gkv, ở 0, 2 và 4 giây sau khi bộ định tuyến trở thành cổng chuyển tiếp. Tuy nhiên, có một tham số cấu hình cho phép bạn chọn số lượng Gkv (bao gồm cả "vô hạn") và khoảng thời gian.

Tôi sử dụng MC-LAG khá nhiều, đặc biệt là VSS, VPC và Clustering (Tôi không phải là người thích xếp chồng).

Trường hợp tôi không thể sử dụng MC-LAG hoặc GLBP, đây là những gì tôi áp dụng cho các bộ định tuyến ranh giới L2 / L3 trong khuôn viên của mình (Tôi có khuôn viên 350 tòa nhà nên tôi sử dụng Cat6k khá nhiều):

Cat6k-v15(config)#interface vlan 100
Cat6k-v15(config-if)#standby arp ?
  gratuitous  Setup gratuitous ARP interval and count

Cat6k-v15(config-if)#standby arp gratuitous ?
  count     Set HSRP gratuitous ARP count
  interval  Set HSRP gratuitous ARP interval
  <cr>

Cat6k-v15(config-if)#standby arp gratuitous count ?
  <0-60>  Number of gratuitous ARPs to send after group is activated (0 for continuous)

Cat6k-v15(config-if)#standby arp gratuitous count 0 ?
  count     Set HSRP gratuitous ARP count
  interval  Set HSRP gratuitous ARP interval
  <cr>

Cat6k-v15(config-if)#standby arp gratuitous count 0 interval ?
  <3-1800>  Gratuitous ARP Interval (sec)

Cat6k-v15(config-if)#standby arp gratuitous count 0 interval 60 ?
  count     Set HSRP gratuitous ARP count
  interval  Set HSRP gratuitous ARP interval
  <cr>

Cat6k-v15(config-if)#standby arp gratuitous count 0 interval 60 

(Tôi sẽ đăng các tài liệu tham khảo cho tất cả những điều này, nhưng tôi không có "danh tiếng" đủ cao trên trang web này để đăng nhiều hơn hai URL.)