Techerest
EN

QoS บน Cisco ด้วย MQC: Class-Map, Policy-Map, LLQ, Policing และ Shaping

18 ต.ค. 2569 Cisco Class-Map HQoS LLQ MQC Network Engineer Networking Policing Policy-Map QoS Shaping

หลังจากเข้าใจพื้นฐาน Quality of Service หรือ QoS ทั้ง Classification, Marking, DSCP, CoS, Queuing, Policing และ Shaping แล้ว ขั้นต่อไปคือการนำแนวคิดเหล่านี้มาสร้างเป็น Policy บนอุปกรณ์ Cisco

บน Cisco IOS และ IOS XE หนึ่งใน Framework สำคัญสำหรับการ Configure QoS คือ Modular QoS CLI หรือ MQC ซึ่งแบ่งการทำงานออกเป็น Class-Map, Policy-Map และ Service-Policy ทำให้ Network Engineer สามารถกำหนดได้ว่า Traffic ใดคือ Voice, Video หรือ Business Application และแต่ละ Class ควรได้รับการจัดการอย่างไรเมื่อ Network เกิด Congestion

บทความนี้จะสร้าง QoS Policy ตั้งแต่ต้น พร้อมอธิบาย LLQ, Bandwidth Guarantee, Policing, Shaping, Policy Direction, Verification Counter และ Troubleshooting เพื่อให้สามารถนำหลักการไปประยุกต์กับ Cisco Network จริงได้

สารบัญ

ภาค 1: Cisco MQC คืออะไร?

Modular QoS CLI หรือ MQC

MQC เป็นโครงสร้าง Configuration ที่ช่วยให้ Cisco QoS Policy ถูกแบ่งออกเป็นส่วนที่เข้าใจง่าย 

Traffic
   |
   v
CLASS-MAP
What traffic?
   |
   v
POLICY-MAP
What should we do?
   |
   v
SERVICE-POLICY
Where should policy run?
   |
   v
INTERFACE

แนวคิดนี้สำคัญมาก เพราะช่วยแยกคำถามสามข้อออกจากกัน: 

1. Traffic อะไร?
   =
   Class-Map


2. จะจัดการอย่างไร?
   =
   Policy-Map


3. ใช้ Policy ที่ไหน?
   =
   Service-Policy

Class-Map, Policy-Map และ Service-Policy ทำงานร่วมกันอย่างไร?

Class-Map

ใช้สำหรับ Classification หรือระบุว่า Traffic ใด อยู่ใน Class ใด 

class-map match-any VOICE
 match dscp ef

Policy-Map

กำหนด Treatment ให้กับ Class 

policy-map WAN-QOS
 class VOICE
  priority percent 10

Service-Policy

นำ Policy ไป Apply กับ Interface และ Direction ที่ต้องการ 

interface GigabitEthernet0/0
 service-policy output WAN-QOS

มองทั้งสามส่วนพร้อมกัน

DSCP EF
   |
   v
class-map VOICE
   |
   v
policy-map WAN-QOS
   |
   v
priority treatment
   |
   v
service-policy output
   |
   v
WAN Interface

ภาค 2: QoS Lab Topology

ตัวอย่าง Network

LAN
 |
 |
 v
+---------+
|   R1    |
|         |
| Gi0/0   |================ ISP
+---------+
               WAN
             100 Mbps

สมมติ Traffic มี:

VOICE
=
DSCP EF


VIDEO
=
DSCP AF41


BUSINESS
=
DSCP AF31


OTHER
=
Default

เป้าหมายคือเมื่อ WAN เกิด Congestion: 

VOICE
=
Priority


VIDEO
=
Guaranteed Bandwidth


BUSINESS
=
Guaranteed Bandwidth


OTHER
=
Remaining Resources
QoS Syntax และ Hardware Behavior แตกต่างกันตาม Cisco Platform และ IOS/IOS XE Release คำสั่งในบทความเป็นตัวอย่างเพื่ออธิบาย MQC ก่อนใช้ Production ต้องตรวจ Feature Support, Queue Architecture และ Command Reference ของอุปกรณ์จริง

ภาค 3: Class-Map

สร้าง Class-Map เพื่อ Classification

VOICE:

class-map match-any VOICE
 match dscp ef

VIDEO:

class-map match-any VIDEO
 match dscp af41

BUSINESS:

class-map match-any BUSINESS
 match dscp af31

Traffic Flow

Packet
 |
 +---- DSCP EF
 |       |
 |       v
 |     VOICE
 |
 +---- DSCP AF41
 |       |
 |       v
 |     VIDEO
 |
 +---- DSCP AF31
         |
         v
      BUSINESS

Classify ด้วย ACL ได้หรือไม่?

ได้บน Platform และ Feature ที่รองรับ MQC Classification ด้วย ACL

ตัวอย่างแนวคิด:

ip access-list extended BUSINESS-APP
 permit tcp 10.10.10.0 0.0.0.255 host 10.20.20.50 eq 443

จากนั้น:

class-map match-any BUSINESS
 match access-group name BUSINESS-APP
ACL ที่ใช้ Classification ไม่ควรถูกสับสนกับ Security ACL ใน MQC Context ACL สามารถถูกใช้เพื่อระบุ Traffic Class ส่วนผลลัพธ์ของ QoS จะขึ้นอยู่กับ Policy-Map ที่นำ Class นั้นไปใช้งาน

match-any กับ match-all ต่างกันอย่างไร?

match-any

Traffic Match เพียงหนึ่งเงื่อนไข ก็สามารถเข้า Class ได้ 

class-map match-any REALTIME
 match dscp ef
 match dscp af41

แนวคิด:

EF
OR
AF41

match-all

Traffic ต้องตรงกับ ทุก Match Statement ที่กำหนดใน Class ตามความสามารถของ Platform 

Condition A
AND
Condition B

จึงควรตรวจ Logic ให้ชัดก่อนใช้ เพราะ Classification ที่ผิด จะทำให้ QoS Treatment ผิดไปตั้งแต่ต้นทาง

ภาค 4: Policy-Map

Policy-Map คืออะไร?

เมื่อ Classify Traffic แล้ว ขั้นต่อไปคือกำหนดว่า แต่ละ Class จะได้รับ Treatment อย่างไร

ตัวอย่าง:

policy-map WAN-QOS

 class VOICE
  priority percent 10

 class VIDEO
  bandwidth percent 20

 class BUSINESS
  bandwidth percent 25

 class class-default
  fair-queue

นี่เป็นตัวอย่างเชิงแนวคิด ของการสร้างหลาย Queue สำหรับ Traffic แต่ละประเภท 

WAN-QOS
   |
   +---- VOICE
   |       Priority
   |
   +---- VIDEO
   |       Bandwidth
   |
   +---- BUSINESS
   |       Bandwidth
   |
   +---- DEFAULT
           Remaining Traffic

ภาค 5: LLQ และ Priority Queue

LLQ คืออะไร?

LLQ หรือ Low Latency Queuing เป็นแนวคิดที่เพิ่ม Strict Priority Treatment ให้กับ Traffic ที่ไวต่อ Delay ภายใน QoS Scheduling Architecture ที่รองรับ

ตัวอย่างที่พบได้บ่อย:

class VOICE
 priority percent 10

หมายถึง VOICE Class ได้รับ Priority Treatment ตาม Policy และ Platform Behavior

ทำไม Voice ใช้ Priority?

เพราะ Voice ไวต่อ:

Delay

Jitter

Packet Loss

Voice Packet จึงไม่ควร ต้องรอหลัง Bulk Traffic เป็นเวลานาน เมื่อเกิด Congestion

Priority Queue ไม่ควรใหญ่เกินไป

Priority Traffic
       |
       | Too Much
       v
Consumes Link
       |
       v
Other Classes
receive fewer resources

Priority Class จึงต้องถูกออกแบบ ตามปริมาณ Real-Time Traffic จริง ไม่ใช่ใส่ Application ทุกประเภท ลง Priority Queue

อย่าตีความ priority percent เป็น Reserved Bandwidth แบบง่าย ๆ Priority Command มีพฤติกรรมเฉพาะของ LLQ รวมถึงกลไกที่เกี่ยวข้องกับ Congestion และ Platform Implementation จึงต้องตรวจ Documentation ของอุปกรณ์ที่ใช้งานจริง

ภาค 6: Bandwidth Guarantee

bandwidth percent คืออะไร?

ตัวอย่าง:

class BUSINESS
 bandwidth percent 25

ใช้กำหนด Bandwidth Treatment ให้ Class ภายใต้ QoS Scheduler เมื่อเกิด Congestion ตาม Platform และ Policy Model

ไม่ใช่ Maximum Bandwidth เสมอไป

แนวคิดสำคัญคือ Bandwidth Guarantee ไม่จำเป็นต้องหมายความว่า Class นั้นห้ามใช้เกินค่าที่กำหนด เมื่อ Link ยังมี Capacity เหลือ 

Congestion
   |
   v
Guaranteed Share
   |
   v
Class receives
configured treatment

ถ้าต้องการควบคุม Maximum Rate ต้องพิจารณา Policing หรือ Shaping ตาม Requirement

ภาค 7: class-default

class-default คืออะไร?

Traffic ที่ไม่ Match Class ที่เราสร้างไว้ จะเข้า: 

class-default

ตัวอย่าง:

policy-map WAN-QOS

 class VOICE
  priority percent 10

 class BUSINESS
  bandwidth percent 25

 class class-default
  fair-queue

ดังนั้น Class-Default ไม่ควรถูกมองข้าม เพราะใน Network จริง Traffic จำนวนมาก อาจอยู่ใน Class นี้

ภาค 8: Service-Policy

นำ Policy ไปใช้กับ Interface

สร้าง Class-Map และ Policy-Map อย่างเดียว ยังไม่ทำให้ Policy ทำงานบน Traffic

ต้อง Apply:

interface GigabitEthernet0/0
 service-policy output WAN-QOS

Workflow ที่สมบูรณ์

class-map
   |
   v
policy-map
   |
   v
service-policy
   |
   v
interface
   |
   v
traffic

ภาค 9: Input กับ Output QoS

Direction สำคัญอย่างไร?

QoS Policy ต้อง Apply ใน Direction ที่ถูกต้อง 

             Router

Traffic ---> [ Gi0/0 ] --->
               ^
               |
             INPUT


Traffic <--- [ Gi0/0 ] <---
                         ^
                         |
                       OUTPUT
depending on traffic direction

ต้องคิดจากมุมมอง ของ Interface นั้น

ตัวอย่าง WAN Egress

LAN
 |
 v
Router
 |
 | OUTPUT
 v
WAN

ถ้าต้องการจัด Queue ก่อน Traffic ออก WAN มักพิจารณา Output Policy บน WAN-Facing Interface

ทำไม Queue มักเกี่ยวข้องกับ Output?

เพราะ Congestion มักเกิดเมื่อ Traffic กำลังรอส่งออกจาก Interface ที่มี Capacity จำกัด 

Fast LAN
   |
   v
Router
   |
   | Output Queue
   v
Slow WAN

ภาค 10: DSCP Marking ด้วย MQC

MQC สามารถ Mark Traffic ได้อย่างไร?

สมมติ Traffic ถูก Classification ด้วย ACL: 

ip access-list extended VOICE-SIGNALING
 permit tcp 10.10.10.0 0.0.0.255 host 10.20.20.10 eq 5060

สร้าง Class: 

class-map match-any VOICE-SIGNALING
 match access-group name VOICE-SIGNALING

จากนั้น Mark: 

policy-map MARK-QOS

 class VOICE-SIGNALING
  set dscp cs3
ตัวอย่างนี้ใช้เพื่ออธิบาย MQC Marking เท่านั้น Voice Signaling Protocol, Port และ DSCP ต้องกำหนดตามระบบจริง ไม่ควรสมมติว่า Voice Environment ทุกแห่ง ใช้ Protocol หรือ Marking แบบเดียวกัน

Marking Workflow

Packet
   |
   v
Classification
   |
   v
Policy-Map
   |
   v
set dscp
   |
   v
Marked Packet

ภาค 11: Policing บน Cisco

Policing ใช้ทำอะไร?

Policing ใช้ตรวจ Traffic Rate และจัดการ Traffic ที่เกิน Policy 

Traffic
   |
   v
Policer
   |
   +---- Conform
   |       |
   |       v
   |     Forward
   |
   +---- Exceed
           |
           v
       Drop / Remark
       depending on policy

ตัวอย่างแนวคิด MQC

policy-map POLICE-TEST

 class BUSINESS
  police 10000000

ตัวอย่างนี้สื่อแนวคิด การ Police Traffic ที่ประมาณ 10 Mbps แต่ Syntax, Default Burst, Actions และหน่วยที่รองรับ ต้องตรวจตาม Platform

อย่านำ Policing Configuration แบบสั้นไปใช้ Production โดยไม่ตรวจ Burst Parameter QoS Policer เกี่ยวข้องกับ Rate, Burst และ Token Bucket Behavior การกำหนดค่าไม่เหมาะสม อาจทำให้ Application ถูก Drop มากกว่าที่คาด

Policing เหมาะกับอะไร?

ตัวอย่าง Requirement:

Guest Traffic
must not exceed policy


Customer Traffic
must comply with contracted rate


Specific Application
must be rate limited

ภาค 12: Shaping บน Cisco

Traffic Shaping ใช้ทำอะไร?

Shaping ช่วยควบคุม อัตราการส่ง Traffic โดย Queue Traffic ส่วนเกิน ไว้ชั่วคราว แทนการ Drop ทันที แบบ Policing บาง Policy 

Traffic Burst
150 Mbps
   |
   v
Shaper
100 Mbps
   |
   +---- Send
   |
   +---- Queue
          |
          v
       Send Later

ตัวอย่าง MQC

policy-map WAN-SHAPER

 class class-default
  shape average 100000000

แนวคิดคือ Shape Traffic ไปที่ประมาณ 100 Mbps

Shaping Syntax, Rate Granularity, Queue Behavior และ Hardware Support แตกต่างกันตาม Platform ควรตรวจ Operational Result ด้วย Verification Command เสมอ

ภาค 13: Hierarchical QoS

Hierarchical QoS หรือ HQoS คืออะไร?

บาง Design ต้องการ: 

Shape Entire WAN
        |
        v
100 Mbps
        |
        +---- Voice Priority
        |
        +---- Video
        |
        +---- Business
        |
        +---- Default

นี่คือแนวคิดของ Parent Policy + Child Policy

Child Policy

policy-map CHILD-QOS

 class VOICE
  priority percent 10

 class VIDEO
  bandwidth percent 20

 class BUSINESS
  bandwidth percent 25

 class class-default
  fair-queue

Parent Policy

ตัวอย่างแนวคิด:

policy-map PARENT-SHAPER

 class class-default
  shape average 100000000
  service-policy CHILD-QOS

Apply Parent Policy

interface GigabitEthernet0/0
 service-policy output PARENT-SHAPER

ทำไมต้องมี Parent Shaper?

สมมติ Physical Interface เป็น 1 Gbps แต่ Provider Contract อนุญาตเพียง 100 Mbps: 

Router Interface
1 Gbps
    |
    v
Provider Service
100 Mbps

Router อาจไม่เห็น Physical Interface Congestion ที่ 100 Mbps เพราะ Local Interface ยังส่งได้ถึง 1 Gbps

Parent Shaper สามารถสร้าง Logical Bottleneck ใกล้กับ Service Rate เพื่อให้ Child QoS Policy จัด Queue ตาม Design ก่อน Traffic ไปถึง Provider Policer

นี่เป็นหนึ่งใน Use Case สำคัญของ Hierarchical QoS โดยเฉพาะ Ethernet WAN ที่ Physical Port Speed สูงกว่า Provider CIR หรือ Service Rate

ภาค 14: Cisco QoS Lab แบบครบขั้นตอน

Lab Requirement

สมมติ WAN Service:

100 Mbps

QoS Requirement:

Class DSCP Treatment
VOICE EF Priority 10%
VIDEO AF41 Bandwidth 20%
BUSINESS AF31 Bandwidth 25%
DEFAULT อื่น ๆ Remaining Resources

Step 1 — สร้าง VOICE Class

class-map match-any VOICE
 match dscp ef

Step 2 — สร้าง VIDEO Class

class-map match-any VIDEO
 match dscp af41

Step 3 — สร้าง BUSINESS Class

class-map match-any BUSINESS
 match dscp af31

Step 4 — สร้าง Child Policy

policy-map CHILD-QOS

 class VOICE
  priority percent 10

 class VIDEO
  bandwidth percent 20

 class BUSINESS
  bandwidth percent 25

 class class-default
  fair-queue

Step 5 — สร้าง Parent Shaper

policy-map PARENT-SHAPER

 class class-default
  shape average 100000000
  service-policy CHILD-QOS

Step 6 — Apply กับ WAN Interface

interface GigabitEthernet0/0
 description WAN-TO-ISP
 service-policy output PARENT-SHAPER

QoS Architecture ที่ได้

LAN Traffic
     |
     v
R1
     |
     v
PARENT-SHAPER
100 Mbps
     |
     v
CHILD-QOS
     |
     +---- VOICE
     |       LLQ
     |
     +---- VIDEO
     |       Bandwidth
     |
     +---- BUSINESS
     |       Bandwidth
     |
     +---- DEFAULT
             Fair Queue
     |
     v
ISP

ภาค 15: Verification

คำสั่งสำคัญที่สุด: show policy-map interface

show policy-map interface GigabitEthernet0/0

คำสั่งนี้สำคัญกว่า การดู Running Configuration อย่างเดียว เพราะช่วยให้เห็น Operational Counter ของ QoS Policy

สิ่งที่ต้องตรวจ

Service-policy output

Class-map VOICE

Packets Matched

Bytes Matched

Offered Rate

Drop Rate

Queue Statistics

Police Statistics

Shape Statistics

ตรวจ Class-Map

show class-map

ตรวจ Policy-Map

show policy-map

ตรวจ Interface

show interfaces GigabitEthernet0/0

มองหา:

Input Rate

Output Rate

Drops

Errors

Interface State

Running Config ใช้ตรวจอะไร?

show running-config | section class-map

show running-config | section policy-map

show running-config interface GigabitEthernet0/0

ใช้ตรวจ Configuration แต่ต้องใช้ Operational Commands ร่วมด้วยเพื่อพิสูจน์ว่า Traffic Match Policy จริง

อ่าน Counter อย่างไร?

สมมติ VOICE Class: 

VOICE

Packets Matched
=
0

แต่มี Voice Call กำลังใช้งานอยู่

นี่เป็นสัญญาณให้ตรวจ:

Is Voice really marked EF?

Is policy on correct interface?

Correct direction?

Does traffic cross this interface?

Is class-map matching correctly?

ถ้า Counter เพิ่ม แปลว่า QoS ทำงานสมบูรณ์แล้วหรือไม่?

ยังไม่จำเป็น

Counter เพิ่มพิสูจน์ว่า Traffic Match Class แต่ยังต้องตรวจ: 

Queue Behavior

Drops

Latency

Jitter

Application Quality

End-to-End Marking

ภาค 16: Cisco QoS Troubleshooting

Troubleshooting Workflow

Application Problem
        |
        v
Network Reachable?
        |
        v
Congestion?
        |
        v
QoS Policy Applied?
        |
        v
Correct Interface?
        |
        v
Correct Direction?
        |
        v
Class Counter Increasing?
        |
        v
Marking Correct?
        |
        v
Queue Drops?
        |
        v
Shaper / Policer?
        |
        v
Provider QoS?
        |
        v
End-to-End Test

Case 1 — Voice ไม่เข้า VOICE Class

ตรวจ:

show policy-map interface GigabitEthernet0/0

ถ้า:

VOICE
0 packets

ตรวจ DSCP จริง:

Expected
=
EF


Actual
=
CS0?

Root Cause อาจอยู่ที่ Endpoint หรือ Access Layer ไม่ได้ Mark Traffic ตามที่ QoS Policy คาดไว้

Case 2 — Policy สร้างแล้วแต่ไม่มีผล

ตรวจว่า Apply หรือยัง:

show running-config interface GigabitEthernet0/0

ต้องพบ:

service-policy output PARENT-SHAPER

การมี Policy-Map อยู่ใน Configuration ไม่ได้หมายความว่า Policy ถูกใช้งาน

Case 3 — Apply ผิด Direction

สมมติต้องการ Queue:

LAN
 |
 v
Router
 |
 v
WAN

แต่ Policy ถูก Apply: 

service-policy input WAN-QOS

Policy อาจไม่ได้จัดการ Traffic ใน Direction ที่ต้องการ

Case 4 — Voice ยังมี Jitter

ตรวจ:

Voice Classification

Voice Packet Rate

Priority Queue Drops

WAN Utilization

Physical Errors

Provider QoS

Remote Site QoS

End-to-End Delay

QoS ฝั่งเดียว ไม่สามารถรับประกัน End-to-End Quality ถ้า Bottleneck อยู่ที่อีกส่วนของ Network

Case 5 — Provider Drop Traffic

สถานการณ์:

Router Interface
1 Gbps
    |
    |
    v
Provider
100 Mbps CIR
    |
    v
Provider Policer

Router อาจส่ง Burst เกิน Service Rate จน Provider Drop

พิจารณา:

Parent Shaping
      |
      v
Rate aligned
with provider service

Case 6 — Backup ยังรบกวน Voice

ตรวจ:

Is Voice correctly classified?

Is backup classified?

Is congestion at this interface?

Is child policy active?

Is parent shaper working?

Is priority queue dropping?

Is bottleneck elsewhere?

Case 7 — Traffic เข้า class-default มากเกินไป

ถ้า Traffic ที่ควรเป็น VIDEO หรือ BUSINESS กลับอยู่ใน class-default ให้ตรวจ Classification 

Expected DSCP?

Actual DSCP?

Class-map correct?

Traffic remarked upstream?

ภาค 17: QoS Mistakes ที่พบบ่อย

1. สร้าง Policy แต่ลืม Apply

class-map
✓

policy-map
✓

service-policy
X

ผลคือ Policy ไม่ทำงานบน Interface

2. Apply ผิด Direction

Input กับ Output ต้องคิดจากมุมของ Interface

3. เชื่อ DSCP จากทุก Endpoint

ถ้า User สามารถ Mark Traffic เป็น EF ได้เอง Priority Queue อาจถูกใช้งานผิดวัตถุประสงค์

4. ใส่ Traffic มากเกินไปใน Priority Queue

Voice
Video
ERP
Web
Backup
     |
     v
PRIORITY

นี่ไม่ใช่ QoS Design ที่ดี

5. ไม่สร้าง Logical Bottleneck ให้ตรง Service Rate

พบได้เมื่อ: 

Physical Interface
=
1 Gbps


Provider CIR
=
100 Mbps

ถ้า Congestion เกิดที่ Provider แทนที่จะเกิดที่ Router Queue Local QoS อาจควบคุม Traffic ได้ไม่ตรงตามที่ต้องการ

6. ดูแต่ Configuration ไม่ดู Counter

QoS ต้อง Verify จาก Operational Data 

Configuration
+
Counters
+
Traffic Test
+
Application Result

7. ทดสอบเฉพาะตอน Link ว่าง

Queuing Policy ต้องถูกทดสอบ ภายใต้ Congestion

ภาค 18: Production QoS Best Practices

1. Measure Traffic ก่อนสร้าง Policy

เก็บข้อมูล:

Peak Utilization

Application Mix

DSCP Distribution

Voice Calls

Video Sessions

Business Traffic

Backup Window

2. กำหนด Enterprise QoS Classes

เช่น:

REALTIME

VIDEO

BUSINESS

DEFAULT

BULK

ไม่ควรให้แต่ละ Site สร้าง Class Naming และ DSCP Mapping คนละแบบโดยไม่มีเหตุผล

3. กำหนด Trust Boundary

Endpoint
   |
   v
Access Layer
   |
   v
Trust / Remark
   |
   v
QoS Domain

4. ใช้ Priority เฉพาะ Traffic ที่จำเป็น

โดยเฉพาะ Real-Time Traffic ที่มี Requirement ชัดเจน

5. ตรวจ Physical Speed กับ Service Rate

อย่าสมมติว่า: 

Interface Speed
=
Provider Bandwidth

สองค่านี้อาจต่างกันมาก

6. ตรวจ Provider QoS Policy

ต้องรู้:

Supported DSCP

Provider Classes

CIR

Policing Behavior

Queue Allocation

Remarking Policy

7. Monitor show policy-map interface

หลัง Deploy ควรตรวจ Counter เป็นระยะ

8. ใช้ Change Management

QoS Policy ที่ผิด สามารถทำให้ Business Application ถูก Drop หรือถูกจำกัด Bandwidth โดยไม่ตั้งใจ 

Backup
   |
   v
Change
   |
   v
Apply
   |
   v
Verify
   |
   v
Monitor
   |
   +---- Success
   |
   +---- Problem
           |
           v
        Rollback

9. Document QoS Design

Class Match Treatment
VOICE DSCP EF Priority
VIDEO DSCP AF41 Guaranteed Bandwidth
BUSINESS DSCP AF31 Guaranteed Bandwidth
DEFAULT Unmatched Default Queue

ภาค 19: คำถามที่พบบ่อย

Cisco MQC คืออะไร?

MQC หรือ Modular QoS CLI เป็น Framework สำหรับสร้าง QoS Policy โดยใช้ Class-Map, Policy-Map และ Service-Policy

Class-Map ใช้ทำอะไร?

ใช้ Classification เพื่อระบุว่า Traffic ใด อยู่ใน Class ใด

Policy-Map ใช้ทำอะไร?

กำหนด Treatment ให้แต่ละ Traffic Class เช่น Priority, Bandwidth, Marking, Policing หรือ Shaping ตาม Feature ที่ Platform รองรับ

Service-Policy ใช้ทำอะไร?

ใช้ Apply Policy-Map กับ Interface หรือ Context ที่ Platform รองรับ

LLQ คืออะไร?

Low Latency Queuing เป็นกลไก Priority Treatment สำหรับ Traffic ที่ไวต่อ Delay เช่น Voice ใน QoS Architecture ที่รองรับ

bandwidth percent กับ priority percent เหมือนกันหรือไม่?

ไม่เหมือนกัน 

bandwidth percent
=
Bandwidth treatment /
guarantee under congestion


priority percent
=
Strict priority treatment
with LLQ behavior

รายละเอียดของ Scheduler และ Enforcement ขึ้นอยู่กับ Platform

Policing กับ Shaping ต่างกันอย่างไร?

Policing
=
Excess traffic
may be dropped or remarked


Shaping
=
Excess traffic
is queued and sent later

ทำไมต้องใช้ Hierarchical QoS?

Use Case สำคัญคือ Physical Interface Speed สูงกว่า WAN Service Rate 

1 Gbps Interface
      |
      v
100 Mbps Provider Service

Parent Shaper สามารถกำหนด Logical Rate และ Child Policy จัด Queue ภายใน Rate นั้น

คำสั่งไหนสำคัญที่สุดสำหรับ Troubleshoot MQC?

show policy-map interface

เพราะช่วยดูว่า Traffic Match Class หรือไม่ รวมถึง Counter, Queue, Drop, Police และ Shape Information ที่ Platform แสดง

QoS Policy มี Counter เพิ่ม แปลว่าทำงานถูกต้องทั้งหมดหรือไม่?

ไม่ Counter แสดงว่า Traffic เข้า Class แต่ยังต้องตรวจ: 

Correct Treatment

Drops

Delay

Jitter

Application Quality

End-to-End QoS

QoS สามารถแก้ Bandwidth ไม่พอได้หรือไม่?

QoS ช่วยจัดลำดับ การใช้ Bandwidth แต่ไม่สร้าง Capacity ใหม่

หาก Link ใช้งานเต็ม เป็นเวลานานอย่างต่อเนื่อง อาจต้องพิจารณา Bandwidth Upgrade ร่วมด้วย

บทสรุป

Cisco MQC ช่วยเปลี่ยนแนวคิด QoS ให้กลายเป็น Policy ที่สามารถ Configure, Verify และ Troubleshoot ได้อย่างเป็นระบบ

จำ Workflow หลัก:

CLASS-MAP
   |
   | What traffic?
   v

POLICY-MAP
   |
   | What treatment?
   v

SERVICE-POLICY
   |
   | Where?
   v

INTERFACE

ตัวอย่าง:

DSCP EF
   |
   v
VOICE Class
   |
   v
LLQ Priority
   |
   v
WAN Output

ถ้า Physical Interface เร็วกว่า Provider Service: 

Physical Port
1 Gbps
   |
   v
Parent Shaper
100 Mbps
   |
   v
Child QoS
   |
   +---- Voice
   |
   +---- Video
   |
   +---- Business
   |
   +---- Default
   |
   v
Provider

แต่ Configuration เพียงอย่างเดียว ยังไม่เพียงพอ

Network Engineer ต้อง Verify: 

Policy Applied?

Correct Direction?

Traffic Matching?

DSCP Correct?

Queue Drops?

Priority Queue Healthy?

Shaper Working?

Provider Policy Compatible?

และคำสั่งสำคัญคือ:

show policy-map interface

เพราะ QoS ที่ดี ไม่ได้พิสูจน์จาก Configuration แต่พิสูจน์จาก Traffic Counter, Queue Behavior, Application Performance และผลลัพธ์ภายใต้ Congestion จริง

เมื่อเข้าใจ QoS และ MQC แล้ว หัวข้อถัดไปจะเข้าสู่ การสร้าง Secure Connectivity ระหว่าง Network ผ่าน Infrastructure ที่เราไม่ควบคุมทั้งหมด

บทความถัดไป: VPN Fundamentals สำหรับ Network Engineer: Site-to-Site VPN, Remote Access VPN, IPsec และ Tunnel

Share this
Facebook Share X
TECHEREST COMMUNITY

Share your thoughts here

Join the conversation and share your perspective on this article.

Comments will load when you reach this section.
Older →