| Age | Commit message (Collapse) | Author |
|
Just for debugging purposes and a better visibility.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
In bgp_open_option_parse the code is checking that the
stream has at least 2 bytes to read ( the opt_type and
the opt_length). However if BGP_OPEN_EXT_OPT_PARAMS_CAPABLE(peer)
is configured then FRR is reading 3 bytes. Which is not good
since the packet could be badly formateed. Ensure that
FRR has the appropriate data length to read the data.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
In peek_for_as4_capability the code is checking that the
stream has at least 2 bytes to read ( the opt_type and the
opt_length ). However if BGP_OPEN_EXT_OPT_PARAMS_CAPABLE(peer)
is configured then FRR is reading 3 bytes. Which is not good
since the packet could be badly formated. Ensure that
FRR has the appropriate data length to read the data.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Just adding a support for peer-groups, because now it's not possible to
configure BGP role for peer-groups.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
This commit fixes some issues that were noted by the reviewer
Signed-off-by: Eugene Bogomazov <eb@qrator.net>
|
|
RFC9234 is a way to establish correct connection roles (Customer/
Provider, Peer or with RS) between bgp speakers. This patch:
- Add a new configuration/terminal option to set the appropriate local
role;
- Add a mechanism for checking used roles, implemented by exchanging
the corresponding capabilities in OPEN messages;
- Add strict mode to force other party to use this feature;
- Add basic support for a new transitive optional bgp attribute - OTC
(Only to Customer);
- Add logic for default setting OTC attribute and filtering routes with
this attribute by the edge speakers, if the appropriate conditions are
met;
- Add two test stands to check role negotiation and route filtering
during role usage.
Signed-off-by: Eugene Bogomazov <eb@qrator.net>
|
|
N-bit flag should be exchanged in BGP OPEN messages, not only when the
bgpd is restarted/started.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
bgpd: Implement GR N-Bit and CEASE/Hard Reset notification
|
|
Also, add N-Bit (Notification) flag for Graceful Restart.
This is a preparation for RFC8538.
More information: https://datatracker.ietf.org/doc/html/rfc8538
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Just to better understand what they mean.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Just to better understand what they mean.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
The compiler is, rightly, pointing out that in some cases it is
possible that the pkt_afi and pkt_safi values are not properly
set and could result in a use before initialized. I do not
actually belive that this is possible, but let's make the compiler
happy.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Tested between GoBGP and FRR (this commit).
```
┌───────────┐ ┌────────────┐
│ │ │ │
│ GoBGPD │ │ FRRouting │
│ (restart) │ │ │
│ │ │ │
└──────┬────┘ └───────┬────┘
│ │
│ │
│ │
│ ┌───────────┐ │
│ │ │ │
│ │ │ │
└─────┤ FRRouting ├────────┘
│ (helper) │
│ │
└───────────┘
// GoBGPD
% cat /etc/gobgp/config.toml
[global.config]
as = 65002
router-id = "2.2.2.2"
port = 179
[[neighbors]]
[neighbors.config]
peer-as = 65001
neighbor-address = "2a02:abc::123"
[neighbors.graceful-restart.config]
enabled = true
restart-time = 3
long-lived-enabled = true
[[neighbors.afi-safis]]
[neighbors.afi-safis.config]
afi-safi-name = "ipv6-unicast"
[neighbors.afi-safis.mp-graceful-restart.config]
enabled = true
[neighbors.afi-safis.long-lived-graceful-restart.config]
enabled = true
restart-time = 10
[[neighbors.afi-safis]]
[neighbors.afi-safis.config]
afi-safi-name = "ipv4-unicast"
[neighbors.afi-safis.mp-graceful-restart.config]
enabled = true
[neighbors.afi-safis.long-lived-graceful-restart.config]
enabled = true
restart-time = 20
% ./gobgp global rib add -a ipv6 2001:db8:4::/64
% ./gobgp global rib add -a ipv6 2001:db8:5::/64 community 65535:7
% ./gobgp global rib add -a ipv4 100.100.100.100/32
% ./gobgp global rib add -a ipv4 100.100.100.200/32 community 65535:7
```
1. When killing GoBGPD, graceful restart timer starts in FRR helper router;
2. When GR timer expires in helper router:
a) LLGR_STALE community is attached to routes to be retained;
b) Clear stale routes that have NO_LLGR community attached;
c) Start LLGR timer per AFI/SAFI;
d) Recompute bestpath and reannounce routes to peers;
d) When LLGR timer expires, clear all routes on particular AFI/SAFI.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
bgpd: Implement rfc9072
|
|
```
OPEN has (no message found) capability (71), length 14
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
Related: https://datatracker.ietf.org/doc/html/rfc9072
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
Restart Router mode.
FRRouting (Restarter):
```
bgp long-lived-graceful-restart stale-time 10
bgp graceful-restart restart-time 1
```
Tested with GoBGP (Helper):
```
long-lived-graceful-restart: advertised and received
Local:
ipv4-unicast, restart time 100000 sec
Remote:
ipv4-unicast, restart time 10 sec, forward flag set
```
Logs:
```
{"Key":"192.168.10.123","Reason":"graceful-restart","State":"BGP_FSM_ESTABLISHED","Topic":"Peer","level":"info","msg":"Peer Down","time":"2021-10-25T17:48:36+03:00"}
{"Key":"192.168.10.123","State":"BGP_FSM_IDLE","Topic":"Peer","level":"warning","msg":"graceful restart timer expired","time":"2021-10-25T17:48:37+03:00"}
{"Family":65537,"Key":"192.168.10.123","Topic":"Peer","level":"info","msg":"start LLGR restart timer (10 sec) for ipv4-unicast","time":"2021-10-25T17:48:37+03:00"}
{"Family":65537,"Key":"192.168.10.123","Topic":"Peer","level":"info","msg":"LLGR restart timer (10 sec) for ipv4-unicast expired","time":"2021-10-25T17:48:47+03:00"}
% ./gobgp global rib
Network Next Hop AS_PATH Age Attrs
S*>10.0.2.0/24 192.168.10.123 174 00:12:08 [{Origin: ?} {Med: 0} {Communities: llgr-stale} {Extcomms: [174:1282304808]}]
```
Helper mode will be added with upcoming PRs.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
Before:
```
192.168.10.17 OPEN has MultiProtocol Extensions capability (1), length 4
192.168.10.17 OPEN has MP_EXT CAP for afi/safi: IPv4/unicast
```
After:
```
192.168.10.17 OPEN has MultiProtocol Extensions capability (1), length 4
192.168.10.17 OPEN has MultiProtocol Extensions capability for afi/safi: IPv4/unicast
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
```
192.168.10.17 OPEN has Graceful Restart capability (64), length 6
192.168.10.17 OPEN has Graceful Restart capability
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
The idea is to disable addpath-rx capability to avoid unnecessary additional
routes installed.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
If we don't advertise any capabilities (dont-capability-negotiate), we
shouldn't set msg size to 65k only if received this capability from another
peer.
Before:
```
~/frr# vtysh -c 'show ip bgp update-group' | grep 'Max packet size'
Max packet size: 65535
```
After:
```
~/frr# vtysh -c 'show ip bgp update-group' | grep 'Max packet size'
Max packet size: 4096
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
BGP_MAX_PACKET_SIZE no longer represented the absolute maximum BGP
packet size as it did before, instead it was defined as 4096 bytes,
which is the maximum unless extended message capability is negotiated,
in which case the maximum goes to 65k.
That introduced at least one bug - last_reset_cause was undersized for
extended messages, and when sending an extended message > 4096 bytes
back to a peer as part of NOTIFY data would trigger a bounds check
assert.
This patch redefines the macro to restore its previous meaning,
introduces a new macro - BGP_STANDARD_MESSAGE_MAX_PACKET_SIZE - to
represent the 4096 byte size, and renames the extended size to
BGP_EXTENDED_MESSAGE_MAX_PACKET_SIZE for consistency. Code locations
that definitely should use the small size have been updated, locations
that semantically always need whatever the max is, no matter what that
is, use BGP_MAX_PACKET_SIZE.
BGP_EXTENDED_MESSAGE_MAX_PACKET_SIZE should only be used as a constant
when storing what the negotiated max size is for use at runtime and to
define BGP_MAX_PACKET_SIZE. Unless there is a future standard that
introduces a third valid size it should not be used for any other
purpose.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
|
|
Implement https://www.rfc-editor.org/rfc/rfc8654.txt
```
> | jq '."192.168.10.25".neighborCapabilities.extendedMessage'
"advertisedAndReceived"
```
Another side is Bird:
```
BIRD 2.0.7 ready.
Name Proto Table State Since Info
v4 BGP --- up 19:39:15.689 Established
BGP state: Established
Neighbor address: 192.168.10.123
Neighbor AS: 65534
Local AS: 65025
Neighbor ID: 192.168.100.1
Local capabilities
Multiprotocol
AF announced: ipv4
Route refresh
Extended message
Graceful restart
4-octet AS numbers
Enhanced refresh
Long-lived graceful restart
Neighbor capabilities
Multiprotocol
AF announced: ipv4
Route refresh
Extended message
Graceful restart
4-octet AS numbers
ADD-PATH
RX: ipv4
TX:
Enhanced refresh
Session: external AS4
Source address: 192.168.10.25
Hold timer: 140.139/180
Keepalive timer: 9.484/60
Channel ipv4
State: UP
Table: master4
Preference: 100
Input filter: ACCEPT
Output filter: ACCEPT
Routes: 9 imported, 3 exported, 8 preferred
Route change stats: received rejected filtered ignored accepted
Import updates: 9 0 0 0 9
Import withdraws: 2 0 --- 2 0
Export updates: 11 8 0 --- 3
Export withdraws: 0 --- --- --- 0
BGP Next hop: 192.168.10.25
```
Tested at least as well with to make sure it works with backward compat.:
ExaBGP 4.0.2-1c737d99.
Arista vEOS 4.21.14M
Testing by injecint 10k routes with:
```
sharp install routes 172.16.0.1 nexthop 192.168.10.123 10000
```
Before extended message support:
```
2021/03/01 07:18:51 BGP: u1:s1 send UPDATE len 4096 (max message len: 4096) numpfx 809
2021/03/01 07:18:51 BGP: u1:s1 send UPDATE len 4096 (max message len: 4096) numpfx 809
2021/03/01 07:18:51 BGP: u1:s1 send UPDATE len 4096 (max message len: 4096) numpfx 809
2021/03/01 07:18:51 BGP: u1:s1 send UPDATE len 4096 (max message len: 4096) numpfx 809
2021/03/01 07:18:51 BGP: u1:s1 send UPDATE len 4096 (max message len: 4096) numpfx 809
2021/03/01 07:18:51 BGP: u1:s1 send UPDATE len 4096 (max message len: 4096) numpfx 809
2021/03/01 07:18:52 BGP: u1:s1 send UPDATE len 4096 (max message len: 4096) numpfx 809
2021/03/01 07:18:52 BGP: u1:s1 send UPDATE len 4096 (max message len: 4096) numpfx 809
2021/03/01 07:18:52 BGP: u1:s1 send UPDATE len 4096 (max message len: 4096) numpfx 809
2021/03/01 07:18:52 BGP: u1:s1 send UPDATE len 4096 (max message len: 4096) numpfx 809
2021/03/01 07:18:52 BGP: u1:s1 send UPDATE len 4096 (max message len: 4096) numpfx 809
2021/03/01 07:18:52 BGP: u1:s1 send UPDATE len 2186 (max message len: 4096) numpfx 427
2021/03/01 07:18:53 BGP: u1:s1 send UPDATE len 3421 (max message len: 4096) numpfx 674
```
After extended message support:
```
2021/03/01 07:20:11 BGP: u1:s1 send UPDATE len 50051 (max message len: 65535) numpfx 10000
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
16:40:49 BGP: 192.168.0.2: sending route-refresh (BoRR) for IPv4/unicast
16:40:51 BGP: 192.168.0.2: sending route-refresh (EoRR) for IPv4/unicast
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
bgpd: GR fixes
|
|
1) When a session comes up for a peer and if the peer has not adverised
the GR capabilities, BGP sends a request to Zebra to clear any
stale routes that might exist from that peer.
2) When OPEN message is received from the peer, clear the previously
advertised GR capability by the peer, if the lastest received
OPEN message does not contain the GR capability.
Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
|
|
Remove mid-string line breaks, cf. workflow doc:
.. [#tool_style_conflicts] For example, lines over 80 characters are allowed
for text strings to make it possible to search the code for them: please
see `Linux kernel style (breaking long lines and strings)
<https://www.kernel.org/doc/html/v4.10/process/coding-style.html#breaking-long-lines-and-strings>`_
and `Issue #1794 <https://github.com/FRRouting/frr/issues/1794>`_.
Scripted commit, idempotent to running:
```
python3 tools/stringmangle.py --unwrap `git ls-files | egrep '\.[ch]$'`
```
Signed-off-by: David Lamparter <equinox@diac24.net>
|
|
Some were converted to bool, where true/false status is needed.
Converted to void only those, where the return status was only false or true.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
Just keep the code cool.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
Most of the code uses macros, thus let's keep the code unified.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
Fix bgp gr style
|
|
*: don't null after XFREE; XFREE does this itself
|
|
This patch fixes the noncompliant style for the following commit range:
4a6e80fbf
2ba1fe695
efcb2ebbb
8c48b3b69
dc95985fe
0f0444fbd
85ef4179a
eb451ee58
2d3dd828d
9e3b51a7f
d6e3c15b6
34aa74486
6102cb7fe
d7b3cda6f
2bb5d39b1
5f9c1aa29
5cce3f054
3a75afa4b
f009ff269
cfd47646b
2986cac29
055679e91
034e185dc
794b37d52
b0965c44e
949b0f24f
63696f1d8
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
|
|
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
|
|
slankdev/slankdev-bgpd-support-prefix-sid-srv6-l3vpn
bgpd: additional Prefix-SID sub-types for supporting SRv6 l3vpn
|
|
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
|
|
Some recent commits got some bad formating. Clean this up.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
bgp graceful restart additional debug logs, resolved
merge conflicts.
Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
|
|
Reorganizing bgp gr debug logs and code review comments.
Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
|
|
*Adding helper caller hooks function for signalling from BGPD
to ZEBRA to enable or disable GR feature in ZEBRA depending
on bgp per peer gr configuration.
Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
|
|
When the peer router's gr mode had changed from helper/restart
to disable. The local bgp gr router should reset the peer
router's restart-time stored.
Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
|
|
BGP Helper node doesn't set R-bit in OPEN message after the
restart or reload of the BGP router.
Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
|
|
bgp tcp connection.
When the BGP peer is configured between two bgp routes both routers would create
peer structure , when they receive each other’s open message. In this event both
speakers, open duplicate TCP sessions and send OPEN messages on each socket
simultaneously, the BGP Identifier is used to resolve which socket should be closed.
If BGP GR is enabled the old tcp session is dumped and the new session is retained.
So while this transfer of connection is happening, if all the bgp gr config
is not migrated to the new connection, the new bgp gr mode will never get applied.
Fix Summary:
1. Replicate GR configuration from the old session to the new session in bgp_accept().
2. Replicate GR configuration from stub to full-fledged peer in bgp_establish().
3. Disable all NSF flags, clear stale routes (if present), stop restart & stale timers
(if they are running) when the bgp GR mode is changed to “Disabled”.
4. Disable R-bit in cap, if it is not set the received open message.
Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
|
|
* Added new show command to show the graceful restart
information for each neighbor.
Cmd: show bgp [<ipv4|ipv6>] neighbors [<A.B.C.D|X:X::X:X|WORD>] graceful-restart
* Changes to show neighbors commands for displaying
graceful restart information.
Cmd :show [ip] bgp [<view|vrf> VIEWVRFNAME] [<ipv4|ipv6>] neighbors [<A.B.C.D|X:X::X:X|
Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
|
|
* Changes to the capability sending function to advertise
graceful restart capability in the bgp OPEN message.
Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
|
|
Duplicated domain name capability messages cause memory leak. The amount
of leaked memory is proportional to the size of the duplicated
capabilities. This bug was introduced in 2015.
To hit this, a BGP OPEN message must contain multiple FQDN capabilities.
Memory is leaked when the hostname portion of the capability is of
length 0, but the domainname portion is not, for any of the duplicated
capabilities beyond the first one.
https://tools.ietf.org/html/draft-walton-bgp-hostname-capability-00
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
|
|
This commit makes bgpd to support VPNv4's extended
nexthop capability for bgp-capability negotiation
when BGP open messaging.
Signed-off-by: Hiroki Shirokura <slank.dev@gmail.com>
|
|
BGP: Rectifying the log messages.
|
|
This change addresses the following:
1) Ensures logs under DEBUG macro checks are categorized
as zlog_debug instead of zlog_info.
2) Error logs are categorized as zlog_err instead of zlog_info.
3) Rephrasing certain logs to make them appear more intuitive.
Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
|