[Fwd: RE: [c-nsp] MPLS EXP label imposition]

[David Freedman]

Ok, I was fearing the worst on this one.

There are a number of reasons why ingress policy such as this on all our 
entrypoints is not really a good solution for us at this time,

I'm going to try and open a TAC case today to see if there is anything 
else that can be done, just in case,
I'll keep the list updated if I find anything.

Thanks again,

Dave.


Neil J. McRae wrote:
> Dave,
> Nope, you need to do it on all entry points. There are
> other good reasons why you'd want to do this also. Bewarey
> of GSR cards that can't cope with this though, trident E2 
> being one of them. I agree that this is a PITA.
> 
> Neil. 
> 
>> -----Original Message-----
>> From: cisco-nsp-bounces at puck.nether.net 
>> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Freedman
>> Sent: 12 September 2005 10:15
>> To: cisco-nsp at puck.nether.net
>> Subject: [Fwd: RE: [c-nsp] MPLS EXP label imposition]
>> 
>> /me forwards this on.
>> 
>> Does anybody else have a strategy for dealing with this?
>> 
>> I can't say that the default cisco behaviour of copying QoS 
>> information from IP to MPLS automatically is a good thing for 
>> us at the moment....
>> 
>> 
>> Dave.
>> 
>> -------- Original Message --------
>> Subject: RE: [c-nsp] MPLS EXP label imposition
>> Date: Mon, 12 Sep 2005 08:33:11 +0200
>> From: Oliver Boehmer (oboehmer) <oboehmer at cisco.com>
>> To: David Freedman <david.freedman at uk.clara.net>
>> 
>> David Freedman <mailto:david.freedman at uk.clara.net> wrote on Friday,
>> September 09, 2005 12:39 PM:
>> 
>> >  >> If it is the default behaviour whether there is a global
>> >  configuration >> to prevent this from happening.
>> >  >> Or, if the only way to prevent this from happening is 
>> to manually
>> >  >> rewrite all precedence bits to 0.
>> >  >
>> > 
>> > Following on from Merlin's Question, We're currently 
>> looking at a way
>> > of avoiding having to do this on all entrypoints.
>> >
>> > The problem is, whereas its simple to imply on connections 
>> external to
>> > the network (such as peering and transit), its not so simple when it
>> > comes down to implying it on Gateway / PE routers, of which we have
>> > lots in multiple countries with literally thousands of
>> > interfaces/subinterfaces. 
>> 
>> I don't know anything about your network, but if it resembles 
>> most other
>> ISP networks, I don't think there is much you can do other 
>> than applying
>> a generic policy-map on all customer interfaces. Since you can use the
>> same policy-map on all interfaces where you want to re-mark 
>> the pkts to
>> dscp default, this process should be script'able.
>> 
>> > We are mainly concerned, therefore in securing PE routers.
>> > 
>> > I experimented with QPPB for this, on the PE->P interfaces, 
>> with a map
>> > that set precedence to zero , such as:
>> 
>> I don't think QPPB will do what you want as it will, as you say, not
>> differentiate between customers allowed to mark their pkts 
>> and those who
>> don't.
>> 
>> > Does anybody else have any ideas?
>> 
>> you sent this email unicast to me ;-)
>> 
>> 	oli
>> 
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>