| Age | Commit message (Collapse) | Author |
|---|
|
As we don't use addresss-family ipv4-unicast by default we
should to send informational message about AFI for peer is required
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When we use neighbor as interface we must not use option
'source-interface'
for example:
neighbor eth0 source-interface eth0
Such option can be used for IP/IPv6 neighbors
|
|
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
|
|
|
|
|
|
|
|
|
|
Commit 5f1c1ae4 ("bgp: T3798: add support for neighbor local-as <n> replace-as")
added support for a new CLI option when the local-as is changed for a specified
neighbor or peer-group.
There was an error in the CLI / design as the "replace-as" option can only be
used when "no-prepend" is defined. Thus "no-prepend" became a <node> and
the new "replace-as" leafNode is now a child of "no-prepend".
|
|
|
|
This adds the following new commands:
set protocols bgp address-family ipv4-unicast route-map vpn export foo-map-out
set protocols bgp address-family ipv4-unicast route-map vpn import foo-map-in
set protocols bgp address-family ipv6-unicast route-map vpn export foo-map-out
set protocols bgp address-family ipv6-unicast route-map vpn import foo-map-in
|
|
|
|
|
|
|
|
|
|
|
|
The "v6only" CLI tree was not taken into account during validation.
vyos@vyos:~$ show configuration commands | grep bgp
set protocols bgp local-as '200'
set protocols bgp neighbor eth0.204 address-family ipv6-unicast
set protocols bgp neighbor eth0.204 interface v6only remote-as '100'
vyos@vyos:~$ show bgp ipv6 sum
IPv6 Unicast Summary:
BGP router identifier 172.18.254.201, local AS number 200 vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 1, using 21 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt
eth0.204 4 100 99 99 0 0 0 01:35:07 0 0
Total number of neighbors 1
|
|
|
|
Commit 4f9aa30f ("vrf: bgp: T3523: add route-map support for kernel routes")
added the possibility to also filter BGP routes towards the OS kernel, but the
smoketests failed. Reason was a non working CLI command applied to bgpd.
Thus the VRF route-map and the BGP configuration is now split into two templates,
one to be used for each daemon (zebra and bgpd).
Nevertheless one more bug was found in vyos.frr which currently does not suppoort
calling modify_section() inside a configuration "block". See [1] for more info.
[1]: https://phabricator.vyos.net/T3529
|
|
route-map
|
|
This commit has a dependecy on https://github.com/FRRouting/frr/issues/8403,
thus support will be "commented out" by default.
|
|
|
|
|
|
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>
|
|
Removing the Zebra/Linux Kernel route-map added by "set protocols bgp route-map"
was not removed once applied. This was because the removal must happen within
the zebra daemon and not bgpd.
|
|
|
|
It is only possible to set one local-as override per BGP neighbor/peer-group.
In addition to this, the override AS number is not allowed to be the same as
the one from the global BGP process.
If this would still be the case frr-reload would error out:
> frr-reload output: 184 % Cannot have local-as same as BGP AS number
|
|
|
|
When configuring a BGP neighbor via an interface, FRR requires that the
peer-group and remote-as node from under the interface statement is used.
This is now enforced by a verify() check.
|
|
|
|
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
|
|
|
|
|
|
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
!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
local variable 'peer_group' referenced before assignment.
|
|
When moving from Quagga to FRR the BGP address-family was extended by an
invalid peer-group statement. FRR always moved a configured peer-group
from the AFI level down to the neighbor level.
With the migration to FRR reload we must take care about this by ourselves.
|
|
|
|
|
