(no subject)

From: adam gibs <adamgibs7_at_gmail.com>
Date: Sun, 27 Sep 2009 12:16:27 +0400

Rick,

In back-to-back VRF the new label will be assigned on core towards
distribution because in back-to back vrf the packet forwarded to isp is an
IP packet and packet which i will recieve from ISP will also be an IP packet
because view from my end to ISP is as such as CE device communicating
through BGP and from ISP end he will thing that am as a CE device, Correct
me if am wrong,

Suppose if am not policing inbound traffic on each VRF interface (coming
from ISP to CORE) it will utilize the link as much as he wants???? and that
traffic will continue utilizing till distribution switch. The LINK between
the distribution and the core is 10G no such problem for this link but what
about other clients which will also flow their traffic on link between ISP
and CORE they will survive,so what am thinking is the QOS what should be
implement on core for each VRF interface is 1 service policy output with the
bandwidth command according the SLA with the customer and 1 service input
policy configured with the police command where exceed traffic will be
dropped,Correct me what am suggesting is write????

Question 3

The IP precedence what i will receive from ISP end i should alter on links
between distribution and core ?????? OR core should just relay the TOS bits
to EXP bits,And which MPLS QOS will be applied on inbound traffic when i
dont configure an service policy output towards distribution switch,

Question 4
Bydefault ip precedence are copied to EXP and they are just relayed to other
end of customer untill and unless any alteration has been done in
intermediate routers of ISP????????

Immediate response will be appreciated.

On Sun, Sep 27, 2009 at 1:03 AM, Rick Mur <rmur_at_ipexpert.com> wrote:

> Hi Adam,
>
> To answer your first question it's definitely regular QoS as you don't
> exchange any labeled packets with your ISP, so there is no MPLS header to
be
> altered.
>
> The second question depends on how much the 10G link is utilized between
> the core and distribution. I would say that QoS would not be very much of
> use as most QoS techniques are based on congested links. It would only have
> any use if you would implement policing to restrict certain types of
> traffic. Again on a 10G link, I would say that's not really necessary, but
I
> don't have an overview on how much traffic is flowing over that link :-)
> The topology between Core and Distribution is also quite strange. You
> terminate MPLS VPNs from ISP to DS? Or are it just VRF sub-interfaces
> (VRF-Lite)?
>
>
> --
>
> Regards,
>
> Rick Mur
> CCIE2 #21946 (R&S / Service Provider)
> Sr. Support Engineer  IPexpert, Inc.
> URL: http://www.IPexpert.com <http://www.ipexpert.com/>
>
>
> On 26 sep 2009, at 22:32, adam gibs wrote:
>
> The Connection is as below
>>
>> CE---DS/PE-----CoreP/PE----ISP/PE,
>>
>> The link between distribution and the core is fiber 10 gig i dont want to
>> implement any bandwidth limitation on the links between distribution and
>> the
>> core i want let the customer use the 10 gig link upto the core but on core
>> VRF sub-interfaces facing to ISP which QOS i have to apply traditional QOS
>> or MPLS QOS ????.The packet will be a IPV4 am having a back to back vrf
>> connection with ISP.
>>
>> question 2:
>> The traffic which i will recieve from ISP definately i will police that
>> traffic according to CLient demand bandwidth but when it will travel
>> towards
>> the distribution switch i should implement QOS towards the distribution
>> switch???? or i shld implement MPLS QOS or i shld leave that traffic as
>> default,because i want the 10 Gig link between core and distribution shld
>> be
>> utilize as much as can.Can u advise me what are the drawback for this.
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Sun Sep 27 2009 - 12:16:27 ART

This archive was generated by hypermail 2.2.0 : Sun Oct 04 2009 - 07:42:04 ART