The idea is to find out prefixes including specific BGP table version and
above.
Let's say I have a converged network and suddently I noticed a couple of
prefixes seems hijacked.
I want to look what new prefixes arrived with a specific BGP table version.
```
exit1-debian-9# show ip bgp version 8
BGP table version is 9, local router ID is 192.168.100.1, vrf id 0
Default local pref 100, local AS 65534
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
bgpd: Show RPKI short state in `show bgp <afi> <safi>`
Just to be more informant, copying from Cisco.
```
exit1-debian-9# sh ip bgp
BGP table version is 4, local router ID is 192.168.100.1, vrf id 0
Default local pref 100, local AS 65534
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
David Lamparter [Fri, 9 Apr 2021 18:38:56 +0000 (20:38 +0200)]
pceplib: add missing endian.h and config.h
endian.h supplies be*toh() and htobe*() functions. This fixes the build
on musl libc. On other systems it seems endian.h comes in transitively
from some other header.
(Also, all .c files should have config.h or zebra.h as the first
include, even if it works without that it's b0rked and only works due to
luck.)
Tested-by: Lucian Cristian <lucian.cristian@gmail.com> Signed-off-by: David Lamparter <equinox@diac24.net>
Igor Ryzhov [Fri, 9 Apr 2021 16:42:23 +0000 (19:42 +0300)]
lib, doc: add "route-map NAME optimization" command
Currently we have a "route-map optimization" command which is entered
from inside the route-map entry but actually applies to the whole
route-map. In addition, this command is not shown in the running-config
and not stored to the startup-config during "write".
Let's add a new command on the config node level to control this setting
and show it in the running-config to make possible to save it during
"write".
The old command is saved for the backward compatibility but hidden and
marked as deprecated.
David Lamparter [Fri, 9 Apr 2021 17:56:05 +0000 (19:56 +0200)]
build: don't link pathd/path_main.c twice
Can't have things duplicate in libpath.a and pathd directly, they'll
crash into eath other on linking. No idea why this doesn't error out in
our CI builds, but it definitely breaks LTO builds.
Signed-off-by: David Lamparter <equinox@diac24.net>
Quentin Young [Fri, 9 Apr 2021 17:13:45 +0000 (13:13 -0400)]
tools: add note to users re: frr.conf overwrite
Most software doesn't overwrite its own config files; vtysh's 'wr mem'
may be confusing, so add a note to the config file explaining changes
made may be overwritten.
Quentin Young [Tue, 16 Feb 2021 23:05:38 +0000 (18:05 -0500)]
*: remove *.conf.sample files
Most of these are many, many years out of date. All of them vary
randomly in quality. They show up by default in packages where they
aren't really useful now that we use integrated config. Remove them.
Quentin Young [Fri, 9 Apr 2021 16:55:33 +0000 (12:55 -0400)]
doc: describe acceptable commit messages
Update workflow.rst to state that commit messages consisting solely of
program output, or that otherwise fail to adequately summarize the
changes being made, are unacceptable.
Philippe Guibert [Fri, 26 Feb 2021 09:04:25 +0000 (10:04 +0100)]
zebra: move neighbor table configuration to dplane contexts
Instead of directly configuring the neighbor table after read from zapi
interface, a zebra dplane context is prepared to host the interface and
the family where the neighbor table is updated. Also, some other fields
are hosted: app_probes, ucast_probes, and mcast_probes. More information
on those fields can be found on ip-ntable configuration.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Thu, 25 Feb 2021 10:12:34 +0000 (11:12 +0100)]
zebra, lib: handle NEIGH_ADD/DELETE to zebra dataplane framework
EVPN neighbor operations were already done in the zebra dataplane
framework. Now that NHRP is able to use zebra to perform neighbor IP
operations (by programming link IP operations), handle this operation
under dataplane framework:
- assign two new operations NEIGH_IP_INSTALL and NEIGH_IP_DELETE; this
is reserved for GRE like interfaces:
example: ip neigh add A.B.C.D lladdr E.F.G.H
- use 'struct ipaddr' to store and encode the link ip address
- reuse dplane_neigh_info, and create an union with mac address
- reuse the protocol type and use it for neighbor operations; this
permits to store the daemon originating this neighbor operation.
a new route type is created: ZEBRA_ROUTE_NEIGH.
- the netlink level functions will handle a pointer, and a type; the
type indicates the family of the pointer: AF_INET or AF_INET6 if the
link type is an ip address, mac address otherwise.
- to keep backward compatibility with old queries, as no extension was
done, an option NEIGH_NO_EXTENSION has been put in place
- also, 2 new state flags are used: NUD_PERMANENT and NUD_FAILED.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Thu, 25 Feb 2021 14:06:23 +0000 (15:06 +0100)]
zebra: fixes NDA_DST in netlink_neigh_update() function
When netlink_neigh_update() is called, the link registration was
failing, due to bad request length.
Also, the query was failing if NDA_DST was an ipv6 address.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Fri, 13 Dec 2019 17:09:11 +0000 (18:09 +0100)]
nhrp, lib, zebra: add/del neighbor entry possible from nhrp
a zebra api is extended to offer ability to add or remove neighbor
entry from daemon. Also this extension makes possible to add neigh
entry, not only between IPs and macs, but also between IPs and NBMA IPs.
This API supports configuring ipv6/ipv4 entries with ipv4/ipv6 lladdr.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Thu, 12 Dec 2019 15:08:26 +0000 (16:08 +0100)]
nhrpd: link layer registration to notifications
neighbor notifications are done in zebra. so, instead of relying on
nhrp, rely on zebra by using zebra api interface.
Consequently, the code originally used in nhrp for netlink neighor
notification is no more used.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Thu, 12 Dec 2019 15:06:59 +0000 (16:06 +0100)]
zebra: link layer config and notification, implementation in zebra
zebra implements zebra api for configuring link layer information. that
can be an arp entry (for ipv4) or ipv6 neighbor discovery entry. This
can also be an ipv4/ipv6 entry associated to an underlay ipv4 address,
as it is used in gre point to multipoint interfaces.
this api will also be used as monitoring. an hash list is instantiated
into zebra (this is the vrf bitmap). each client interested in those entries
in a specific vrf, will listen for following messages: entries added, removed,
or who-has messages.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Thu, 12 Dec 2019 15:05:14 +0000 (16:05 +0100)]
lib: link layer neighbor registration and notification, define API msgs
This patch implements new zapi api to get neighbor information that zebra knows
and that other daemons may need to know. Actually, nhrp daemons is
interested in getting the neighbor information on gre interfaces, and
the API will be used for that.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Tue, 16 Jul 2019 13:21:29 +0000 (15:21 +0200)]
nhrpd: lookup appropriate ipsec path
lookup appropriate ipsec path. there are systems where the path where
the charon.vici file is not in standard paths. For that, 'ipsec
--piddir' may help in solving the path.
result of ipsec --piddir is as follow for example:
'
/etc/ike/ipsec.d/run
'
Note that the assumption is done that even if there are several
instances of strongswan across the vrfs, the charon.vici path file is
the same across vrfs. Consequently, as there is a thread per vrf that
performs vici initialisation, and file path retrieval is part of the
vici initialisation procedure, in order to avoid intempestive system
calls, use a boolean 'vici_charon_filepath_done' to avoid doing
unnecessary calls.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Rafael Zalamena [Fri, 9 Apr 2021 13:54:23 +0000 (10:54 -0300)]
ospfd: fix crash on interface/vrf removal
The interface parameters deletion must be called before
`route_table_finish` due to the usage of the route data structures to
search neighbors in the same interface. If the route info is removed
before that we get the following crash:
```
6 0x00007f5c6ed50394 in core_handler at lib/sigevent.c:255
7 <signal handler called>
8 ospf_interface_bfd_apply (ifp=<optimized out>) at ospfd/ospf_bfd.c:130
9 0x000055d4c306d076 in ospf_interface_disable_bfd at ospfd/ospf_bfd.c:159
10 0x000055d4c3071781 in ospf_del_if_params at ospfd/ospf_interface.c:553
11 0x000055d4c3071900 in ospf_if_delete_hook at ospfd/ospf_interface.c:704
12 0x00007f5c6ed17935 in hook_call_if_del at lib/if.c:59
13 if_delete_retain at lib/if.c:290
14 0x00007f5c6ed19bc5 in if_delete at lib/if.c:313
15 0x00007f5c6ed19d88 in if_terminate at lib/if.c:1067
16 0x00007f5c6ed63a04 in vrf_delete at lib/vrf.c:297
17 0x00007f5c6ed76784 in zclient_vrf_delete at lib/zclient.c:1974
18 zclient_read at lib/zclient.c:3686
19 0x00007f5c6ed60f85 in thread_call at lib/thread.c:1815
20 0x00007f5c6ed20228 in frr_run at lib/libfrr.c:1149
21 0x000055d4c306bc70 in main at ospfd/ospf_main.c:233
```
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Current behavior has an EVPN_ENABLED check for both standard and 'no'
forms of 'advertise-svi-ip' and 'advertise-default-gw'. This prevents a
user from removing either command from running config if
'advertise-all-vni' is not present.
This commit removes/adjusts the EVPN_ENABLED checks to always allow the
'no' command so config doesn't get stuck.
Description:
Route leaking from default vrf to non-default vrf stops after frr restart.
If the interface comes up after route leaking is configured,
in the case of vpn router id update, we delete the ecommunity value
and never reconfigure the rtlist.
This results in skipping route leak to non-default vrfs (vpn to vrf).
Router-id change that is not explicitly configured
(a change from zebra, frr restart) should not replace a configured vpn RD/RT.
Added few helpful debugs as well.
Co-authored-by: Santosh P K <sapk@vmware.com> Co-authored-by: Kantesh Mundaragi <kmundaragi@vmware.com> Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
VRF-Lite: Fix export of withdraw-in-progress routes
Problem:
Stale routes are seen in the bgp table(ipv4 and ipv6)
RCA:
Scenario1:
Interface down and withdraw is in-progress.
Router bgp config leading to re-leaking.
Now, withdraw-in-progress routes,
are again leaked to bgp vrf instance(s) importing routes.
Whenever we see an interface down
and corresponding address delete,
while withdrawal of exported routes is in-progress,
routes are marked as being removed and put into work queue.
‘router bgp’ config is updated, which triggers
bgp_vpn_leak_export; which exports routes from configured bgp vrf to VPN.
So withdraw-in-progress routes,
are again leaked to bgp vrf instance(s) importing routes; leading to stale routes.
Scenario2:
- 'no import vrf non-default-vrf’ [in the default vrf]
- bgp update from the peer withdrawing prefix [non-default vrf]
- 'import vrf non-default-vrf’ [configured in the default vrf]
While withdrawal of exported routes is in-progress,
routes are marked as being removed and put into work queue,
In the meantime, if import vrf is configured,
which exports routes from configured bgp vrf to VPN.
So withdraw-in-progress new routes,
are again leaked to bgp vrf instance(s) importing routes; leading to stale routes.
Fix:
Whenever leaking routes (leak_update),
for already existing routes,
skip the routes with bgp_path_info
marked as being removed.
Also added the log message for the return.
Co-authored-by: Santosh P K <sapk@vmware.com> Co-authored-by: Kantesh Mundaragi <kmundaragi@vmware.com> Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
Description:
After FRR restart, routes are not getting redistributed;
when routes added first and then 'redistribute static' cmd is issued.
During the frr restart, vrf_id will be unknown,
so irrespective of redistribution, we set the redistribute vrf bitmap.
Later, when we add a route and then issue 'redistribute' cmd,
we check the redistribute vrf bitmap and return CMD_WARNING;
zebra_redistribute_add also checks the redistribute vrf bitmap and returns.
Instead of checking the redistribute vrf bitmap, always set it anyways.
Co-authored-by: Santosh P K <sapk@vmware.com> Co-authored-by: Kantesh Mundaragi <kmundaragi@vmware.com> Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
Abhinay Ramesh [Wed, 31 Mar 2021 11:32:57 +0000 (11:32 +0000)]
bgpd: vrf route leaking, fix vrf delete
Description:
Imported/leak-from routes do not get withdrawn/removed
even if the source VRF is deleted.
Deleting and re-adding a tenant vrf, does not refresh the RIB.
Whenever VRF is deleted (bgp_vrf_disable),
currently we are withdrawing leak-from-vrf and
leak-to-vrf routes from vpn table for the vrf,
which is deleted.
But we are currently not withdrawing routes from leak-to vrfs.
We should also withdraw leak-to routes
from leak-to vrfs (calling vpn_leak_to_vrf_withdraw).
Co-authored-by: Santosh P K <sapk@vmware.com> Co-authored-by: Kantesh Mundaragi <kmundaragi@vmware.com> Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
Abhinay Ramesh [Wed, 31 Mar 2021 11:05:56 +0000 (11:05 +0000)]
bgpd: vrf route leaking, fix the bgp instance delete and re-add
Description:
FRR doesn't re-install the routes, imported from a tenant VRF,
when bgp instance for source vrf is deleted and re-added again.
When bgp instance is removed and re-added, when import statement is already there,
then route leaking stops between two VRFs.
Every 'router bgp' command should trigger re-export of all the routes
to the importing bgp vrf instances.
When a router bgp is configured, there could be bgp vrf instance(s) importing routes from
this newly configured bgp vrf instance.
We need to export routes from configured bgp vrf to VPN.
This can impact performance, whenever we are testing scale from vrf route-leaking perspective.
We should not trigger re-export for already existing bgp vrf instances.
Co-authored-by: Santosh P K <sapk@vmware.com> Co-authored-by: Kantesh Mundaragi <kmundaragi@vmware.com> Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
Igor Ryzhov [Tue, 6 Apr 2021 18:09:50 +0000 (21:09 +0300)]
lib: fix usage of operational data in CLI
CLI must never use operational data, because this won't work in
transactional mode. Rework search for prefix-list/access-list entries
using only candidate config.
Mark Stapp [Tue, 6 Apr 2021 19:26:51 +0000 (15:26 -0400)]
ospfd: permit over-write of message-digest-key
Allow over-write of message-digest-key interface config. Most
attributes handle multi-instance by ... ignoring instances,
and tolerating repeated config: do the same for md5 auth.
ospfd: fix output of dead-interval in show running
When you set OSPF hello-interval for an interface and dead-interval is
not set for this interface, dead-interval will be calculated and set
automatically. "show running-config" will contain an invalid command:
test(config)# interface vpp1
test(config-if)# ip ospf area 0
test(config-if)# ip ospf hello-interval 1
test(config-if)# exit
test(config)#
test(config)# do show running-config
...
interface if1
ip ospf area 0
ip ospf dead-interval minimal hello-multiplier 0
ip ospf hello-interval 1
!
...
Reuben Dowle [Thu, 18 Mar 2021 02:40:09 +0000 (15:40 +1300)]
ospfd: Suppress spurious write message when using ip nhrp map multicast
When ip nhrp map multicast is being used, this is usually accompanied by an
iptables rule to block the original multicast packet. This causes sendmsg to
return EPERM.
projects / mirror_frr.git / log