Link-bandwidth is encoded into extended community, not ipv6 extended community.
Thus it's not needed here at all.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
This is needed to implement and use larger bandwidths rather than limiting only
to theoretical 34Gbps max bandwidth.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
This was caught by the grpc_basic test which was receiving an invalid error
result, which was returned b/c inside zebra the libyang code was flagging the
value as invalid for a derived zebra interface type.
Signed-off-by: Christian Hopps <chopps@labn.net>
When a BFD down notification is received and the C-bit is set in both
directions, any ongoing graceful restart should be aborted and stale
routes removed from the RIB.
This commit updates the `bfd_bgp_cbit_topo3` topotest accordingly to
fix the expected outcomes in the `test_bfd_loss_intermediate` test.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
RFC5492 says:
This document defines a new Error Subcode, Unsupported Capability.
The value of this Subcode is 7. The Data field in the NOTIFICATION
message MUST list the set of capabilities that causes the speaker to
send the message. Each such capability is encoded in the same way as
it would be encoded in the OPEN message.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
RFC-7607 specifically calls out the allowed usage
of AS 0 to signal that the a particular address is
not in use and should be guarded against. Add
the ability to specify this special AS in the rpki
commands.
eva# show rpki as-number 0
RPKI/RTR prefix table
Prefix Prefix Length Origin-AS
2.57.180.0 22 - 24 0
2.58.144.0 22 - 22 0
2.59.116.0 24 - 24 0
4.42.228.0 22 - 22 0
5.57.80.0 22 - 22 0
<snip>
2a13:df87:b400:: 38 - 38 0
2a13:df84:: 32 - 32 0
2630:: 16 - 16 0
Number of IPv4 Prefixes: 1166
Number of IPv6 Prefixes: 617
eva# show rpki prefix 2630::/16 0
Prefix Prefix Length Origin-AS
2630:: 16 - 16 0
eva#
Fixes: #15778
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The debug command was removed in 17e9298e47 ("bgpd: Remove 'debug bgp
allow-martian'")
Cleanup all references to the debug command.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Operational data should not be used on validation stage. Move the usage
to apply stage only.
Fixes#15707.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
If a command is not marked as `YANG`-converted, the current command
batching buffer is flushed before executing the command. We shouldn't
flush the buffer when executing an `exit` command. It should only be
flushed if the next command is not `YANG`-converted, which is checked by
the command itself, not the previous `exit`.
Fixes#15706.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
The 'table-direct' redistribute command is available for ipv4 unicast but
not for ipv6 unicast.
Add the command to ipv6 unicast as well.
Fixes: b6367f8460 ("bgpd: add redistribute table-direct support")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
The usage of the `bgp bestpath med missing-as-worst` command
was being accepted and applied during bestpath, but during output
of the routes affected by this it would not give any indication
that this was happening or what med value was being used.
Fixes: #15718
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When trying to connect to a BGP peer that does not respons, the 'show
bgp neighbors' command does not give any indication on the local and
remote addresses used:
> # show bgp neighbors
> BGP neighbor is 192.0.2.150, remote AS 65500, local AS 65500, internal link
> Local Role: undefined
> Remote Role: undefined
> BGP version 4, remote router ID 0.0.0.0, local router ID 192.0.2.1
> BGP state = Connect
> [..]
> Connections established 0; dropped 0
> Last reset 00:00:04, Waiting for peer OPEN (n/a)
> Internal BGP neighbor may be up to 255 hops away.
> BGP Connect Retry Timer in Seconds: 120
> Next connect timer due in 117 seconds
> Read thread: off Write thread: off FD used: 27
The addressing information (address and port) are only available
when TCP session is established, whereas this information is present
at the system level:
> root@ubuntu2204:~# netstat -pan | grep 192.0.2.1
> tcp 0 0 192.0.2.1:179 192.0.2.150:38060 SYN_RECV -
> tcp 0 1 192.0.2.1:46526 192.0.2.150:179 SYN_SENT 488310/bgpd
Add the display for outgoing BGP session, as the information in
the getsockname() API provides information for connected streams.
When getpeername() API does not give any information, use the peer
configuration (destination port is encoded in peer->port).
> # show bgp neighbors
> BGP neighbor is 192.0.2.150, remote AS 65500, local AS 65500, internal link
> Local Role: undefined
> Remote Role: undefined
> BGP version 4, remote router ID 0.0.0.0, local router ID 192.0.2.1
> BGP state = Connect
> [..]
> Connections established 0; dropped 0
> Last reset 00:00:16, Waiting for peer OPEN (n/a)
> Local host: 192.0.2.1, Local port: 46084
> Foreign host: 192.0.2.150, Foreign port: 179
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When attempting to get the src and destination addresses of a given
connection, the API may return the NULL pointer, but further code
in bgp_zebra_nexthop_set() already does a check about the given
pointer.
Relaxing the error code for all the returned adressing.
Fixes: 1ff9a34058 ("bgpd: bgpd-fsm-fix.patch")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
