Age | Commit message (Collapse) | Author |
|
If a router has not formed an LDP neighbor adjacency yet, it
answers all received LDP Hello packets from non-neighbors with
new Hello packets.
This leads to flooding LDP packets to all routers for each LDP
incoming packet.
Add configuration option to disable this behavior
```
set protocols mpls ldp interface eth0 disable-establish-hello
```
|
|
* bgp: T7157: Allow using route-maps for VRF route leaking in BGP
Added the possibility of using route-map in route leaking.
* Improve the constraint error message
---------
Co-authored-by: Daniil Baturin <daniil@baturin.org>
|
|
Added match source-vrf to route-map
|
|
|
|
* set protocols bgp address-family <ipv4-unicast|ipv6-unicast> redistribute
table <n> [metric <n>] [route-map <name>]
|
|
Re-use existing XML constraint added via commit 8f6246da6 ("xml: T7161: provide
re-usable building block for alternative routing tables") and add handy CLI
completion helper.
FRRouting supports redistribution of multiple non-main tables, thus make this
a multi node in addition, too.
|
|
T7089: Fix static route when using PPPoE default route
|
|
Removed an unnecessary command that caused an error
when creating a configuration with VRF and NHRP.
|
|
|
|
|
|
NHRP migration to FRR
|
|
|
|
|
|
Migrate "set protocols static route <x.x.x.x/x> next-hop <y.y.y.y> bfd multi-hop
source <z.z.z.z> profile <NAME>" to: "set protocols static route <x.x.x.x/x>
next-hop <y.y.y.y> bfd profile bar"
FRR supports only one source IP address per BFD multi-hop session. VyOS
had CLI cupport for multiple source addresses which made no sense.
|
|
FRR 10.2 will use "[no] ip forwarding" and "[no] ipv6 forwarding" to enable or
disable IP(v6) forwarding. We no longer rely on sysctl as this was overridden
by FRR later on.
Remove code path for sysctl setting and solely rely on FRR.
|
|
tagNode
This will save an entire level for the configuration and there is no need for a
parent "multicast" node, as it will only have "route" as tagNode below.
Move set protocols static multicast route <x.x.x.x/y> to:
* set protocols static mroute <x.x.x.x/y>
|
|
With FRR 10.0 daemons started to be migrated to integrated FRR mgmtd and a
northbound interface. This led to some drawbacks in the current state how
changes to FRR are handled. The current implementation will use frr-reload.py
and specifies excatly WHICH daemon needs a config update and will only replace
this part inside FRR.
With FRR10 and mgmtd when a partial configuration is sent to mgmtd, it will
remove configuration parts from other daemons like bgpd or ospfd which have
not yet been migrated to mgmtd.
It's not possible to call frr-reload.py with daemon mgmtd - it will error out.
This commit will also change the CLI for static routes:
CLI command "set protocols static route 10.0.0.0/8 next-hop 1.2.3.4 bfd multi-hop
source 1.1.1.1" will be split into:
* set protocols static route 10.0.0.0/8 next-hop 1.2.3.4 bfd source-address 1.1.1.1
* set protocols static route 10.0.0.0/8 next-hop 1.2.3.4 bfd multi-hop
To make the XML blocks reusable, and comply with the FRR CLI - this was actually
a wrong implementation from the beginning as you can not have multiple BFD
source addresses.
CLI command "set protocols static route 10.0.0.0/8 next-hop 1.2.3.4 bfd multi-hop
source 1.1.1.1 profile bar" is changed to:
* set protocols static route 10.0.0.0/8 next-hop 1.2.3.4 bfd profile bar
CLI commands "set protocols static multicast interface-route" is moved to:
* set protocols static multicast route <x.x.x.x/x> interface
To have an identical look and feel with regular static routes.
|
|
Drop newlines added by macro statement and Jinja2 comments. Jinja2 comments
will be removed during package build on the shipped files.
|
|
|
|
|
|
|
|
|
|
|
|
OpenFabric is a routing protocol providing link-state routing with efficient flooding for topologies like spine-leaf networks.
FRR implements OpenFabric in a daemon called fabricd
|
|
|
|
|
|
|
|
When adding and removing VRF instances on the fly it was noticed that the vni
statement under the VRF instance in FRR vanishes. This was caused by a race
condition which was previously designed to fix another bug.
The wierd design of a Python helper below the VRF tree to only generate the
VNI configuration nodes is now gone and all is rendered in the proper place.
|
|
Fixed using 'route-map', 'as-set' and 'summary-only' together in
aggregation in BGP
|
|
|
|
|
|
Example:
vyos@vyos# set protocols ospfv3 redistribute bgp
Possible completions:
metric OSPF default metric
metric-type OSPF metric type for default routes (default: 2)
route-map Specify route-map name to use
|
|
context
* set vrf name <name> ip nht no-resolve-via-default
* set vrf name <name> ipv6 nht no-resolve-via-default
|
|
* set system ip nht no-resolve-via-default
* set system ipv6 nht no-resolve-via-default
|
|
|
|
bgp: T6032: add EVPN MAC-VRF Site-of-Origin support
|
|
srv6: T5849: add segment support to "protocols static route6"
|
|
In some EVPN deployments it is useful to associate a logical VTEP's Layer 2
domain (MAC-VRF) with a Site-of-Origin "site" identifier. This provides a BGP
topology-independent means of marking and import-filtering EVPN routes
originated from a particular L2 domain. One situation where this is valuable
is when deploying EVPN using anycast VTEPs
set protocols bgp address-family l2vpn-evpn mac-vrf soo
|
|
* set protocols static route6 <prefix> next-hop <address> segments 'x:x::x:x/y:y::y/z::z'
* set protocols static route6 <prefix> interface <interface> segments 'x:x::x:x/y:y::y/z::z'
|
|
|
|
rpki: T6023: add support for CLI knobs expire-interval and retry-interval
|
|
* set protocols bgp parameters labeled-unicast <explicit-null | ipv4-explicit-null | ipv6-explicit-null>
* set protocols bgp parameters allow-martian-nexthop
* set protocols bgp parameters no-hard-administrative-reset"
|
|
|
|
|
|
* set protocols bfd peer <x.x.x.x> minimum-ttl <1-254>
* set protocols bfd profile <name> minimum-ttl <1-254>
|
|
set protocols bgp address-family ipv4-unicast nexthop vpn export <ipv4-address|ipv6-address>
set protocols bgp address-family ipv6-unicast nexthop vpn export <ipv4-address|ipv6-address>
|
|
set protocols bgp address-family ipv4-unicast sid vpn export <auto|1-1048575>
set protocols bgp address-family ipv6-unicast sid vpn export <auto|1-1048575>
|
|
|
|
frr: T4020: add option to define number of open file descriptors
|
|
This allows the operator to control the number of open file descriptors each
daemon is allowed to start with. The current assumed value on most operating
systems is 1024.
If the operator plans to run bgp with several thousands of peers then this is
where we would modify FRR to allow this to happen.
set system frr descriptors <n>
|