.. _example_system_conntrack_logging_logging:

#######
Logging
#######

The following scenarios show how to configure
the conntrack logging option with different
traffic policies and services enabled, in order
to check that all fields are displayed correctly and all events are captured.

**********
New events
**********

Description
===========

Check NEW sessions events are captured

Scenario
========

.. include:: logging/newevents

.. raw:: html

  <hr>

*************
Update events
*************

Description
===========

Check UPDATE sessions events are captured

Scenario
========

.. include:: logging/updateevents

.. raw:: html

  <hr>

**************
Destroy events
**************

Description
===========

Check DESTROY sessions events are captured

Scenario
========

.. include:: logging/destroyevents

.. raw:: html

  <hr>

***************
Default logging
***************

Description
===========

Set a simple configuration, send a ``ping`` command from one device to other
and check that default fields appear when running ``system journal show``.

Scenario
========

.. include:: logging/defaultlogging

.. raw:: html

  <hr>

****************
Policies logging
****************

Description
===========

Set a simple configuration with mark and label traffic policies,
send a ``ping`` command from one device to other
and check that default, mark and label fields appear when running ``system journal show``.

Scenario
========

.. include:: logging/policieslogging

.. raw:: html

  <hr>

***********
VRF logging
***********

Description
===========

Set a simple configuration with a vrf,
send a ``ping`` command from one device to other
and check that default and vrf fields appear when running ``system journal show``.

Scenario
========

.. include:: logging/vrflogging

.. raw:: html

  <hr>

******************
Not-Bypass logging
******************

Description
===========

Set a simple configuration with a firewall service,
send a ``ping`` command from one device to other
and check that default and bypass fields appear when running ``system journal show``.

Scenario
========

.. include:: logging/not-bypasslogging

.. raw:: html

  <hr>

************
Offload flag
************

Description
===========

Set a simple configuration with ``DUT0`` as an intermediary between ``DUT1``
and ``DUT2``. Initiate a ``ssh`` connection from ``DUT1`` to ``DUT2``
and check that default and offload fields appear when running ``system journal show``.

Scenario
========

.. include:: logging/offloadflag

.. raw:: html

  <hr>

******************
App detect logging
******************

Description
===========

Set a simple configuration enabling app detection in ``system conntrack``, send a ping command from ``DUT1``
and check app detect field appears when running ``system journal show``. After that, enabling app detection
in ``system conntrack`` for http host, try to copy ``index.html`` from a http server
and check that the app detect field appears and belongs to the http server when running ``system journal show``.

Scenario
========

.. include:: logging/appdetectlogging

.. raw:: html

  <hr>

**********************
App Detect Drop Packet
**********************

Description
===========

Set a ``traffic policy`` with action ``drop`` for all the packets matching an appid specified by a ``traffic selector``.
Enable ``http-host`` and ``http-url option`` in ``system conntrack appdetect`` path in order to see relevant information about http packets.
Finnally, log that packets with app-id option and check that appdetect field appear in journal when
running ``system journal show``

Scenario
========

.. include:: logging/appdetectdroppacket

.. raw:: html

  <hr>