Hi, I'm having a scenarios for applying QoS on the entire customer network. Its something like this:
i. Equipment -> Layer2 SW -> PE VRF -> P
The equipment's traffics are not marked with anything at least, the equipment gateway would be the PE VRF. I'm thinking of such QoS in these scenarios:
i. PE ingress, match any based on the VRF and set dscp marking from here
ii. PE egress, match by the dscp marked @ the ingress interface and perform policing/shaping and then conversion to MPLS Experimental bit
iii. P ingress, implement congestion avoidance here, as far as I understand, congestion avoidance are based on dscp, if I perform DSCP convertion to EXP bit in the PE egress interface, would the P ingress interface still use the congestion avoidance?
I'm venturing into the possibility on how the QoS is best implemented in such scenarios, and appreciate if you guys with such experiences to shed some lights and ideas here...
can I safely says the approach would be something like this?
@ the PE
Router(config)# policy-map policy1
Router(config-pmap)# class class1
Router(config-pmap-c)# configure the dscp marking
check-in this policy as input under the vrf table as this is where the traffic would initiate from the equipment
Router(config)# policy-map policy2
Router(config-pmap)# class class2
Router(config-pmap-c)# match the dscp marked @ the input vrf
Router(config-pmap-c)# set the mpls experimental topmost bit
Router(config-pmap-c)# policing the traffic based on bandwidth percent or CIR
check-in this policy as input @ the PE egress interfaces -> P routers, means the PE egress interface will perform the EXP marking based on the DSCP bit and perform the policing here, would be be efficient way of doing QoS?
Then from there onwards, P routers only based on the EXP bit to adjust the congestion avoidance? But I saw we can use random-detect dscp @ the P routers, is there any congestion avoidance using the EXP bit @ the P routers end? As if we set the EXP bit on the PE egress interface, P routers would not be able to configure congestion avoidance based on the DSCP right?
I'm just venturing out the easier and cleaner way to configure the QoS so configuration maintenance would be better in near future.
The edge in a MPLS VPN L3 scenario is the VRF access link.
At the VRF access link you can mark the DSCP and/or directy mark the EXP bits in the MPLS label stack that will be used starting from link PE-P.
If you choice to mark the DSCP depending on your scenario this can mean different things:
the choice of a specific LSP, copying of a three bits subset of DSCP on the EXP bits (leftmost three in DSCP).
But this happens by default you don't need to explicitly configure the EXP marking.
About WRED: even if the syntax doesn't provide an EXP choice in the WRED commands the P router should be able to treat MPLS packets as expected.
How this happens can be a question of implementation.
I made functional and performance tests and I can say WRED works with a mix of IP and MPLS traffic as expected.
It can map EXP to DSCP EXP 000 for example and treat them according to setups for a DSCP field = EXP 000 i.e. a CSX in DSCP terminology. Or it can inspect the MPLS packet to find the DSCP field in the IP packet inside (less probable: the MPLS label stack depth can vary so this is less efficient)
Introduction: The "external-out enable" command is available for
configuration under the "router ospf process" in case of the IOS-XR
operating system. This command basically enables advertisement of
intra-area routes on the device as external routes in th...
Introduction Basic configuration for netflow Scale parameters for
netflow Netflow support Architecture Packet flow for netflow Inside the
LC CPU Netflow Cache size, maintenance and memory Sample usage Cache
Size Aging Permanent cache Characteristics Which...