cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
528
Views
5
Helpful
9
Replies
Paul Bundschuh
Beginner

Is routing protocol traffic / pings treated differently than normal traffic on serial links?

Just wondering if routing protocol control traffic (hellos/updates/etc) is queued preferentially to normal traffic, on a serial link? Assuming *no* QoS/MQC is configured on either end of the link? Also, are pings treated with lesser priority than normal traffic? I believe they are all treated the same, using FIFO on the output queue/transmit ring. And I know that routing protocol traffic *is* treated preferentially within the router itself, using pak_priority settings. Thanks.

1 ACCEPTED SOLUTION

Accepted Solutions
Palani Mohan
Cisco Employee

Hi Paul

This thread is showing up as "Unanswered". Kindly ask questions/clarifications and we will aim to answer them. On the other hand, if your questions are answered, please select "Endorse Answer" and it would lead to the thread status changing to "Answered".

On a regular basis, we scan the forums to assist unanswered questions. This is the background for this request.

Sincerely ... Palani

View solution in original post

9 REPLIES 9
Georg Pauwen
VIP Expert

Paul,

indeed, in addition to marking important control datagrams processed within the router with the PAK_PRIORITY flag. All IGP traffic (RIP/EIGRP/OSPF) is by default marked to DSCP6, the highest priority. Pings are treated as normal, default traffic. I know that a lot of ISPs treat pings even as low priority traffic.

. . . marked to DSCP6, the highest priority.

Don't forget DSCP CS7.

Also keep in mind any ToS marking doesn't guarantee any special treatment, or what the actual special treatment might be.

Joseph W. Doherty
Hall of Fame Expert

By default, for Cisco, I believe there no special preference for interface queuing (also including non-serial links), i.e. it's all FIFO.  I also believe ping packets are treated like other packets.

However, some Cisco devices do give preference to what traffic is dropped first if the interface ingress queue fills.  I think their preference is for IPPrec 6 and 7 values.

Palani Mohan
Cisco Employee

Hi Paul

On links T1/E1 below, the default queuing is fair-queue aka weighted fair queue. (Not FIFO). For more info, check the reference doc.

With this for background, here are the answers for the two questions:
Routing protocol pkts are definitely prioritized ahead of all other types of traffic. This part is hard-coded in IOS. Two attributes are used for priority handling and these are:

  • IP Precedence bits
  • pak_priority

to arrive at what gets prioritized at times of congestion. For more info on this, review the contents of the doc titled “Understanding How Routing Updates and Layer 2 Control Packets Are Queued on an Interface with a QoS Service Policy
NOTE: This doc (strongly) hints that this applies only when QoS is applied. Please keep in mind when the link speed is fair-queue, it is QoS applied scenario.


Pings originating/terminating at the router are control plane traffic. These are “process switched”, as opposed to data plane traffic which  are (mostly) “CEF switched”. CEF switching happens under interrupt whereas process switching has to wait for its turn of using the CPU. Without getting into additional details, the answer is that process switched traffic will be handled with lesser priority (I am using the word in a very very loose manner) when compared to CEF switched pkts.

I hope this helps …. Palani

On links T1/E1 below, the default queuing is fair-queue aka weighted fair queue. (Not FIFO). For more info, check the reference doc.

I thought the more recent versions of IOS no longer supported interface WFQ.  Can you confirm whether they do or not?  Your doc reference is version 12.2 and your other link reference is dated Feb 15, 2008.

That said, I forgot about serial interface default WFQ.  Well done to mention it!

NOTE: This doc (strongly) hints that this applies only when QoS is applied. Please keep in mind when the link speed is fair-queue, it is QoS applied scenario.

Yup, if interface WFQ is enabled, whether by default or explicitly, WFQ prioritizes by IPPrec value. So, Palani is quite right for slower serial interfaces which are actively running WFQ, routing packets with their IPPrec 6 settings would be prioritized.  (BTW, I recall WFQ had an original weighting methodology, later amended, so actual amount of prioritization differs between WFQ "versions".  I doubt you would ever run a IOS version using the original methodology.)

Pings originating/terminating at the router are control plane traffic. These are “process switched”, as opposed to data plane traffic which  are (mostly) “CEF switched”. CEF switching happens under interrupt whereas process switching has to wait for its turn of using the CPU. Without getting into additional details, the answer is that process switched traffic will be handled with lesser priority (I am using the word in a very very loose manner) when compared to CEF switched pkts.

Much in that paragraph easy to misunderstand.

A point to emphasis in what Palani wrote, this does not apply to transit packets, only, as he notes, to control plane packets originating/terminating at the router.

Packets terminating at the device would not be process switched or CEF switched.

I believe all locally/device sourced packets are process switched.

Locally/device source packets also need CPU to do whatever else needs to be done to source them and process them, and that's often managed under some software process.  Generally transit traffic has the highest "priority".

I've noted the above, because the OP isn't really clear if he is only asking about packets originating/terminating at the device, whether just transiting the device, or both, as both can apply to typical control plane traffic like pings and routing packets.

The statement to be very careful of, which Palani also tries to note, is:

Without getting into additional details, the answer is that process switched traffic will be handled with lesser priority (I am using the word in a very very loose manner) when compared to CEF switched pkts.

Indeed priority might, or might not, be applicable at all.

If packets all arrived on the same ingress interface, and were to be all directed to the same egress interface, but some were to be process switched and some CEF switched . . .

If they were of the same "flow", delivery order would not change.

If there were of different "flows", I don't think delivery order would change, but I'm not sure.  (Palani, do you know?)

If packets arrived on two different interfaces, both directed to the same egress interface, and the packets on one ingress interface were all process switched and on the other ingress interface all CEF switched, (assuming all else equal), more of the CEF switched packets may go out the egress interface.  This not because of any "priority", per se, but because CEF can maintain a higher transfer rate due to much less internal processing overhead per packet.

Palani, I read the first link you mentioned, and that only applies to interfaces with a service policy (MQC) applied. My question is for an interface with no QoS at all.

As for pings, I meant ping traffic in general, not generated by the router itself. 

I forgot that fact about T1/E1 links and below. However, I am interested in higher rate links, i.e. T3 or Ethernet.

So I think the answer to my question, is that both of these types of traffic are put on greater-than-E1-speed link in a FIFO fashion, with no preference whatsoever (except for within the router itself via the pak_priority mechanism for routing protocol packets). Obviously I can specify QoS to change the link behavior, but was wondering about the default settings I suppose.

As for pings, I meant ping traffic in general, not generated by the router itself. 

For transient ping packets, again, it should be treated like other transient packets (by default).

For routing protocols, I believe PAK should only apply for locally generated packets.  Of course, most IGPs would not transit a box.  Only iBGP commonly does, but when it does, again, it too would be treated like other transient traffic (by default).

When you get to interface itself, and default FIFO, I've found this Cisco statement:

Note: With legacy queuing methods such as priority queuing and custom queuing or with a default interface FIFO queue, non-RSP routers enqueue pak_priority messages to the head of the queue to ensure both minimal latency and minimal drop probability.

found in this old document: http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-congestion-management-queueing/18664-rtgupdates.html

BTW, the above treatment for something like EIGRP, explains the EIGRP feature to limit its own link bandwidth utilization so as to not totally starve other traffic.  I.e. effectively, PAK priority (with FIFO) is PQ.

BTW, also found BGP packets do not get PAK priority.

Hi Paul

I thought I responded but, it is not the case. Hope it is not too late.

My question is for an interface with no QoS at all.


If show int states FIFO, then that would confirm pkts leaving the interface will be in the order they are lined up on the tx ring (First In to the Tx ring).

NOTE: QoS may be applied via config OR IOS may determine QoS needs to be applied (depending on the link speed)

As for pings, I meant ping traffic in general, not generated by the router itself.

A ping transmitting through the router is IP/pkt (as far as the router is concerned) and is no different from a TCP/HTTP or UDP/RTP pkt. These will be CEF switched and FIFO’d out.

NOTE: If the interface config has features (ZBF for example) configured, then IOS will look beyond layer-3 but, the default behavior would be limit to looking at layer-3.


I forgot that fact about T1/E1 links and below. However, I am interested in higher rate links, i.e. T3 or Ethernet.

FIFO

So I think the answer to my question, is that both of these types of traffic are put on greater-than-E1-speed link in a FIFO fashion, with no preference whatsoever (except for within the router itself via the pak_priority mechanism for routing protocol packets). Obviously I can specify QoS to change the link behavior, but was wondering about the default settings I suppose.

You are correct. Default is FIFO for all pkts, in the order they are handed off to the Tx Ring. Every now and then, we see configs with aggressive hello/Dead timers. While this work fine mostly except when high traffic (CPU is pegged at 100% or near 100%). When this happens, you will see adjacency flap. So, here is your indirect evidence that when show int says FIFO, it is FIFO for all pkts.

Kind regards ... Palani

Palani Mohan
Cisco Employee

Hi Paul

This thread is showing up as "Unanswered". Kindly ask questions/clarifications and we will aim to answer them. On the other hand, if your questions are answered, please select "Endorse Answer" and it would lead to the thread status changing to "Answered".

On a regular basis, we scan the forums to assist unanswered questions. This is the background for this request.

Sincerely ... Palani

View solution in original post