Khủng hoảng QoS - IP VPN được quản lý


9

(Trước hết, tôi xin lỗi vì bức tường văn bản này. Tôi không biết cách làm cho nó ngắn hơn mà không làm mất thông tin quan trọng. Ban đầu tôi muốn sử dụng phòng trò chuyện cho việc này, giống như chúng tôi làm trên serverfault cho các loại này câu hỏi, nhưng không có ai trong phòng kỹ thuật mạng).

Chúng tôi là một tập đoàn với một số công ty con, nơi chúng tôi có IP-VPN được quản lý khá lớn với khoảng 70 địa điểm khác nhau, thay đổi từ 2Mbps SHDSL đến 100Mbps sợi. IP-VPN mang nhiều VPN (hoặc chính xác là đường hầm).

Ưu tiên của lưu lượng là điều này, từ quan điểm quản lý và thiết kế:

  1. VoIP (Avaya và Lync)
  2. Video (Lync)
  3. RDP
  4. Các dịch vụ nội bộ (trình lưu trữ tệp, Active Directory, mạng nội bộ, v.v.)
  5. Các dịch vụ nội bộ không được ưu tiên (máy chủ proxy để sử dụng internet, dịch vụ cập nhật windows, quản lý cấu hình trung tâm hệ thống, proxy cập nhật chống vi-rút, v.v.)
  6. Lưu lượng truy cập không phù hợp (internet)

VoIP chỉ được sử dụng tại một số văn phòng nhất định, nơi có lượng người dùng thấp. Văn phòng từ xa lớn nhất sử dụng VoIP ngay bây giờ có SHDSL 4mbps với 5 nhân viên và 5 điện thoại IP avaya chạy codec G.711 ALAW 64K. Điều này sẽ không bao giờ mang lưu lượng dữ liệu voip lên đến hơn 320kbps. Tôi đã xác minh rằng điện thoại sử dụng DSCP 46 cho âm thanh và do đó, nó khớp chính xác như EF (xem cấu hình bên dưới). Tuy nhiên, tín hiệu được khớp với là DSCP 24, điều mà tôi không chắc là hồ sơ QoS của chúng tôi có nhận được không ..

Tất cả các địa điểm từ xa sử dụng RDP chống lại một số trang trại RDS tại HQ của chúng tôi (sợi 2x100Mbit). Băng thông được sử dụng cho RDP không quá dễ để tìm ra, vì về cơ bản nó sử dụng mọi thứ nó nhận được. Chúng tôi có một số hạn chế nhất định được đặt ra để đảm bảo rằng nó không quá đói tài nguyên, nhưng điều đó có thể nằm ngoài phạm vi của trang web này. Gần đây, chúng tôi có một số vấn đề khá nghiêm trọng với RDP ( /server/515809/mouse-coder-jumps-around-when-USE-rdp ), đó là lý do tại sao tôi đăng bài này lên kỹ thuật mạng.

Lync sử dụng DSCP 46 cho âm thanh và DSCP 34 cho video. Các dịch vụ nội bộ và các dịch vụ nội bộ không được ưu tiên chỉ được kết hợp bởi các mạng con và mọi thứ khác chỉ phù hợp với bất kỳ.

Đây là bản sao của bản sửa đổi cấu hình QoS mới nhất mà tôi đã sửa đổi một chút để ẩn tên và địa chỉ IP nhất định:

!
class-map match-any INTERNAL-PRI
 match access-group name CUST-INT-PRI
 match access-group name CUST-DMZ
class-map match-any INTERNAL-NOPRI
 match access-group name CUST-INT-NOPRI
class-map match-any REMOTEDESKTOP
 match access-group name RDP
class-map match-any ALL
 match any
class-map match-any NETWORK
 match ip precedence 6
 match ip precedence 7
class-map match-any EF
 match ip dscp ef
 match ip dscp cs5
class-map match-any AF-HIGH
 match ip dscp af41
 match ip dscp cs4
class-map match-any AF-MEDHI
 match ip dscp af31
 match ip dscp cs3
class-map match-any AF-MEDIUM
 match ip dscp af21
 match ip dscp cs2
class-map match-any AF-LOW
 match ip dscp af11
 match ip dscp cs1
class-map match-any BE
 match ip dscp default
!
!
policy-map setTos
 class EF
 class REMOTEDESKTOP
  set ip dscp af31
 class INTERNAL-PRI
  set ip dscp af21
 class INTERNAL-NONPRI
  set ip dscp af11
 class class-default
  set ip dscp default
policy-map useTos
 class EF
  priority percent 10
 class AF-HIGH
  bandwidth remaining percent 35
 class AF-MEDHI
  bandwidth remaining percent 25
 class AF-LOW
  bandwidth remaining percent 20
 class BE
  bandwidth remaining percent 10
 class NETWORK
policy-map QOS
 class ALL
  shape average 4096000
  service-policy useTos
!
!         
ip access-list standard CUST-DMZ
 permit 123.123.123.0 0.0.0.255
!
ip access-list standard CUST-INT-PRI
 permit 10.50.0.0 0.0.0.255
 permit 10.51.0.0 0.0.0.255
!
ip access-list standard CUST-INT-NOPRI
 permit 10.50.10.0 0.0.0.255
 permit 10.51.10.0 0.0.0.255
!
ip access-list extended RDP
 permit tcp any eq 3389 any
 permit tcp any any eq 3389
!

Như bạn có thể thấy, đó là một cấu hình QoS khá lớn. Lưu ý rằng chúng tôi không tạo cấu hình này cho bản thân, tất cả đều được thực hiện bởi một nhân viên trước tại nhà cung cấp IP-VPN của chúng tôi. Cũng lưu ý rằng giá trị hình dạng được thay đổi tùy theo loại kết nối (2mbps, 4mbps, 8mbps và 10mbps).

Bây giờ có lẽ bạn đang tự hỏi - câu hỏi ở đây là gì? Ở đây đi ..

  1. Giống như tôi đã đề cập trước đó, chúng tôi đang chìm đắm trong các khiếu nại của người dùng RDP về việc đầu vào lag / người dùng không được công nhận. Có phải chúng ta không ưu tiên nó một cách chính xác? Có thể đảm bảo rằng RDP nhận được một lượng tối thiểu mất gói, độ trễ và jitter, nhưng vẫn bị hạn chế trong băng thông?
  2. Tôi không thấy bất kỳ đề cập đến hàng đợi trong cấu hình này. Tôi đã đọc một số tài liệu của Microsoft và họ khuyên nên sử dụng hàng ưu tiên trên VoIP và WRED trên video. Làm thế nào để tôi thực hiện điều này xảy ra?
  3. Như cấu hình hiển thị, không có phân loại AF nào sử dụng mức giảm trung bình hoặc cao. Những loại dịch vụ an toàn để thả? RDP, video và voip không hoạt động tốt với giọt ..
  4. Là tỷ lệ phần trăm theo thứ tự? Nó tổng hợp lên đến 100% sử dụng

Bất kỳ đề xuất nào khác đều được chào đón, vì tôi rất mong muốn được sắp xếp này. Nếu bạn nghĩ rằng quá nhiều để trả lời trên trang web Hỏi & Đáp, tôi sẽ chỉ cắn bụi và thuê một chuyên gia tư vấn từ đối tác Cisco Gold của chúng tôi, điều đó ổn về mặt tài chính - tôi chỉ muốn tìm hiểu điều này nếu có thể.


Mô hình nào của Cisco đang thực hiện qos này và loại giao diện nào được cấu hình trên? Bạn có thể chỉnh sửa trong show policy-map interface, show proc cpu history, show interface <your-interface-w-QOS-service-policy>, show buff, và show runn interface <your-interface-w-QOS-service-policy>từ các bộ định tuyến và thêm nó vào dưới cùng của câu hỏi?
Mike Pennington

Tôi không có quyền truy cập quản lý vào các bộ định tuyến vì đây là dịch vụ IP-VPN được quản lý. Các dòng 2, 4 và 8mbps chạy trên 1811 / 881G và được kết nối với cổng FE0 / 1 thông thường và các dòng 10mbps chạy trên 892F được kết nối với SFP (thường là sợi DWDM). Tôi có quyền truy cập vào một số thống kê web, cho thấy mức sử dụng rất thấp trên cpu / mem.
pauseka

Có câu trả lời nào giúp bạn không? nếu vậy, bạn nên chấp nhận câu trả lời để câu hỏi không xuất hiện mãi mãi, tìm kiếm câu trả lời. Ngoài ra, bạn có thể cung cấp và chấp nhận câu trả lời của riêng bạn.
Ron Maupin

Câu trả lời:


6

Để trả lời câu hỏi của bạn:

  • Lưu lượng RDP sẽ nhận được tới 25% băng thông còn lại. Trong đó băng thông đã được bảo lưu là 35% ( mặc định lớp được 25% theo mặc định và EF nhận 10%). Vì vậy, nếu tôi đúng, bạn đã gán ~ 665Kbps cho RDP. Dù sao, bạn nên kiểm tra xem bạn có đang bỏ các gói phát hành lệnh dưới đây không:

show policy-map <your wan interface> output class REMOTEDESKTOP

và kiểm tra các gói bị rơi.

  • Cisco chỉ định một hàng đợi cho mỗi lớp do người dùng định nghĩa bao gồm các lệnh băng thông hoặc cảnh sát . Để làm cho một câu chuyện dài đơn giản, các lệnh đó xác định lượng băng thông được chỉ định cho mỗi hàng đợi trong các tắc nghẽn.

  • Về lý thuyết, mọi luồng dựa trên TCP sẽ ổn với các giọt. Trong thực tế một số trong số họ không. Việc bỏ các bit ưu tiên cho các bộ định tuyến biết các gói nào sẽ bị hủy, trong một lớp nhất định, trước khi tắc nghẽn xảy ra. Vì RDP là loại lưu lượng duy nhất được xác định trong lớp REMOTEDESKTOP của bạn , bạn không nên lo lắng về nó.

  • Tỷ lệ phần trăm băng thông không theo thứ tự (như Jeremy đã nêu).

Điều đó nói rằng, có rất nhiều điều tôi sẽ thay đổi trong cấu hình của bạn:

  • Không có sự trùng khớp giữa một số lớp của setTos và bản đồ chính sách useTos . Chẳng hạn, cái có tên AF-CAO đang xử lý không có gói nào vì không có lớp nào trong setTos đặt DSCP thành AF41.

  • Lớp BE trong setTos bằng cách nào đó tự đánh bại vì nó làm cho lớp mặc định của lớp trở nên vô dụng. Lưu ý rằng mặc định lớplớp duy nhất do hệ thống xác định và nhận 25% băng thông theo mặc định (100 - băng thông dự trữ tối đa).

  • phần trăm băng thông còn lại không phải là lựa chọn tốt nhất (như Jeremy giải thích). Tôi sẽ thay đổi nó thành phần trăm băng thông .

  • Tôi muốn tự đánh dấu các gói EF và không phụ thuộc vào cài đặt của điện thoại.


Cảm ơn, điều này đã làm sáng tỏ rất nhiều nhầm lẫn. Tôi đang làm việc trên một cấu hình QoS mới và sẽ đăng nó khi tôi hoàn thành. Một câu hỏi mặc dù - bạn nói rằng bandwith / cảnh sát sẽ nhận được một hàng đợi cho mỗi lớp do người dùng định nghĩa. Điều gì xảy ra nếu tôi tạo hai lớp do người dùng định nghĩa, cả hai đều được ưu tiên? Họ sẽ kết thúc trong cùng một hàng đợi LLQ?
pauseka

Để đặc biệt, các giá trị cảnh sát và băng thông cho IOS biết có bao nhiêu dung lượng bộ đệm để dự trữ cho mỗi loại lưu lượng. Tôi không biết điều gì sẽ xảy ra khi bạn định cấu hình hai tuyên bố cảnh sát khác nhau trong cùng một bản đồ chính sách, nhưng tôi cho rằng IOS sẽ coi chúng như hai hàng đợi khác nhau và gửi lưu lượng truy cập của chúng thẳng đến giao diện bên ngoài. Thay vào đó, trong trường hợp băng thông, IOS tạo ra hàng đợi cho mỗi luồng (cặp proto / ip / port - đích proto / ip / port) của lưu lượng sử dụng không gian địa chỉ dành riêng cho lớp phù hợp.
Marco Marzetti

7

Điều đầu tiên nhảy ra với tôi là bạn dường như định hình mọi thứ thành 4 Mbps. Tôi tưởng tượng rằng tốc độ thay đổi trên các bộ định tuyến / trang web với tốc độ mạch khác nhau, nhưng bạn thường muốn tránh định hình khi xử lý các ứng dụng nhạy cảm với độ trễ như VoIP và RDP vì nó có thể gây ra tình trạng đệm và jitter quá mức trong thời gian tắc nghẽn.

Ngoài ra, bandwidth remaining percentlệnh này hơi phức tạp: Mỗi trường hợp thực sự phân bổ n% băng thông có sẵn còn lại, không phải n% trên tổng số. Đồ họa này từ một bài viết của Arden Packeer sẽ giúp minh họa ý tưởng:

'Băng thông' so với 'băng thông còn lại'

Điều quan trọng cần lưu ý là mọi phân loại bạn xác định cần phải phù hợp với những gì nhà cung cấp mạng WAN của bạn hỗ trợ. Hầu hết các nhà cung cấp chỉ cung cấp một số ít hồ sơ QoS được cấu hình sẵn mà bạn phải chọn phù hợp nhất với nhu cầu của mình. Bạn có thể phân loại theo cách bạn muốn đối với lưu lượng truy cập đến ở cạnh WAN, nhưng các điều khiển QoS của nhà cung cấp là những gì kiểm soát việc xử lý lưu lượng trong quá trình truyền qua mạng WAN.


Tôi quên thêm rằng trung bình hình dạng được điều chỉnh theo đường ống trong tay. Ví dụ tôi đã sao chép là từ SHDSL 4mbps. Điểm hay về QS MPLS, tôi sẽ hỏi họ nó trông như thế nào. Tôi có thể ra lệnh cho bất kỳ QoS nào tôi muốn trên thiết bị CE. Cảm ơn lời giải thích đặt phòng, nó có ý nghĩa hơn rất nhiều bây giờ. Nó cũng cho thấy một lỗ hổng lớn trong cấu hình QoS hiện tại, có 70% đặt trước băng thông cho EF!
pauseka

Tôi sẽ không lo lắng về các thẻ của ISP vì anh ấy đã giới hạn băng thông trên bộ định tuyến biên của mình, do đó không xảy ra tắc nghẽn.
Marco Marzetti

1
Sự tắc nghẽn vẫn có thể xảy ra trên toàn mạng của nhà cung cấp, đặc biệt là với các mẫu lưu lượng truy cập nhiều-một. Đó là lý do tại sao việc đánh dấu lưu lượng liên quan đến sơ đồ phân loại của nhà cung cấp là rất quan trọng.
Jeremy kéo dài
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.