Compile with v2.0.0 tag of `libyang2` branch of:
https://github.com/CESNET/libyang
staticd init load time of 10k routes now 6s vs ly1 time of 150s
Signed-off-by: Christian Hopps <chopps@labn.net>
Show alias name instead of numerical value in `show bgp <prefix>. E.g.:
```
root@exit1-debian-9:~/frr# vtysh -c 'sh run' | grep 'bgp community alias'
bgp community alias 65001:123 community-1
bgp community alias 65001:123:1 lcommunity-1
root@exit1-debian-9:~/frr#
```
```
exit1-debian-9# sh ip bgp 172.16.16.1/32
BGP routing table entry for 172.16.16.1/32, version 21
Paths: (2 available, best #2, table default)
Advertised to non peer-group peers:
65030
192.168.0.2 from home-spine1.donatas.net(192.168.0.2) (172.16.16.1)
Origin incomplete, metric 0, valid, external, best (Neighbor IP)
Community: 65001:12 65001:13 community-1 65001:65534
Large Community: lcommunity-1 65001:123:2
Last update: Fri Apr 16 12:51:27 2021
exit1-debian-9#
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
vtysh will return an informational message to the user that changing any
graceful-shutdown related parameter will require a peer reset. This is should
not be treated as an error message (resulting in a return code of 1) but
rather as a simple information to the user.
This fixes GitHub issue https://github.com/FRRouting/frr/issues/8403
$ vtysh -c configure -c 'router bgp 100' -c 'bgp graceful-restart'
Graceful restart configuration changed, reset all peers to take effect
$ echo $?
0
Signed-off-by: Christian Poessinger <christian@poessinger.com>
For whatever reason the dampening show run code was outside the normal
loop of code that handles the afi/safi portion. consolidate it into
the rest of the normal code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
bgp_config_write_peer_af already checks to see if we are
a dynamic peer. No need to do so right before we call it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When we are cycling through all peers and looking for
dampening data to dump, do not consider non-configed
peers( dopplegangers ).
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Problem Statement:
=================
In scale setup BGP sessions start flapping.
RCA:
====
In virtualized environment there are multiple places where
MTU need to be set. If there are some places were MTU is not set
properly then there is chances that BGP packets get fragmented,
in scale setup this will lead to BGP session flap.
Fix:
====
A new tcp option is provided as part of this implementation,
which can be configured per neighbor and helps to set the TCP
max segment size. User need to derive the path MTU between the BGP
neighbors and set that value as part of tcp-mss setting.
1. CLI Configuration:
[no] neighbor <A.B.C.D|X:X::X:X|WORD> tcp-mss (1-65535)
2. Running config
frr# show running-config
router bgp 100
neighbor 198.51.100.2 tcp-mss 150 => new entry
neighbor 2001:DB8::2 tcp-mss 400 => new entry
3. Show command
frr# show bgp neighbors 198.51.100.2
BGP neighbor is 198.51.100.2, remote AS 100, local AS 100, internal link
Hostname: frr
Configured tcp-mss is 150, synced tcp-mss is 138 => new display
4. Show command json output
frr# show bgp neighbors 2001:DB8::2 json
{
"2001:DB8::2":{
"remoteAs":100,
"bgpTimerKeepAliveIntervalMsecs":60000,
"bgpTcpMssConfigured":400, => new entry
"bgpTcpMssSynced":388, => new entry
Risk:
=====
Low - This is a config driven feature and it sets the max segment
size for the TCP session between BGP peers.
Tests Executed:
===============
Have done manual testing with three router topology.
1. Executed basic config and un config scenarios
2. Verified if the config is updated in running config
during config and no config operation
3. Verified the show command output in both CLI format and
JSON format.
4. Verified if TCP SYN messages carry the max segment size
in their initial packets.
5. Verified the behaviour during clear bgp session.
6. done packet capture to see if the new segment size
takes effect.
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
If a user issues the following commands:
```
router bgp 65000 vrf red
router bgp 65000 view red
```
bgpd ends up having NB config inconsistent with actual data.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
increase the maximum number of neighbors in a bgp group.
Set the maximum value to 50000 instead of 5000.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Instead of using bgp_get_default which refers to operational state, we
can check existence of the default node using only candidate config.
The same thing is done in "no router bgp" command.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
This new BGP configuration is akin to "bgp bestpath aspath
multipath-relax". When applied, paths learned from different peer types
will be eligible to be considered for multipath (ECMP). Paths from all
of eBGP, iBGP, and confederation peers may be included in multipaths
if they are otherwise equal cost.
This change preserves the existing bestpath behavior of step 10's result
being returned, not the result from steps 8 and 9, in the case where
both 8+9 and 10 determine a winner.
Signed-off-by: Joanne Mikkelson <jmmikkel@arista.com>
Remove old BFD API usage and replace it with the new one.
Highlights:
- More shared code: the daemon gets notified with callbacks instead of
having to roll its own code to find the notified sessions.
- Less code to integrate with BFD.
- Remove hidden commands to configure single / multi hop. Use
protocol data instead.
BGP can determine if a peer is single/multi hop according to the
following criteria:
a. If the IP address is a link-local address (single hop)
b. The network is shared with peer (single hop)
c. BGP is configured for eBGP multi hop / TTL security (multi hop)
- Respect the configuration hierarchy:
a. Peer configuration take precendence over peer-group
configuration.
b. When peer group configuration is removed, reset peer
BFD configurations to defaults (unless peer had specific
configs).
Example:
neighbor foo peer-group
neighbor foo bfd profile X
neighbor 192.168.0.2 peer-group foo
neighbor 192.168.0.2 bfd
! If peer-group is removed the profile configuration gets
! removed from peer 192.168.0.2, but BFD will still enabled
! because of the neighbor specific bfd configuration.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Should return an actual useful error message.
Commit: 055679e915 messed this error message
up.
Fixes: #8246
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
now that sequence number is configurable, there is no problem in
permitting to configure seq 0 sequence number.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When you use a single BGP session for both IPv4 and IPv6 it's a bit
annoying going into ipv6 address-family and explicitly activating it.
Let's get this automatically if enabled with `bgp default ipv6-unicast`.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
flowspec address family can now use attribute-unchanged attribute.
This parameter is necessary when it comes to play with
route-server-client, as that latter command forces to change
attribute-unchanged nexthop.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Currently when deleting a neighbor from a peer-group:
no neighbor A.B.C.D peer-group FOO
We must specify FOO, while A.B.C.D is sufficient enough of an
identifier to know what to do.
Make PGNAME optional on this command and just delete the peer.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add SNMP support for L3vpn Vrf table as defined in [RFC4382]
Keep track of vrf status for the table and for future traps.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
This command was put in place to allow upgrades for the
neighbor command from the BGP_NODE and have it put
into the ipv4 uni node instead. Since this
utterly kills the yang conversion. I believe we need
to remove this. Since people upgrading will just loose
the route-map applicatoin( if they are using such an old
config ) and RFC 8212 will come into play. They'll figure
it out pretty fast.
Fixes: #7983
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Talking w/ Chirag and he indicated that we can just backout the command
to the original and things would `work` and they do( at least a quick test does )
Put this in place until a proper fix can be done.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
- Move vtysh handler to DEFPY
- Convert neighbor route-map command to transactional cli.
- After nb conversion, remove not used apis.
- Implement NB callbacks for afi-safis
Signed-off-by: Chirag Shah <chirag@nvidia.com>
- Move vtysh handler to DEFPY
- Convert neighbor prefix-list command to transactional cli.
- After nb conversion, remove not used apis.
- implement NB apis for ipv4 afi-safis
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Christian Hopps
Russ White
David Lamparter
Igor Ryzhov
Donatas Abraitis
Christian Poessinger
Donald Sharp
Abhinay Ramesh
Philippe Guibert
Joanne Mikkelson
Rafael Zalamena
Chirag Shah
Quentin Young
David Lamparter
Pat Ruddy
Donald Sharp