mirror of
https://github.com/vyos/vyos-documentation.git
synced 2025-10-26 08:41:46 +01:00
Merge pull request #183 from StephenOrJames/master
Fix some typos and capitalizations
This commit is contained in:
Daniil Baturin
GitHub
commit
bea7c7318f
@ -23,5 +23,5 @@ branch on the bottom left corner.
|
||||
VyOS CLI syntax may change between major (and sometimes minor) versions. Please
|
||||
always refer to the documentation matching your current, running installation.
|
||||
If a change in the CLI is required, VyOS will ship a so called migration script
|
||||
which will take care of adjusting the synatax. No action needs to be taken by
|
||||
which will take care of adjusting the syntax. No action needs to be taken by
|
||||
you.
|
||||
|
||||
@ -7,8 +7,8 @@ VyOS 1.x line aims to preserve backward compatibility and provide a safe
|
||||
upgrade path for existing Vyatta Core users. You may think of VyOS 1.0.0 as
|
||||
VC7.0.
|
||||
|
||||
Vyatta release compatiblity
|
||||
---------------------------
|
||||
Vyatta release compatibility
|
||||
----------------------------
|
||||
|
||||
Vyatta Core releases from 6.5 to 6.6 should be 100% compatible.
|
||||
|
||||
|
||||
@ -22,7 +22,7 @@ Shopping Cart
|
||||
|
||||
Optional (10GE)
|
||||
---------------
|
||||
If you wan't to get additional ethernet ports or even 10GE connectivity
|
||||
If you want to get additional ethernet ports or even 10GE connectivity
|
||||
the following optional parts will be required:
|
||||
|
||||
* 1x Supermicro RSC-RR1U-E8 (Riser Card)
|
||||
@ -98,7 +98,7 @@ Shopping Cart
|
||||
* 1x VARIA Group Item 326745 19" dual rack for APU4
|
||||
* 1x Compex WLE900VX (Optional mini PCIe WiFi module)
|
||||
|
||||
The 19" enclosure can accomodate up to two APU4 boards - there is a single and
|
||||
The 19" enclosure can accommodate up to two APU4 boards - there is a single and
|
||||
dual front cover.
|
||||
|
||||
.. note:: Compex WLE900VX is only supported in mPCIe slot 1.
|
||||
@ -252,7 +252,7 @@ Qotom Q355G4
|
||||
|
||||
The install on this Q355G4 box is pretty much plug and play. The port numbering
|
||||
the OS does might differ from the labels on the outside, but the UEFI firmware
|
||||
has a port blink test built in with MAC adresses so you can very quickly
|
||||
has a port blink test built in with MAC addresses so you can very quickly
|
||||
identify which is which. MAC labels are on the inside as well, and this test
|
||||
can be done from VyOS or plain Linux too. Default settings in the UEFI will
|
||||
make it boot, but depending on your installation wishes (i.e. storage type,
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
.. _vyosonvmware:
|
||||
|
||||
Running on VMWare ESXi
|
||||
Running on VMware ESXi
|
||||
######################
|
||||
|
||||
ESXi 5.5 or later
|
||||
@ -14,7 +14,7 @@ using the normal process around `install image`.
|
||||
Memory Contention Considerations
|
||||
--------------------------------
|
||||
When the underlying ESXi host is approaching ~92% memory utilisation it will start the balloon process in s a 'soft' state to start reclaiming memory from guest operating systems.
|
||||
This causes an artifical pressure using the vmmemctl driver on memory usage on the virtual guest. As VyOS by default does not have a swap file, this vmmemctl pressure is unable to
|
||||
This causes an artificial pressure using the vmmemctl driver on memory usage on the virtual guest. As VyOS by default does not have a swap file, this vmmemctl pressure is unable to
|
||||
force processes to move in memory data to the paging file, and blindly consumes memory forcing the virtual guest into a low memory state with no way to escape. The balloon can expand to 65% of
|
||||
guest allocated memory, so a VyOS guest running >35% of memory usage, can encounter an out of memory situation, and trigger the kernel oom_kill process. At this point a weighted
|
||||
lottery favouring memory hungry processes will be run with the unlucky winner being terminated by the kernel.
|
||||
|
||||
@ -6,7 +6,7 @@ Configuration Overview
|
||||
|
||||
VyOS makes use of a unified configuration file for the entire systems
|
||||
configuration: ``/config/config.boot``. This allows easy template creation,
|
||||
backup, and replication of system configuration. A sytem can thus also be
|
||||
backup, and replication of system configuration. A system can thus also be
|
||||
easily cloned by simply copying the required configuration files.
|
||||
|
||||
Terminology
|
||||
@ -341,7 +341,7 @@ Config Archive
|
||||
==============
|
||||
|
||||
VyOS automatically maintains backups of every previous configurations which
|
||||
has been comitted to the system.
|
||||
has been committed to the system.
|
||||
|
||||
Local Archive
|
||||
-------------
|
||||
|
||||
@ -234,7 +234,7 @@ Many base system packages are pulled straight from Debian's main and contrib
|
||||
repositories, but there are exceptions.
|
||||
|
||||
This chapter lists those exceptions and gives you a brief overview what we
|
||||
have done on those packages. If you only wan't to build yourself a fresh ISO
|
||||
have done on those packages. If you only want to build yourself a fresh ISO
|
||||
you can completely skip this chapter. It may become interesting once you have
|
||||
a VyOS deep dive.
|
||||
|
||||
|
||||
@ -62,7 +62,7 @@ your commit message, as shown below:
|
||||
* ``Jenkins: add current Git commit ID to build description``
|
||||
|
||||
If there is no Phabricator_ reference in the commits of your pull request, we
|
||||
have to ask you to ammend the commit message. Otherwise we will have to reject
|
||||
have to ask you to amend the commit message. Otherwise we will have to reject
|
||||
it.
|
||||
|
||||
Writing good commit messages
|
||||
@ -83,7 +83,7 @@ The format should be and is inspired by: https://git-scm.com/book/ch5-2.html
|
||||
|
||||
* Followed by a message which describes all the details like:
|
||||
|
||||
* What/why/how something has been changed, makes everyones life easier when
|
||||
* What/why/how something has been changed, makes everyone's life easier when
|
||||
working with `git bisect`
|
||||
|
||||
* All text of the commit message should be wrapped at 72 characters if
|
||||
@ -93,7 +93,7 @@ The format should be and is inspired by: https://git-scm.com/book/ch5-2.html
|
||||
* If applicable a reference to a previous commit should be made linking
|
||||
those commits nicely when browsing the history: ``After commit abcd12ef
|
||||
("snmp: this is a headline") a Python import statement is missing,
|
||||
throwing the follwoing exception: ABCDEF``
|
||||
throwing the following exception: ABCDEF``
|
||||
|
||||
* Always use the ``-x`` option to the ``git cherry-pick`` command when back or
|
||||
forward porting an individual commit. This automatically appends the line:
|
||||
@ -109,7 +109,7 @@ Limits:
|
||||
|
||||
* We only accept bugfixes in packages other than https://github.com/vyos/vyos-1x
|
||||
as no new functionality should use the old style templates (``node.def`` and
|
||||
Perl/BASH code. Use the new stlye XML/Python interface instead.
|
||||
Perl/BASH code. Use the new style XML/Python interface instead.
|
||||
|
||||
Please submit your patches using the well-known GitHub pull-request against our
|
||||
repositories found in the VyOS GitHub organisation at https://github.com/vyos
|
||||
@ -120,7 +120,7 @@ Determinine source package
|
||||
|
||||
Suppose you want to make a change in the webproxy script but yet you do not know
|
||||
which of the many VyOS packages ship this file. You can determine the VyOS
|
||||
package name in question by using Debians ``dpkg -S`` command of your running
|
||||
package name in question by using Debian's ``dpkg -S`` command of your running
|
||||
VyOS installation.
|
||||
|
||||
.. code-block:: none
|
||||
@ -138,7 +138,7 @@ Fork Repository and submit Patch
|
||||
|
||||
Forking the repository and submitting a GitHub pull-request is the preferred
|
||||
way of submitting your changes to VyOS. You can fork any VyOS repository to your
|
||||
very own GitHub account by just appending ``/fork`` to any repositories URL on
|
||||
very own GitHub account by just appending ``/fork`` to any repository's URL on
|
||||
GitHub. To e.g. fork the ``vyos-1x`` repository, open the following URL in your
|
||||
favourite browser: https://github.com/vyos/vyos-1x/fork
|
||||
|
||||
@ -149,7 +149,7 @@ repository:
|
||||
|
||||
* Fork: ``git remote add myfork https://github.com/<user>/vyos-1x.git``
|
||||
|
||||
In order to record you as the author of the fix please indentify yourself to Git
|
||||
In order to record you as the author of the fix please identify yourself to Git
|
||||
by setting up your name and email. This can be done local for this one and only
|
||||
repository ``git config`` or globally using ``git config --global``.
|
||||
|
||||
@ -260,7 +260,7 @@ Configuration Script Structure and Behaviour
|
||||
|
||||
Your configuration script or operation mode script which is also written in
|
||||
Python3 should have a line break on 80 characters. This seems to be a bit odd
|
||||
nowadays but as some people also work remotly or programm using vi(m) this is
|
||||
nowadays but as some people also work remotely or program using vi(m) this is
|
||||
a fair good standard which I hope we can rely on.
|
||||
|
||||
In addition this also helps when browsing the GitHub codebase on a mobile
|
||||
@ -563,7 +563,7 @@ Examples:
|
||||
|
||||
* Good: "TCP connection timeout"
|
||||
* Bad: "tcp connection timeout"
|
||||
* Horrible: "Tcp connectin timeout"
|
||||
* Horrible: "Tcp connection timeout"
|
||||
|
||||
Acronyms also **must** be capitalized to visually distinguish them from normal
|
||||
words:
|
||||
@ -673,10 +673,10 @@ Migrating old CLI
|
||||
- None
|
||||
- All logic should be in the scripts
|
||||
|
||||
Continous Integration
|
||||
=====================
|
||||
Continuous Integration
|
||||
======================
|
||||
|
||||
VyOS makes use of Jenkins_ as our Continous Integration (CI) service. Our CI
|
||||
VyOS makes use of Jenkins_ as our Continuous Integration (CI) service. Our CI
|
||||
server is publicly accessible here: https://ci.vyos.net. You can get a brief
|
||||
overview of all required components shipped in a VyOS ISO.
|
||||
|
||||
@ -687,7 +687,7 @@ but instead of building it from source on every run, we rather always fetch a
|
||||
fresh copy (if needed) from Dockerhub_.
|
||||
|
||||
Each module is build on demand if a new commit on the branch in question is
|
||||
found. After a successfull run the resulting Debian Package(s) will be deployed
|
||||
found. After a successful run the resulting Debian Package(s) will be deployed
|
||||
to our Debian repository which is used during build time. It is located here:
|
||||
http://dev.packages.vyos.net/repositories/.
|
||||
|
||||
|
||||
@ -123,13 +123,13 @@ With the firewall you can set rules to accept, drop or reject ICMP in, out or lo
|
||||
|
||||
set firewall all-ping enable
|
||||
|
||||
When the command above is set, VyOS will answer every ICMP echo request addressed to itself, but that will only happen if no other rule is applied droping or rejecting local echo requests. In case of conflict, VyOS will not answer ICMP echo requests.
|
||||
When the command above is set, VyOS will answer every ICMP echo request addressed to itself, but that will only happen if no other rule is applied dropping or rejecting local echo requests. In case of conflict, VyOS will not answer ICMP echo requests.
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
set firewall all-ping disable
|
||||
|
||||
When the comand above is set, VyOS will answer no ICMP echo request addressed to itself at all, no matter where it comes from or whether more specific rules are being applied to accept them.
|
||||
When the command above is set, VyOS will answer no ICMP echo request addressed to itself at all, no matter where it comes from or whether more specific rules are being applied to accept them.
|
||||
|
||||
Example Partial Config
|
||||
----------------------
|
||||
|
||||
@ -39,7 +39,7 @@ How is VyOS different from any other router distributions and platform?
|
||||
- DHCP, TFTP, mDNS repeater, broadcast relay and DNS forwarding support
|
||||
- Both IPv4 and IPv6 support
|
||||
- Runs on physical and virtual platforms alike: small x86 boards, big servers,
|
||||
KVM, Xen, VMWare, Hyper-V, and more
|
||||
KVM, Xen, VMware, Hyper-V, and more
|
||||
- Completely free and open source, with documented internal APIs and build
|
||||
procedures
|
||||
- Community driven. Patches are welcome and all code, bugs, and nightly builds
|
||||
|
||||
@ -51,7 +51,7 @@ configured to be the default (:opcmd:`set system image default-boot`).
|
||||
.. opcmd:: delete system image [image-name]
|
||||
|
||||
Delete no longer needed images from the system. You can specify an optional
|
||||
image name to delete, the image name can be retrived via a list of available
|
||||
image name to delete, the image name can be retrieved via a list of available
|
||||
images can be shown using the :opcmd:`show system image`.
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
@ -64,7 +64,7 @@ distributions it is installed by default as package managers use it to verify
|
||||
package signatures. If not pre-installed, it will need to be downloaded and
|
||||
installed.
|
||||
|
||||
The offical VyOS public key can be retrieved in a number of ways. Skip to
|
||||
The official VyOS public key can be retrieved in a number of ways. Skip to
|
||||
:ref:`gpg-verification` if the key is already present.
|
||||
|
||||
It can also be retrieved directly from a key server:
|
||||
@ -158,7 +158,7 @@ downloaded.
|
||||
downloaded VyOS image. That small *.asc* file is the signature for the
|
||||
associated image.
|
||||
|
||||
Finally, verify the authencity of the downloaded image:
|
||||
Finally, verify the authenticity of the downloaded image:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
@ -274,7 +274,7 @@ method which allows deploying VyOS through the network.
|
||||
|
||||
* :ref:`dhcp-server`
|
||||
* :ref:`tftp-server`
|
||||
* Webserver (HTTP) - optional, but we will use it to speed up intallation
|
||||
* Webserver (HTTP) - optional, but we will use it to speed up installation
|
||||
* VyOS ISO image to be installed (do not use images prior to VyOS 1.2.3)
|
||||
* ``pxelinux.0``, ``ldlinux.c32`` from SYSLINUX_
|
||||
(https://mirrors.edge.kernel.org/pub/linux/utils/boot/syslinux/)
|
||||
|
||||
@ -13,8 +13,8 @@ you can have as many as you want.
|
||||
|
||||
.. hint:: A Dummy interface is always up, thus it could be used for
|
||||
management traffic or as source/destination for and :abbr:`IGP (Interior
|
||||
Gateway Protocol)` like :ref:`bgp` so your internal BGP link is not dependant
|
||||
on physical link states and multiple routes can be choosen to the
|
||||
Gateway Protocol)` like :ref:`bgp` so your internal BGP link is not dependent
|
||||
on physical link states and multiple routes can be chosen to the
|
||||
destination. A :ref:`dummy-interface` Interface should always be preferred
|
||||
over a :ref:`loopback-interface` interface.
|
||||
|
||||
|
||||
@ -14,8 +14,8 @@ services on your local machine.
|
||||
|
||||
.. hint:: A lookback interface is always up, thus it could be used for
|
||||
management traffic or as source/destination for and :abbr:`IGP (Interior
|
||||
Gateway Protocol)` like :ref:`bgp` so your internal BGP link is not dependant
|
||||
on physical link states and multiple routes can be choosen to the
|
||||
Gateway Protocol)` like :ref:`bgp` so your internal BGP link is not dependent
|
||||
on physical link states and multiple routes can be chosen to the
|
||||
destination. A :ref:`dummy-interface` Interface should always be preferred
|
||||
over a :ref:`loopback-interface` interface.
|
||||
|
||||
|
||||
@ -31,7 +31,7 @@ may be blocked by the hypervisor.
|
||||
|
||||
.. note:: As VyOS is based on Linux and there was no official IANA port assigned
|
||||
for VXLAN, VyOS uses a default port of 8472. You can change the port on a
|
||||
per VXLAN interface basis to get it working accross multiple vendors.
|
||||
per VXLAN interface basis to get it working across multiple vendors.
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
@ -23,7 +23,7 @@ added the configuration tree, specifying any detected settings (for example,
|
||||
its MAC address) and configured to run in monitor mode.
|
||||
|
||||
To be able to use the wireless interfaces you will first need to set a
|
||||
regulatory domain with the country code of your locaion.
|
||||
regulatory domain with the country code of your location.
|
||||
|
||||
.. cfgcmd:: set system wifi-regulatory-domain DE
|
||||
|
||||
@ -34,7 +34,7 @@ Configuring Access-Point
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The following example creates a WAP. When configuring multiple WAP interfaces,
|
||||
you must specify unique IP addresses, channels, Network IDs commonly refered
|
||||
you must specify unique IP addresses, channels, Network IDs commonly referred
|
||||
to as :abbr:`SSID (Service Set Identifier)`, and MAC addresses.
|
||||
|
||||
The WAP in this example has the following characteristics:
|
||||
@ -281,8 +281,8 @@ The wireless interface identifier can range from wlan0 to wlan999.
|
||||
|
||||
.. opcmd:: show interfaces wireless <wlanX> scan
|
||||
|
||||
This command is used to retrive information about WAP within the range of your
|
||||
wireless interface. This command is usefull on wireless interfaces configured
|
||||
This command is used to retrieve information about WAP within the range of your
|
||||
wireless interface. This command is useful on wireless interfaces configured
|
||||
in station mode.
|
||||
|
||||
.. note:: Scanning is not supported on all wireless drivers and wireless
|
||||
|
||||
@ -13,7 +13,7 @@ In a minimal, configuration the following must be provided:
|
||||
* a interface with a nexthop
|
||||
* one rule with a LAN (inbound-interface) and the WAN (interface).
|
||||
|
||||
lets assume we have two dhcp WAN interfaces and one LAN (eth2)
|
||||
Let's assume we have two DHCP WAN interfaces and one LAN (eth2):
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
|
||||
12
docs/nat.rst
12
docs/nat.rst
@ -94,10 +94,10 @@ rewritten to address the internal (private) host.
|
||||
Bidirectional NAT
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
This is a common szenario where both :ref:`source-nat` and
|
||||
This is a common scenario where both :ref:`source-nat` and
|
||||
:ref:`destination-nat` are configured at the same time. It's commonly used then
|
||||
internal (private) hosts need to establish a connection with external resources
|
||||
and external systems need to acces sinternal (private) resources.
|
||||
and external systems need to access internal (private) resources.
|
||||
|
||||
NAT, Routing, Firewall Interaction
|
||||
----------------------------------
|
||||
@ -109,7 +109,7 @@ NAT Ruleset
|
||||
-----------
|
||||
|
||||
:abbr:`NAT (Network Address Translation)` is configured entirely on a series
|
||||
of so called `rules`. Rules are numbered and evaluated by the underlaying OS
|
||||
of so called `rules`. Rules are numbered and evaluated by the underlying OS
|
||||
in numerical order! The rule numbers can be changes by utilizing the
|
||||
:cfgcmd:`rename` and :cfgcmd:`copy` commands.
|
||||
|
||||
@ -145,7 +145,7 @@ rules applied. Five different filters can be applied within a NAT rule
|
||||
set nat source rule 20 outbound-interface eth0
|
||||
|
||||
* **inbound-interface** - applicable only to :ref:`destination-nat`. It
|
||||
configures the interface which is used for the inside traffic the the
|
||||
configures the interface which is used for the inside traffic the
|
||||
translation rule applies to.
|
||||
|
||||
Example:
|
||||
@ -205,7 +205,7 @@ Address Conversion
|
||||
------------------
|
||||
|
||||
Every NAT rule has a translation command defined. The address defined for the
|
||||
translation is the addrass used when the address information in a packet is
|
||||
translation is the address used when the address information in a packet is
|
||||
replaced.
|
||||
|
||||
Source Address
|
||||
@ -358,7 +358,7 @@ Example:
|
||||
* Redirect Microsoft RDP traffic from the internal (LAN, private) network via
|
||||
:ref:`destination-nat` in rule 110 to the internal, private host 192.0.2.40.
|
||||
We also need a :ref:`source-nat` rule 110 for the reverse path of the traffic.
|
||||
The internal network 192.0.2.0/24 is reachable via interfache `eth0.10`.
|
||||
The internal network 192.0.2.0/24 is reachable via interface `eth0.10`.
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
|
||||
@ -29,7 +29,7 @@ Operation
|
||||
|
||||
.. opcmd:: show protocols static arp
|
||||
|
||||
Display all known ARP table entries spanning accross all interfaces
|
||||
Display all known ARP table entries spanning across all interfaces
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
@ -50,4 +50,4 @@ Operation
|
||||
10.1.1.1 ether 00:53:00:de:23:2e C eth1
|
||||
10.1.1.100 ether 00:53:00:de:23:aa CM eth1
|
||||
|
||||
.. _ARP: https://en.wikipedia.org/wiki/Address_Resolution_Protocol
|
||||
.. _ARP: https://en.wikipedia.org/wiki/Address_Resolution_Protocol
|
||||
|
||||
@ -177,7 +177,7 @@ Route Selection
|
||||
.. cfgcmd:: set protocols bgp <asn> parameters bestpath as-path confed
|
||||
|
||||
This command specifies that the length of confederation path sets and
|
||||
sequences should should be taken into account during the BGP best path
|
||||
sequences should be taken into account during the BGP best path
|
||||
decision process.
|
||||
|
||||
.. cfgcmd:: set protocols bgp <asn> parameters bestpath as-path multipath-relax
|
||||
|
||||
@ -58,7 +58,7 @@ Configuration
|
||||
|
||||
Example
|
||||
^^^^^^^
|
||||
The next exemple is a simple configuration of conntrack-sync.
|
||||
The next example is a simple configuration of conntrack-sync.
|
||||
|
||||
|
||||
.. figure:: /_static/images/service_conntrack_sync-schema.png
|
||||
@ -117,7 +117,7 @@ If you are using VRRP, you need to define a VRRP sync-group, and use ``vrrp sync
|
||||
set service conntrack-sync failover-mechanism vrrp sync-group 'syncgrp'
|
||||
|
||||
|
||||
On the active router, you should have informations in the internal-cache of
|
||||
On the active router, you should have information in the internal-cache of
|
||||
conntrack-sync. The same current active connections number should be shown in
|
||||
the external-cache of the standby router
|
||||
|
||||
|
||||
@ -291,7 +291,7 @@ Raw parameters can be passed to shared-network-name, subnet and static-mapping:
|
||||
These parameters are passed as-is to isc-dhcp's dhcpd.conf under the
|
||||
configuration node they are defined in. They are not validated so an error in
|
||||
the raw parameters won't be caught by vyos's scripts and will cause dhcpd to
|
||||
fail to start. Always verify that the parameters are correct before commiting
|
||||
fail to start. Always verify that the parameters are correct before committing
|
||||
the configuration. Refer to isc-dhcp's dhcpd.conf manual for more information:
|
||||
https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcpdconf
|
||||
|
||||
|
||||
@ -34,7 +34,7 @@ Configuration
|
||||
.. cfgcmd:: set service dns dynamic interface <interface> rfc2136 <service-name> server <server>
|
||||
|
||||
Configure the DNS `<server>` IP/FQDN used when updating this dynamic
|
||||
assignemnt.
|
||||
assignment.
|
||||
|
||||
.. cfgcmd:: set service dns dynamic interface <interface> rfc2136 <service-name> zone <zone>
|
||||
|
||||
@ -124,7 +124,7 @@ hostnames, protocol and server.
|
||||
.. cfgcmd:: set service dns dynamic interface <interface> service <service> server <server>
|
||||
|
||||
When a ``custom`` DynDNS provider is used the `<server>` where update
|
||||
requests are beeing sent to must be specified.
|
||||
requests are being sent to must be specified.
|
||||
|
||||
Example:
|
||||
^^^^^^^^
|
||||
|
||||
@ -4,9 +4,9 @@
|
||||
UDP Broadcast Relay
|
||||
###################
|
||||
|
||||
Certain vendors use broadcasts to identify their equipemnt within one ethernet
|
||||
Certain vendors use broadcasts to identify their equipment within one ethernet
|
||||
segment. Unfortunately if you split your network with multiple VLANs you loose
|
||||
the ability of identifying your equiment.
|
||||
the ability of identifying your equipment.
|
||||
|
||||
This is where "UDP broadcast relay" comes into play! It will forward received
|
||||
broadcasts to other configured networks.
|
||||
@ -20,7 +20,7 @@ Configuration
|
||||
.. cfgcmd:: set service broadcast-relay id <n> description <description>
|
||||
|
||||
A description can be added for each and every unique relay ID. This is
|
||||
usefull to distinguish between multiple different ports/appliactions.
|
||||
useful to distinguish between multiple different ports/appliactions.
|
||||
|
||||
.. cfgcmd:: set service broadcast-relay id <n> interface <interface>
|
||||
|
||||
|
||||
@ -24,7 +24,7 @@ Configuration
|
||||
# Enable proxy service
|
||||
set service webproxy listen-address 192.168.0.1
|
||||
|
||||
# By default it will listen to port 3128. If you wan't something else you have to define that.
|
||||
# By default it will listen to port 3128. If you want something else you have to define that.
|
||||
set service webproxy listen-address 192.168.0.1 port 2050
|
||||
|
||||
# By default the transparent proxy on that interface is enabled. To disable that you simply
|
||||
@ -43,7 +43,7 @@ Options
|
||||
Filtering by category
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you wan't to use existing blacklists you have to create/download a database
|
||||
If you want to use existing blacklists you have to create/download a database
|
||||
first. Otherwise you will not be able to commit the config changes.
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
@ -28,7 +28,7 @@ Local
|
||||
|
||||
.. cfgcmd:: set system login user <name> authentication encrypted-password <password>
|
||||
|
||||
Setup encrypted password for given username. This is usefull for
|
||||
Setup encrypted password for given username. This is useful for
|
||||
transferring a hashed password from system to system.
|
||||
|
||||
.. cfgcmd:: set system login user <name> group <group>
|
||||
@ -127,7 +127,7 @@ Configuration
|
||||
|
||||
Setup the `<timeout>` in seconds when querying the RADIUS server.
|
||||
|
||||
.. hint:: If you wan't to have admin users to authenticate via RADIUS it is
|
||||
.. hint:: If you want to have admin users to authenticate via RADIUS it is
|
||||
essential to sent the ``Cisco-AV-Pair shell:priv-lvl=15`` attribute. Without
|
||||
the attribute you will only get regular, non privilegued, system users.
|
||||
|
||||
|
||||
@ -164,11 +164,11 @@ The `unlimited` keyword is used to specify that an unlimited number of packets
|
||||
can be captured (by default, 1,000 packets are captured and you're returned to
|
||||
the VyOS command prompt).
|
||||
|
||||
Interface Bandwith
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
Interface Bandwidth
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
to take a quick view on the used bandwith of an interface use the ``monitor
|
||||
bandwith`` command
|
||||
to take a quick view on the used bandwidth of an interface use the ``monitor
|
||||
bandwidth`` command
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
@ -199,7 +199,7 @@ show the following:
|
||||
Interface performance
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To take a look on the network bandwith between two nodes, the ``monitor
|
||||
To take a look on the network bandwidth between two nodes, the ``monitor
|
||||
bandwidth-test`` command is used to run iperf.
|
||||
|
||||
.. code-block:: none
|
||||
@ -209,8 +209,8 @@ bandwidth-test`` command is used to run iperf.
|
||||
accept Wait for bandwidth test connections (port TCP/5001)
|
||||
initiate Initiate a bandwidth test
|
||||
|
||||
* The ``accept`` command open a listen iperf server on TCP Port 5001
|
||||
* The ``initiate`` command conncet to this server.
|
||||
* The ``accept`` command opens a listening iperf server on TCP Port 5001
|
||||
* The ``initiate`` command connects to that server to perform the test.
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
|
||||
@ -164,7 +164,7 @@ HUB Example Configuration:
|
||||
HUB on AWS Configuration Specifics
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Setting this up on AWS will require a "Custom Protocol Rule" for protocol number "47" (GRE) Allow Rule in TWO places. Firstly on the VPC Network ACL, and secondly on the security group network ACL attached to the EC2 instance. This has been tested as working for the offical AMI image on the AWS Marketplace. (Locate the correct VPC and security group by navigating through the details pane below your EC2 instance in the AWS console)
|
||||
Setting this up on AWS will require a "Custom Protocol Rule" for protocol number "47" (GRE) Allow Rule in TWO places. Firstly on the VPC Network ACL, and secondly on the security group network ACL attached to the EC2 instance. This has been tested as working for the official AMI image on the AWS Marketplace. (Locate the correct VPC and security group by navigating through the details pane below your EC2 instance in the AWS console)
|
||||
|
||||
SPOKE Configuration
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
@ -25,7 +25,7 @@ what needs to be changed to make it work with a different protocol. We assume
|
||||
that IPsec will use pre-shared secret authentication and will use AES128/SHA1
|
||||
for the cipher and hash. Adjust this as necessary.
|
||||
|
||||
.. NOTE:: VMWare users should ensure that VMXNET3 adapters used, e1000 adapters
|
||||
.. NOTE:: VMware users should ensure that VMXNET3 adapters used, e1000 adapters
|
||||
have known issue with GRE processing
|
||||
|
||||
IPsec policy matching GRE
|
||||
|
||||
@ -141,7 +141,7 @@ RADIUS authentication
|
||||
======================
|
||||
|
||||
To enable RADIUS based authentication, the authentication mode needs to be
|
||||
changed withing the configuration. Previous settings like the local users, still
|
||||
changed within the configuration. Previous settings like the local users, still
|
||||
exists within the configuration, however they are not used if the mode has been
|
||||
changed from local to radius. Once changed back to local, it will use all local
|
||||
accounts again.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user