• If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.
Xin chào ! Nếu đây là lần đầu tiên bạn đến với diễn đàn, xin vui lòng danh ra một phút bấm vào đây để đăng kí và tham gia thảo luận cùng VnPro.

Announcement

Collapse
No announcement yet.

Giải pháp QoS cho MPLS/VPN

Collapse
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Giải pháp QoS cho MPLS/VPN

    Hi bà con,

    Hiện nay VDC đã triển khai MPLS trên mạng Core của họ và cũng sắp sửa tung ra dịch vụ VPN-MPLS based cho khách hàng. Một nhu cầu phát sinh là cần phải trang bị một hệ thống QoS chuyên dụng để kiểm soát traffic VPN cho từng khách hàng. Mình có một số thắc mắc về vấn đề này muốn trao đổi với các chuyên gia

    1. Làm sao một hệ thống QoS có thể phân biệt được các gói tin VPN/MPLS base và những gói tin MPLS bình thường (không phải VPN)

    2. Làm sao có thể phân biệt được các traffic VPN của các khách hàng khác nhau khi đi ngang qua hệ thống QoS để từ đó apply vào những cơ chế kiểm soát băng thông hợp lý?

    3. Khi triển khai VPN trên mạng MPLS thì Router tại khách hàng có cần cấu hình gì đặc biệt chăng hay cũng bình thường như các khách hàng non-MPLS?

    4. Khi một gói tin đi ngang qua Core Router trên mạng MPLS thì một label sẽ được gắn thêm vào gói tin đó rồi forward đến router kế tiếp. Vậy cơ chế gán cái Label này như thế nào? do các Core Router tự quyết định hay mình có thể can thiệp?

    Mình attach mô hình mạng Core VDC cho các bác tham khảo nhé

  • #2
    Re: Giải pháp QoS cho MPLS/VPN

    1. Làm sao một hệ thống QoS có thể phân biệt được các gói tin VPN/MPLS base và những gói tin MPLS bình thường (không phải VPN)
    Phân biệt hay không là do người cấu hình, QoS không có "lỗi" trong việc này, nếu chỉ là pure-MPLS-format packet thì ta có thể dùng trường EXP có tron MPLS-packet để classify, còn nếu có VPN/MPLS thì người ta không dùng EXP bit nữa (xem phần 2 sẽ ro..:) )

    2. Làm sao có thể phân biệt được các traffic VPN của các khách hàng khác nhau khi đi ngang qua hệ thống QoS để từ đó apply vào những cơ chế kiểm soát băng thông hợp lý?
    VPN của các khách hàng khác nhau sẽ phân biệt qua trường RT (route-target); bao gồm Import và Export RT. Trường RT cũng chính là Community trong BGP.

    Còn để phân biệt traffic VPN của các khách hàng khác nhau (cái này mới củ chuối) thì chắc là người ta sẽ sử dụng cách này (tôi không biết VDC sẽ dùng cách gì, nhưng theo những gì tôi biết và suy luận, có lẽ nó như thế này, có gì sai xin chỉ giáo)

    - Từ Custommer đến ISP thì có thể vẫn dùng trường EXP trong gói tin MPLS để classification đươc. (từ CE-Router lên PE-Router)
    - Tiếp theo ISP phải mapping sang BGP community (cái này phải hand-on). Như đã nói ở trên thì các gói tin VPN của các Custommer khác nhau phân biệt qua RTRT chính là BGP-community mở rộng, như vậy traffic của các VPN khác nhau sẽ được "phân biệt" qua BGP-community.
    - Đặt QoS mechanism (policy, sharping, dropping,...) tại các router P và PE dựa trên BGP-community (tìm hiểu thêm ở phần QPPB trong QoS).
    - khi gói tin về đến endgress Router thì sẽ được mapping ngược trở lại từ Community----> EXP bit trong gói tin MPLS.

    3. Khi triển khai VPN trên mạng MPLS thì Router tại khách hàng có cần cấu hình gì đặc biệt chăng hay cũng bình thường như các khách hàng non-MPLS?
    "non-VPN" hay là "non-MPLS"? cái này chắc bạn hơi nhầm 1 chút :D

    4. Khi một gói tin đi ngang qua Core Router trên mạng MPLS thì một label sẽ được gắn thêm vào gói tin đó rồi forward đến router kế tiếp. Vậy cơ chế gán cái Label này như thế nào? do các Core Router tự quyết định hay mình có thể can thiệp?
    Cơ chế hoàn toàn automatic, chứ không thì có gán label "rục tay".
    MPLS dùng cơ chế LDP để phân phối nhãn (nếu nhớ kô nhầm :D)

    Mong các bạn tham gia bàn luân.

    Comment


    • #3
      Re: Giải pháp QoS cho MPLS/VPN

      Originally posted by hhnts
      Hi bà con,

      Một nhu cầu phát sinh là cần phải trang bị một hệ thống QoS chuyên dụng để kiểm soát traffic VPN cho từng khách hàng. Mình có một số thắc mắc về vấn đề này muốn trao đổi với các chuyên gia

      1. Làm sao một hệ thống QoS có thể phân biệt được các gói tin VPN/MPLS base và những gói tin MPLS bình thường (không phải VPN)

      2. Làm sao có thể phân biệt được các traffic VPN của các khách hàng khác nhau khi đi ngang qua hệ thống QoS để từ đó apply vào những cơ chế kiểm soát băng thông hợp lý?

      3. Khi triển khai VPN trên mạng MPLS thì Router tại khách hàng có cần cấu hình gì đặc biệt chăng hay cũng bình thường như các khách hàng non-MPLS?

      4. Khi một gói tin đi ngang qua Core Router trên mạng MPLS thì một label sẽ được gắn thêm vào gói tin đó rồi forward đến router kế tiếp. Vậy cơ chế gán cái Label này như thế nào? do các Core Router tự quyết định hay mình có thể can thiệp?
      robedan cũng chỉ mới bắt đầu đọc về mpls nên có những ý kiến sau

      Nên chia các khách hàng của dịch vụ ra thành các mức. Việc phân loại này dựa vào MPLS CoS (class of services).
      Các dịch vụ được triển khai bao gồm

      a/ packet classfication: CAR có thể được dùng trước khi các gói có thể bị gán nhãn
      b/ Tránh nghẽn thì có thể dùng WRED
      c/ Có thể dùng CBWFQ để qui định phần băng thông cho một loại dịch vụ nào đó.[quote]
      Robedan
      Học viên CCNP VnPro khóa 2

      Comment


      • #4
        RE: Giải pháp QoS cho MPLS/VPN

        Nên chia các khách hàng của dịch vụ ra thành các mức. Việc phân loại này dựa vào MPLS CoS (class of services).
        Các dịch vụ được triển khai bao gồm

        a/ packet classfication: CAR có thể được dùng trước khi các gói có thể bị gán nhãn
        b/ Tránh nghẽn thì có thể dùng WRED
        c/ Có thể dùng CBWFQ để qui định phần băng thông cho một loại dịch vụ nào đó
        a) viết MPLS CoS là kô đụng MPLS kô có trường này, mà có trường tương đương EXP.
        b)Nếu dùng CoS để phân loại thì chỉ phân loại được dịch vụ thôi, ví dụ như là chỉ phân loại được Voice, Mission-Critical traffic... việc phân loại dịch vụ này sẽ áp dụng cho toàn bộ các khách hàng, mà yêu cầu của ta đưa ra là cho các khách hàng khác nhau mà

        Cùng nhau bàn tiếp nhé !

        Comment


        • #5
          Dường như Robedan và Vnpro-fan đang muốn sử dụng chính những MPLS router trên mạng MPLS để làm QoS, còn mình lại đang nghĩ theo hướng khác đó là đặt thêm một thiết bị khác, có thể là Non-Cisco, để quản lý QoS cho các session VPN/MPLS. thiết bị này sẽ được đặt ngay sau PE-Router như sau:

          Khách hàng VPN------PE-Router---QoS device(non-cisco)---P-Router----QoS device-----PE-Router-----Khach hàng VPN

          cho dù là sử dụng thiết bị nào thì Bài toán sẽ dễ dàng giải quyết nếu chúng ta có thể phân biệt các traffic khác nhau. Cái nào là Pure MPLS, cái nào là VPN-MPLS, và cái VPN-MPLS nào là của khách hàng nào.....

          Ở giải pháp của VPpro-fan mình thấy phải can thiệp vào các PE-Router nhiều qúa, mà không biết có thể làm được không nữa (not sure ). Đó chính là lý do mình nghĩ tới giải pháp sử dụng một thiết bị QoS khác hoạt động riêng biệt, tức là chỉ làm nhiệm vụ QoS thôi mà không dính líu gì tới việc Routing & Switching. NHững việc này sẽ do các Core router đảm nhận. như vậy các Core Router cũng đỡ vất vả để làm việc QoS. Tóm lại là việc ai nấy làm.

          Tuy nhiên thiết bị QoS mình đặt vào thì chỉ có thể phân biệt được ở mức độ cái nào là packet Pure IP, cái nào là MPLS (dựa vào 20 bit label và 3 bit EXP). thiết bị QoS cũng không hiểu được khái niệm RT hay BGP community như Vnpro-fan đưa ra. Do đó để phân biệt được giữa các khách hàng với nhau có lẽ phải dựa vào 3 tiêu chí:

          - Tiêu chí thứ I: Phải phân biệt được traffic này có phải là MPLS hay không. Cái này thì rõ ràng sẽ dựa vào trường Label hoặc EXP
          - tiêu chí thứ 2: Dựa trên địa chỉ Destination IP. Địa chỉ này cũng là địa chỉ Private của mạng LAN tại mỗi khách hàng. thiết bị QoS sẽ monitor tất cả các packet đi ngang nó và kiểm tra địa chỉ Destination IP. Nếu địa chỉ này đúng là của khách hàng VPN và cộng thêm gói tin này có một label gì đó thì nó sẽ biết đây là gói tin VPN và của khách hàng nào.

          Tuy nhiên ở đây lại nẩy sinh một vấn đề nữa. Nếu 2 khách hàng khác nhau cùng thuê VPN và cùng sử dụng Subnet giống nhau thì sao? Ví dụ cả 2 Khách hàng A và B sử dụng địa chỉ Private cho VPN là 172.16.0.0/16. Lúc này có lẽ cần phải dùng thêm Tiêu chí thứ 3:

          - Tiêu chí 3 dựa trên địa chỉ Source từ mỗi khách hàng. Bởi vì địa chỉ Source từ khách hàng chắc chắn phải là địa chỉ Public nên 2 khách hàng khác nhau chắc chắn phải có IP khác nhau.

          vậy túm lại:

          1. Để phân biệt một packet có phải là MPLS/VPN hay không thì dựa vào Label và Destination IP (Nhớ là phải dựa vào cả 2 tiêu chí này cùng lúc mới được)

          2. Sau khi đã biết được 1 gói tin đúng là MPLS/VPN rồi thì xét tiếp tới Source IP của nó xem nó xuất phát từ khách hàng nào để từ đó phân biệt các khách hàng với nhau

          Wow! Tất cả đều mới chỉ là suy luận của tui thôi, rất mong bà con cho ý kiến nhé

          Comment


          • #6
            Dường như Robedan và Vnpro-fan đang muốn sử dụng chính những MPLS router trên mạng MPLS để làm QoS, còn mình lại đang nghĩ theo hướng khác đó là đặt thêm một thiết bị khác, có thể là Non-Cisco, để quản lý QoS cho các session VPN/MPLS. thiết bị này sẽ được đặt ngay sau PE-Router như sau:

            Khách hàng VPN------PE-Router---QoS device(non-cisco)---P-Router----QoS device-----PE-Router-----Khach hàng VPN
            Ủa, anh định đề xuất giải pháp mới cho các ISP à

            Ở giải pháp của VPpro-fan mình thấy phải can thiệp vào các PE-Router nhiều qúa, mà không biết có thể làm được không nữa (not sure ).
            Nếu các PE mà làm hổng nổi chắc Cisco sập tiệm quạ VDC dùng con 12410 là phê lắm rồi

            thiết bị QoS cũng không hiểu được khái niệm RT hay BGP community như Vnpro-fan đưa ra.
            Thiết bị nào vậy bạn ?

            Do đó để phân biệt được giữa các khách hàng với nhau có lẽ phải dựa vào 3 tiêu chí:

            - Tiêu chí thứ I: Phải phân biệt được traffic này có phải là MPLS hay không. Cái này thì rõ ràng sẽ dựa vào trường Label hoặc EXP
            - tiêu chí thứ 2: Dựa trên địa chỉ Destination IP. Địa chỉ này cũng là địa chỉ Private của mạng LAN tại mỗi khách hàng. thiết bị QoS sẽ monitor tất cả các packet đi ngang nó và kiểm tra địa chỉ Destination IP. Nếu địa chỉ này đúng là của khách hàng VPN và cộng thêm gói tin này có một label gì đó thì nó sẽ biết đây là gói tin VPN và của khách hàng nào.

            Tuy nhiên ở đây lại nẩy sinh một vấn đề nữa. Nếu 2 khách hàng khác nhau cùng thuê VPN và cùng sử dụng Subnet giống nhau thì sao? Ví dụ cả 2 Khách hàng A và B sử dụng địa chỉ Private cho VPN là 172.16.0.0/16. Lúc này có lẽ cần phải dùng thêm Tiêu chí thứ 3:

            - Tiêu chí 3 dựa trên địa chỉ Source từ mỗi khách hàng. Bởi vì địa chỉ Source từ khách hàng chắc chắn phải là địa chỉ Public nên 2 khách hàng khác nhau chắc chắn phải có IP khác nhau.

            vậy túm lại:

            1. Để phân biệt một packet có phải là MPLS/VPN hay không thì dựa vào Label và Destination IP (Nhớ là phải dựa vào cả 2 tiêu chí này cùng lúc mới được)

            2. Sau khi đã biết được 1 gói tin đúng là MPLS/VPN rồi thì xét tiếp tới Source IP của nó xem nó xuất phát từ khách hàng nào để từ đó phân biệt các khách hàng với nhau

            Wow! Tất cả đều mới chỉ là suy luận của tui thôi, rất mong bà con cho ý kiến nhé
            Anh mà làm như thế này chắc hết QoS luôn quá, em phân tích sơ sơ cho anh xem nhe, có gì không phải thì cho em biết:
            1. Anh dùng 2 thiết bị riêng biệt : 1 thằng QoS, 1 thằng R&S. Chắc anh vẫn chưa nghĩ đến việc chức năng connectivity đặt trên con nào? apply các QoS rule là apply lên các interfaces, mà các Interface lại đặt trên con R&S trong khi ấy anh tách quách 2 con ra rồi vậy thì QoS như thế nào ?
            2. Trong trường hợp anh đặt toàn bộ các Interface lên con QoS (non-Cisco) của anh thì...anh định mua thêm một con 12000 mới à?
            3. Nói chung hình như đây chỉ là ý tưởng của anh thôi đúng kô, em chưa thấy thằng nào lam theo giải pháp này cả

            Comment


            • #7
              RE: Giải pháp QoS cho MPLS/VPN

              Hi anh hhnts, hi mọi người,

              Thực ra thì các giải pháp cung cấp dịch vụ QoS và xây dựng mô hình mạng MPLS/VPN đều đã được chuẩn hóa, anh chịu khó tim hiểu thêm tài liệu ( http://www.net130.com/attestation/ccip/ccip.htm ). Vấn đề là anh sử dụng cách thức nào cho phù hợp với môi trường mạng thôi.

              Em nói thể để khẳng định rằng anh em mình không cần phải bàn cãi nhau về "cách thức thực hiện QoS trong môi trường mạng MPLS/VPN", ngay cả trường hợp anh đang đề cập là "Internet MPLS/VPN" cũng thế.

              Vấn đề cần trao đổi là chọn lựa mô hình, áp dụng thực tiễn (khi mà hệ thống Customer của ISP do anh quản trị phức tạp) có nảy sinh gì khó khăn. Anh có thể post các vấn đề này để trao đổi cùng mọi người.

              (Thành thật xin lỗi bác hhnts và mọi người vì bài viết ko đúng mục đích của thread nay. So sorry)
              1\'\'hpSky
              If only I could turn back time...

              Comment


              • #8
                HI vnPro_Fan

                Hình như bạn không hiểu ý mình thì phải !!! và cũng chưa biết một thiết bị QoS chuyên dụng không phải Cisco. Thực ra một số thiết bị QoS non-cisco đã được sử dụng tại VNam như Packeteer, Allot... còn xịn hơn Cisco nhiêù,

                QoS lúc đó chỉ do thằng QoS định đoạn còn mấy con PE router chỉ có mỗi việc Routing, Switching thôi. Dĩ nhiên các rule phải apply vào các interface của con QoS chứ làm sao mà apply vào con R&S được !

                Dĩ nhiên là phải mua thêm con QoS mới rồi nhưng không phải la 12000 của Cisco ! Con này chắc đắt le lưỡi luôn, mua thêm con này chắc chết.

                Dù sao cũng cám ơn bạn

                Comment


                • #9
                  RE: Giải pháp QoS cho MPLS/VPN

                  giải pháp QoS của hhnts đưa ra có một vài khuyết điểm sau:

                  1/ packeteers không phải là một sản phẩm QoS.
                  2/ Nếu có một thiết bị như vậy trong mô hình, thiết bị đó vẫn phải thực hiện chức năng routing và switching.
                  3/ Giải pháp không đồng nhất, khó quản trị.
                  4/ Chức năng QoS trong giải pháp này phải mang tính chất tích hợp vào hệ thống mạng. Không thể nào có thể tách chức năng này ra khỏi các MPLS routers được.

                  Theo ý kiến của tôi, trước hết nên tìm hiểu lại các mô hình QoS trên môi trường MPLS. tập trung hướng nghiên cứu về các mô hình này. Chọn lấy một mô hình phù hợp và triển khai theo mô hình đó.

                  Cám ơn
                  Long Nguyen

                  Comment


                  • #10
                    Re: RE: Giải pháp QoS cho MPLS/VPN

                    Hi KimLong

                    1/ packeteers không phải là một sản phẩm QoS.

                    Các sản phẩm của Packeteer (www.packeteer.com)đích thực là những sản phẩm thực hiện các chức năng theo dõi, định dạng và kiểm soát và nén băng thông. Thiết bị này không thể gọi là thiết bị QoS thì gọi là gì đây?

                    2/ Nếu có một thiết bị như vậy trong mô hình, thiết bị đó vẫn phải thực hiện chức năng routing và switching.

                    Điều này mới hết sức vô lý. Chẳng có sự ràng buộc nào giữa các thiết bị QoS và các thiết bị R&S cả. QoS hoạt động hoàn toàn "trong suốt" chứ chẳng cần Routing gì ở đây hết. Địa chỉ IP trên trên các interface của QoS chỉ mang tính năng quản lý thôi. Tất nhiên cũng chẳng ai cấm một thiết bị QoS thực hiện việc routing, nhưng đó là điều không cần thiết

                    3/ Giải pháp không đồng nhất, khó quản trị.

                    Thực ra vấn đề quản trị không khó tí nào. Các thiết bị này đều hỗ trợ đầy đủ các công cụ quản trị qua Software, Web, CLI, SNMP MIB... Bạn hoàn toàn có thể tích hợp các MIB file này vào một SNMP platform như HP Openview để quản lý chung với các thiết bị khác. Chẳng lẽ để đạt được mục đích đồng nhất thiết bị mình cứ phải sử dụng các sản phẩm của cùng một hãng hay sao. Chẳng lẽ cứ Router là Cisco thì Firewall phải là PIX chắc??? mà không thể là Checkpoint, NetScreen, Fortinet, Secure Computing... được hay sao?

                    4/ Chức năng QoS trong giải pháp này phải mang tính chất tích hợp vào hệ thống mạng. Không thể nào có thể tách chức năng này ra khỏi các MPLS routers được.

                    Có thể là như vậy nhưng ở đây mình muốn bàn tới một giải pháp tách rời, còn nếu tích hợp tất tần tật vào trong Cisco thì khỏi bàn phải bàn nữa làm gì

                    many thanks

                    Comment


                    • #11
                      Re: RE: Giải pháp QoS cho MPLS/VPN

                      Originally posted by hhnts
                      Hi KimLong

                      1/ packeteers không phải là một sản phẩm QoS.

                      Các sản phẩm của Packeteer (www.packeteer.com)đích thực là những sản phẩm thực hiện các chức năng theo dõi, định dạng và kiểm soát và nén băng thông. Thiết bị này không thể gọi là thiết bị QoS thì gọi là gì đây?

                      2/ Nếu có một thiết bị như vậy trong mô hình, thiết bị đó vẫn phải thực hiện chức năng routing và switching.

                      Điều này mới hết sức vô lý. Chẳng có sự ràng buộc nào giữa các thiết bị QoS và các thiết bị R&S cả. QoS hoạt động hoàn toàn "trong suốt" chứ chẳng cần Routing gì ở đây hết. Địa chỉ IP trên trên các interface của QoS chỉ mang tính năng quản lý thôi. Tất nhiên cũng chẳng ai cấm một thiết bị QoS thực hiện việc routing, nhưng đó là điều không cần thiết

                      3/ Giải pháp không đồng nhất, khó quản trị.

                      Thực ra vấn đề quản trị không khó tí nào. Các thiết bị này đều hỗ trợ đầy đủ các công cụ quản trị qua Software, Web, CLI, SNMP MIB... Bạn hoàn toàn có thể tích hợp các MIB file này vào một SNMP platform như HP Openview để quản lý chung với các thiết bị khác. Chẳng lẽ để đạt được mục đích đồng nhất thiết bị mình cứ phải sử dụng các sản phẩm của cùng một hãng hay sao. Chẳng lẽ cứ Router là Cisco thì Firewall phải là PIX chắc??? mà không thể là Checkpoint, NetScreen, Fortinet, Secure Computing... được hay sao?

                      4/ Chức năng QoS trong giải pháp này phải mang tính chất tích hợp vào hệ thống mạng. Không thể nào có thể tách chức năng này ra khỏi các MPLS routers được.

                      Có thể là như vậy nhưng ở đây mình muốn bàn tới một giải pháp tách rời, còn nếu tích hợp tất tần tật vào trong Cisco thì khỏi bàn phải bàn nữa làm gì

                      many thanks
                      a. Tôi hoàn toàn đồng ý với bạn KimLong
                      b. bạn hhnts nên về đọc tiếp các tài liệu về QoS và MPLS, bạn nên đọc các giáo trình không phải của Cisco để cho kô phải "Cisco hóa" kiến thức, sau đó quay lại các giáo trình Cisco thử xem có gì khác không? khi bạn đọc tài liệu rồi bạn sẽ thấy những gì mà tui, 1''hpksy, kimlong nói là có lý của nó.
                      c. nếu anh hhnts ở Hà Nội thì chúng ta có thể gặp nhau để trao đổi thêm được
                      Các ý kiến của tui chỉ mang tính đóng góp
                      THÂN

                      Comment


                      • #12
                        Hi hhnts,

                        Những nhận định của bạn rất pro, tôi tiếc là có những chú không biết được những cái hay khác cần phải trau dồi thêm cho cái vốn kiến thức còn hạn hẹp của mình mà lại cứ cắm đầu cắm cổ mà cãi bừa, gàn lắm
                        Flux -> Flask -> SELinux (RHEL 4)
                        Beating the 0-day vulrerability threat

                        Comment


                        • #13
                          Originally posted by itmansaigon
                          Hi hhnts,

                          Những nhận định của bạn rất pro, tôi tiếc là có những chú không biết được những cái hay khác cần phải trau dồi thêm cho cái vốn kiến thức còn hạn hẹp của mình mà lại cứ cắm đầu cắm cổ mà cãi bừa, gàn lắm
                          Cái thread này xem ra cũng bắt đầu "nóng" rồi đây :D

                          hehe..nhận định "trông có vẻ pro" của bạn hhnts nhưng thật ra trên cơ sở của nền tảng kiến thức chưa clear về QoS đấy bạn "itmansaigon" ạ

                          QoS mới thật sự là QoS khi mà nó đảm bảo QoS end-to-end, nhưng mà ta xem lại các sản phẩm + giải pháp đi kèm mà bạn hhts đưa ra lại không đảm bảo được tính chất này, giải pháp này chỉ dành cho end-user thôi mà nếu là tôi tôi chẳng bao giờ tư vấn cho khách hàng giải pháp này, vì làm QoS tại đầu cuối chẳng có ý nghĩa gì khi mà ISP không đảm bảo QoS cho ta

                          Comment


                          • #14
                            Pro-fan

                            Làm ơn đọc kỹ lại dùm cái thread mà tui đưa ra. thực sự tui đang muốn tìm một giải pháp QoS cho ISP để phục vụ các khách hàng MPLS/VPN (Chưa quan tâm tới QoS cho End user)

                            Bạn hãy đưa một giải pháp cụ thể để mọi người cùng bàn tiếp. Một cái gì tương đối cụ thể một chút chứ cứ "lý thuyết suông" thì không ra vấn đề được

                            Comment


                            • #15
                              Originally posted by vnpro_fan
                              QoS mới thật sự là QoS khi mà nó đảm bảo QoS end-to-end, nhưng mà ta xem lại các sản phẩm + giải pháp đi kèm mà bạn hhts đưa ra lại không đảm bảo được tính chất này, giải pháp này chỉ dành cho end-user thôi mà nếu là tôi tôi chẳng bao giờ tư vấn cho khách hàng giải pháp này, vì làm QoS tại đầu cuối chẳng có ý nghĩa gì khi mà ISP không đảm bảo QoS cho ta
                              Đúng là khi càng đi đường xa mới biết được bạn nào là bạn hiền, QoS tại đầu cuối có tác dụng rất hiệu quả cho việc ngăn chặn những user lạm dụng Internet để download liên miên làm ảnh hưởng đến total bandwidth, đối với phía bên ngoài thì cho phép Internet users truy cập web site của mình dễ dàng mà không bị các Internet services khác như SMTP, FTP... lấn át.
                              Flux -> Flask -> SELinux (RHEL 4)
                              Beating the 0-day vulrerability threat

                              Comment

                              Working...
                              X