QoS and Traffic shaping across MPLS?

Discussion in 'Cisco' started by Rob, Oct 5, 2005.

  1. Rob

    Rob Guest

    I am trying to setup CoS, QoS and queuing across our MPLS network
    through our service provider. We don't run any MPLS natively; it is
    all done by them. Most of the materials I have and references on
    Cisco's web site don't mention MPLS that much, so I'm not quite sure
    which "kind" of congestion control or avoidance I should implement.

    We have a 45Mb DS3 at our datacenter, and multiple smaller sites with
    either single T1's or dual MLPPP bonded T1's. We are all meshed and
    everyone routes to everyone equally through OSPF. 'Very nice network,
    and much better than our old AT&T Frame-relay. My problem is I want
    to do QoS for VoIP through my network and I'm scratching my head as to
    the best method given the network.

    As everyone here knows, with most direct point-to-point links such as
    T1, the egress speed is identical to the ingress speed. 1.544 =
    1.544. Your only concern is to apply appropriate queuing out of the
    serial interface to prioritize your favorite packets in whatever order
    you see fit. LLQ, CBQ, Fair-queueing, FIFO, whatever. It'll simply
    travel down the pipe and be received in that same order. However,
    with dissimilar link sizes, like going from a DS3 to a DS1, this can't
    be easily done! A 45Mb DS3 would never see it as congestion on its'
    side, although the poor little DS1 certainly would.

    My question is -- Do most service provider's MPLS networks apply any
    traffic shaping or queuing mechanism within the cloud at all? Or does
    it need to be completely controlled by me? Are packets dropped (I
    assume so…) when the end node can't receive traffic as fast as the
    head node can send?

    There are a lot of QoS and congestion avoidance mechanisms available
    in Cisco IOS, but most of them refer to Frame-relay. I was thinking
    of applying the same traffic-shaping syntax to my own Cisco routers,
    except that I don't have to worry about any CIR value - only port
    speed. There is also no MPLS equivalent of BECN's or FECN's that I'm
    aware of, so I'm not quite sure if the MPLS cloud would send me any
    feedback if packets were indeed dropped. So can I even use LLQ +
    CBWFQ to seperate my voice from everything else? Or do I also have to
    figure out generic traffic shaping and incorporate it into the mix?

    Thanks.
    -Bob
     
    Rob, Oct 5, 2005
    #1
    1. Advertisements

  2. Rob

    stephen Guest

    ours does - if you subscribe to the QoS options (there is a charge for high
    priority bandwidth), then we push your packets thru the cloud using 3 bits
    of priority which are part of MPLS.

    PE router at the far end uses the markings to decide what to send.

    even if you fix this, you need to limit high priority traffic. the IPT
    system may have some tools to limit bandwidth or number of calls across each
    pipe.
    www.cisco.com/go/srnd has some info on call manager configs for WANs that
    explains the Cisco mechanism, but the concepts should be pretty general.
    Nope. the access link may run F/Relay encapsulation but i havent seen any
    mapping to FECN / BECN.

    So can I even use LLQ +
    Yes - but some of the problems need either a lightly loaded network, or help
    from the telco.

    Or do I also have to
    you need to mark the packets so that the MPLS cloud "knows" what priority to
    work with - so oyu need to fit in with the priority scheme the cloud is set
    for.

    Without that there is probably enough bandwidth in the MPLS that discards
    and jitter are not a major issue, but you may have problem where the access
    pipe exits the cloud

    you could shape all your traffic to stay inside the bandwidth or you may get
    discards at the outbound PE interface - and if you shape the traffic that
    hard you might as well go back to a real F/Relay network.....
     
    stephen, Oct 5, 2005
    #2
    1. Advertisements

  3. Rob

    Rob Guest

    My provider is Global Crossing, and they do have different service
    queues for Basic, Enhanced and Premium. I can setup (with them)
    whatever IP Precedence or DSCP bits I want to represent each class.
    They do have a defined priority of 90% / 9% / 1% is there is
    congestion on their network. I am not so worried about that as what
    do I do for my side of the QoS and queueing to insure that my
    datacenter DS3 doesn't flood a remote T1. I know TCP is self
    sufficient, but UDP is not. I am running VoIP now over those links,
    but I have not begun to have any congestion issues where I need QoS,
    but I can see it coming. Is simply having my appropriate voice
    packets marked as DSCP 'EF' which sends it down the "Premium" pipe
    good enough? I wouldn't think so. Should I just implement LLQ +
    CBWFQ, or should I even worry about traffic shaping?

    -Bob
     
    Rob, Oct 5, 2005
    #3
  4. Rob

    stephen Guest

    its not flooding that is the issue, its limiting high priority traffic.

    make sure the Voip is limited so that it doesnt go over the amount of
    traffic GS will allow at high priority.

    so long as they implement QoS on their routers, if there is low priority
    congestion then they throw low priorty packets in preference to high
    priority.

    I know TCP is self
    you need something like LLQ.

    i suggest you force some overloads so that you understand how it works
    before you have to do diagnostics on the fly.
     
    stephen, Oct 5, 2005
    #4
  5. Rob

    Igor Mamuzic Guest

    I had a similar problem like yours and it appears like solved for now.
    I don't have a MPLS cloud between my sites since remote sites are connecting
    onto central site for accessing corporate web applications using SSL (trough
    the Internet). So, what I done:

    - Let say that you have a central site router (R1) connected with 2 Mbps FR
    to my ISP. Remote site router (R2) is using 1 mbps ADSL Internet connection.
    There is always been a problem when R2 router had overloaded it's ADSL by R1
    since it has a faster link then R2.
    To prevent such behavior I simply implemented CB traffic shaping and place
    that policy-map at the inside R2's interface because you must implement TS
    for outbound traffic. For TS value use bit rate for about 5% lower than your
    bw defined with SLA. Now you may place CBWFQ classes as nested in TS to
    provide prioritization at R2 site for certain traffic classes (downstream
    traffic from R1 actually).
    Doing this way you have to sacrifice 5% of your actual SLA bw, but you'll
    get control (static only, that is without congest. dicovery such as
    FECN/BECN) over congestion and QoS between remote sites over ISP networks
    which you don't control. It seems to work for me (actually I run such setup
    for about a 1 year with no problems discovered yet). Of course, such setup
    suppose that your ISP's are providing bw defined in SLA... Actually, thanks
    to this setup I discovered that 1 of my SP's had incorrectly implemented TS
    since I could never achieve bit rate (to bring my TS active) when I
    transmitted with bit rate even for 5% lower then my actual SLA. After I
    presented them such proof they had to correct their ATM TS misconfig. and
    now it works fine:)

    I realize that my explanation could be a little bit unclear, so on your
    request I'll provide sample topology and configs...

    B.R.
    Igor
     
    Igor Mamuzic, Oct 6, 2005
    #5
  6. Rob

    Rob Guest

    Igor,
    I am familiar with shaping outbound traffic from an ADSL line because
    of my Vonage use across the Internet. I'm not sure the analogy is the
    same with my work. My T1's are also not asymetric. My biggest
    concern is whether or not I have to do traffic shaping or other form
    of QoS at the DS3 headend.

    Did you perform any LLQ or CB queuing on your R1?
     
    Rob, Oct 6, 2005
    #6
  7. Rob

    Igor Mamuzic Guest

    Rob,

    For your VoIP traffic (this is one of your traffic kind if I understood well
    your posts) you should implement LLQ (inside CBTS if you follow my advice)
    since you don't want your VoIP traffic to starve lower priority traffic.

    I use CB TS for outbound traffic on R1. I shape it also for the 5 % less
    then my SLA contracted bw to avoid packet loss in the carrier network if I
    run over contracted BW. Then inside of the CB TS policy-map I nest CBWFQ
    classes (for example outbound traffic sourced from my business application
    www server) to give some priority for this traffic. On this way I hopefully
    have all eventual packet loss controlled on my R1 and not in the carrier
    network which I don't control.

    In my career once I had a problem with excessive outbound traffic drop at my
    serial interface (FR) and Cisco TAC engineer advised me to implement any
    kind of traffic shaping at my R1 better then letting my SP's cloud doing
    this without my control.
    In this way if you experience poor transmission performances and your TS
    seems do be inactive then you know that (if there is no IOS bugs:) )
    something is wrong in your carrier's cloud...
    But, there is a little let say caveat in my approach to this problem: if you
    don't implement any TS, but only CBWFQ/LLQ then if your interface out queue
    becomes saturated CBWFQ or LLQ will manage congestion to provide priority...
    On the other hand, with CBWFQ/LLQ nested inside of the CBTS policy-map your
    queueing method will never be aware of congestion in the carrier cloud,
    since it activates only if you exceed TS transfer value, but anyway your
    carrier should provide you with error free transmission (in ideal world:) )
    anyway so you don't have to worry about this "caveat":)

    B.R.
    Igor
     
    Igor Mamuzic, Oct 7, 2005
    #7
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.