<commit_before>.. only:: not (epub or latex or html)

    WARNING: You are looking at unreleased Cilium documentation.
    Please use the official rendered version released here:
    https://docs.cilium.io

#######
Routing
#######

.. _arch_overlay:

Encapsulation
=============

When no configuration is provided, Cilium automatically runs in this mode as it
is the mode with the fewest requirements on the underlying networking
infrastructure.

In this mode, all cluster nodes form a mesh of tunnels using the UDP-based
encapsulation protocols `VXLAN` or `Geneve`. All traffic between Cilium nodes
is encapsulated.

Requirements on the network
---------------------------

* Encapsulation relies on normal node to node connectivity. This means that if
  Cilium nodes can already reach each other, all routing requirements are
  already met.

* The underlying network and firewalls must allow encapsulated packets:

  ================== =====================
  Encapsulation Mode Port Range / Protocol
  ================== =====================
  VXLAN (Default)    8472/UDP
  Geneve             6081/UDP
  ================== =====================

Advantages of the model
-----------------------

Simplicity
  The network which connects the cluster nodes does not need to be made aware
  of the PodCIDRs. Cluster nodes can spawn multiple routing or link-layer
  domains. The topology of the underlying network is irrelevant as long as
  cluster nodes can reach each other using IP/UDP.

Addressing space
  Due to not depending on any underlying networking limitations, the available
  addressing space is potentially much larger and allows to run any number of
  pods per node if the PodCIDR size is configured accordingly.

Auto-configuration
  When running together with an orchestration system such as Kubernetes, the
  list of all nodes in the cluster including their associated allocation prefix
  node is made available to each agent automatically. New nodes joining the
  cluster will automatically be incorporated into the mesh.

Identity context
  Encapsulation protocols allow for the carrying of metadata along with the
  network packet. Cilium makes use of this ability to transfer metadata such as
  the source security identity and load balancing state to perform
  direct-server-return (DSR).


Disadvantages of the model
--------------------------

MTU Overhead
  Due to adding encapsulation headers, the effective MTU available for payload
  is lower than with native-routing (50 bytes per network packet for VXLAN).
  This results in a lower maximum throughput rate for a particular network
  connection. This can be largely mitigated by enabling jumbo frames (50 bytes
  of overhead for each 1500 bytes vs 50 bytes of overhead for each 9000 bytes).

.. _arch_direct_routing:
.. _native_routing:

Native-Routing
==============

The native routing datapath is enabled with ``tunnel: disabled`` and enables
the native packet forwarding mode. The native packet forwarding mode leverages<commit_msg>docs: Remove mention of state transfer for DSR<commit_after>.. only:: not (epub or latex or html)

    WARNING: You are looking at unreleased Cilium documentation.
    Please use the official rendered version released here:
    https://docs.cilium.io

#######
Routing
#######

.. _arch_overlay:

Encapsulation
=============

When no configuration is provided, Cilium automatically runs in this mode as it
is the mode with the fewest requirements on the underlying networking
infrastructure.

In this mode, all cluster nodes form a mesh of tunnels using the UDP-based
encapsulation protocols `VXLAN` or `Geneve`. All traffic between Cilium nodes
is encapsulated.

Requirements on the network
---------------------------

* Encapsulation relies on normal node to node connectivity. This means that if
  Cilium nodes can already reach each other, all routing requirements are
  already met.

* The underlying network and firewalls must allow encapsulated packets:

  ================== =====================
  Encapsulation Mode Port Range / Protocol
  ================== =====================
  VXLAN (Default)    8472/UDP
  Geneve             6081/UDP
  ================== =====================

Advantages of the model
-----------------------

Simplicity
  The network which connects the cluster nodes does not need to be made aware
  of the PodCIDRs. Cluster nodes can spawn multiple routing or link-layer
  domains. The topology of the underlying network is irrelevant as long as
  cluster nodes can reach each other using IP/UDP.

Addressing space
  Due to not depending on any underlying networking limitations, the available
  addressing space is potentially much larger and allows to run any number of
  pods per node if the PodCIDR size is configured accordingly.

Auto-configuration
  When running together with an orchestration system such as Kubernetes, the
  list of all nodes in the cluster including their associated allocation prefix
  node is made available to each agent automatically. New nodes joining the
  cluster will automatically be incorporated into the mesh.

Identity context
  Encapsulation protocols allow for the carrying of metadata along with the
  network packet. Cilium makes use of this ability to transfer metadata such as
  the source security identity.


Disadvantages of the model
--------------------------

MTU Overhead
  Due to adding encapsulation headers, the effective MTU available for payload
  is lower than with native-routing (50 bytes per network packet for VXLAN).
  This results in a lower maximum throughput rate for a particular network
  connection. This can be largely mitigated by enabling jumbo frames (50 bytes
  of overhead for each 1500 bytes vs 50 bytes of overhead for each 9000 bytes).

.. _arch_direct_routing:
.. _native_routing:

Native-Routing
==============

The native routing datapath is enabled with ``tunnel: disabled`` and enables
the native packet forwarding mode. The native packet forwarding mode leverages
{'fraction_non_alphanumeric': 0.10420140046682227, 'fraction_numerical': 0.007335778592864288, 'mean_word_length': 3.7992, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2264253', 'n_tokens_mistral': 1473, 'n_tokens_neox': 1365, 'n_words': 774}