============== Traffic Policy ============== .. sidebar:: Contents .. contents:: :depth: 2 :local: This chapter covers some aspects related to ``traffic policy``, which is a set of rules that allows us to perform different actions on network packets (such as packet mangling (ToS, TTL, etc), PBR (Policy-Based Routing), firewalling, or rate-limit). Policies can be applied to the different types of traffic: * **link** traffic: incoming level 2 traffic (*only for physical devices*). * **in** traffic: incoming traffic. * **out** traffic: outgoing traffic. * **local-in**: local incoming traffic. * **local-out**: local outgoing traffic. Every ``traffic policy`` contains a set of rules that are processed in order. If a rule has a ``traffic selector`` configured and the network packet matches at least one of the selector rules, policy actions are applied. If the policy rule has no ``traffic selector`` configured, then all packets will match. :doc:`Here <../selector/index>` you can find more information about ``traffic selectors``. Policy rules always perform an action, the default one being to ``accept`` the packet; i.e., no more policy rules are processed. This default behavior can be changed by setting the ``action`` field. For example, with the ``drop`` action we can drop a packet. Therefore, later stages or hooks in the network path will not be aware of the existence of that packet. Another useful action is ``continue``. This can be set to change some fields in the packet (like *dscp*, *ttl*, *tcp-mss*) and continue the policy rule processing. Configuration command :osdx:cfg:`traffic policy * rule * advisor *` can be used to dynamically enable/disable a policy rule depending on an advisor status. If the advisor is enabled, the policy rule will be enabled too. Otherwise, the policy rule will be disabled and it will be skipped. Traffic policies can also be used for QoS pre-classification, ensuring packets are automatically assigned to the appropriate ``traffic control`` class without executing any filter. As a result, packet processing is optimized, and performance is improved. :doc:`Here <../control/index>` you can find more information about ``traffic control``. Configuration ============= This is the syntax to create a ``traffic policy``: .. code-block:: none set traffic policy [ ... ] In order to assign a ``traffic policy`` to an interface, you have to use the following command: .. code-block:: none set interfaces traffic policy [priority ] ``traffic policies`` can also be globally configured. This means that policy rules will be evaluated regardless of the input/output interface. They can be configured by using the following command: .. code-block:: none set system traffic policy [priority ] Since ``traffic policies`` can be configured at both interface and system levels, it is important to define the execution order using the ``priority`` field. This field indicates at what point in the network path the ``traffic policy`` will be executed. Higher priority means it will be executed earlier. If an interface policy has the same priority as a system policy, the one attached to the interface will be executed before. .. attention:: ``priority`` must be carefully chosen because the actions that a traffic policy performs may affect the following traffic policies. For example, a traffic policy with very-high priority could mangle a packet and subsequent traffic policies may not even be processed. The ``priority`` field can also be used to indicate if the traffic policy has to be executed before or after NAT (Network Address Translation) rules. ``traffic policies`` configured with a ``very-high`` or ``high`` priority will be executed before NAT. ``traffic policies`` configured with a ``low`` or ``very-low`` priority will be executed afterwards. Finally, some traffic policies can also be attached to the *link* hooks of physical interfaces (Ethernet, Cellular, etc). In this case, you have to use the following commands: .. code-block:: none set interfaces traffic policy Examples ======== Let's suppose we want to define a ``traffic policy`` to process outgoing traffic. We need to mark all packets that match the ''SEL_1'' selector and we want to drop all packets that match ''SEL_2''. To create that policy, we have to type the following commands: .. code-block:: none set traffic policy POLICY_1 rule 1 selector SEL_1 set traffic policy POLICY_1 rule 1 set mark 1 set traffic policy POLICY_1 rule 2 selector SEL_2 set traffic policy POLICY_1 rule 2 action drop Now, if we want to attach that ``traffic policy`` to a specific interface, we can use the following command: .. code-block:: none set interfaces ethernet eth1 traffic policy out POLICY_1 On the other hand, if we want to always execute that ``traffic policy``, (regardless of the interface the packets traverses), we would use this command: .. code-block:: none set system traffic policy out POLICY_1 :ref:`Here `, you can find more examples related to ``traffic policies``. Monitoring ========== The :osdx:op:`traffic policy * show detailed` operational command can be used to display some network statistics. *Example:* .. code-block:: none admin@osdx$ traffic policy show detailed Policy SET_VRF -- ifc eth0 -- hook in --------------------------------------------------------------------- rule selector pkts match pkts eval bytes match bytes eval --------------------------------------------------------------------- 1 ACTION_TRIGGER 7 7 444 444 --------------------------------------------------------------------- Total 7 7 444 444 Selector ACTION_TRIGGER (Policy SET_VRF -- ifc eth0 -- hook in -- rule 1) --------------------------------------------------------- rule pkts match pkts eval bytes match bytes eval --------------------------------------------------------- 1 (excl.) 0 7 0 444 2 7 7 444 444 --------------------------------------------------------- Total 7 7 444 444 Command Summary =============== .. depth=5 to show traffic policy actions .. osdx:cmdtree:: cfg :maxdepth: 5 traffic policy .. osdx:cmdtree:: op traffic policy