| Age | Commit message (Collapse) | Author |
|---|
|
Sometimes a modem might give a local IP before it retrieves a WAN IP.
This can be an issue with failover routes,
since the default route will get overridden.
|
|
Every time when set configuration bgp, you need set AS number. There is very
less benefit in this system so the AS number is moved from a tagNode level down
to a leafNode with the name "local-as", same as on the neighbor or peer-group
level.
This changes the CLI configuration from:
set protocols bgp 100 neighbor 10.10.1.2 remote-as 200
to
set protocols bgp local-as 100
set protocols bgp neighbor 10.10.1.2 remote-as 200
|
|
Replace the Flask micro-framework with FastAPI, in order to support
extensions to the API and OpenAPI 3.* generation. This change will
remain backwards compatible with previous versions. Notably, the
multipart forms version of requests remain supported; in addition
application/json requests are now natively supported.
|
|
As we and FRR do not support multiple FRR process instances, there is no need
to make this configurable for a user. We rather rely on a solid default "VyOS".
|
|
VRF support can be tested using:
set vrf name red table 1000
set vrf name red protocols isis domain FOOO
set vrf name red protocols isis net 49.0001.1921.6800.1002.00
set vrf name red protocols isis interface eth1
|
|
As there can only be one running IS-IS process (FRR limitation) there is no need
in having a tagNode here. This adds artifical restrictions/limitations when
moving on to support VRFs for IS-IS protocol.
|
|
Instead of having the dynamic routing protocols OSPF and BGP residing under
the "protocols vrf <name> [ospf|bgp]" nodes, rather move them directly under
the "vrf name <name> protocols [ospf|bgp]" node. Now all VRF related parts
are placed under the same root node.
This eases the verify steps tremendously, as we do not need to check wheter a
VRF eists or not, it will always exist as we operate under a child node.
|
|
The following VyOS CLI config
vrf red {
bgp 100 {
neighbor 1.1.1.1 {
peer-group foo
}
peer-group foo {
passive
password bar
remote-as 200
}
}
}
Will generaste the FRR configuration:
!
router bgp 100 vrf red
no bgp ebgp-requires-policy
no bgp network import-check
neighbor foo peer-group
neighbor foo remote-as 200
neighbor foo password bar
neighbor foo passive
neighbor 1.1.1.1 peer-group foo
!
|
|
VyOS CLI config:
vrf red {
ospf {
default-information {
originate {
always
}
}
default-metric 30
passive-interface default
}
}
Will create the FRR configuration snippet:
!
router ospf vrf red
auto-cost reference-bandwidth 100
timers throttle spf 200 1000 10000
passive-interface default
default-metric 30
default-information originate always
!
|
|
|
|
set protocols bgp 65010 address-family l2vpn-evpn vni 100 route-target both 516:10516
set protocols bgp 65010 address-family l2vpn-evpn vni 100 rd 192.168.0.1:514
Todo: add verify() step to check if at least one evpn enabled BGP neighbor
exits, else FRR will error out with: This command is only supported under EVPN VRF
|
|
(cherry picked from commit 55c4dd3586a3b0e2fe53ccad75c996b55d9979eb)
|
|
|
|
nptv6: T2518: Support IPv6 address translation
|
|
|
|
|
|
|
|
* set protocols bgp ASN address-family ipv4-unicast maximum-paths
* set protocols bgp ASN address-family ipv4-unicast maximum-paths-ibgp
* set protocols bgp ASN address-family ipv6-unicast maximum-paths
* set protocols bgp ASN address-family ipv6-unicast maximum-paths-ibgp
|
|
dhcp: T3300: add DHCP default route distance
|
|
|
|
|
|
|
|
|
|
|
|
|
|
bgp: T2100: Changing RFC8212 behavior and option toggle
|
|
In this commit we add the default operation within BGP
to have RFC8212 disabled for eBGP routes. This default
should preserve the normal behavior for VyOS from earlier
releases of FRR to the current latest release. Another
option that we add is the ability to toggle whether or
not RFC8212 is enabled or disabled.
|
|
|
|
As thought in the beginning the dhcp-interface route option can not be
superseeded by the interface option. When a route is installed for a DHCP
interface, that interface is usually a broadcast interface which can not be
used for plain interface-based routes.
The old Vyatta logic was migrated to Python where the current received
next-hop address from the DHCP interface is installed as next-hop address.
|
|
|
|
(cherry picked from commit d5804b19d3ffecdd4fe6bd89d50ac84dabb549fd)
|
|
bgp: T3322: Fix timers for neighbor
|
|
|
|
|
|
We need to exit from the bfd context by end instead of exit, else FRR reload
will get confused:
frr-reload output: 168 2021-02-16 21:13:19,014 DEBUG: LINE
ip prefix-list GLOBAL seq 10 permit 192.168.100.1/32: append to current_context_lines, ['bfd']
|
|
This superseeds GitHub pull request #723 by implementing support to add an OSPF
virtual-link interface which connects different areas to the "no passive-interface"
configuration option when the system uses "passive-interface default".
Setting "protocols ospf passive-interface-exclude vlink0" on the VyOS CLI will
render the FRR OSPF configuration "no passive-interface VLINK0".
|
|
In order to keep the current behavior when upgrading from 1.2 -> 1.3 -> 1.4
FRR requires us to set this option.
This configuration modifies the behavior of the network statement. If you have
this configured the underlying network must exist in the rib (default). If you
have the [no] form configured then BGP will not check for the networks
existence in the rib.
For FRR versions 7.3 and before frr defaults for datacenter were the network
must exist, traditional did not check for existence. For versions 7.4 and
beyond both traditional and datacenter the network must exist.
VyOS uses "traditional".
|
|
|
|
bfd: T3310: migrate to get_config_dict() and FRR reload
|
|
|
|
|
|
|
|
|
|
|
|
* protocols bgp 65000 neighbor 192.0.2.1 address-family ipv4-unicast addpath-tx-all
* protocols bgp 65000 neighbor 192.0.2.1 address-family ipv4-unicast addpath-tx-per-as
* protocols bgp 65000 neighbor 2001:db8::1 address-family ipv6-unicast addpath-tx-all
* protocols bgp 65000 neighbor 2001:db8::1 address-family ipv6-unicast addpath-tx-per-as
|
|
|
|
|
|
The following options were not represented in the Jinja2 template:
- port
- advertisement-interval
- strict-capability-match
In addition the smoketests have been extended to support IPv6 neighbors, too.
|
|
|
|
|
