Giải pháp QoS cho MPLS/VPN

[hhnts]

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é

[vnpro_fan]

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 RT mà RT 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.

[robedan]

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]

[vnpro_fan]

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é !

[hhnts]

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é

[vnpro_fan]

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ả

[1''hpSky]

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)

[hhnts]

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

[kimlong]

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

[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

[vnpro_fan]

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

[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

[vnpro_fan]

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

[hhnts]

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

[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

Đú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.

[ryan]

Hi all,
Cac ban co the tham khao thong tin san pham moi cua packeteer tai http://www.packeteer.com/prod-sol/products/1200.cfm. 4 trong 1 :lol:

[ISR3800]

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

Chả biết chú vnpro_fan này tài cao học rộng đến đâu không biết mà dám lên mặt dạy đời, kêu người ta học này học nọ. Chú mới nên đọc nhiều kiến thức khác đi, Cisco chỉ là 1 hãng trong công nghệ mạng. Trong mạng core thì Cisco làm sao so sánh với Juniper, Nortel... được. Cho nên chú đừng có chê bai người khác và kêu người ta đọc này đọc nọ .
Mr HHNTS là Giám đốc kỹ thuật của công ty Nam Trường Sơn. Nếu chú cũng không biết NTS là công ty nào thì chú chả biết gì về thị trường mạng viễn thông của VN cả. Chú cũng chả có tư cách gì để nói người ta đọc này đọc nọ cả. Ngu dốt mà cứ tưởng mình hay.

[cisco336]

Theo giải pháp của hhnts đã nêu:
Khách hàng VPN------PE-Router---QoS device(non-cisco)---P-Router----QoS device-----PE-Router-----Khách hàng VPN

Việc đặt QoS device trong MPLS domain như vậy dẫn đến 1 lọat các vấn đề phức tạp sau:

1. Thiết bị QoS này phải có khả năng chạy LDP hay TDP protocol nhằm trao đổi labels với các MPLS routers khác như PE và P
2. Trong MPLS domain, giải pháp QoS duy nhất là dựa vào EXP bit có trong MPLS header (MPLS device không có khả năng đọc IP header), nên thiết bị QoS này cũng phải dựa vào EXP bit này để triển khai QoS

Do đó, điểm triển khai QoS nên là các PE routers vì đó là nơi mà các khách hàng nối vào hệ thống MPLS.

[ScriptKiddies]

Theo tôi biết nếu đặt thiết bị QoS tại từng điểm thì việc xử lý và thực hiện chính sách QoS sẽ chỉ thực hiện tại điểm đó (đối với traffic in và out). Tuy nhiên câu hỏi ở đây là phải xử lý QoS trên toàn tuyến (end-to-end) và giữa 2 điểm bất kỳ trong MPLS domain, thì việc sử dụng thiết bị QoS sẽ bất cập bởi phải deploy rất nhiều thiết bị (tại mỗi Hop). Mà trong MPLS của SP thì có thể có rất nhiều Router (nhiều khi hàng trăm Router) thì việc sử dụng nhiều thiết bị QoS khó thực hiện được.

Giải pháp MPLS của Juniper (tốt nhất bây giờ) và ngay cả Cisco thường dùng kỹ thuật MPLS Traffic Engineering kết hợp với giao thức RSVP để đảm bảo QoS giữa 2 điểm bất kỳ trong MPLS domain được thực hiện hiệu quả. Các Router P và PE phải chạy được LDP thì mới sử dụng kỹ thuật này được.

[ScriptKiddies]

Sản phẩm QoS Packeteer thực hiện rất tốt chức năng kiểm soát traffic in-out tại một điểm, bản thân tôi đã cấu hình thử và thấy chạy ngon, nhất là trong trường hợp đặt chính sách QoS cho việc sử dụng Internet của một công ty. Tuy nhiên QoS của MPLS là một vấn đề khác mà Packeteer không giải quyết được. Các bạn có thể tham khảo mô hình xây dựng MPLS của các ISP lớn trên thế giới để biết họ làm thế nào. Nói chung cũng khá phức tạp.

[Tuangia]

Hi hhnts

Bạn nói attach mô hình mạng Core của VDC để mọi người tham khảo mà có thấy đâu. Bạn hãy attach lên cho mọi người tham khảo.

[bahuan]

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é

Đối với sản phẩm của Cisco, mình chỉ là newbie nên không rành nó có những chức năng gì. Tuy nhiên, mình đã làm việc với sản phẩm SER5500 của Nortel và thấy đây là một Edge router thực sự mạnh. Theo mình biết, trong MPLS VPN, mỗi packet thuộc VPN sẽ được gán cho ít nhất 2 label trước khi forward lên core network (Một số trường hợp có thể có nhiều label hơn như : Carrier's carrier VPN). Đối với trường hợp 2 label, 1 inner label để phân biệt các VPN và 1 outer label của MPLS protocol (LDP).

Trong SER5500 này, có một cái service để phân loại traffic từ customer site lên ISP được gọi là DiffServe. Nhiệm vụ của nó để chuyển các loại traffic (FTP, HTTP...) thành ToS field trong IP header (việc này tất nhiên được thực hiện tại PE).

Ngoài ra, còn có một service khác để chuyển từ trường ToS sang EXP bit của MPLS header.

Không biết bấy nhiêu đây có thể đáp ứng được câu hỏi của bạn hay không ? Mình nghĩ nếu sản phẩm của Nortel có hỗ trợ những chức năng này thì chắc Cisco củng có thôi (not sure)

Ngoài ra, mình được biết từ một số tài liệu, QoS cho MPLS có thể được thực hiện bằng cách chia label thành các range. => Phần này thì không rõ lắm, mình cũng thực sự đang muốn tìm hiểu thêm.

Cơ chế gắn label :
Đối với inner label (VPN label) thì dựa vào quá trình trao đổi label diễn ra giữa các MP-BGP peer (Multi protocol BGP). Sau khi trao đổi label thành công, mỗi PE sẽ có các label mapping cho tất cả các VPN đã configure.
Đối với outer label (MPLS label) tùy thuộc vào MPLS protocol sử dụng (static label, LDP, TE...). Do đó label mapping tại các Core router có thể được quyết định bởi nhà quản trị (static label) hoặc do protocol tự trao đổi giữa các router.

Mình xin đưa ra một mô hình đơn giản về MPLS VPN như sau :
|--IGP (OSPF, RIP...)-|
|------ MP-BGP------|
|------MPLS---------|
CE1---PE1---------------PE2----CE2

Lỡ mình nói có gì sai xin các bạn góp thêm ý kiến. Đây chỉ là hiểu biết bây giờ của mình thôi, kiến thức cần phải update hàng ngày :D

[opnet]

Hiện tôi đang có bản mô phỏng OPNET Modeler, hỗ chợ rất tốt cho MPLS
- MPLS TE
- MPLS VPN
-MPLS QoS

Nếu bạn cần, chúng tôi sẽ phục vụ cài đặt tận tình
Giá cả:
30 USD cho 1 PC
100 USD cho 5PC
150 USD cho > 10 PC

chạy thử miễn phí !!!!!
phục vụ tận tình
địa bàn hà nội

xim tham khảo tại www.opnet.com
lien he luongvietthang101010@yahoo.com

[opnet]

Hiện tôi đang có bản mô phỏng OPNET Modeler, hỗ chợ rất tốt cho MPLS
- MPLS TE
- MPLS VPN
-MPLS QoS

Nếu bạn cần, chúng tôi sẽ phục vụ cài đặt tận tình
Giá cả:
30 USD cho 1 PC
100 USD cho 5PC
150 USD cho > 10 PC

chạy thử miễn phí !!!!!
phục vụ tận tình
địa bàn HN

xim tham khảo tại www.opnet.com
lien he luongvietthang101010@yahoo.com

[bigbang2005]

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é

các câu hỏi của bạn thì liên quan nhiều đến MPLS VPN hơn là QoS MPLS VPN. nói đến QoS MPLS VPN thì bạn tìm hiểu 2 mô hình cơ bản là pipe & uniform, nói đến việc giá trị IP Pre/DSCP của khách hàng thay đổi và ảnh hưởng như thế nào trong mạng nhà cung cấp dịch vụ. Các phương pháp QoS thông thường từ trước thì vẫn được áp dụng cho QoS MPLS VPN
Best luck!

[silverhead]

Chả biết chú vnpro_fan này tài cao học rộng đến đâu không biết mà dám lên mặt dạy đời, kêu người ta học này học nọ. Chú mới nên đọc nhiều kiến thức khác đi, Cisco chỉ là 1 hãng trong công nghệ mạng. Trong mạng core thì Cisco làm sao so sánh với Juniper, Nortel... được. Cho nên chú đừng có chê bai người khác và kêu người ta đọc này đọc nọ .
Mr HHNTS là Giám đốc kỹ thuật của công ty Nam Trường Sơn. Nếu chú cũng không biết NTS là công ty nào thì chú chả biết gì về thị trường mạng viễn thông của VN cả. Chú cũng chả có tư cách gì để nói người ta đọc này đọc nọ cả. Ngu dốt mà cứ tưởng mình hay.

Bạn ISR3800 ơi, đọc lại các bài viết của bạn tôi mới thấy bạn là người nên đọc lại và học lại. Tôi có đọc được 1 bài của bạn về vấn đề H.323 và SIP cũng sai. Ai bảo bạn SIP không hỗ trợ Video, VTN của bạn hiện đang cung cấp dịch vụ Video Conference với các thiết bị endpoint VSX7000 hoặc HDX9002 của Polycom đếu có hỗ trợcả SIP và H323 và dịch vụ IP Centrex cũng chạy trên SIP là ntn?
Việc so sánh giữa Cisco và Juniper bạn cũng hơi hồ đồ đấy. Chắc bạn cũng chưa nắm được lịch sử ra đời và phát triển của Juniper. Tôi chỉ mách nhỏ bạn 1 ý là Juniper được tách ra từ Cisco
Không biết bạn có cổ phàn của NTS không mà bạn phát biểu về NTS mạnh thế. Nói thật với bạn NTS cũng chỉ là em út trong thị trường VT ở VN thôi. NTS làm sao so sánh được với FPT, ISP, EIS, ...

[cuong58]

Hi bạn đầu bạc, NTS thực sự là 1 cty đáng nể trong thị trường VT Vn đấy, EIS ngày xưa cũng hùng mạnh thật nhưng giờ thì... FPT va ISP chỉ mạnh trong lĩnh vực enterprise.
Còn bạn nhắc đến sự ra đời của Ju thì không hiểu bạn có biết người đứng ra thành lập Ju từ Cisco trước đó giữ vị trí nào trong Cisco ko? Xin thưa đó là giám đốc công nghệ của Cisco. Chính vì vậy chủ trương của Ju là luôn đi truớc Cisco về mặt công nghệ tới vai năm trong khi Cisco vẫn còn ngủ quên trong sự độc bá thiên hạ của mình. Sự đi trước trong công nghệ thể hiện rõ nhất o kiến trúc phần cứng mà hiện giờ Cisco đang phải học tập Ju đấy.

[silverhead]

Bạn Cuong58, không có nghĩa giám đốc công nghệ của Cisco đứng ra thành lập Ju thì Ju hơn Cisco. Nhưng tôi đồng ý với bạn và Ju cũng có 1 số điểm mạnh hơn Cisco nhưng ngược lại Cisco cũng có dòng sản phẩm mạnh hơn.
Đỗi với NTS tôi không nghĩ đó là công ty đáng nể trong thị trường VT VN. Thời gian gần đây NTS có trúng thầu đc các gói thầu tương đối của VNPT, Viettel,... hay Bộ tài chính đâu.

[skyline-1]

Làm ơn cho mình hỏi về vấn đề QoS
Theo tài liệu nói, khả năng cung cấp chất lượng dịch vụ của IP là không cao. Do đó, ip ko thích hợp với các dịch vụ thời gian thực, như voice và video.
Trong IP sử dụng 3 bit đầu tiên trong trường loại dịch vụ (Service Type - ToS) trong phần mào đầu của gói dữ liệu IP để thực hiện QoS.
VẬy cho mình hỏi, tại sao khả năng thực hiện QoS của IP lại ko cao. So với thực hiện QoS trên MPLS thì, thực hiện QoS trên MPLS có điểm nào tốt hơn.

Cám ơn các bạn.

[vnpro-test]

Chào bạn,

Theo mình nghĩ khả năng cung cấp chất lượng dịch vụ của IP nói không cao là chưa đúng. Vì điển hình voice IP với G711 có thể cung cấp dịch vụ thoại chất lượng là 4.1 so với ĐT thường (mạng PSTN) là 4.0.
Mình nghĩ sách nói vậy là do IP có nhiều trường và nằm ở layer 3, MPLS thì nằm ở layer 2.5 đọc các trường trong MPLS nhanh hơn so với đọc trường trong IP. Và đây cũng là ưu điểm chính của MPLS.

[xenoxone]

Bạn Cuong58, không có nghĩa giám đốc công nghệ của Cisco đứng ra thành lập Ju thì Ju hơn Cisco. Nhưng tôi đồng ý với bạn và Ju cũng có 1 số điểm mạnh hơn Cisco nhưng ngược lại Cisco cũng có dòng sản phẩm mạnh hơn.
Đỗi với NTS tôi không nghĩ đó là công ty đáng nể trong thị trường VT VN. Thời gian gần đây NTS có trúng thầu đc các gói thầu tương đối của VNPT, Viettel,... hay Bộ tài chính đâu.

không có nghĩa giám đốc công nghệ Cisco đứng ra thành lập Ju thì Ju hơn Cisco, nhưng thực tế sử dụng cho thấy trong các mạng Core thì Ju hoạt động ổn định cà đáp ứng nhu cầu nâng cấp cao hơn Cisco. Tất nhiên mỗi hãng có điểm mạnh yếu khác nhau, cũng như bạn có thể thấy các thiết bị gần đầu cuối ít xuất hiện Juniper mà đa phần là Cisco. Cả 2 hãng đang có gắng lấp khuyết điểm của mình bằng một số dòng cải thiện. Nhưng nói chung, với các hệ thống lớn, Ju chiếm ưu thế nhiều hơn.

[ductri]

không phải bàn tán nhiều ,hiện tại mạng core thì đồ của juniper ăn đứt cisco ,còn thị phần enterprise thì cisco chiếm đếm 70%,cisco phát triển được như ngày hôm nay một phần đóng góp rất quan trọng là vấn đề marketing cực kỳ tốt với các authorized academy ở khắp nơi :)

[thanhsam2003]

Khi em vao GNS3 va keo con router vao thi no thong bao la:IOS Base config "baseconfig.txt no such file or directory"
Khi em cau hinh router thi dong lenh" P(config-if)# mpls ip " bi bao loi cho mpls
va dong lenh:PE1(config-router)#neighbor 4.4.4.4 update-source Loopback0 .no bao chu Loopback0
Mong cac pro giup do gium!
Xin cam on!