How to monitor Cisco QoS using SNMP

In the following post i will explain a way to get the correct OID, in order to monitor QoS policies using SNMP.

From time to time we may encounter situations were we will need to monitor specific policy-map, which configured on certain interface, for knowing and differentiate between traffic types. For example a policy-map which mark international and domestic traffic on the same interface.

Few notes for the above example:

- I'm using snmpwalk utility on Linux based machine to get and show the SNMP OID values

- The device that i monitor is Cisco 2811 router

- SNMP community is "snmp-community"

- Router IP is 192.168.10.1

- The descriptions and OID information is taken from Cisco SNMP navigator (http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en)

First let's list look at router interfaces description:

ifDescr

A textual string containing information about the interface, this string should include the name of the
manufacturer, the product name and the version of the interface hardware/software

snmpwalk -v 2c -c snmp-community 192.168.10.1 1.3.6.1.2.1.2.2.1.2

Output:

 

[root@linux-srv ~]# snmpwalk -v 2c -c snmp-community 192.168.10.1 1.3.6.1.2.1.2.2.1.2 IF-MIB::ifDescr.1 = STRING: FastEthernet0/0 IF-MIB::ifDescr.2 = STRING: FastEthernet0/1 IF-MIB::ifDescr.3 = STRING: FastEthernet0/0/0 IF-MIB::ifDescr.4 = STRING: FastEthernet0/0/1 IF-MIB::ifDescr.5 = STRING: FastEthernet0/0/2 IF-MIB::ifDescr.6 = STRING: FastEthernet0/0/3 IF-MIB::ifDescr.7 = STRING: Null0 IF-MIB::ifDescr.8 = STRING: Vlan1 IF-MIB::ifDescr.9 = STRING: Vlan2 IF-MIB::ifDescr.11 = STRING: Vlan5

Next let's see the QoS policies attached to these interfaces:

cbQosIfIndex

ifIndex for the interface to which this service is attached.

snmpwalk -v 2c -c snmp-community 192.168.10.1 1.3.6.1.4.1.9.9.166.1.1.1.1.4

Output:

 

[root@linux-srv ~]# snmpwalk -v 2c -c snmp-community 192.168.10.1 1.3.6.1.4.1.9.9.166.1.1.1.1.4 SNMPv2-SMI::enterprises.9.9.166.1.1.1.1.4.16 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.166.1.1.1.1.4.32 = INTEGER: 2 SNMPv2-SMI::enterprises.9.9.166.1.1.1.1.4.34 = INTEGER: 2

From the output above we can see that  there is one policy (16) over FastEthernet 0/0 and two policies (32 and 34) over Fastethernet 0/1.

In order to determine to which type of interface the policy is attached we will use the following:

cbQosIfType

This describes the logical interface/media type to which this service policy is attached following this table:

InterfaceType
1:mainInterface
2:subInterface
3:frDLCI
4:atmPVC
5:controlPlane
6:vlanPort

snmpwalk -v 2c -c snmp-community 192.168.10.1 1.3.6.1.4.1.9.9.166.1.1.1.1.2

Output:

[root@linux-srv ~]# snmpwalk -v 2c -c snmp-community 192.168.10.1 1.3.6.1.4.1.9.9.166.1.1.1.1.2 SNMPv2-SMI::enterprises.9.9.166.1.1.1.1.2.16 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.166.1.1.1.1.2.32 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.166.1.1.1.1.2.34 = INTEGER: 1

 We can see that all three policies (16,32,34) are attached to the main interface (using the above table).

Now let's determine the policy direction - input or output:

 

cbQosPolicyDirection

This indicates the direction of traffic for which this service policy is applied

TrafficDirection
1:input
2:output

snmpwalk -v 2c -c snmp-community 192.168.10.1 1.3.6.1.4.1.9.9.166.1.1.1.1.3

Output:

 

[root@linux-srv ~]# snmpwalk -v 2c -c snmp-community 192.168.10.1 1.3.6.1.4.1.9.9.166.1.1.1.1.3 SNMPv2-SMI::enterprises.9.9.166.1.1.1.1.3.16 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.166.1.1.1.1.3.32 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.166.1.1.1.1.3.34 = INTEGER: 2

We can see that policy 16 and 32 are in the input direction and policy 34 is in the output direction.


Next we will see the bit-rate for a specific policy usin the following:

cbQosCMPrePolicyBitRate

The bit rate of the traffic prior to executing any QoS policies

snmpwalk -v 2c -c snmp-community 192.168.10.1 1.3.6.1.4.1.9.9.166.1.15.1.1.7.XXX

Replace the XXX with the policy number, in my example 16,32 or 34

Output:

 

[root@ib-tools ~]# snmpwalk -v 2c -c bynet8001 80.74.118.138 1.3.6.1.4.1.9.9.166.1.15.1.1.7.32 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.7.32.13311825 = Gauge32: 105000 SNMPv2-SMI::enterprises.9.9.166.1.15.1.1.7.32.14640113 = Gauge32: 910000

From the output we can see that the bit-rate for policy 32, which goes in the input direction and attached to FastEthernet 0/1, is 105000 bps and 910000 bps.

the reason for the two values is deriving from the fact that there is also class-default for this policy.

looking on the router interface shows:

 

Router# show policy-map interface  fastEthernet 0/1  FastEthernet0/1   Service-policy input: POLICY1     Class-map: CLASS1 (match-all)       213152018 packets, 204489798566 bytes       30 second offered rate 105000 bps, drop rate 0 bps       Match: access-group name ACL_IB_NET       QoS Set         dscp 19           Packets marked 213152020     Class-map: class-default (match-any)       243225777 packets, 189119340706 bytes       30 second offered rate 910000 bps, drop rate 0 bps       Match: any       QoS Set         dscp default           Packets marked 243225788   Service-policy output: POLICY1     Class-map: CLASS1 (match-all)       191459549 packets, 119638333572 bytes       30 second offered rate 95000 bps, drop rate 0 bps       Match: access-group name ACL_IB_NET       QoS Set         dscp 19           Packets marked 191459550     Class-map: class-default (match-any)       381851041 packets, 87361395996 bytes       30 second offered rate 860000 bps, drop rate 0 bps       Match: any       QoS Set         dscp default           Packets marked 381726600

we can also use the following for post policy rate and drop bit-rate:

cbQosCMPostPolicyBitRate

The bit rate of the traffic after executing QoS policies

snmpwalk -v 2c -c snmp-community 192.168.10.1 1.3.6.1.4.1.9.9.166.1.15.1.1.11

cbQosCMDropBitRate

The bit rate of the drops per class as the result of all features that can produce drops (e.g., police, random detect, etc.).

snmpwalk -v 2c -c snmp-community 192.168.10.1 1.3.6.1.4.1.9.9.166.1.15.1.1.18

OSPF network types - Part 2

the physical topology remains the same:

But in this example all 3 routers are connected in full mesh topology, through the frame-relay cloud, which the default OSPF network type is NON-BROADCAST.

R1#sh ip ospf interface Serial0/0 is up, line protocol is up   Internet Address 10.1.123.1/24, Area 0   Process ID 1, Router ID 192.168.11.1, Network Type NON_BROADCAST, Cost: 64   Transmit Delay is 1 sec, State DR, Priority 1   Designated Router (ID) 192.168.11.1, Interface address 10.1.123.1   No backup designated router on this network   Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5     oob-resync timeout 120     Hello due in 00:00:23   Supports Link-local Signaling (LLS)   Index 1/1, flood queue length 0   Next 0x0(0)/0x0(0)   Last flood scan length is 0, maximum is 0   Last flood scan time is 0 msec, maximum is 0 msec   Neighbor Count is 0, Adjacent neighbor count is 0   Suppress hello for 0 neighbor(s) Loopback1 is up, line protocol is up   Internet Address 192.168.11.1/24, Area 0   Process ID 1, Router ID 192.168.11.1, Network Type LOOPBACK, Cost: 1   Loopback interface is treated as a stub Host

The attributes for this type of network are as follow:

LAS flooding – Unicast

Neighbor statement – Yes

DR/BDR Election – Yes

Timers – 30/120

Modify next-hop – No

Note that this type of network is the default for frame-relay physical and Point-to-Multipoint.

In order to accomplish adjacency between all three we will have to configure neighbor statements on each one of them.

R1:

R1#sh running-config | s ospf router ospf 1  log-adjacency-changes  network 10.1.123.1 0.0.0.0 area 0  network 192.168.11.1 0.0.0.0 area 0  neighbor 10.1.123.2  neighbor 10.1.123.3

The result:

R1#sh ip ospf neighbor Neighbor ID     Pri   State           Dead Time   Address         Interface 192.168.22.1      1   FULL/BDR        00:01:36    10.1.123.2      Serial0/0 192.168.33.1      1   FULL/DR         00:01:50    10.1.123.3      Serial0/0

OSPF network types - Part 1

This time i will examine the options for OSPF network types.
Let's take the following scenario:

Side note – as part of my preparation to the CCIE R&S lab exam I keep practice and configuring manually a cisco router as frame-relay switch instead of using the built-in one.

Here we have a hub and spoke topology where R1 is the hub and R2 and R3 are the spokes. R1 is configured with interface s0/0.123 multipoint were R2 and R3 are configured with sub-interface point-to-point.

After finishing configure the interfaces (encapsulation, fram-relay, IP's) and OSPF process i didn't manage to see adjcencies...!

here is a snippet from the configurations:

R1:

interface Serial0/0.123 multipoint  ip address 10.1.123.1 255.255.255.0  ip ospf network point-to-multipoint  snmp trap link-status  frame-relay map ip 10.1.123.2 102 broadcast  frame-relay map ip 10.1.123.3 103 broadcast  frame-relay interface-dlci 102  frame-relay interface-dlci 103  no frame-relay inverse-arp

R2:

interface Serial0/0.12 point-to-point  ip address 10.1.123.2 255.255.255.0  ip ospf network point-to-point  frame-relay interface-dlci 201

R3:

interface Serial0/0.13 point-to-point  ip address 10.1.123.3 255.255.255.0  ip ospf network point-to-point  snmp trap link-status  frame-relay interface-dlci 301

So first let's examine this situation more deeply, we have a hub router which connected to two spoke routers, so the hub is multipoint while the two spokes are point-to-point.

Now OSPF network type Point-to-Multipoint uses the following:

LSA flooding - Multicast

DR/BDR Election - No

Timers - 30/120

Neighbor statement - No

Modify next-hop - yes

while point-to-point network type uses:

LSA flooding - Multicast

DR/BDR Election - No

Timers -10/40

Neighbor statement - No

Modify next-hop -No

3 basic things we should check if adjacency between OSPF neighbors doesn't come up:

1. LSA flooding method (unicast or multicast)

2. MTU

3. Timers

As you may recall OSPF adjacencies never comes up if the timers are not the same, in my example the multipoint uses 30/120 while PtP uses 10/40.

In order to fix the problem configure ip ospf hello-timer, in the interface level, on the hub router to match the spokes timers.

How to configure GRE tunnel between Cisco IOS and Linux

Let’s have the following scenario:

Both nodes are connected through the internet, here in my example, using private IP.

On the Cisco device, Fa0/0 is the WAN interface with the following configuration:

interface Tunnel1  description TO-LINUX-SERVER  ip address 192.168.10.2 255.255.255.252  ip mtu 1436  tunnel source Fastethernet 0/0  tunnel destination 172.16.0.2

Where tunnel source is the IP of the Cisco router, tunnel destination is the IP of the Linux server and 192.168.10.2 is the IP of the tunnel.

On the Linux server ETH0 is the WAN interface which connected to the internet

modprobe ip_gre ip tunnel add gre_tun0 mode gre remote 10.0.0.2 local 172.16.0.2 ttl 255 ip tunnel ls ip link ls dev gre_tun0 ip link set gre_tun0 up ip link ls dev gre_tun0 ip addr add 192.168.10.1/30 dev gre_tun0 ip addr ls dev gre_tun0 ifconfig gre_tun0 mtu 1380

Modeprobe runs the module for GRE; ip tunnel creates the tunnel with gre_tun0 as the name for the tunnel. Remote and local are the same as source and destination.

In order to configure the GRE tunnel permanently and to make sure it will be configured after reload of the server use the following:

Vi /etc/rc.local

And add the configuration to the file:

#!/bin/sh # # This script will be executed *after* all the other init scripts. # You can put your own initialization stuff in here if you don't # want to do the full Sys V style init stuff. touch /var/lock/subsys/local modprobe ip_gre #GRE Tunnel CONFIG modprobe ip_gre ip tunnel add gre_tun0 mode gre remote 10.0.0.2 local 172.16.0.2 ttl 255 ip tunnel ls ip link ls dev gre_tun0 ip link set gre_tun0 up ip link ls dev gre_tun0 ip addr add 192.168.10.1/30 dev gre_tun0 ip addr ls dev gre_tun0 ifconfig gre_tun0 mtu 1380 ~                                                                                                        ~                                                                                                        ~                                                                                                         ~                                                                                                        ~                                                                                                         "/etc/rc.local" 32L, 1051C

Don’t forget to type wq! to save the file.

Remember that GRE stands for General Routing Encapsulation and It’s not encrypting or protecting the data from eavesdrop eyes.  The encapsulation itself adds 24 bytes to the IP packet and (4 bytes for the GRE protocol and 20 bytes for one more IP header)