Hello Ahmed ,
I am pretty sure about the concept i have stated in my last email. As a
reference , you can read the MPLS QoS design guide chapter in the "End to End
Qos Network Design" book.
In the uniform mode the IP Precedence will always be copied into the EXP value
during label imposition (as you stated) .In disposition , you will always need
QoS groups on the egress PE (if explicit null is disabled of course) in order
to perform egress policy according to EXP value. Whenever the EXP value is
changed inside the cloud it is OK , our main target is to propagate the last
EXP value to the customer IP markings (provider and customer are considered one
entity).
There is also a great CCO link explaining different QoS tunneling modes.
Actually this link made my life much better.
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftdtmode.html
----- Original Message ----
From: ahmed mahmoud <[EMAIL PROTECTED]>
To: OSL CCIE Service Provider Lab Exam <[email protected]>
Sent: Wednesday, June 25, 2008 8:45:59 AM
Subject: Re: [OSL | CCIE_SP] QoS group
Hello Hisham
I have a doubt about the concept you stated
" *** The opposite is not correct i.e During label disposition (popping) the
EXP value is not copied to whatever is below it. The label will be popped and
nothing will be propagated downwards. "
as I believe that the "uniform mode " is the default one, where the IPP is
copied into the mpls-EXP at the imposition and mpls-EXP is copied back at the
poping... and whenever the mpls-EXP is changed through the SP cloud it will
affect both labels according to the command
"
set mpls experimental imposition
To set the value of the Multiprotocol Label Switching (MPLS) experimental (EXP)
field on all imposed label entries, use the set mpls experimental imposition
command in QoS policy-map class configuration mode.
"
but when we need to have the "pipe-mode" or "short-pipe mode" we should use
the other command
"
set mpls experimental topmost
To set the Multiprotocol Label Switching (MPLS) experimental (EXP) field value
in the topmost label on either an input or an output interface, use the set
mpls experimental topmost command in QoS policy-map class configuration mode.
"
Which will leave the VPN-label Exp unchanged So the IPP at the egress will not
be changed as well.
Thanks
Ahmed
On Tue, Jun 24, 2008 at 11:37 PM, hehsam elezaby <[EMAIL PROTECTED]> wrote:
Hello ,
I would like to add a piece of info which helped me so much during my lab
preparation and made me understand MPLS QoS scenarios very well.
*** The EXP field is copied from whatever there is below it during label
imposition. For example if we have an ingress PE and it is doing MPLS VPN label
imposition , it will apply same value as IP Precedence to both MPLS labels
being added on top of the IP packet.
*** The opposite is not correct i.e During label disposition (popping) the EXP
value is not copied to whatever is below it. The label will be popped and
nothing will be propagated downwards.
We always need QoS groups on PE routers when we do policies in the egress
direction to the CE based upon provider markings (EXP bits). The packet arrives
at the PE with only the VPN label and it copies the EXP value into the QoS
group and then performs egress policy based on whatever value is inside the QoS
group. This is what we usually call the "pipe mode". You will never need such a
setup if the customer packet already has DSCP or IP Precedence marking because
we will be simply doing our policy based on the original customer marking AKA
"short pipe" mode.
But what is for some kind of reason (usually a forced marking policy configured
in the middle of the provider network) the MPLS VPN packet will have different
EXP values on both labels and the PHP router (P router one hop before PE) will
then pop the topmost label and propagate the packet with an unrealistic label
i.e bottom label which should have been changed too but it actually didn't
(again as i explained in the second point , the EXP value will never be
propagated in a pop operation). We need to guarantee that the policy is based
upon the topmost label EXP value so we copy it into the QoS group on the PHP
router and then perform policy based on this value in egress direction to PE
router. This could be needed in both "pipe" and "short pipe" modes because it
is something related to the P router and not the PE.
Finally , if we have Explicit null enabled , we will never need any QoS groups
on the P routers because it will always be sending a dual stack label to the PE
router no matter what happens. But definitely we will still need it on PE
routers in egress policies as i explained before for the "pipe mode".
I hope this helps.
Hisham El-Ezaby
CCIE# 21190 (SP)
----- Original Message ----
From: mohamed hamed <[EMAIL PROTECTED]>
To: OSL CCIE Service Provider Lab Exam <[email protected]>
Sent: Monday, June 23, 2008 11:35:54 PM
Subject: [OSL | CCIE_SP] QoS group
Hi everyone,
Does anyone know where we should use the QoS group on P or PE Router?
As I understand that we usually use it on PE router, but I found some Labs on
the internetwork expert use it on P router as well
If anyone knows why we should use QoS grouo on P routers , please unicast me a
mail back
Mohamed Hamed
Network Consulting Engineer
Mobile(KSA-Riyadh): +966543464502
________________________________
Introducing Live Search cashback . It's search that pays you back! Try it Now
