CUC (6) CUCM (26) Jabber (6) Python (2) Routing (3) Solarwinds Orion NPM (4) switching (1) Video (6) voice (2)

Monday, 19 March 2018

IPSEC Site to site VPN 101

Little post on IPSEC, also a good recap for myself. I will outline the components used in IPSEC when setting up a site  to site VPN for instance. I dont really want to drill down too much into the details of each protocol. This post is more around the components needed and steps/tips to trouble shoot.

IPSEC VPN is described in RFC 4301.

IPSEC is not a protocol, its is more similar to an architecture, that contains a number of protocols (mainly isakmp, AH and ESP)

IPSEC comprises of the following main elements:
  • IKE/IKEv2: which is used to negotiate tunnel parameters. These parameters are: (H.A.G.L.E)
    • Hashing for data integrity (md5/sha)
    • Authentication (certs or preshared key (PSK))
    • Group (Diffie-Hellman group)
    • Lifetime (how long will the tunnel be up for (seconds)
    • Encryption for data confidentiality (AES, 3DES, AES-256)
  • AH which is more or less become obsolete because of it inability to deal with NAT
  • ESP Encapsulation for encryption and authentication.

In order to have a fully functional site to site VPN, there are 2 types of SA's (Security Association) that need to be established:

  1. ISAKMP SA's (Phase 1), bidirectional SA, used as a management channel, to exchange keys between the peers for instance (similar to the B-channel on a BRI)
  2. IPSEC SA's (Phase 2), these are unidirectional, so you will need 2 IPSEC SA's. This happens once Phase 1 is successful. These IPSEC SA's are used to define how the end user data is protected, using transform sets
So for a functional IPSEC tunnel, a total of 3 SA's are required. These two types of SA's are also referred to as Phase 1 and Phase 2. Here is a visualization of this:

ESP (encapsulating Security Payload) and SPI

Once the SA's have been established, ESP does the hard work of protecting the traffic across the tunnel. ESP uses IP as its Layer 3 protocol and puts itself at layer 4. So if you were to Wireshark capture Tunneled traffic, you would not see a TCP port, but an ESP header containing an SPI (security Perimeter Index), a sequence number, followed by an encrypted payload.  

SPI are a 32bit random number that is associated with an IPSEC sa. As soon as a VPN endpoint receives an ESP encapsulated packet with a certain SPI, it knows exactly what transform set to apply to decrypt and integrity check the payload. If your firewall/router has multiple site to site IPSEC VPNs, you will have a multitude of SPI.

If you issue a sh crypto ipsec sa on a firewall or router, this will show you the associated SPI's. for example:

fw01/pri/act# sh cry ipsec sa
    <output omitted>
    inbound esp sas:
      spi: 0xE11468F9 (3776211193)
         SA State: active
         transform: esp-3des esp-md5-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, }
         slot: 0, conn_id: 223428608, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (4373768/1686)
         IV size: 8 bytes
         replay detection support: Y
         Anti replay bitmap:
    outbound esp sas:
      spi: 0x859B5920 (2241550624)
         SA State: active
         transform: esp-3des esp-md5-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, }
         slot: 0, conn_id: 223428608, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (4373506/1686)
         IV size: 8 bytes
As you can see there are 2 IPSEC SA's one for inbound, one for outbound, each with their own SPI, on the remote end these values will be opposite of course.

You can also clearly see the applied transform sets of each SA, using ESP with Triple DES encryption and HMAC-MD5 for message authentication and integrity.

Remember every SA can have a different transform set, although this is not recommended.

Diagnostics on Cisco devices

Of course, when will you be most likely to set up a site to site VPN? Correct, when talking into some 3rd party systems, or when some 3rd party needs to talk into some of your systems.  What sort of Forewall/VPN concentrator does this party have? Really could be anything, Juniper, Palo alto, Sonic. I have had my fair share of pain getting VPN's set up inter vendor. And before you blame the other guy for not sending you the right transform set, make damn sure that you are right. So I think a few hints and tips could make a lot of difference.

There are really two commands available that should be your best friend when diagnosis IPSEC VPN issues:

  • sh crypto isakmp sa
  • sh crypto ipsec sa

fw01/pri/act# show crypto isakmp sa  detail
IKEv1 SAs:
   Active SA: 5
    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 5
1   IKE Peer:
    Type    : L2L             Role    : responder
    Rekey   : no              State   : MM_ACTIVE
    Encrypt : 3des            Hash    : MD5
    Auth    : preshared       Lifetime: 28800
    Lifetime Remaining: 16894

As you can see above, there is your 'HAGLE' (hash, authentication,Group (well sort of), Lifetime, Encryption). What is important above is that the ISAKMP SA is established  (MM_ACTIVE). If you do not see your ISAKMP SA established, go no further, trouble shoot Phase1 first. Other states are:

MM_NO_STATE (typically cause by connectivity issue with the peer), MM_KEY_EXCH (could mean PSK mismatch), MM_SA_SETUP (peers agree on isakmp sa and will continue the process of negotiation).

If your Phase1 SA is not established, you will need to run debug commands to see what transform set are being attempted and what the remote end is sending you. for this you can use:

  • debug crypto isakmp
  • debug crypto isakmp error
  • debug crypto isakmp ha
Before you do this, you might want to consider, using conditional debugging, i.e. only capture debug information related to the failing VPN tunnel/peer. This because you might be running a large number of tunnels which would result in large amount of debug information.  To enable conditional crypto debugging:

debug crypto condition <cond-type> <cond-value>

as a condition value, you could choose the peer IP address for instance. To reset the condition use: debug crypto condition reset

Now the next test phase 2, if phase 1 is established, use the show cypto ipsec sa command. You would get something similar to the output below:

fw01/pri/act# sh crypto ipsec sa peer
peer address:
    Crypto map tag: outside_map, seq num: 2, local addr:
      access-list Internet_cryptomap_1 extended permit ip         
      local ident (addr/mask/prot/port): (
      remote ident (addr/mask/prot/port): (
      #pkts encaps: 359869, #pkts encrypt: 358126, #pkts digest: 358126
      #pkts decaps: 280949, #pkts decrypt: 279563, #pkts verify: 279563
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 359869, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #TFC rcvd: 0, #TFC sent: 0
      #Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
      #send errors: 0, #recv errors: 0
     local crypto endpt.:, remote crypto endpt.:
      path mtu 1500, ipsec overhead 58(36), media mtu 1500
      PMTU time remaining (sec): 0, DF policy: copy-df
      ICMP error validation: disabled, TFC packets: disabled
      current outbound spi: 67EA5A7C
      current inbound spi : 08278FA3
    inbound esp sas:
      spi: 0x08278FA3 (136810403)
         SA State: active
         transform: esp-3des esp-md5-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, }
         slot: 0, conn_id: 223428608, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (4373709/1407)
         IV size: 8 bytes
         replay detection support: Y
         Anti replay bitmap:
    outbound esp sas:
      spi: 0x67EA5A7C (1743411836)
         SA State: active
         transform: esp-3des esp-md5-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 2, IKEv1, }
         slot: 0, conn_id: 223428608, crypto-map: outside_map
         sa timing: remaining key lifetime (kB/sec): (4373391/1407)
         IV size: 8 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001

The SA will show you H.A.G.L.E for both inbound and outbound SA's. It will also show you what traffic is protected by the VPN Tunnel. 

Good luck and namaste!!

Tuesday, 6 March 2018

BGP Conditional Advertisement Feature

BGP Conditional Advertisement Feature

This is actually a pretty cool feature, i didn't even know it existed until I was looking for a solution to advertise a subnet (prefix in BGP talk), only if a certain condition existed. This is exactly what conditional advertisements does

"The Border Gateway Protocol (BGP) conditional advertisement feature provides additional control of route advertisement, depending on the existence of other prefixes in the BGP table."

I am assuming, for those who want to read this post, that you have some understanding of BGP and its use of prefix-lists and route maps, otherwise this post might be hard to understand. Mind you, conditional advertisement are part of the CCIE R&S exam.

So let me go straight to the scenario:

So the routers under my admin domain are BEN and IBM. My primary router is BEN and my public IP range I am advertising is 
  • My two ISPs are Telstra and Next. 
  • BEN has an eBGP neighbour with Telstra,
  • IBM has an eBGP peer with Next. 
  • Then BEN and IBM from an iBGP neighbourship.
Nothing new so far. Now I have found that when advertising out the same public IP address (prefix) towards 2 different providers, even with AS path prepend, trying to make one ISP more preferable over the other, is highly unpredictable. This is because some providers prefer other providers no matter how often you AS prepend the crap out of your public prefix. This can cause asynchronous routing where your exit path is the primary ISP and entry through your secondary router. So I was looking for another solution; only route my public IP addresses out to the backup provider (Next in my case), in the event the primary fails. Or even better; fail over when the primary ISP stops advertising a default route into my organisation through the primary router.

In order to put all this in place, most, if not all configuration is done on the secondary router; IBM, so lets dive in.

As you can see below, the secondary internet router (IBM) has 2 default gateways

IBM#sh ip bgp topology *

For address family: IPv4 Unicast

BGP table version is 26, local router ID is

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
     Network          Next Hop            Metric LocPrf Weight Path
 *>i             0    200      0 3000 i
 *                         100      0 4000 i

The most preferred on comes from the BEN router, which in turn is being advertised by the Telstra Router ( Initially I was going to use ip sla tracking on the IBM router to advertise out if BEN lost the connection to Telstra, but this is not as fool proof as checking if the default gateway is still being advertised by BEN, because if my primary internet router no longer sends a default route to my secondary internet router, the either my primary router is down, the link to Telstra is down, or Telstra is for some other reason no longer advertising a default route.

OK so on my IBM i set up a conditional advertisement to my Next BGP peer:

router bgp 5000
address-family ipv4
 neighbor advertise-map ADVERTISE non-exist-map NON-EXIST

what this means is that route map ADVERTISE is being invoked when the condition in route map NON-EXIST no longer exists.

route-map ADVERTISE permit 10
 match ip address 60
route-map NON-EXIST permit 10
 match ip address prefix-list TEST
 match community 1
So the ADVERTISE route map is the easy part, it constitutes our public IP prefix

access-list 60 permit
the NON-EXIST route map is the condition that needs checking, and has in fact two conditions in it; it checks the prefix for a certain community and it checks if the actual prefix is available in the BGP table:

ip prefix-list TEST seq 5 permit

The reason there are two conditions, is that  (refer to the sh ip bgp topology * output above), there are two prefixes in the table; one from each provider. Now I am only interested in checking one of them; namely the one that comes from BEN I though it would be easiest to add a check for a certain community in (although AS path would have worked as well).

ip community-list 1 permit 362000
So basically this second condition check to see if the route has 362000 as the community.
You can check the route to see if the community attribute is set and has the correct value. see below

IBM#sh ip bgp
BGP routing table entry for, version 25
Paths: (3 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  3000, (received & used) from (
      Origin IGP, metric 0, localpref 200, valid, internal, best
      Community: 36200
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1

So at this stage both conditions should be met; a) a default route in the BGP table and b)a route with community attribute 36200. So our public prefix should NOT be advertised out IBM to Next. To verify: 

IBM#sh ip bgp nei
BGP neighbor is,  remote AS 4000, external link
---<output omitted>
Condition-map NON-EXIST, Advertise-map ADVERTISE, status: Withdraw
---<output omitted>
As you can see the conditional advertisement states "withdraw" which means the condition to start advertising is not met; ie.e we have a valid default route coming from BEN. So let me break something to trigger the condition to change. For this I will shut the connection between Telstra and BEN. (Remember BEN does not originate, its receives it from Telstra and as soon as that link breaks, it should no longer receive a default route either).

when debugging routing on IBM:

*Mar  7 04:45:48.908: RT: updating bgp (0x0)  :
    via   0 1048577
*Mar  7 04:45:48.915: RT: closer admin distance for, flushing 1 routes
*Mar  7 04:45:48.919: RT: add via, bgp metric [20/0]

as you can see the from BEN gets purged from the bgp table. and consequently the conditional advertisement kicks in:

IBM#sh ip bgp nei
  Condition-map NON-EXIST, Advertise-map ADVERTISE, status: Advertise
To double check this, we check what routes the IBM router is sending to Next:

IBM#sh ip bgp nei advertised-routes
BGP table version is 13, local router ID is
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
     Network          Next Hop            Metric LocPrf Weight Path
 *>            0         32768 i

Any questions, drop me a line.


Sunday, 28 January 2018

Awesome URLs

some URL that I would like to share, as they got me out of trouble a few times.


  • ASA
           On the order of how NAT gets processed on 8.3+, how NAT rules stack to network object NATing and that the order of your rules does matter, well at least sometimes. Written up by Journi Forss, so he gets all the credit.

  • Juniper  (i know right ;-)  )



Monday, 15 January 2018

Firepower IPS search for certain CVE

Sometimes you might need to know if your Firepower software protects against a certain, published vulnerability. In other words; does your Firepower box have the required rules to recognize the signatures of certain vulnerabilities?
First thing you need to do is find the CVE (common vulnerabilities and exposures) number
and write down the number for instance CVE-2017-5354
now go to your Firepower Virtual Defence Centre:

  1. Edit your Intrusion Policy
  2. Edit your Intrusion Policy and go to the Rules section.
  3. On the left side accordion panel select "Rule Content."
  4. Click Reference  (as per below)

5: Click CVE ID and enter the CVE code (do not include CVE-  !!)

Enter CVE ID and click OK.  For CVE-2017-5754 this could give the following output:

As you can see in the picture above, the Firepower engine, contains IPS rules to recognise the signature of CVE 2017-5475 (Meltdown)


Sunday, 17 December 2017

Directing traffic from your ASA to a Firepower module

I d like to do a little post on how to direct traffic to your firepower module, cos without directing traffic to it, really IPS and Malware analyses are no good, so you will need to give the firepower module something to work with, sort of the same as 'interesting traffic' on a crypto map.

Typically all traffic is directed to your firepower module, even if you want to do only IPS and Malware detection, keeping all your Access-list/policies on your ASA, in which case you simply dont create any acces-lists on your firepower module and leave all L3/L4 filtering to the tradition of the ASA

So first verify if your FP module is inserted, 

ASA-FW1# sh module

Mod  Card Type                                                                 Model              Serial No.
---- --------------------------------------------                      ------------------ -----------
   1 ASA 5516-X with FirePOWER services, 8GE, AC,             ASA5516            JADxyz
 sfr FirePOWER Services Software Module                            ASA5516            JADxyz

you will now need to install the software on it. I will not go into detail, so use

If you decide to deploy your firepower module inline, you will need to define what traffic you want to send to your firepower module you will need to put some configuration in place on the ASA. Typically all traffic is directed to the Firepower module. (match any in the confuguration example below). First the class map firepower matches all traffic and is then applied to the global policy map, in conjucntion with the sfr fail-open command bringing the firepower module inline.

class-map firepower
 match any
policy-map global_policy
 class firepower
  sfr fail-open

You can verify if the firepower module is receiving any traffic by going to the Firesight manager centre and analyse the connection events. 


Thursday, 23 November 2017

Juniper SRX basic troubleshoot commands

show security zones:

this will display the various 'zones' /logical interfaces together with their physical interfaces


SRX_FW1>>show interfaces terse

this will show you all the interfaces, their IP address and status

SRX-FW1>> show chassis routing-engine

shows uptime, serial number CPU util, temperature etc.


show security ipsec inactive-tunnels detail:

this will tell you when tunnels went down and come back up, also tells remote GW IP address

show security ipsec security-associations

this will tell you what encryption is used 

This command will also provide details on for instance the index of the SA. every SA has an inbound and outbound leg (indicated by the arrows left of the SA ID).

you can drill down into each sa by issuing: show security ipsec index <number>. This will tell you exactly what policy belongs to what sa.

show security ike security-associations details

This will show if a tunnel has any input and output.

show security ike active peer

displays IKE and remote IP addresses

Trouble shoot Traffic flows:

Traffic flows:

show security flow session source-prefix <ipaddr/32> destination-prefix <>
This will show you what TCP session are in progress or were attempted. A very usefull command if you want to find out, if traffic is actually hitting your firewall.

show security match-policies from-zone <name> to-zone <name2> source-ip <beh> destination-ip <blah>destination-port <jaja> protocol <meh>.

This command is extremely useful, it is pretty much a Junos CLI version of the ASA packet tracer, in that it will tell you how certain traffic gets treated by the Junos FW engine.

show security policies hit-count

This will show you an increasing hit count against your security policies
very very useful. if you generate traffic against a certain intended policy and your hit count stays at zero, you need to revise your policies potentially.

-SRX-FW1> show configuration system syslog

this will tell you what the names of the log files are, for instance:

file traffic {
    any any;
    archive files 100;
file block_traffic {
    any any;

monitor traffic matching "net" no-resolve brief

monitor traffic matching "net" no-resolve detail

show traffic log

SRX-FW1> show log traffic | ?
Possible completions:
  count                Count occurrences
  display              Show additional kinds of information
  except               Show only text that does not match a pattern
  find                 Search for first occurrence of pattern
  hold                 Hold text without exiting the --More-- prompt
  last                 Display end of output only
  match                Show only text that matches a pattern
  no-more              Don't paginate output
  refresh              Refresh a continuous display of the command
  request              Make system-level requests
  resolve              Resolve IP addresses
  save                 Save output text to file
  trim                 Trim specified number of columns from start of line

so if you want to search for an ip address go (for instance issue:

SRX-FW1> show log traffic | find

still to read:

Monday, 21 August 2017

using SNMP to monitor class maps / interface policies as well as some solarwinds

Sometimes it is just plain useful to  get some insight into the traffic classes that you use on some police map of, yes, some interface. Many organisation will have some sort of net flow tool deployed in their network, but that does not really give you any details on bit rates and drop rates that take place on an interface, in times of congestion. Sure Cisco prime can quantify QoS, but using snmp pollers is much cheaper.  The trick is to find the right OID to poll. So let me get stuck right into it.


From your Cisco device's, CLI issue the following:

EXECUTE:           show snmp mib ifmib ifindex

GigabitEthernet0/1.100: Ifindex = 14
GigabitEthernet0/1: Ifindex = 3
GigabitEthernet0/1.10: Ifindex = 20
GigabitEthernet0/1.9: Ifindex = 19
Backplane-GigabitEthernet0/3: Ifindex = 4
GigabitEthernet0/1.7: Ifindex = 17
Async0/0/3: Ifindex = 9
Async0/0/1: Ifindex = 7
GigabitEthernet0/1.5: Ifindex = 15
GigabitEthernet0/1.3: Ifindex = 13
Loopback0: Ifindex = 10
Embedded-Service-Engine0/0: Ifindex = 1
Null0: Ifindex = 5
GigabitEthernet0/0: Ifindex = 2    <-------this is the interface we are interested in
GigabitEthernet0/1.11: Ifindex = 11
GigabitEthernet0/1.8: Ifindex = 18
GigabitEthernet0/1.6: Ifindex = 16
Async0/0/2: Ifindex = 8
Async0/0/0: Ifindex = 6
GigabitEthernet0/1.2: Ifindex = 12


Get the cbQosIfIndex (OID for the ifindex you retrieved in Step 1 (ifindex=2 in this case).

EXECUTE: snmp walk: <>


. = INTEGER: 2
. = INTEGER: 11
. = INTEGER: 12
. = INTEGER: 13
. = INTEGER: 14
. = INTEGER: 15
. = INTEGER: 16
. = INTEGER: 17
. = INTEGER: 18
. = INTEGER: 19
. = INTEGER: 20

The cbQosPolicyIndex (OID value returned, in this example, is 34

This means that, on interface Gi0/0 (Integer=2)  the cbQosPolicyIndex  = 34


Use the MIB Object cbQosCMName ( to get the names of class-maps configured on the router.

Now, query the Class map configuration as follows:

snmp walk:  <.>

. = STRING: "class-default"
. = STRING: "cm-prec-2-out"
. = STRING: "cm-prec-3-out"
. = STRING: "cm-prec-1-out"
. = STRING: "cm-prec-4-5-out"
. = STRING: "cm-prec-2-in"
. = STRING: "cm-prec-3-in"
. = STRING: "cm-prec-4-in"
. = STRING: "cm-prec-1-in"

Suppose, we are interested in the QosConfig of "cm-prec-4-5-out". Make a note of the highlighted value 12472097, which is cbQosConfigIndex.


Use cbQosConfigIndex to get the cbQosPolicyIndex ( and cbQosObjectsIndex ( for individual class-maps.


In order to get the Object Identifier (OID), search for the cbQosConfigIndex value obtained in Step 3 (12472097) in the output below:

EXECUTE: snmp walk: <>


. = GAUGE32: 14151856
. = GAUGE32: 10273235
. = GAUGE32: 5239858
. = GAUGE32: 12472097    <_----cm-prec-4-5-out
. = GAUGE32: 11175747
. = GAUGE32: 855826
. = GAUGE32: 1594
. = GAUGE32: 13688019
.  = GAUGE32: 1593
. = GAUGE32: 8774209
. = GAUGE32: 12112579
. = GAUGE32: 1594
. = GAUGE32: 9357059
. = GAUGE32: 10583344
. = GAUGE32: 1593
. = GAUGE32: 5252402
. = GAUGE32: 14230322
. = GAUGE32: 2482753
. = GAUGE32: 5276466
. = GAUGE32: 1434177 <--cm-prec-2-out
. = GAUGE32: 14812867
. = GAUGE32: 1298848
. = GAUGE32: 15444834
. = GAUGE32: 6784962

in the output above  The highlighted values are: cbQosConfigIndex (12472097), cbQosPolicyIndex (34), and cbQosObjectsIndex (2196705).


Now let us pull some relevant information of the router; let find out how much traffic is in in the pm-prec-4-5--out

Router # show policy-map interface GigabitEthernet0/0

EXECUTE: snmp walk <>  
. = GAUGE32: 0
all policy map classes:
. = GAUGE32: 0                    <-----4-5 out
. = GAUGE32: 119000                <-------------default  bps
. = GAUGE32: 0                     <-----1 out
. = GAUGE32: 163000
. = GAUGE32: 3000                <----3 out
. = GAUGE32: 29000               <-----2 out

Time to get into some practicalities. Once you have obtained the 3 values:
cbQosConfigIndex (12472097) 
cbQosPolicyIndex (34)
cbQosObjectsIndex (2196705)
To poll data from the Policy-map 
(in correlation with QosObjectsType=classmap)

Use the base: , many options are available:
+-- -R-- Counter   cbQosCMPrePolicyPktOverflow(1)
+-- -R-- Counter   cbQosCMPrePolicyPkt(2)
+-- -R-- Counter64 cbQosCMPrePolicyPkt64(3)
+-- -R-- Counter   cbQosCMPrePolicyByteOverflow(4)
+-- -R-- Counter   cbQosCMPrePolicyByte(5)
+-- -R-- Counter64 cbQosCMPrePolicyByte64(6)
+-- -R-- Gauge     cbQosCMPrePolicyBitRate(7)
+-- -R-- Counter   cbQosCMPostPolicyByteOverflow(8)
+-- -R-- Counter   cbQosCMPostPolicyByte(9)
+-- -R-- Counter64 cbQosCMPostPolicyByte64(10)
+-- -R-- Gauge     cbQosCMPostPolicyBitRate(11)
+-- -R-- Counter   cbQosCMDropPktOverflow(12)
+-- -R-- Counter   cbQosCMDropPkt(13)
+-- -R-- Counter64 cbQosCMDropPkt64(14)
+-- -R-- Counter   cbQosCMDropByteOverflow(15)
+-- -R-- Counter   cbQosCMDropByte(16)
+-- -R-- Counter64 cbQosCMDropByte64(17)
+-- -R-- Gauge     cbQosCMDropBitRate(18)
+-- -R-- Counter   cbQosCMNoBufDropPktOverflow(19)
-- -R-- Counter   cbQosCMNoBufDropPkt(20)
-- -R-- Counter64 cbQosCMNoBufDropPkt64(21)

For example, cbQosCMPostPolicyBitRate  (, 
polls the bit rate of the traffic after QoS policy execution, 
derived from 11 in the table above, so drop rate would be:

Solarwinds configuration.
Solarwinds NPM has the ability to poll certain OIDs through customized pollers.
Go to universal device pollers:

As you can see we are polling, to find the post policy bit rate. The oid will actually return a table will the traffic rates for all class maps on all applied interfaces.
The post policy bit rate poller can be summarised as per above. Now lets have a closer look in solarwinds npm at a device that we have assigned the poller to:

Picture above shows the dfjbit rate for a class map prec-4-5-out (yes exactly the same name as when querying earlier on in this post). essentially the graph above depicts
in the graph above, go to EDIT:
<As can be seen above only 18.1136785 is graphed, which is cm-prec-4-5-out.
if you wanted to graph more class maps: = STRING: "cm-prec-3-out" = GAUGE32: 2482753
you could tick for instance: 18.11057649, in the devicepoller graph above, for cm-prec-3-out to be graphed source: