I am using Orion NPM to monitor the MPLS WAN links. For each MPLS interface on Cisco 3845, 2 entries come up. For example, 'G0/1.2077' is the configured interface, and 'G0/1.2077-mpls layer' is the second entry shown the NFM. There are huge statistics differences between these 2 entries. In my case, the vlan 2077 is allocated 2M bandwidth. Traffic shaping is configured. The second entry(with MPLS layer) always shows over 400% link utiliztion; while the first one shows only 30% link utilization. The shaping is never seen active.
Is this link really congested? How to understand the 'mpls layer' statistics?
Are there commands that can be used on the router to check the 'mpls layer' statistics?
Since this is an MPLS enabled link between 2 PE routers that are connected by metraethernet via a service provider, all traffic except OSPF and BGP are MPLS labeled. In the policy-map, I have a default class defined which should catch everything:
priority percent 40
set mpls experimental topmost 5
bandwidth percent 20
set mpls experimental topmost 3
bandwidth percent 40
set mpls experimental topmost 0
The policy is used as a child policy so that it can be applied to the sub-interface:
shape average 2048000
I can see drops in the default-class in the child policy-map. No drops have ever been seen in the priority class 'QOS-GROUP5-50', but occassionally we get choppy voice and weak voice. I suspect that the SP drop the over-subscribed traffic that includes voip traffic. This over-subscribed traffic might be the 'mpls layer' traffic.
This reasoning holds water for another similar 10M link. This is only 30% utilized when the voice is choppy. However the 'mpls layer' entry in the monitoring tool shows 90% utilization spikes. It seems to me that the 'mpls layer' entry is more accurate.
My issuse is how to take that 'mpls layer' traffic into QoS classification? Why the default class does not catch this?
Unable to comment on the MPLS layer stats, but in general, most monitoring isn't sufficiently granular to "see" microbursts that can impact VoIP quality.
To guarantee VoIP quality, you need to insure its packets go first when there's congestion, but this also entails insuring something like LLQ does "see" the congestion. For instance, you may need to override the default hardware FIFO queue. Or, with a shaper, use a smaller Tc then the defualt. (You also should account for vendor real-time policer values although often difficult to get them to document.) Also with shapers, you might need to account for Ethernet framing overhead. Since you mention using a subinterface, another issue is subinterfaces logically oversubscribing the physical bandwidth.
1. Introduction Internet security is important with the increasing
attacks that are happening every day. Many internet and browsing
security solutions exist, but some are not very easy to use or maybe the
question is how can I enable them? In this referen...
Cisco Software Manager Server API Guide This document describes the
programmatic interfaces, RESTful APIs, which are supported by Cisco
Software Manager Server (CSM Server). Overview CSM Server supports a set
of finite RESTful APIs. The first step to use ...
If you are using Cisco's new linux-based Cisco Software Manager server,
then you probably want to make sure there is a startup service for
it.I'll assume that you've already installed the CSM server on a
systemd-based linux system. The commands given belo...