Routing

Expand all | Collapse all

Class of Service with MPLS LSP's..

Jump to Best Answer
  • 1.  Class of Service with MPLS LSP's..

    Posted 04-26-2010 02:49

    Hi, i'm hoping someone can point me in the right direction on how to complete this;

     

    I have a MPLS based core network ( running on J6350s' ), with 1GB links configured between them.   I have a number of Layer 3 VPN's configured in this network and also a number of L2 VPN's.      The various layer 3 Vpn's and layer 2 vpns belong to different business units. 

     

    What i need to do, is make sure that one ( or more ) business units can't monolopise all the bandwidth on the various links, but i want to allow the business units to be able to 'burst' to use any 'available' bandwidth.

     

    Each business units  traffic arrives on seperate interfaces on the PE routers, so it is reletively easy to determine which traffic belongs to who.

     

    THe various bu's will have varying 'guarrentees' of service levels;

     

    VPN-A   300Mbs-1

    VPN-B   300Mbs-1

    VPN-C   200Mbs-1

     

    There will be a number of other services that will consume the remaining bandwidth, i know it doe'sn add up to 1000!

     

    What i am thinking i'd like to do is this;

     

    On the ingress interfaces of the PE, i'll mark all traffic coming in, as either exceeding the 'guarrenteed' traffic limit or as being below it.  ( i'm not sure what or how i shoudl 'mark' it with )

     

    On teh egress interface of teh PE, ( the MPLS side ), i'll use the 'markings' that were applyed in ingress to put the packets in various queues.  ( again i'm not sure of how i should do this )..

     

    FYI, all teh PE routers are diretly attacehd to each other, and there are no 'P' routers in this network, and given the reletively low number of clients, its fesible to set up these controls on each PE egress router..

     

    Coudl someone be kind enough to point me in the right direction.

     

     

     

     

     

     

     



  • 2.  RE: Class of Service with MPLS LSP's..
    Best Answer

    Posted 04-26-2010 13:27

    Andrew,

     

    There are many ways to accomplish this.  The simplest would be to perform ingress policing on the L3VPNs and use differential WRED.  I would caution against ever using a policer to split packets from a flow into more than one queue as it would guarantee out-of-order packets for anything exceeding the policer.  A better way to do this would be to classify all customer traffic into a single forwarding-class and queue-separate each customer.  But with only 8x outgoing queues per port this would limit the scalability of the solution.

     

    Here's how I would use policing/wred to accomplish your goal:

     

    On the ingress interface (customer-facing) attach a firewall filter with a policer (or you can attach a logical-interface policer under the [ edit interfaces ge-x/y/z unit n ] hierarchy with a "family inet policer input <policername>".  The exceed action on the policer is set to loss-priority high.  This is an internal marking on the packet metadata within the router which can be used to trigger differential WRED on out-of-spec packets.

     

    The policers are defined under [ edit firewall ]

     

     

    policer 300m {
        if-exceeding {
            bandwidth-limit 300m;
            burst-size-limit 300k;
        }
        then loss-priority high;
    }
    policer 200m {
        if-exceeding {
            bandwidth-limit 200m;
            burst-size-limit 200k;
        }
        then loss-priority high;
    }

     

     

    The policers are attached to the customer-facing ports.  In this case, ge-0/0/1 is VLAN-tagged with each tag corresponding to a customer:

     

    interfaces {
        ge-0/0/1 {
            description Customer-Facing;
            vlan-tagging;
            link-mode full-duplex;
            unit 100 {
                vlan-id 100;
                family inet {
                    policer {
                        input 300m;
                    }
                    address 10.1.1.1/24;
                }
            }
            unit 200 {
                vlan-id 200;
                family inet {
                    policer {
                        input 300m;
                    }
                    address 10.1.2.1/24;
                }
            }
            unit 300 {
                vlan-id 300;
                family inet {
                    policer {
                        input 200m;
                    }   
                    address 10.1.3.1/24;
                }       
            }           
        } 
    }

     

     

     

    The logic here is that ingress traffic is run through the policer (in this example 300Mb/sec with a 300k burst-size).  Any packets not exceeding the policer go un-marked.  Any packets exceeding the policer are marked (but not droppped).  You would attach  policers to each customer-facing interface.


    Then, as packets are enqueued to the egress (core-facing) interface, you would configure CoS so that if the queue depth increases the marked packets are dropped before other traffic.   This way, traffic up to the policed amount goes through unmolested, but excessive traffic is subject to drop in the event of congestion.

     

    Here's an example of a simple CoS config that will apply separate WRED profiles to marked vs unmarked traffic (in this case applied to the MPLS core interface ge-0/0/0):

     

     

    class-of-service {
        drop-profiles {
            aggressive {
                interpolate {
                    fill-level [ 50 75 90 100 ];
                    drop-probability [ 0 50 75 100 ];
                }
            }
            hockeystick {
                interpolate {
                    fill-level [ 75 90 100 ];
                    drop-probability [ 0 75 100 ];
                }
            }
        }
        interfaces {
            ge-0/0/0 {
                scheduler-map wan;
            }
        }
        scheduler-maps {
            wan {
                forwarding-class best-effort scheduler sch-normal;
                forwarding-class network-control scheduler sch-nc;
            }
        }
        schedulers {
            sch-normal {
                transmit-rate percent 90;
                buffer-size percent 90;
                priority low;
                drop-profile-map loss-priority high protocol any drop-profile aggressive;
                drop-profile-map loss-priority low protocol any drop-profile hockeystick;
            }
            sch-nc {
                transmit-rate percent 5;
                buffer-size percent 5;
                priority high;
            }
        }
    }

     

    Packets that exceed the policers are marked with a loss-priority of high.  Then as these are placed on the egress interface queue, any PLP-high packets are subject to the "aggressive" WRED profile (which starts dropping at 50% queue depth).  Any unmarked packets are left alone until the queue becomes extremely congested, then the "hockeystick" profile kicks in to provide fair-drops to protect TCP throughput.

     



  • 3.  RE: Class of Service with MPLS LSP's..

    Posted 04-26-2010 23:27

    Hi Dan,

     

    Thankyou for a very thoughtful reply and a great description of the logic that you've applied.    As you say, there are many ways to acheive this, and i'd thought of at least three, but i'd not considered using this model.. It is another example of how flexible Junos is.

     

    If you wanted to extend this model to support different dcsp classifications, would you be able to acheive this? I don't really need very many queues four would be more than sufficent.

     

     

     

     



  • 4.  RE: Class of Service with MPLS LSP's..

    Posted 05-31-2013 22:11

    Hi JNPRdbackman, your response here was really good, hoping you can help me with a similar requirement.

     

    I have pictured my current network in its basic form below.

     

    I have 2 providers I use to connect R2 to R3, the 2 pipes are 400mb and 100mb in size.

    I have built 2 LSP's between R3 & R2, one LSP is 100mb and the other is 400Mb

    I have built 2 LSP's between R3 and R1, one LSP is 100mb and the other is 300Mb.

    I have turned on load-balance bandwidth and enabled load-balance-traffic in the forwarding-table.

     

    Traffic is working pretty well and load sharing across the 2 links, however I'm not sure if R3 thinks it has 1Gb of capacity due to the 2 x 400mb and 2 x 100mb LSP's built, in actual fact this should be shared, so this is my first problem.

     

    Second problem I have is in the image you can see "Layer 2 customer" off R3 and R1, this customer should have guarenteed 100Mb. The second layer2 customer on R3 and R2 should have guarenteed bandwidth of 50mbps and burst to 100mb when available. Internet customers (They are in a L3VPN routing instance called International) hanging off R1 & R2 going out R3 to equinix should only use remaining bandwidth.

     

    So in summary I have:

    -500Mb capacity between R2 & R3

    -Layer 2 customer should have guarenteed 100Mbps no burst

    -2nd Layer 2 customer should have guarenteed 50Mbps and allowed to burst to 100Mbps

    -Customers in the routing instance International should have 350Mb guarenteed and burst to 500Mbps (total capacity) when available.

     

    Any help on achiving this would be greatly appreciated.

     

    2013-06-01 16.56.58.jpg

     

    Many thanks

    Barry



  • 5.  RE: Class of Service with MPLS LSP's..

    Posted 07-28-2015 21:59

    If we config policer and multifield classifier,MF will take priority over policer that assign forwarding-class right ?