When a peer has no IPv6 global address to send as nexthop, it sends the
IPv6 link-local instead as global. "show bgp ipv6 json" displays the
same address in global and link-local scopes.
> "nexthops": [
> {
> "ip": "fe80::a495:38ff:fea6:6ea3",
> "afi": "ipv6",
> "scope": "global",
> "used": true
> },
> {
> "ip": "fe80::a495:38ff:fea6:6ea3",
> "afi": "ipv6",
> "scope": "link-local"
> }
> ]
However, "used" key is set on the global nexthop but not in link-local.
It is correct but it makes difficult to test JSON to expect the usage of
a link-local. The contrary is also correct.
Set "used" key on the link-local nexhop instead to facilitate the tests.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
When the IPv6 global is removed on an interface towards a peer, the
IPv6 nexthop global that is sent is a IPv4-mapped IPv6 address. It
should be the link-local.
At removal, replace the global by the next global address or the
link-local as last resort.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
bgpd keeps on advertising IPv6 prefixes with a IPv6 link-local nexthop
after a valid IPv6 global appears.
At bgpd startup, the IPv6 global is announced by zebra after the
link-local. Only the link-local is advertised. Clearing the BGP sessions
make the global to to be announced.
Update the nexthops with the global IPv6 when available.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
This reverts commit 0325116a27.
It was causing an issue where a nexthop for IPv6 over an IPv4 session
was always rewritten to an IPv4-mapped IPv6 address even when a valid
IPv6 global address was existing.
Link: https://github.com/FRRouting/frr/issues/15610
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
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>
Today, with the following bgp instance configured, the
local VRF label is allocated even if it is not used.
> router bgp 65500 vrf vrf1
> address-family ipv4 unicast
> label vpn export allocation-mode per-nexthop
> label vpn export auto
> rd vpn export 444:1
> rt vpn both 52:100
> export vpn
> import vpn
The 'show mpls table' indicates that the 16 label value
is allocated, but never used in the exported prefixes.
> r1# show mpls table
> Inbound Label Type Nexthop Outbound Label
> -----------------------------------------------------
> 16 BGP vrf1 -
> 17 BGP 192.168.255.13 -
> 18 BGP 192.0.2.12 -
> 19 BGP 192.0.2.11 -
Fix this by only allocating new label values when really
used. Consequently, only 3 labels will be allocated instead
of previously 4.
> r1# show mpls table
> Inbound Label Type Nexthop Outbound Label
> -----------------------------------------------------
> 16 BGP 192.168.255.13 -
> 17 BGP 192.0.2.11 -
> 18 BGP 192.0.2.12 -
Fixes: 577be36a41 ("bgpd: add support for l3vpn per-nexthop label")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
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>
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>
Prompt nothing for an empty (and failed) operation. Take
`bgp graceful-restart` as an example:
Before:
```
anlan(config-router)# bgp graceful-restart
Graceful restart configuration changed, reset all peers to take effect
anlan(config-router)# bgp graceful-restart
Graceful restart configuration changed, reset all peers to take effect
anlan(config-router)#
```
After:
```
anlan(config-router)# bgp graceful-restart
Graceful restart configuration changed, reset all peers to take effect
anlan(config-router)# bgp graceful-restart
anlan(config-router)#
```
Signed-off-by: anlan_cs <anlan_cs@tom.com>
The same command should be accepted, it is an empty operation. Take
`neighbor <X> graceful-restart-helper` as an example:
Before:
```
anlan(config-router)# neighbor 3.3.3.3 graceful-restart-helper
Graceful restart configuration changed, reset this peer to take effect
anlan(config-router)# neighbor 3.3.3.3 graceful-restart-helper
Graceful restart configuration changed, reset this peer to take effect
% The Graceful Restart command used is not valid at this moment.
anlan(config-router)#
```
After:
```
anlan(config-router)# neighbor 3.3.3.3 graceful-restart-helper
Graceful restart configuration changed, reset this peer to take effect
anlan(config-router)# neighbor 3.3.3.3 graceful-restart-helper
Graceful restart configuration changed, reset this peer to take effect
anlan(config-router)#
```
Signed-off-by: anlan_cs <anlan_cs@tom.com>
BGP receives notification from zebra about an vpn that
needs to be installed into the evpn tables. Unfortunately
this function was walking the entirety of evpn tables
3 times. Modify the code to walk the tree 1 time and
to just look for the needed route types as you go.
This reduces, in a scaled environment, processing
time of the zclient_read function from 130 seconds
to 95 seconds. For a up / down / up interface
scenario.
Signed-off-by: Rajasekar Raja <rajasekarr@vndia.com>
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The 'show bgp neighbors' output appends additional lines after GR mode
helpers.
> # show bgp neighbors
> [..]
> End-of-RIB received: IPv4 VPN
> Local GR Mode: Helper*
>
> Remote GR Mode: Helper
>
> R bit: True
>
Fix this by not appending the extra line feed.
> # show bgp neighbors
> [..]
> End-of-RIB received: IPv4 VPN
> Local GR Mode: Helper*
> Remote GR Mode: Helper
> R bit: True
Fixes: 0e4e879b40 ("bgpd: fix silly format string SNAFU")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Current changes deals with EVPN routes installation to zebra.
In evpn_route_select_install() we invoke evpn_zebra_install/uninstall
which sends zclient_send_message().
This is a continuation of code changes (similar to
ccfe452763) but to handle evpn part
of the code.
Ticket: #3390099
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
When receiving a BGP update that includes a colored extended community,
the nexthop is tracked in the bgp nexthop tracking context, but the
color is never recorded. Adding to this, the BGP route is not prevented
from being installed without hte color.
Actually, the srte color is set only when the SRTE_COLOR attribute is set.
And that attribute value is only set when an ext. community is locally
created, or an srte value is set, but not when a BGP update with a color
ext. community is received.
Fix this by setting the SRTE_COLOR attribute on this last case.
Fixes: 442e2edcfa ("bgpd: add functions related to srte_color management")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Currently bgp_path_info's are stored in reverse order
received. Sort them by the best path ordering.
This will allow for optimizations in the future on
how multipath is done.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
