Pseudowire State vs Traffic Counters: Which One Proves Delivery
Oper state says the service is configured and up; counters say frames moved. Join both on the VC index and check direction, discontinuity and MIB support.
A pseudowire reporting up tells you the service exists and that both directions agree it should carry traffic. It does not tell you that a single customer frame ever crossed it. The state objects and the counter objects were written for different purposes, and treating one as proof of the other is where most of these dashboards go wrong. Comparing them is the job, since trusting either one alone answers a question nobody asked.
State and counters answer different questions
The main VC entry carries a combined operational status, and that status is up only when both directional states are up. Everything behind it is control-plane and configuration knowledge: the local attachment circuit, the peer, the signalling. A row in this state is a statement about intent and readiness, not about forwarded frames.
Traffic lives in a separate table of high-capacity counters for packets and bytes, and those rows carry the same VC index. Growth there is evidence that frames moved through that particular row during the interval you measured. An unchanged counter is ambiguous on its own. An idle service, a collector reading the wrong row and a silently broken path all produce the same flat line.
| Question | Object | What it can establish |
|---|---|---|
| Is the service up? | cpwVcOperStatus | Both direction states agree the VC should carry traffic. |
| Which side is down? | cpwVcInboundOperStatus, cpwVcOutboundOperStatus | Direction of the reported fault. |
| Did frames move? | cpwVcPerfTotalTable HC counters | Observed forwarding on that row between two polls. |
| Is the interval clean? | cpwVcPerfTotalDiscontinuityTime | Whether the counter was reset inside the window. |
Read the table as two columns of evidence, not one ladder of severity. Up with flat counters is not a worse version of up with growth, it is a different observation with a different next step.
Join on the VC index, not on the number in the ticket
The VC table is indexed by a single integer, and the VC ID, peer address, service type and name are attributes of that row. Those attributes are how you find your service; the index is how you keep finding it after the first poll. An interface index, a displayed circuit name or an MPLS label is not that index even when the numbers coincide.
Derive the numeric OIDs from the MIB file on the collector rather than from a blog post, then walk the table once and store the identity you found.
snmptranslate -On CPW-VC-MIB::cpwVcIndex
snmptranslate -On CPW-VC-MIB::cpwVcPerfTotalDiscontinuityTime
snmpwalk -v2c -c monitor 10.60.4.21 -On CPW-VC-MIB::cpwVcTableRecord the management address and the index together in the monitoring system. Re-provisioning can move a service to a different row, and a collector that joined on the VC ID by name will then keep plotting a stale index that still answers politely.
Direction means the pseudowire, not the subscriber
Inbound counters describe what the VC received from the packet-switched network; outbound counters describe what it forwarded toward that network. On a PE facing a customer, that often maps to download and upload in some order. On a hub PE, or on a PE that peers with a core, the same object names describe the opposite customer experience.
Write the mapping down once per device role and keep it in the dashboard label. A graph titled customer upload that actually plots traffic into the core will survive review and quietly mislead everyone who uses it for capacity decisions. The same risk applies to alerts built on those graphs, which will page the wrong team. Label each graph by direction of travel relative to the pseudowire, and let the customer mapping live in the panel that needs it.
One test beats any amount of reading object descriptions: pull a known file through the service, poll both directions immediately afterwards, and see which counter moved. Record the result next to the device role, because the next person will ask the same question.
A rate is only valid inside one discontinuity window
Compute a rate as the increase in the byte counter divided by the elapsed seconds, and multiply by eight for bits per second. Treat the interval as invalid if the counter decreased, the agent restarted, the row changed, or the discontinuity object moved. That object is expressed against system uptime, so a device restart invalidates it as well. Drop the sample and open a new window instead of drawing a spike.
Take two samples with a known gap and keep the timestamps from the collector, not from your terminal history.
snmpget -v2c -c monitor -Oqv 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalInHCBytes.7
sleep 60
snmpget -v2c -c monitor -Oqv 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalInHCBytes.7
snmpget -v2c -c monitor -Oqv 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalDiscontinuityTime.7High-capacity counters make wrapping a non-issue on a single pseudowire, so a decrease almost always means a reset, a replacement agent or a different row rather than arithmetic overflow. That is why the third command matters as much as the first two.
Check what the installed release actually supports
A MIB definition is a specification, not a promise about your image. Tables can be missing, partially implemented, or present but unpopulated until a feature is enabled, and the same platform can differ between releases. The CISCO-IETF-PW-MIB definition gives you the object names; the device tells you whether they answer.
Poll both tables and the firmware string in one pass, then compare against what the release note claims.
snmpget -v2c -c monitor -Oqv 10.60.4.21 SNMPv2-MIB::sysDescr.0
snmpwalk -v2c -c monitor 10.60.4.21 CPW-VC-MIB::cpwVcTable | wc -l
snmpwalk -v2c -c monitor 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalTable | wc -lAn empty walk and an unsupported walk are different failures, so read the error rather than the line count alone. If the state table answers and the performance table does not, the join you designed in the first section has nowhere to land, and the fix is a collector change rather than a circuit change.
The sequence for a disputed circuit is short: confirm the row identity from the index, confirm the direction mapping with one known transfer, compute the rate only inside a clean discontinuity window, and confirm that both tables answer on that release. Each step removes one candidate explanation. When all four hold and counters still do not move, the evidence points away from the pseudowire. That is the point where a packet capture on the attachment circuit earns its keep.