Chúng tôi là nhà cung cấp dịch vụ được quản lý điều hành một mạng có kích thước nhỏ trong một trung tâm dữ liệu duy nhất ở Sydney. Gần đây chúng tôi đã triển khai một liên bang POP mới ở Melbourne (cả hai đều ở bờ biển phía đông Australia) và lần đầu tiên tôi phải đối mặt với những thách thức trong thế giới thực về kỹ thuật giao thông. Hy vọng của tôi là tôi có thể nhận được một số hướng dẫn ở đây về cách có được một số mức độ kiểm soát đối với các đường dẫn iBGP của tôi.
Tôi có thể sẽ đăng một vài câu hỏi liên quan đến nhau, nhưng trong trường hợp này tôi đặc biệt quan tâm đến kỹ thuật giao thông nội bộ. Tôi thấy rất khó để tìm ra cách để iBGP đưa ra quyết định định tuyến tối ưu.
Mục tiêu chính đối với tôi là cần tìm cách cung cấp cho iBGP một số khái niệm về ranh giới và khoảng cách trên mỗi POP. Vì vậy, tôi có thể phân biệt giữa một POP ở cùng thành phố, với một quốc gia liên bang, với một quốc gia nằm ở phía đông so với bờ biển phía tây. Sau đó tối ưu hóa định tuyến trong / ngoài nước dựa trên điều này.
Tôi biết rằng sẽ có rất nhiều tình huống tùy trường hợp, nhưng tôi hy vọng tôi có thể phát triển chiến lược định tuyến iBGP có thể hoạt động được 80% thời gian và phần còn lại tôi sẽ phải xử lý các trường hợp cạnh đặc biệt trong cấu hình.
Bối cảnh
- Chúng tôi vừa mua 4x ASR 1001-X để hoạt động như các thiết bị cạnh của chúng tôi ở mỗi POP (gấp đôi trên mỗi POP nhưng do chuyển đổi giới hạn phần cứng nên hiện tại tôi chỉ tập trung triển khai thiết bị 1 cạnh ở Melbourne)
- Chúng tôi cũng sử dụng Juniper để chuyển đổi phần cứng. EX4500 là "công tắc lõi" và EX4200 của chúng tôi ở lớp truy cập.
- Bây giờ chúng tôi có nhà cung cấp quá cảnh gấp 2 lần. Chúng tôi chỉ kết nối với mỗi nhà cung cấp ở mỗi tiểu bang.
- AS 1000 là một công cụ tổng hợp và sử dụng AS 4000 như một trong những thượng nguồn chính của nó ở Sydney.
- Điều này đặt ra một chút thách thức vì tất cả các đường dẫn nhận được thông qua AS 1000 thường dài hơn 1 so với những đường chúng ta nhận được từ AS 4000.
- Tôi đang sử dụng Ansible để tạo cấu hình IOS bằng các mẫu Jinja2. Vì vậy, không phải là vấn đề để tạo ra nhiều logic trên bản đồ tuyến ngang hàng của iBGP để hoàn thành công việc.
Mục tiêu của tôi
Về cơ bản, tôi muốn có thể đạt được định tuyến tối ưu giữa các POP khi chúng tôi triển khai chúng. Nhưng hiện tại tôi không thể đạt được bất kỳ mức độ kiểm soát nào đối với cách iBGP đang chọn đường dẫn của nó.
Thiết kế hiện tại của tôi
- Tôi hiện có 2 ASR1K hoạt động như các bộ định tuyến biên với các bảng đầy đủ ở Sydney và một ở Melbourne.
- Cả hai POP đều sử dụng các nhà cung cấp dịch vụ vận chuyển khác nhau.
- Chúng tôi có một mạch điểm tới điểm giữa hai POP được kết thúc ở cả hai phía bởi các thiết bị cạnh trên giao diện phụ dot1q.
- Chúng tôi chạy OSPF qua liên kết này giữa tất cả các thiết bị cạnh và chi phí của liên kết được tăng lên vì vậy đây là đường dẫn OSPF ưu tiên thấp nhất.
- Chúng tôi có một khu vực OSPF 0 duy nhất trên cả hai POP.
- Các thiết bị cạnh có nhiều lõi / cạnh hội tụ hơn - các công tắc lõi của chúng tôi không thực hiện nhiều L3 vì chúng không thể xử lý toàn bộ bảng.
- Trong mỗi POP, ASR1K hoạt động như bộ phản xạ tuyến đường cho các thiết bị BGP khác trong POP đó - tường lửa, công tắc lõi, LNS, v.v.
- Mỗi nhóm có ID cụm riêng - không phải mỗi POP. Tìm kiếm một sự thay đổi này thành per-POP.
- Mỗi ASR1K tạo ra một tuyến mặc định cho các máy khách phản xạ tuyến qua BGP.
- Tất cả các ASR1K đều nằm trong lưới iBGP.
- Tất cả các tuyến đều có cùng một địa phương pref tại tất cả các trang web.
Ví dụ về định tuyến phụ tối ưu
- Nếu tôi có Melbourne và Sydney chuyển tuyến tất cả trực tuyến, định tuyến đi ra hoạt động tốt. Lối ra giao thông Sydney qua Sydney và Melbourne thoát qua Melbourne.
- Vấn đề là chỉ bằng cách vô hiệu hóa quản trị viên quá cảnh Sydney chính của tôi, quá cảnh tại Melbourne của tôi bây giờ tự động được ưu tiên. Thay vì quá cảnh Sydney thứ cấp của tôi thông qua bộ định tuyến BDR02 ở Sydney.
- Vì vậy, tôi kết thúc với một kịch bản thường là nơi giao thông sau đó sẽ quay trở lại Melbourne qua tuyến đường của chúng tôi, lối ra ở Melbourne, sau đó tuyến đường trở lại Sydney. Đường dẫn phát sinh <1ms hiện tại khoảng 30 ms.
Để làm cho vấn đề tồi tệ hơn, trong kịch bản cụ thể này, tôi không thể hiểu tại sao Melbourne lại được ưa thích.
- Trọng lượng là giống hệt nhau
- Địa phương pref là giống hệt nhau
- Đường dẫn AS có cùng độ dài
- Không có con đường là tự bắt nguồn.
- Cả hai đều có IGP là nguồn gốc.
- Cả hai đều có số liệu (MED?) Là 0.
- Cả hai đều là đường dẫn iBGP từ phối cảnh của bộ định tuyến này.
- Số liệu IGP Tôi đã nghĩ có liên quan đến chi phí liên kết OSPF khi chúng tôi sử dụng OSPF làm IGP của chúng tôi.
- Tôi đã xác nhận băng thông tham chiếu 100G được đặt trên tất cả các thiết bị OSPF.
EDIT: 30/01: Tôi nghĩ rằng tôi đã sai về cách tính chi phí IGP và có lẽ chúng hiện tại giống nhau? Tất cả các tuyến OSPF của tôi là loại E2. Nếu chi phí IGP là như nhau thì tôi cho rằng việc lựa chọn đường dẫn tốt nhất sẽ xảy ra dựa trên RID, trong trường hợp này RID của MEL BDR sẽ thấp hơn SYD.
Tôi đã đặt chi phí liên kết OSPF giữa Sydney cao hơn 15.000 so với mặc định. Tôi đã tính toán điều này để hoạt động đáng tin cậy với băng thông tham chiếu 100 Gbps của chúng tôi.
Về chi phí liên kết OSPF - đây là tùy chọn OSPF của mỗi bước tiếp theo của các tuyến BGP:
bdr-01-syd#sh ip route x.x.201.73 (AS 4000 next hop)
Routing entry for x.x.201.72/30
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 15000
Last update from x.x.13.51 on Port-channel1.1125, 14:57:17 ago
Routing Descriptor Blocks:
* x.x.13.51, from x.x.13.66, 14:57:17 ago, via Port-channel1.1125
Route metric is 20, traffic share count is 1
bdr-01-syd#
bdr-01-syd#sh ip route x.x.31.5 (AS 1000 next hop)
Routing entry for x.x.31.4/30
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 5
Last update from x.x.216.67 on Port-channel1.36, 1d00h ago
Routing Descriptor Blocks:
* x.x.216.67, from x.x.216.163, 1d12h ago, via Port-channel1.36
Route metric is 20, traffic share count is 1
bdr-01-syd#
x.x.201.73 is the next hop to 139.130.4.4 via the Melbourne path.
x.x.13.51 is the other end of the inter-state Point to Point. x.x.13.66 is BDR-01-MEL.
x.x.31.5 is the next hop to 139.130.4.4 via the Secondary Sydney transit in the same POP as the primary transit - via BDR-02-SYD.
x.x.216.67 is the local OSPF VLAN for the Sydney POP that both BDR01 and BDR02 are in.
x.x.216.163 is the BDR-02-SYD router.
Xét về các lựa chọn OSPF này, tôi có thể thấy "số liệu chuyển tiếp" ngắn hơn được chọn. Tôi đã nghĩ rằng BGP nên chọn con đường Sydney dựa trên điều này.
Bạn có thể thấy từ dấu vết này rằng chúng tôi ngay lập tức nhảy tới Melbourne thông qua Backhaul vì bước nhảy đầu tiên là 13ms: (139.130.4.4 được phát sóng và có đường dẫn ở cả hai tiểu bang).
bdr-01-syd#traceroute 139.130.4.4
Type escape sequence to abort.
Tracing the route to 139.130.4.4
VRF info: (vrf in name/id, vrf out name/id)
1 x.x.13.51 13 msec 13 msec 13 msec
2 x.x.201.73 14 msec 14 msec 14 msec
3 x.x.196.54 [AS 4000] [MPLS: Label 25049 Exp 0] 14 msec 14 msec 14 msec
4 x.x.196.51 [AS 4000] 14 msec 14 msec 14 msec
5 139.130.110.29 [AS 1221] 14 msec 15 msec 14 msec
6 203.50.11.113 [AS 1221] 16 msec 14 msec 16 msec
7 139.130.4.4 [AS 1221] 13 msec 14 msec 14 msec
bdr-01-syd#
bdr-01-syd#sh ip route 139.130.4.4
Routing entry for 139.130.0.0/16
Known via "bgp 5000", distance 200, metric 0
Tag 4000, type internal
Last update from x.x.201.73 06:06:14 ago
Routing Descriptor Blocks:
* x.x.201.73, from x.x.13.66, 06:06:14 ago
Route metric is 0, traffic share count is 1
AS Hops 2
Route tag 4000
MPLS label: none
bdr-01-syd#
bdr-01-syd#sh ip bgp regexp ^1000 1221$
BGP table version is 11307146, local router ID is x.x.216.161
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
...
* i 139.130.0.0 x.x.31.5 0 100 0 1000 1221 i
...
Versus the path via AS 4000:
bdr-01-syd#sh ip bgp regexp ^4000 1221$
*>i 138.130.0.0 x.x.201.73 0 100 0 4000 1221 i
bdr-01-syd#
Trong sản phẩm này, cả quá cảnh thứ cấp ở Sydney đều là đường dẫn hợp lệ và quá cảnh tại Melbourne cũng vậy. Melbourne được chọn là tốt nhất.
bdr-01-syd#sh ip bgp 139.130.4.4
BGP routing table entry for 139.130.0.0/16, version 10794227
Paths: (2 available, best #2, table default)
Advertised to update-groups:
66
Refresh Epoch 1
1000 1221, (received & used)
x.x.31.5 (metric 20) from x.x.216.163 (x.x.216.163)
Origin IGP, metric 0, localpref 100, valid, internal
Community: 1000:65110 5000:1000 5000:1001 5000:1002
rx pathid: 0, tx pathid: 0
Refresh Epoch 2
4000 1221, (received & used)
x.x.201.73 (metric 20) from x.x.13.66 (x.x.13.66)
Origin IGP, metric 0, localpref 100, valid, internal, best
Community: 4000:5307 4000:6100 4000:53073 5000:1000 5000:1030 5000:1031
rx pathid: 0, tx pathid: 0x0
bdr-01-syd#
Những gì tôi đã thử
Tôi đã thử thêm chi phí liên kết OSPF là 15.000 mà tôi đã tính là một con số an toàn dựa trên băng thông ref 100 Gbps của mình vì luôn luôn là chi phí OSPF ít được ưu tiên nhất. Tôi nghĩ rằng điều này sẽ được tính là "chi phí IGP" và BGP vẫn thích con đường Melbourne vì một số lý do.
Sau khi điều này dường như không có bất kỳ tác động nào, kế hoạch chính của tôi là sử dụng tiền thưởng AS PATH trên iBGP. Kế hoạch là tôi sẽ có các nhóm ngang hàng trên mỗi POP. Và trong khuôn mẫu của mình, tôi sẽ chỉ định có bao nhiêu việc phải làm, dựa trên khoảng cách giữa hai POP. Tôi đã nghĩ rằng đây sẽ là một loại mục tiêu khá phổ biến.
Ví dụ:
- Trả trước 0 nếu trong POP
- 1 khoản trả trước nếu POP nội bang
- 2 khoản dự phòng nếu POP liên bang
- 3 khoản dự phòng nếu POP đông tây
Tôi nghĩ rằng nó sẽ hoạt động khá hoàn hảo, là một giải pháp khá thanh lịch và chính xác là loại giải pháp mà tôi hy vọng có được. Tôi đã viết các cấu hình trong một vài giờ và triển khai. Nhưng gãi đầu cho đến khi tôi nhận ra rằng iBGP không hỗ trợ chuẩn bị đường dẫn AS.
- https://routerj Racer.com/2011/02/11/bgp-essentials-the-art-of-path-manipulation/
- https://lists.gt.net/nsp/juniper/3870
- http://blog.ipspace.net/2008/02/bgp-essentials-as-path-prepending.html
Ngay cả khi tôi có thể làm việc này, có vẻ như nó sẽ không bao giờ là một giải pháp được hỗ trợ.
Những gì tôi đang xem xét
- Liên kết cuối cùng đó @ ipspace.net đề cập rằng bạn có thể sử dụng local-pref vì nó vẫn tồn tại bên trong AS. Nhưng tôi đã vạch ra một chính sách địa phương để ưu tiên các tuyến khách hàng hạ lưu, IXes, thông thường ... Có vẻ như sử dụng localpref cho việc này sẽ không kết hợp tốt. Và Ivan không gợi ý điều đó!
- Tôi đã xem xét sử dụng BGP Confederations - nhưng điều này có vẻ như rất nhiều công việc bổ sung cho mạng nhỏ của chúng tôi. Và tôi cũng đọc rằng nó không thêm bước nhảy AS giữa các AS liên minh. Vì vậy, tôi có thể kết thúc ở cùng một vị trí.
- Tôi sẽ cân nhắc sử dụng MPLS (tôi nghĩ MPLS TE?) Nhưng tôi rất xanh khi nói đến MPLS và đã có rất nhiều thách thức trước mắt. Vì vậy, tôi muốn tránh sự phức tạp thêm vào, trừ khi đó là một giải pháp tốt cho vấn đề của tôi.
Tôi sẽ thêm chi tiết vào ngày mai. Hiện tại, đây là một sơ đồ mô tả thiết lập hiện tại của chúng tôi.
