Packets from one specific interface on a 1711 at a remote site need to be tagged so they can be routed differently by a 3745 at headquarters. I've started reading about Policy Based Routing and it looks like this technology will enable me to solve this problem. Are there any cavets that I should know about before I begin a design?
Neither QoS nor high-priority queueing are deployed in this network at present but I want to avoid tagging the packets in such a way that would conflict with VoIP and other standards.
Should I use IP TOS or IP Precedence to tag these packets? If IP Precendece is the way to go, is there any reason to set or avoid the value 1 (priority) vs 2 (immediate), vs 3 (flash)?
You can certainly use Policy maps to set the TOS, IP Prec, diffserv field. Since these are mutually incompatible uses of the same bits in the IP header you need to be careful what you do. I would go for the diffserve interpretation for future compatibility.
Differve is of course a total nightmare to use since a particular value can be (and IS) expressed in 3 different ways.
Bizarre code - ef Expedited forwarding
6 bit value in hex -
8 bit value in hex - 6 bit one x 4 - what goes in the Byte field.
8 bit value in decimal - just to add confusion - 4 ways so far.
I think also that the 6 bit values 'make sense' if you look at it as 2 upper bits and 4 lower bits (or some such). The 4 lower bits then get spilt over two hex digits in the 8 bit representation. Phew!!!
Hope your binary is up to scratch.
IIRC Cisco IP phones use ef for voice and cs3 for signalling.
I would pick a low value and use that for you traffic.
PS I said:- "Since these are mutually incompatible uses" They are also compatible - just to clarify things further:-).
Do you have a leased line, or do you have an end-to-end contract with the ISP(s) involved? If you do not, if the packets are flowing over the internet, then as best I recall, it would not be invalid for those bits to be rewritten by intermediate hops (which, after all, might need to use them to give your packets the proper internal priorities in transit.) If you do not have a direct link or MLPS, then if you want to tag the packets at one location and have the tags read at a remote location, you are going to need to do some kind of encapsulation between the two points. Thta could be via GRE, or could be (e.g.) by using an 802.1Q vlan inside an IPSec tunnel.
If the packets are from a different interface, then the implication would be that they have different original source IP addresses. Is there a reason why you can't have the far end differentiate based upon source IPs? If you are NAT'ing, perhaps you could NAT into different IP ranges?
The remote site is connected to headquarters via private radio protected by CryptoVue. I've already checked with the transport folks and they need to modify their software to pass TOS rather than set it to zero everywhere. This is already in progress.
Yes, these packets are from a different subnet. If I understand you correctly, you're suggesting that I don't need to do any tagging at all because the 3745 can easily differentiate them (and route them differently) based on source IP. Is that true?
TOS uses 3 bits in the same location also used fro Diffserv, and Diffserv values support backward compatibility with ToS, so go with Diffserv.
Although you are free to use different Diffserv values to mean anything you like, there are suggested uses mentioned in the various RFCs which are in widespread use.
With the commercial services, the main limitation is which values are actively used (and how many QoS values are implemented - often you get 3, 4 or 5 different QoS levels eg on MPLS, but you should only use those you need...).
EF (expedited forwarding) is used for real time traffic (normally RTP voice), and BE (best effort) for "everything that gets OK service", normally with some AF values as well.
FWIW many telco MPLS / ATM / Frame Relay services dont guarantee that they will leave alone the Diffserv bits anyway.
If you do get such a service, then dont be surprised if you see a surcharge to use QoS, and possibly some changes to your existing service. Many of these seem to get designed down to a price, rather than built ready for an in service upgrade.......
Finally - adding QoS isnt simple because you have to answer all sorts of questions with side effects (ie what traffic types have 1 got and how should i treat them, and which people have the clout to make me give something high QoS even though it doesnt need it etc), so try to use other methods 1st unless this looks fairly easy.
The old joke is that QoS is 10% engineering 20% luck and 100% politics....
then if you want to tag the packets at one location
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.