DSCP Settings for Host up down and other polling

[Lazybones]

I am rolling out QoS queues on my network and had a few thoughts about monitoring.. Now I could just set a higher priority for all traffic from my Cacti box however I think a more find grain approach in the app would be very useful.

- DSCP setting for ICMP / TCP / UDP host up down poll
- DSCP setting for general SNMP polls
- DSCP settings for Advanced Ping graph, and allow multiple DSCP level graphs per host.

Why this would be useful?

I started to notice that one of my sites had lots of blank graphs right after hitting 100% throughput.. However doing some manual pings I could hit it but with a latency of between 900 and 1300 ms.. Much higher than the cacti default timeout of 400-500.. So I upped my timeout to compensate however it got me thinking that after I upgrade that site to QoS I should set the priority of my monitoring traffic..

I was thinking that host up down detection might be worth prioritizing but graphing might not.. Also I might want to measure how well my QoS is working by measuring latency with different DSCP tag levels at the same time.

I know the poller is being worked on a lot right now.. Maybe QoS /DSCP should be a consideration.

[TheWitness]

Please provide a bit more background. This is not something that I am familiar with. A couple of research links would be helpful.

TheWitness

[Lazybones]

DSCP is an attribute of a packet that helps routers / switches / firewalls determine the priority of processing the packet. For example real time voip may need to be delivered before someones bulk FTP download. Also when a line is full it helps the router determine what to drop first.

Google / wikipidia should return more detailed information.

[Howie]

I always thought that the theory was that management traffic got priority, so that that you can get into that remote router to find out what is going on when the pipe is full...

I don't see what the benefit would be of having different DSCP for ping vs snmp - then you could end up in situations where the poller thinks the host is up (ping) but then makes the congestion worse by firing off a load of snmp requests that will be discarded.

Being able to send requests marked with different codepoints for measurement is interesting though. I think it depends a lot on the underlying SNMP library supporting it, which I don't think net-snmp does. However if you have Cisco devices, you might want to look at the IP SLA features in IOS, which I think can change DSCP/TOS on it's probes, and Cacti can graph it's results.

[Lazybones]

I am aware of the ip sla on cisco gear. My ISP manages part of our mpls and reports using it, however I use a variety of other equipment on my side.

snmp traffic would be easy enough to re classify on my firewalls however I would really like to graph the performance of my ef, af, and untagged traffic as they should have different latancy, jitter and loss stats. As it is all pings from cacti end up as untagged.

[TheWitness]

Use snmp ping then.

[Lazybones]

Use snmp ping then.

If I classify at the router it is an all or nothing thing..

If I want to monitor my 3 classes of service at once I would have to generate packets tagged for each of the queues such as ef, af41 and standard no tag, and graph them at the same time.. This will tell me if one of the queues are full and degrading.. Also I have different SLAs with my provider for each class of traffic... I want my own monitoring to ensure that those SLAs are being met as their monitoring portal seems unreliable and clunky.

[crlshn]

the best idea I found was to implement IP SLA in the cisco Routers and Graph Jitter (for example)
[url]http://forums.cacti.net/about19542.html[url]
[url]http://cisco.com/go/ipsla

you may also use iptables to mark the packets or even the router to remark the packet, but you can only mark 1 flow and the stats may not represent what you are looking for.


PD/sorry for my bad english

[Lazybones]

IP SLA only works if you have Cisco ISR routers on each end... If you by chance have ASAs or other vendor gear you can't use the feature.

[Howie]

Juniper have an equivalent feature in JunOS (don't remember what it's called, but it exists...)

[pbg01]

Use snmp ping then.

If I classify at the router it is an all or nothing thing..

If I want to monitor my 3 classes of service at once I would have to generate packets tagged for each of the queues such as ef, af41 and standard no tag, and graph them at the same time.. This will tell me if one of the queues are full and degrading.. Also I have different SLAs with my provider for each class of traffic... I want my own monitoring to ensure that those SLAs are being met as their monitoring portal seems unreliable and clunky.

I know this question is a few years old but after some research I haven’t been able to find a decent answer to this question. Is there a way to monitor different transit QoS classes by having Cacti send ICMP or TCP probes with different TOS/DSCP markings to a monitor device and have it graph latency and packet loss? I’m thinking something like the Advanced Ping témplate but with different DSCP settings to hit different QoS classes in transit.

[JorisFRST]

I was looking at smokeping, but not sure if it does qos out of the box

[ARC1450]

Kind of old here, but just from another VoIP/Network perspective. . .

For most network stuff you wouldn't trust the QoS markings coming into the switch. You throw an ACL inbound and queue up/mark traffic from there and let ACLs decide what gets marked with which packets. Then you monitor the class-maps in the routers to see if they're getting used, how much they're getting used, and if they're dropping traffic. I don't have one in front on me, but I know doing a "show policy-map [qospolicy]" should show you on a Cisco router how much the policies are getting hit and if things are dropping due to the queue.

Also, if you're using Linux, "ping" supports the "-Q" flag, which will set ToS (which includes DSCP) bits. From the "ping" man page:

Code: Select all

  
-Q tos
Set Quality of Service -related bits in ICMP datagrams.  tos can be decimal (ping only) or hex number.

In RFC2474, these fields are interpreted as 8-bit Differentiated Services (DS), consisting of: bits 0-1 (2 lowest bits) of separate
data, and bits 2-7 (highest 6 bits) of Differentiated Services Codepoint (DSCP). In RFC2481 and RFC3168, bits 0-1 are used for ECN.

Historically (RFC1349, obsoleted by RFC2474), these were interpreted as: bit 0 (lowest bit) for reserved (currently being redefined
as congestion control), 1-4 for Type of Service and bits 5-7 (highest bits) for Precedence.

See also: https://en.wikipedia.org/wiki/Type_of_service for more information.

[TheWitness]

You know, browniebraun has written an amazing IP SLA plugin for Cacti. Someone should bug him to have his employer open source it. It's actually amazing. Seen it in action.