tools/testing/selftests/net/srv6_end_dx6_netfilter_test.sh
Source file repositories/reference/linux-study-clean/tools/testing/selftests/net/srv6_end_dx6_netfilter_test.sh
File Facts
- System
- Linux kernel
- Corpus path
tools/testing/selftests/net/srv6_end_dx6_netfilter_test.sh- Extension
.sh- Size
- 11395 bytes
- Lines
- 341
- Domain
- Support Tooling And Documentation
- Bucket
- tools
- Inferred role
- Support Tooling And Documentation: tools
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
#!/bin/bash
# SPDX-License-Identifier: GPL-2.0
#
# author: Jianguo Wu <wujianguo@chinatelecom.cn>
#
# Mostly copied from tools/testing/selftests/net/srv6_end_dt6_l3vpn_test.sh.
#
# This script is designed for testing the support of netfilter hooks for
# SRv6 End.DX4 behavior.
#
# Hereafter a network diagram is shown, where one tenants (named 100) offer
# IPv6 L3 VPN services allowing hosts to communicate with each other across
# an IPv6 network.
#
# Routers rt-1 and rt-2 implement IPv6 L3 VPN services leveraging the SRv6
# architecture. The key components for such VPNs are: a) SRv6 Encap behavior,
# b) SRv6 End.DX4 behavior.
#
# To explain how an IPv6 L3 VPN based on SRv6 works, let us briefly consider an
# example where, within the same domain of tenant 100, the host hs-1 pings
# the host hs-2.
#
# First of all, L2 reachability of the host hs-2 is taken into account by
# the router rt-1 which acts as an arp proxy.
#
# When the host hs-1 sends an IPv6 packet destined to hs-2, the router rt-1
# receives the packet on the internal veth-t100 interface, rt-1 contains the
# SRv6 Encap route for encapsulating the IPv6 packet in a IPv6 plus the Segment
# Routing Header (SRH) packet. This packet is sent through the (IPv6) core
# network up to the router rt-2 that receives it on veth0 interface.
#
# The rt-2 router uses the 'localsid' routing table to process incoming
# IPv6+SRH packets which belong to the VPN of the tenant 100. For each of these
# packets, the SRv6 End.DX4 behavior removes the outer IPv6+SRH headers and
# routs the packet to the specified nexthop. Afterwards, the packet is sent to
# the host hs-2 through the veth-t100 interface.
#
# The ping response follows the same processing but this time the role of rt-1
# and rt-2 are swapped.
#
# And when net.netfilter.nf_hooks_lwtunnel is set to 1 in rt-1 or rt-2, and a
# rpfilter iptables rule is added, SRv6 packets will go through netfilter PREROUTING
# hooks.
#
#
# +-------------------+ +-------------------+
# | | | |
# | hs-1 netns | | hs-2 netns |
# | | | |
# | +-------------+ | | +-------------+ |
# | | veth0 | | | | veth0 | |
# | | cafe::1/64 | | | | cafe::2/64 | |
# | +-------------+ | | +-------------+ |
# | . | | . |
# +-------------------+ +-------------------+
# . .
# . .
# . .
# +-----------------------------------+ +-----------------------------------+
# | . | | . |
# | +---------------+ | | +---------------- |
# | | veth-t100 | | | | veth-t100 | |
# | | cafe::11/64 | +----------+ | | +----------+ | cafe::22/64 | |
# | +-------+-------+ | route | | | | route | +-------+-------- |
# | | table | | | | table | |
# | +----------+ | | +----------+ |
# | +--------------+ | | +--------------+ |
# | | veth0 | | | | veth0 | |
# | | 2001:11::1/64 |.|...|.| 2001:11::2/64 | |
# | +--------------+ | | +--------------+ |
Annotation
- Atlas domain: Support Tooling And Documentation / tools.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.