1 / 28

Case Study

Case Study. VoIP Case Study Topology. Amsterdam. Service Provider. Hong Kong. Ingress. Egress. General notes: Goal: To analyze typical Junos CoS configurations for edge and core routers in the context of a VoIP application Configuration is unidirectional (from subscriber to PABX)

odomj
Download Presentation

Case Study

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Case Study

  2. VoIP Case Study Topology Amsterdam Service Provider Hong Kong Ingress Egress • General notes: • Goal: To analyze typical Junos CoS configurations for edge and core routers in the context of a VoIP application • Configuration is unidirectional (from subscriber to PABX) • Simplifies and reduces the size of configuration examples • Provides one-way CoS—a similar set of configuration statements needed to provide CoS in the return direction so-0/1/1 45.2 fe-0/0/0 29.1 so-0/1/2 45.1 fe-0/0/0 29.2 10.222.x/24 Montreal fe-0/0/1 2.1 so-0/1/1 3.2 San Jose fe-0/0/1 2.2 so-0/1/1 3.1 Handset Data PABX Data Denver Transit PABX: private automatic branch exchange CoS configured in this direction only!

  3. VoIP Case Study Criteria: Ingress—1 of 2 • Use CoS to support VoIP, conventional Internet, and control traffic received from a customer • Classification and policing: • VoIP SIP signaling uses TCP/UDP port 5060 • RTP media channels use UDP with ports in the range of 16,000–16,500 • Classify all VoIP traffic as expedited forwarding • Classify IP precedence 6 or 7 as network control • Classify all remaining IP precedence 0 traffic as best effort • Police BE traffic to 1 Mbps with a 3000-byte burst; mark excess traffic as high loss priority

  4. VoIP Case Study Criteria: Ingress—2 of 2 • VoIP case study (contd.) • Scheduling and congestion control • Schedule VoIP traffic as high priority with at least 20 Mbps of capacity; limit maximum delay to 200 milliseconds • Schedule BE traffic with low priority and limit to 1 Mbps • Configure weighted random early detection (WRED) for the BE class so that a greater percentage of high loss priority traffic is discarded; only TCP traffic is subjected to WRED • Packet header rewrite • Rewrite the DSCP marker to accommodate BA classification; ensure that loss priority for the EF forwarding class is coupled between chassis

  5. Fabric RewriteMarker Ingress Node Classification and Policing Ingress Forwarding Policy BA Classifier Policing (Ingress) Multifield Classifier Egress Multifield Classifier Policing (Egress) Scheduler Shaper RED

  6. Ingress Node Multifield Classifier [edit firewall family inet filter mf-classify] user@San_Jose# show term 1 { from { protocol [ udp tcp ]; port 5060; } then forwarding-class expedited-forwarding; } term 2 { from { protocol udp; port 16000-16500; } then forwarding-class expedited-forwarding; } term 3 { from { precedence routine; } then { policer police-be; forwarding-class best-effort; } } term 4 { then accept; } Traffic associated with VoIP is classified as EF and accepted Precedence 0 traffic is directed to policer and classified as BE Network control is accepted and classified by ipprec-compatibility

  7. Ingress Policer and Filter Application • Policer marks excess data as high loss priority • mf-classify filter applied inbound on customer-facing interface [edit firewall] user@San_Jose# show policer police-be if-exceeding { bandwidth-limit 1m; burst-size-limit 3k; } then loss-priority high; [edit] user@San_Jose# show interfaces fe-0/0/0 unit 0 { family inet { filter { input mf-classify; } address 10.222.29.2/24; } }

  8. Fabric RewriteMarker Ingress Node Scheduling and WRED Ingress Forwarding Policy BA Classifier Policing (Ingress) Multifield Classifier Egress Multifield Classifier Policing (Egress) Scheduler Shaper RED

  9. Configuring Schedulers • Define a scheduler for all forwarding classes that are in effect [edit class-of-service] user@San_Jose# show schedulers be-scheduler { transmit-rate 1m exact; priority low; drop-profile-map loss-priority low protocol tcp drop-profile low-red; drop-profile-map loss-priority high protocol tcp drop-profile high-red; } ef-scheduler { transmit-rate 20m; buffer-size temporal 200000; priority high; } nc-scheduler { transmit-rate percent 5; priority low; } In this case study, buffer depth is set for the EF class only; delay is measured in microseconds You should always configure a network control scheduler to ensure that control protocols are not starved.

  10. Defining WRED Drop Profiles • Two drop profiles are required for the BE class in this example: • The low-red profile affects TCP traffic with low loss priority • 10% drop probability at 80% queue fill • The high-red profile affects TCP traffic with high loss priority • 10% drop probability at 50% queue fill • Drop profiles are referenced within a scheduler stanza (previous page) [edit class-of-service] user@San_Jose# show drop-profiles low-red { fill-level 80 drop-probability 10; } high-red { fill-level 50 drop-probability 10; }

  11. Link Schedulers to Classes and Interfaces • Define a scheduler map to link forwarding classes to schedulers • Place schedulers into effect on egress interfaces by linking them to a scheduler map [edit class-of-service] user@San_Jose# show scheduler-maps voip-case { forwarding-class best-effort scheduler be-scheduler; forwarding-class expedited-forwarding scheduler ef-scheduler; forwarding-class network-control scheduler nc-scheduler; } [edit class-of-service] user@San_Jose# show interfaces fe-0/0/1 { scheduler-map voip-case; }

  12. Fabric RewriteMarker Ingress Node Rewrite Table Ingress Forwarding Policy BA Classifier Policing (Ingress) Multifield Classifier Egress Multifield Classifier Policing (Egress) Scheduler Shaper RED

  13. Configuring DSCP Rewrite Table • Default DSCP rewrite table does not communicate loss priority for BE traffic • The voip-dscp-rewrite table imports default settings and defines a code point for BE traffic with high loss priority: • The voip-dscp-rewrite table is linked to the egress interface at the ingress node: [edit class-of-service rewrite-rules dscp voip-dscp-rewrite] user@San_Jose# show import default; forwarding-class best-effort { loss-priority high code-point 000001; } [edit class-of-service] user@San_Jose# show interfaces fe-0/0/1 scheduler-map voip-case; unit 0 { rewrite-rules { dscp voip-dscp-rewrite; } } Prepopulates new table with values from the default DSCP rewrite table

  14. Ingress CoS Configuration—Summary (1 of 2) [edit class-of-service] user@San_Jose# show drop-profiles { low-red { fill-level 80 drop-probability 10; } high-red { fill-level 50 drop-probability 10; } } interfaces { fe-0/0/1 { scheduler-map voip-case; unit 0 { rewrite-rules { dscp voip-dscp-rewrite; } } } } rewrite-rules { dscp voip-dscp-rewrite { import default; forwarding-class best-effort { loss-priority high code-point 000001; } } } . . .

  15. Ingress CoS Configuration—Summary (2 of 2) . . . scheduler-maps { voip-case { forwarding-class best-effort scheduler be-scheduler; forwarding-class expedited-forwarding scheduler ef-scheduler; forwarding-class network-control scheduler nc-scheduler; } } schedulers { be-scheduler { transmit-rate 1m exact; priority low; drop-profile-map loss-priority low protocol tcp drop-profile low-red; drop-profile-map loss-priority high protocol tcp drop-profile high-red; } ef-scheduler { transmit-rate 20m; buffer-size temporal 200000; priority high; } nc-scheduler { transmit-rate percent 5; priority low; } } The ingress node’s multifield classifier and policer configuration are not shown here.

  16. VoIP Case Study Criteria: Transit and Egress (1 of 2) • Use CoS to support VoIP, conventional Internet, and control traffic received from an upstream node • BA classification • Configure DSCP-based BA classification compatible with ingress node classification • Scheduling and congestion control • Schedule VoIP traffic as high priority with at least 20 Mbps of capacity • Schedule BE traffic with low priority, and limit this traffic to 1 Mbps • Configure RED profiles for BE traffic that discriminate on loss priority and TCP status flags

  17. VoIP Case Study Criteria: Transit and Egress (2 of 2) • VoIP case study (contd.) • Packet header rewrite • Rewrite the DSCP marker to accommodate BA classification in downstream nodes; ensure that loss priority for the EF forwarding class is coupled between chassis

  18. Fabric RewriteMarker Transit and Egress Node BA Classification Ingress Forwarding Policy BA Classifier Policing (Ingress) Multifield Classifier Egress Multifield Classifier Policing (Egress) Scheduler Shaper RED

  19. Configuring DSCP Classification Table • The voip-dscp-classify table defines code points for BE traffic with high and low loss priority • The DSCP classifiers must match the DSCP rewrite values in effect at the upstream node • Link the voip-dscp-classify table to the ingress interface at transit and egress nodes: [edit class-of-service classifiers dscp voip-dscp-classifier] user@Denver# show import default; forwarding-class best-effort { loss-priority high code-points 000001; } [edit class-of-service] user@Denver# show interfaces fe-0/0/1 unit 0 { classifiers { dscp voip-dscp-classifier; } } Prepopulates new table with values from the default DSCP classifier table

  20. Fabric RewriteMarker Transit and Egress Node Schedulers and WRED Ingress Forwarding Policy BA Classifier Policing (Ingress) Multifield Classifier Egress Multifield Classifier Policing (Egress) Scheduler Shaper RED

  21. Configuring Schedulers • Transit and egress nodes use the same scheduler configuration as the ingress node CoS designs must ensure consistent traffic handling among all nodes in the path. [edit class-of-service] user@Denver# show schedulers be-scheduler { transmit-rate 1m exact; priority low; drop-profile-map loss-priority low protocol tcp drop-profile low-red; drop-profile-map loss-priority high protocol tcp drop-profile high-red; } ef-scheduler { transmit-rate 20m; buffer-size temporal 200000; priority high; } nc-scheduler { transmit-rate percent 5; priority low; }

  22. Defining WRED Drop Profiles • Transit and egress nodes use the same drop profiles configured at the ingress node CoS designs are contingent on consistent and predictable traffic handling among all nodes in the path. [edit class-of-service] user@Denver# show drop-profiles low-red { fill-level 80 drop-probability 10; } high-red { fill-level 50 drop-probability 10; }

  23. Link Schedulers to Classes and Interfaces • A scheduler map links forwarding classes to schedulers and to egress interfaces [edit class-of-service] user@Denver# show scheduler-maps voip-case { forwarding-class best-effort scheduler be-scheduler; forwarding-class expedited-forwarding scheduler ef-scheduler; forwarding-class network-control scheduler nc-scheduler; } [edit class-of-service] user@Denver-3# show interfaces fe-0/0/1 { unit 0 { classifiers { dscp voip-dscp-classifier; } } } so-0/1/1 { scheduler-map voip-case; }

  24. Fabric RewriteMarker Transit Node Marking Ingress Forwarding Policy BA Classifier Policing (Ingress) Multifield Classifier Egress Multifield Classifier Policing (Egress) Scheduler Shaper RED

  25. Configuring Transit Node Marking • Transit nodes have the same DSCP rewrite table as the ingress node • Applied to transit node’s egress interface [edit class-of-service] user@Denver# show rewrite-rules dscp voip-dscp-rewrite { import default; forwarding-class best-effort { loss-priority high code-point 000001; } } [edit class-of-service] user@Denver# show interfaces so-0/1/1 scheduler-map voip-case; unit 0 { rewrite-rules { dscp voip-dscp-rewrite; } } No egress conditioning is required in this case study

  26. Transit/Egress Node CoS Configuration—Summary (1 of 2) . . . so-0/1/1 { scheduler-map voip-case; unit 0 { rewrite-rules { dscp voip-dscp-rewrite; } } } } . . . [edit class-of-service] user@Denver# show classifiers { dscp voip-dscp-classifier { import default; forwarding-class best-effort { loss-priority high code-points 000001; } } } drop-profiles { low-red { fill-level 80 drop-probability 10; } high-red { fill-level 50 drop-probability 10; } } interfaces { fe-0/0/1 { unit 0 { classifiers { dscp voip-dscp-classifier; } } } . . .

  27. Transit/Egress Node CoS Configuration—Summary (2 of 2) . . . rewrite-rules { dscp voip-dscp-rewrite { import default; forwarding-class best-effort { loss-priority high code-point 000001; } } } scheduler-maps { voip-case { forwarding-class best-effort scheduler be-scheduler; forwarding-class expedited-forwarding scheduler ef-scheduler; forwarding-class network-control scheduler nc-scheduler; } } schedulers { be-scheduler { transmit-rate 1m exact; priority low; drop-profile-map loss-priority low protocol tcp drop-profile low-red; drop-profile-map loss-priority high protocol tcp drop-profile high-red; } ef-scheduler { transmit-rate 20m; buffer-size temporal 200; priority high; } nc-scheduler { transmit-rate percent 5; priority low; } }

More Related