| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This commit is a cleanup and refinement of the container hosting implementation.
- Renamed CLI node ipv4-prefix -> prefix so both IPv4 and IPv6 prefix can be
supplied in the future. This is currently limited to IPv4 only as when using
IPv6 networks in combination with IPv4 the IPv4 prefix is altered randomly
- De-nested if clauses
- Use "for foo, bar in baz.items()" to more easily iterate of dictionary
values, this means "bar" can be used to access "baz[foo]"
|
|
This reverts commit 619c518bfc904b060b5b59180940a804fe1beafd.
|
|
|
|
When rendering a dynamic routing protocol ensure the context, e.g. "router bgp"
or "router ospf" is proberly exited before applying any zebra route-map.
|
|
|
|
The following options one can specify in a route-map not got rendered as they
have been missed out:
* set comm-list
* set community
* set extcommunity (both route-target and site-of-origin)
* set table
|
|
get_config_dict()
|
|
|
|
In this commit we add more address families within
BGP. This should bring VyOS the ability to enable
the rest of the capabilities within FRR.
Co-authored-by: Cheeze_It <none@none.com>
|
|
containers: T2216: Add podman for containers
|
|
|
|
Removing the Zebra/Linux Kernel route-map added by "set protocols rip route-map"
was not removed once applied. This was because the removal must happen within
the zebra daemon and not ripd.
|
|
Removing the Zebra/Linux Kernel route-map added by "set protocols isis route-map"
was not removed once applied. This was because the removal must happen within
the zebra daemon and not isisd.
|
|
|
|
set vrf name red protocols bgp address-family l2vpn-evpn advertise ipv4 unicast
|
|
This is a fix for commit 6f6f45c5 ("bgp: T3463: change no-ipv4-unicast order
when applying configuration") as this changed the handling of the "else" path,
which lead to failing smoketests as the "no bgp ebgp-requires-policy" option
was no longer set.
|
|
The "no bgp default ipv4-unicast" option must be applied to FRR before adding
any neighbor to the system. If this is not the case, neighbors will start
exchanging v4 routes over v6 peers.
|
|
Commit 548d9057e3e (vrf: T3344: move dynamic routing protocols under "vrf name
<name> protocols") temporary removed the possibility to specify the VNI for a
given VRF to to changing of the CLI configuration nodes.
As VNI is set inside zebra, we can re-use the now widely deployed frr python
library to configure and change the configuration without any interference to
other FRR daemons.
|
|
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.
|
|
|
