I m trying to find out whether we have any problem with our router L2vpn configurations. At the moment we don't have any QoS policy applied on the L2vpn SAPs, below is the output from the L2 service on the router.
Would like to know more info on the meaning of the Dro. OutProf details shown below
A:CANR23# show service id 88 sap 1/3/2 stats
===============================================================================
Service Access Points(SAP)
===============================================================================
Service Id : 88
SAP : 1/3/2 Encap : null
Description : (Not Specified)
Admin State : Up Oper State : Up
Flags : None
Multi Svc Site : None
Last Status Change : 02/03/2017 15:59:06
Last Mgmt Change : 10/14/2016 17:21:55
-------------------------------------------------------------------------------
Sap per Queue stats
-------------------------------------------------------------------------------
Packets Octets
Ingress Queue 1 (Priority)
Off. HiPrio : 0 0
Off. LoPrio : 9995389721996 9120538343110699
Dro. HiPrio : 0 0
Dro. LoPrio : 0 0
For. InProf : 0 0
For. OutProf : 9995389721996 920538343110699
Egress Queue 1
For. InProf : 0 0
For. OutProf : 693908663496 857043492514928
Dro. InProf : 0 0
Dro. OutProf : 904524897 2303524553385
===============================================================================
SAP Ingress and Egress Verification on L2VPN
Re: SAP Ingress and Egress Verification on L2VPN
With no QoS applied, the default is a single queue containing all traffic, with a PIR of max and a CIR of zero.
Traffic above the CIR is classified by the scheduler as out of profile.
Hence with a CIR of zero, by default, all traffic is classified as out of profile.
Classifying some traffic as in profile and with an appropriate CIR would mean that the scheduler services that first before doing a second pass for the out of profile traffic.
You could have a read from the section "Dequeuing Packets: Queue Rates" onwards at the section on
QoS Architecture and Basic Operation in the Advanced Configuration Guide.
Traffic above the CIR is classified by the scheduler as out of profile.
Hence with a CIR of zero, by default, all traffic is classified as out of profile.
Classifying some traffic as in profile and with an appropriate CIR would mean that the scheduler services that first before doing a second pass for the out of profile traffic.
You could have a read from the section "Dequeuing Packets: Queue Rates" onwards at the section on
QoS Architecture and Basic Operation in the Advanced Configuration Guide.
Re: SAP Ingress and Egress Verification on L2VPN
Thank you Miven
one last question, when reviewing the stats collected and found a Dro. OutProf stats to be high - Does that sound an alarm with my configs? or i dont have to worry that everything is fine
one last question, when reviewing the stats collected and found a Dro. OutProf stats to be high - Does that sound an alarm with my configs? or i dont have to worry that everything is fine
Re: SAP Ingress and Egress Verification on L2VPN
I would say it depends what the traffic levels are on that egress port.
If the egress port is getting over-subscribed and you're trying to send a sustained level of traffic faster than line-rate then you should expect drops, no matter what the config. QoS can help you choose which traffic to drop (as well as do other things like minimise the jitter/latency if you have a sub-set of traffic that is sensitive to it), But there will still be drops if there's too much traffic, unless you police or shape the traffic upstream.
Alternatively, you could be not getting to line-rate and the drops are because of bursts. One reason might be because there are higher bandwidth ingress ports feeding into a lower bandwidth egress port. In that case, allocating more buffer can sometimes help by absorbing the bursts.
If the egress port is getting over-subscribed and you're trying to send a sustained level of traffic faster than line-rate then you should expect drops, no matter what the config. QoS can help you choose which traffic to drop (as well as do other things like minimise the jitter/latency if you have a sub-set of traffic that is sensitive to it), But there will still be drops if there's too much traffic, unless you police or shape the traffic upstream.
Alternatively, you could be not getting to line-rate and the drops are because of bursts. One reason might be because there are higher bandwidth ingress ports feeding into a lower bandwidth egress port. In that case, allocating more buffer can sometimes help by absorbing the bursts.
Re: SAP Ingress and Egress Verification on L2VPN
Post the output of the command "show service sdp," please
