ip-precedence for management traffic
Sachs, Marcus Hans (Marc)
marcus.sachs at verizon.com
Tue Dec 29 12:17:20 CST 2009
Sorry, your original query got lost behind the smoke of my out-of-the-box musings.
My biggest quarrel with any type of IP precedence is that anybody along the chain can set or reset these bits. There is no assurance that a packet's priority will remain at the level set by the originator unless you have some very well disciplined netadmins between sender and receiver who do not fiddle with header bits. If I knew that I could reliably set ToS bits in the IP header and they would remain unchanged then I would add a shim to my local stack that sets all of my flows at the highest priority thereby making my Internet experience a wee bit faster than somebody who leaves those three bits set to 000.
I'm sure others will have widely different opinions.
From: Luca Tosolini [mailto:bit.gossip at chello.nl]
Sent: Tuesday, December 29, 2009 1:38 PM
Subject: Re: ip-precedence for management traffic
my inquiry was very specific and bounded to the following assumptions:
- in-band management
- not possible to filter customer traffic, certainly not for somebody
In this case diffserv can help prioritize management plane traffic over
user traffic. To do that only ipp6 and ipp7 values are available for non
IPP6 is used by default for routing protocols, that is control plane; so
probably it is better not to mess around with it.
This leaves to IPP7 for management plane traffic, value that I can not
recall of having seen used by any application/protocol.
What is the general opinion about this?
On Tue, 2009-12-29 at 12:02 +0100, Luca Tosolini wrote:
> what is the general opinion of using ipp 7 'network control' for
> management traffic like: telnet ssh snmp .....
> The idea is that ipp 0 1 2 3 4 5 are used for user traffic
> ipp = 6 is used by default by routing protocols like BGP, OSPF, LDP ...
> this leaves out only ipp 7 for management traffic, on the premise that
> routing and management should not share the same queue and
More information about the NANOG