What I'm not sure though it whether it reflects the TOS into top-most label or all the labels in the stack by default -equivalence of the set mpls imposition cmd
If it does the top-most only by default -than you'd need to carry the top-most label markings form inbound do outbound interface on the PHP node And I found out that is not possible on 7200 running the 12.2.33 SR codes -as you can't do: exp to qos-group - qos-group to exp adam -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of ar Sent: Monday, September 19, 2011 11:35 AM To: [email protected]; [email protected] Subject: Re: [c-nsp] 7200 DSCP-to-EXP Mapping Thanks. I dont want to apply policy on all ingress interface of the PE to remark traffic. That's why I want to be sure on this TOS reflection.. If this is the case, is it safe enough to just do a policy-map on the PE-to-P interface matching for the reflected EXP bits? --- On Mon, 9/19/11, Mark Tinka <[email protected]> wrote: From: Mark Tinka <[email protected]> Subject: Re: [c-nsp] 7200 DSCP-to-EXP Mapping To: [email protected] Cc: "Tony" <[email protected]>, "ar" <[email protected]> Date: Monday, September 19, 2011, 12:26 AM On Friday, September 16, 2011 12:29:53 PM Tony wrote: > My understanding is that the 3 bits of the IP precedence > field are copied to the EXP as part of the MPLS > encapsulation. This is not platform (or even vendor) > specific. I can confirm that. Always best to mark your ingress packets with the right EXP value if you don't want surprises when queuing and scheduling happens upstream. Mark. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
