| Age | Commit message (Collapse) | Author |
|---|
|
Route-target export/import for l2vpn-evpn vni xxx works as
leafNode with multiple values
We have to use "for" for such values
|
|
Setting something like `protocols ospf area 10 range 10.10.0.0/16` without sub options doesn't work. This is because no range commands are generated when there is no leaf nodes set under the `range` tag node.
```
edit protocols ospf
set area 16 network 10.10.0.0/16
set area 16 range 10.10.0.0/16
commit
```
```
$ vtysh -c 'show run'
!
router ospf
auto-cost reference-bandwidth 100
timers throttle spf 200 1000 10000
network 10.10.0.0/16 area 16
exit
```
The generated FRR commands above is missing something like:
```
area 16 range 10.10.0.0/16
```
|
|
`passive_interface` is a leaf node. Also adds a smoketest.
|
|
|
|
Adding the parameters that were missing to the OSPF FRR template.
|
|
|
|
|
|
no-php-flag
The nested if statement was not properly evaluated during smoketests making
them fail. There is no need to nest the if's - as a simple string can be
appended by {{ 'foo' if bar is vyos_defined }}
|
|
This is to refactor ISIS segment routing to match up with OSPF segment routing.
|
|
|
|
In this commit we add OSPF segment routing, smoke tests, handlers,
FRR template changes, and CLI commands.
|
|
policy: T4660: Changed CLI syntax in route-map set community
|
|
Changed CLI syntax in route-map set community,
set large-community, set extcommunity
Allows to add multiple communities, large-communities
and extcommunities in clear view.
Added new well-known communities.
Added non-transitive feature in extcommunities.
Fixed community's validators.
|
|
FRR supports multiple route-targets to be used for import/export:
address-family l2vpn evpn
route-target import 20:10
route-target import 20:11
route-target import 20:12
route-target import 40:40
route-target export 1:2
route-target export 1:3
route-target export 40:40
exit-address-family
Thus the <multi/> property is added to the relevant CLI nodes.
|
|
isis: T4693: Fix ISIS segment routing configurations
This change is to fix more bugs in which ISIS segment routing was broken due to a refactor. This change also introduces a few additions to the ISIS handler for checking per prefix validations for segment value and mutual exclusivity for two options.
|
|
Add new VyOS CLI command:
set protocols bgp parameters bestpath peer-type multipath-relax
This command specifies that BGP decision process should consider paths from all
peers for multipath computation. If this option is enabled, paths learned from
any of eBGP, iBGP, or confederation neighbors will be multipath if they are
otherwise considered equal cost. [1]
[1]: http://docs.frrouting.org/en/stable-8.3/bgp.html#clicmd-bgp-bestpath-peer-type-multipath-relax
|
|
This change is to fix a bug in which ISIS segment routing was broken due to a refactor.
This change also is going to introduce a smoketest to make sure this is caught in the future.
|
|
|
|
bgp: T4257: Changing BGP "local-as" to "system-as"
This change is to change the global BGP name for the node "local-as" to "system-as"
This is needed so that there's less ambiguity with the local-as feature per neighbor.
bgp: T4257: Changing BGP "local-as" to "system-as"
bgp: T4257: Changing BGP "local-as" to "system-as"
This change is to change the global BGP name for the node "local-as" to "system-as"
This is needed so that there's less ambiguity with the local-as feature per neighbor.
|
|
Commit a2ab95ff68b ("pppoe: T4384: replace default-route CLI option with common
CLI nodes already present for DHCP") had an issue as the PPPoE interface options
and also DHCP interface options did not honor the no-default-route option.
This has been fixed.
|
|
for ipv4
|
|
|
|
prefix-len on both matches. Also change help properties of route-source node.
|
|
|
|
* 'T4449' of https://github.com/nicolas-fort/vyos-1x:
Policy: T4449: Extend matching options for route-map ip nexthop
|
|
|
|
|
|
|
|
FRR: T4020: Added CLI options for FRR daemons
|
|
|
|
|
|
present for DHCP
VyOS 1.4 still leverages PPPd internals on the CLI.
pppd supports three options for a default route, none, auto, force.
* none: No default route is installed on interface up
* auto: Default route is only installed if there is yet no default route
* force: overwrite any default route
There are several drawbacks in this design for VyOS and the users. If auto is
specified, this only counted for static default routes - but what about dynamic
ones? Same for force, only a static default route got replaced but dynamic ones
did not got taken into account.
The CLI is changed and we now re-use already existing nodes from the DHCP
interface configuration:
* no-default-route:
On link up no default route is installed, same as the previous
default-route none
* default-route-distance:
We can now specify the distance of this route for the routing table on the
system. This defaults to 210 as we have for DHCP interfaces. All this will be
migrated using a CLI migration script.
|
|
static routes
Issue is identical to the problem in T3680 (05aa22dcb4ce) which was for DHCP
based routes. Once a static route is added to the system, the PPPoE
auto-installed default route is lost.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
