Send Cease/Hard Reset notification for certain scenario when graceful
restart + notification support (RFC8538) are enabled. In this
implementation, we follow the suggestion of RFC8538 and map following
notification subcodes to Hard Reset subcode.
1. BGP_ERROR_SUB_MAXIMUM_NUMBER_OF_PREFIXES_REACHED
In this case, GoBGP is in the resource shortage and not working
properly. Thus, the peer should stop forwarding packet immediately.
2. BGP_ERROR_SUB_ADMINISTRATIVE_SHUTDOWN
This happens when the user uses DisablePeer API. This clearly indicates
user's intention of shutting down the session. Thus, we should send Hard
Reset.
3. BGP_ERROR_SUB_PEER_DECONFIGURED
This happens when the user uses DeletePeer API or StopBgp API or there's
an ASN mismatch found in the Open phase. The former two cases, the user
shows the intention to shutdown the session, so we should Hard Reset.
The latter case is not so obvious, but I think it's ok to do Hard Reset
because it is an unrecoverable error that cannot be solved without
user's involvement.
4. BGP_ERROR_SUB_HARD_RESET
This case currently doesn't exist, but obviously we should send Hard
Reset when someone explicitly specifies it.
The behavior for the remaining subcodes are unchanged. We may want to
expose a knob to adjust the behavior of BGP_ERROR_SUB_ADMINISTRATIVE_RESET
as suggested by RFC8538, but for this initial implementation, we kept it
as is.
Signed-off-by: Yutaro Hayakawa <[email protected]>
Currently GoBGP does not accept UPDATE messages with nexthops pointing
to a loopback address. This disallows multiple GoBGP instances from
running at the same time on 127.0.0.0/8.
This PR proposes removing this constraint when the RouterID of the
current GoBGP instance itself resides within the testing subnet of
127.0.0.0/8.
When ListPathRequest is done by a gRPC client including a malformed prefix,
the server would crash an invalid memory address reference.
This commit fixes the crash by checking whether the parseCIDR method returned
an error.
restore the API breakage due to c801e18495.
However, this is a hack. Should be removed with the major version updated.
Signed-off-by: FUJITA Tomonori <[email protected]>
Fix TEID processing in Type 2 ST Route:
- TEID can be 0-32 bits value as described in I-D.
Accept hex and IPv4 format for TEID in CLI and show TEID as IPv4 format in CLI.
- TEID is generally represented in hexadecimal format.
- IPv4 format is useful because Type 2 ST Route can be used in the longest match algorithm as described in I-D.
https://datatracker.ietf.org/doc/html/draft-abraitis-bgp-version-capability
Working example with FRR
```
% ./gobgp neighbor 192.168.10.124
BGP neighbor is 192.168.10.124, remote AS 65001
BGP version 4, remote router ID 200.200.200.202
BGP state = ESTABLISHED, up for 00:01:14
BGP OutQ = 0, Flops = 0
Hold time is 3, keepalive interval is 1 seconds
Configured hold time is 90, keepalive interval is 30 seconds
Neighbor capabilities:
multiprotocol:
ipv6-unicast: advertised
ipv4-unicast: advertised and received
route-refresh: advertised and received
extended-nexthop: advertised
Local: nlri: ipv4-unicast, nexthop: ipv6
UnknownCapability(6): received
UnknownCapability(9): received
graceful-restart: advertised and received
Local: restart time 10 sec
ipv6-unicast
ipv4-unicast
Remote: restart time 120 sec, notification flag set
ipv4-unicast, forward flag set
4-octet-as: advertised and received
add-path: received
Remote:
ipv4-unicast: receive
enhanced-route-refresh: received
long-lived-graceful-restart: advertised and received
Local:
ipv6-unicast, restart time 10 sec
ipv4-unicast, restart time 20 sec
Remote:
ipv4-unicast, restart time 0 sec, forward flag set
fqdn: advertised and received
Local:
name: donatas-pc, domain:
Remote:
name: spine1-debian-11, domain:
software-version: advertised and received
Local:
GoBGP/3.10.0
Remote:
FRRouting/8.5-dev-MyOwnFRRVersion-gdc92f44a4
cisco-route-refresh: received
Message statistics:
```
FRR side:
```
root@spine1-debian-11:~# vtysh -c 'show bgp neighbor 192.168.10.17 json' | \
> jq '."192.168.10.17".neighborCapabilities.softwareVersion.receivedSoftwareVersion'
"GoBGP/3.10.0"
root@spine1-debian-11:~#
```
Signed-off-by: Donatas Abraitis <[email protected]>
This includes BGP VPLS NLRI and extended community. There is no CLI/API
support yet. Also, VPLS AFI/SAFI is shared with RFC 6074 which says:
> Both BGP-AD and VPLS-BGP [RFC4761] use the same AFI/SAFI. In order
> for both BGP-AD and VPLS-BGP to co-exist, the NLRI length must be
> used as a demultiplexer.
>
> The BGP-AD NLRI has an NLRI length of 12 bytes, containing only an
> 8-byte RD and a 4-byte VSI-ID. VPLS-BGP [RFC4761] uses a 17-byte
> NLRI length. Therefore, implementations of BGP-AD must ignore NLRI
> that are greater than 12 bytes.
This is not handled in this PR.
The generic transitive experimental extended community types are shared
with FlowSpec. The parsing is extended to handle VPLS as well, but not
other L2 encapsulations.
Fix #2590
- Add TLVType contant values.
- Add NewPathAttributePrefixSID().
- Add SRv6ServiceTLV to support SRv6 L2 Service TLV.
- Move reserved field handling to each type of TLV,
because header and reserved field size are different for each type.
For more details, see https://www.rfc-editor.org/rfc/rfc8669.html
and https://www.rfc-editor.org/rfc/rfc9252.html.
Yutaro Hayakawa
Yuya Kusakabe
Lauri HuotariandFUJITA Tomonori
wenovusandFUJITA Tomonori
Jeremiah Millay
Arjun Singh
Rodrigo Peña
Kirill PletnevandKirill 'horseinthesky' Pletnev
Rastislav SzaboandFUJITA Tomonori
Harry FreeboroughandFUJITA Tomonori
Linus MellbergandFUJITA Tomonori
Enigamictandwatal
menetelk0
Donatas AbraitisandFUJITA Tomonori
Rinat Baygildin
yas-nyanandwatal
Vincent BernatandFUJITA Tomonori