Age | Commit message (Collapse) | Author |
|
|
|
firewall: T4178: T3873: tcp flags syntax refactor, intra-zone-filtering fix
|
|
* Add support for ECN and CWR flags
|
|
|
|
Drop the overcomplex function get_config_value() to search for NTPd
configuration values. Rather assemble the required string and probe for
its presence in the configuration like we do on most other smoketests.
|
|
* Migrates all policy route references from `ipv6-route` to `route6`
* Update test config `dialup-router-medium-vpn` to test migration of `ipv6-route` to `route6`
|
|
Ability to set virtual_address on not vrrp-listen interface
Add ability don't track primary vrrp interface "exclude-vrrp-interface"
Add ability to set tracking (state UP/Down) on desired interfaces
For example eth0 is used for vrrp and we want to track another eth1
interface that not belong to any vrrp-group
|
|
smoketest: shim: Optimise speed of `lsof` command
|
|
firewall: zone-policy: T2199: T4130: Fixes for firewall, state-policy and zone-policy
|
|
|
|
zone-policy
|
|
keepalived: T4109: Add high-availability virtual-server
|
|
Add new feature, high-availability virtual-server
Change XML, python and templates
Move vrrp to root node 'high-availability' as all logic are
handler by root node 'high-availability'
|
|
firewall: T4130: Fix firewall state-policy errors
|
|
|
|
monitoring: T3872: Add a new feature service monitoring
|
|
|
|
* 'firewall' of https://github.com/sarthurdev/vyos-1x:
zone_policy: T3873: Implement intra-zone-filtering
policy: T2199: Migrate policy route op-mode to XML/Python
policy: T2199: Migrate policy route to XML/Python
zone-policy: T2199: Migrate zone-policy op-mode to XML/Python
zone-policy: T2199: Migrate zone-policy to XML/Python
firewall: T2199: Migrate firewall op-mode to XML/Python
firewall: T2199: Migrate firewall to XML/Python
|
|
|
|
|
|
|
|
|
|
As high-abalability is root node for vrrp, the path
should be changed
|
|
|
|
|
|
|
|
|
|
|
|
The implementation of the "auto" option to specify the sflow/netflow
agent-address is very error prone. The current implementation will determine
the IP address used for the "auto" value as follow:
Get BGP router-id
1) If not found use OSPF router-id
2) If not found use OSPFv3 router-id
3) If not found use "the first IP address found on the system
Well, what is the "first IP address found"? Also this changes if DHCP is in use.
Also another disadvantage is when the BGP/OSPF/OSPFv3 router-id is changed,
the agent-address is not updated upon the next reboot of the system.
This task is about removing the "auto" keyword from the CLI at all and make it
either entirely configurable by the user and hardcode the value in CLI, or not
use this at all.
If "auto" is specified we will query the system in the above order and set the
proper router-id in the CLI. If none can be found the CLI node is removed.
|
|
|
|
|
|
|
|
|
|
logs: T3774: Added CLI options to control atop logs rotation
|
|
Added the ability to control the `/var/log/messages` rotation.
Renamed the option `maxsize` to `max-size`.
|
|
|
|
The BGP conditional advertisement feature uses the non-exist-map or the
exist-map and the advertise-map keywords of the neighbor advertise-map command
in order to track routes by the route prefix.
non-exist-map
=============
* If a route prefix is not present in the output of non-exist-map command, then
advertise the route specified by the advertise-map command.
* If a route prefix is present in the output of non-exist-map command, then do
not advertise the route specified by the addvertise-map command.
exist-map
=========
* If a route prefix is present in the output of exist-map command, then
advertise the route specified by the advertise-map command.
* If a route prefix is not present in the output of exist-map command, then do
not advertise the route specified by the advertise-map command.
This feature is useful when some prefixes are advertised to one of its peers
only if the information from the other peer is not present (due to failure in
peering session or partial reachability etc).
The conditional BGP announcements are sent in addition to the normal
announcements that a BGP router sends to its peer.
CLI nodes can be found under:
* set protocols bgp neighbor <ip> address-family <afi> conditional-advertisement
* set protocols bgp peer-group <p> address-family <afi> conditional-advertisement
|
|
In the past a peer-group was only assigned to the BGP process but not bound
to any neighbor. This has been changed.
|
|
This command is applicable at the global level and at an individual bgp level.
If applied at the global level all bgp instances will wait for fib installation
before announcing routes and there is no way to turn it off for a particular
BGP vrf.
|
|
Administrative shutdown of all peers of a bgp instance. Drop all BGP peers,
but preserve their configurations. The peers are notified in accordance with
RFC 8203 by sending a NOTIFICATION message with error code Cease and subcode
Administrative Shutdown prior to terminating connections.
This global shutdown is independent of the neighbor shutdown, meaning that
individually shut down peers will not be affected by lifting it.
|
|
This command enables rejection of incoming and outgoing routes having AS_SET
or AS_CONFED_SET type.
|
|
This command allows user to prevent session establishment with BGP peers with
lower holdtime less than configured minimum holdtime.
When this command is not set, minimum holdtime does not work.
|
|
Whenever BGP peer address becomes unreachable we must bring down the BGP
session immediately. Currently only single-hop EBGP sessions are brought down
immediately. IBGP and multi-hop EBGP sessions wait for hold-timer expiry to
bring down the sessions.
This new configuration option helps user to teardown BGP sessions immediately
whenever peer becomes unreachable.
This configuration is available at the bgp level. When enabled, configuration
is applied to all the neighbors configured in that bgp instance.
|
|
Set the period to rerun the conditional advertisement scanner process.
The default is 60 seconds.
|
|
|
|
|
|
|
|
Background information [1]. Specifies whether an external control plane
(e.g. ip route encap/EVPN) or the internal FDB should be used.
[1]: https://legacy.netdevconf.info/2.2/slides/prabhu-linuxbridge-tutorial.pdf
|
|
|
|
|