.. _example_protocols_bgp_neighbor_multihop:

########
Multihop
########


.. sidebar:: Contents

  .. contents::
    :depth: 2
    :local:

Scenario to verify BGP **multihop** functionality using both **ebgp-multihop**
and **ttl-security** (GTSM - RFC 5082) for eBGP sessions across non-directly
connected peers.

By default, eBGP sessions require peers to be directly connected (TTL=1). When
peers are separated by intermediate routers, additional configuration is needed:

- **ebgp-multihop <N>**: Sets the TTL of outgoing BGP packets to N, allowing
  the session to traverse up to N hops. If N is too low for the actual hop count,
  the packets expire before reaching the peer and the session cannot establish.

- **ttl-security hops <N>**: Implements GTSM (RFC 5082). The sender transmits
  packets with TTL=255 and the receiver only accepts packets with
  TTL >= (255 - N). For a peer 2 hops away, TTL arrives as 253 (255-2).
  With ``hops 1``, minimum accepted TTL is 254, so 253 is rejected.
  With ``hops 5``, minimum accepted TTL is 250, so 253 is accepted.

Each feature is tested with both a low value (session blocked) and a high value
(session established) to verify correct hop/TTL enforcement. The topology uses
3 DUTs: **DUT0** (AS 100) and **DUT1** (AS 200) are 2 hops apart with **DUT2**
acting as a transit router.

.. image:: 3duts.svg
  :width: 400

*****************
Test BGP Multihop
*****************

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

Test eBGP multihop features with both low values (session blocked) and high
values (session established) to verify correct hop/TTL enforcement.

Scenario
========

.. include:: multihop/testbgpmultihop

.. raw:: html

  <hr>