mirror of
https://github.com/vyos/vyos-documentation.git
synced 2025-10-26 01:31:44 +02:00
Compare commits
4 Commits
952837766d
...
0cd19d99a4
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
0cd19d99a4 | ||
|
|
db46ed7f3f | ||
|
|
abe1b22d41 | ||
|
|
0ec6852cfb |
20
README.md
20
README.md
@ -9,23 +9,25 @@ Our old wiki with documentation from the VyOS 1.1.x and early 1.2.0 era can stil
|
||||
|
||||
# Versions
|
||||
|
||||
Our version follows the very same branching scheme as the VyOS source modules
|
||||
itself. We maintain one documentation branch per VyOS release. The default
|
||||
branch that contains the most recent VyOS documentation is called `current`
|
||||
and matches the latest VyOS release which is 1.4 at the time.
|
||||
Our documentation repository follows the same branching scheme as the VyOS source itself.
|
||||
We maintain one documentation branch per VyOS release.
|
||||
The default branch that contains the most recent VyOS documentation is called `current`
|
||||
and matches the latest VyOS rolling release.
|
||||
|
||||
All new documentation enhancements go to the `current` branch. If those changes
|
||||
are beneficial for previous VyOS documentation versions they will be
|
||||
cherry-picked to the appropriate branch(es).
|
||||
|
||||
Post-1.2.0 branches are named after constellations sorted by area from smallest to
|
||||
largest. There are 88 of them, here's the
|
||||
VyOS branches are named after constellations sorted by area from smallest to largest.
|
||||
There are 88 of them, here's the
|
||||
[complete list](https://en.wikipedia.org/wiki/IAU_designated_constellations_by_area).
|
||||
|
||||
* 1.2.x: `crux` (Southern Cross)
|
||||
* 1.3.x: `equuleus` (Little Horse)
|
||||
The branches we have had so far:
|
||||
|
||||
* 1.5.x: `circinus` (Compasses)
|
||||
* 1.4.x: `sagitta` (Arrow)
|
||||
* ...
|
||||
* 1.3.x: `equuleus` (Little Horse)
|
||||
* 1.2.x: `crux` (Southern Cross)
|
||||
|
||||
### Sphinx
|
||||
Debian requires some extra steps for
|
||||
|
||||
@ -26,13 +26,16 @@ This will enable sFlow on the specified interface. You can repeat this command f
|
||||
|
||||
sFlow collects statistics only for traffic *received* on the interface. If you want to monitor traffic *sent* on the interface, you need to enable sFlow on the corresponding interface in the opposite direction.
|
||||
|
||||
Optionally, you can specify the sampling rate for the interface using the following command:
|
||||
Optionally, you can specify the number of bytes from each packet that should be included in the sFlow sample using the following command:
|
||||
|
||||
.. cfgcmd::
|
||||
|
||||
set vpp sflow sample-rate <rate>
|
||||
set vpp sflow header-bytes <bytes>
|
||||
|
||||
This will set the sampling rate for the specified interface. The default sampling rate is 1, which means that every packet is sampled. A higher sampling rate means that fewer packets are sampled, which can reduce the amount of data sent to the sFlow collector. This can be useful in high-traffic environments to reduce the load on the collector.
|
||||
This defines the size of the packet header (in bytes) captured for each sFlow sample.
|
||||
|
||||
The sampling rate is configured globally under the ``system sflow`` section and automatically applied to VPP sFlow.
|
||||
This ensures consistent sampling behavior between the system and VPP, and prevents configuration conflicts.
|
||||
|
||||
Finally, you need to enable integration between VPP and the kernel sFlow agent using the following command:
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user