SD-WAN

 View Only
last person joined: 18 hours ago 

Ask questions and share experiences with SD-WAN and Session Smart Router (formerly 128T).
Back to discussions
Expand all | Collapse all

From a Traffic Engineering perspective I am aware of the ability to rate limit the egress traffic on a per device-interface basis via a transmit-cap in bps. Are you able to manipulate the percentage reserved per class on a per interface basis?

  • 1.  From a Traffic Engineering perspective I am aware of the ability to rate limit the egress traffic on a per device-interface basis via a transmit-cap in bps. Are you able to manipulate the percentage reserved per class on a per interface basis?

     
    Posted 12-13-2017 00:00


  • 2.  RE: From a Traffic Engineering perspective I am aware of the ability to rate limit the egress traffic on a per device-interface basis via a transmit-cap in bps. Are you able to manipulate the percentage reserved per class on a per interface basis?

     
    Posted 12-13-2017 00:00

    Hey Scott Inguagiato the current default reservation per priority is as follows (as of `3.1.7`):

    • `0` -> 80% of transmit capacity
    • `1` -> 10% of transmit capacity
    • `2` -> 9% of transmit capacity
    • `3` -> 1% of transmit capacity

    Currently the reservations are fixed, however upcoming enhancements are planned to allow reservation to be defined by configuration.



  • 3.  RE: From a Traffic Engineering perspective I am aware of the ability to rate limit the egress traffic on a per device-interface basis via a transmit-cap in bps. Are you able to manipulate the percentage reserved per class on a per interface basis?

     
    Posted 12-13-2017 00:00

    Worth noting is that folks interested in trying traffic engineering should use 3.1.7 or newer. The values that Reid L Stidolph mentions above were tuned (for the better) in that release, and 3.1.7 represents a good baseline for testing TE.



  • 4.  RE: From a Traffic Engineering perspective I am aware of the ability to rate limit the egress traffic on a per device-interface basis via a transmit-cap in bps. Are you able to manipulate the percentage reserved per class on a per interface basis?

    Posted 12-13-2017 00:00

    I recently watched your demo of TE (https://www.youtube.com/watch?v=0vSd8qBIWGA). The demo modeled ""Gold"", ""Silver"" type classes. Do these correspond to 0 to 3 above? If so, can you change the percentage of traffic for each class? I'm trying to create a circuit that will support a reservation for real time audio & video of 30%. I'm also worried about network routing protocols and network management traffic. Is this always treated automatically as the highest priority?



  • 5.  RE: From a Traffic Engineering perspective I am aware of the ability to rate limit the egress traffic on a per device-interface basis via a transmit-cap in bps. Are you able to manipulate the percentage reserved per class on a per interface basis?

     
    Posted 12-13-2017 00:00

    Hi Will, in our current (3.1.x) software the priorities are numbered 0-3 and the percentages for each priority are fixed as Reid L Stidolph mentions above. In the forthcoming 3.2.x software we've changed things around a bit to be more user friendly... they'll be named high/medium/low/best-effort, and the percentages you give to each can be tuned to your liking.

     

    We've tried to follow industry/standards body Best Practices when assigning traffic class priorities to different traffic classes in our factory default configuration (e.g., Telephony is high by default, whereas LowPriorityData is best-effort). But you can adjust these to suit your particular environment by setting the configurations as you see fit. These factory defaults are already part of your configuration, but we hide them in order to make things a bit more tidy... if you type ""show config candidate verbose"", the verbose modifier shows all of the stuff that's normally hidden. (Once you change these factory defaults, the PCLI will show them without the ""verbose"" flag.)

     

    If, in your environment, you wanted OAM traffic to be treated with the utmost priority, set its priority/traffic-class to 0/high (for 3.1.x/3.2.x, respectively). Likewise for any other class of traffic.