Move the command from 'lib' to 'vtysh' so we can properly format the
JSON output in a correct manner.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Avoids calling VRF/interface/... handlers in library code more than
once. It's kinda surprising that this hasn't been blowing up already
for the VNC code, luckily these handlers are (mostly?) idempotent.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
... and use it instead of fiddling with the `.synchronous` field.
(Make it const while at it.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Send `ZEBRA_ROUTE_NOTIFY_REQUEST` rather than relying on the options
field in zclient startup.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Send `ZEBRA_ROUTE_NOTIFY_REQUEST` rather than relying on the options
field in zclient startup.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Send `ZEBRA_ROUTE_NOTIFY_REQUEST` rather than relying on the options
field in zclient startup.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Replace `struct list *` with `DLIST(if_connected, ...)`.
NB: while converting this, I found multiple places using connected
prefixes assuming they were IPv4 without checking:
- vrrpd/vrrp.c: vrrp_socket()
- zebra/irdp_interface.c: irdp_get_prefix(), irdp_if_start(),
irdp_advert_off()
(these fixes are really hard to split off into separate commits as that
would require going back and reapplying the change but with the old list
handling)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Without this if we enter something like `debug bgp updates in x.x.x.x prefix-list y`,
prefix-list can't be lookup up, because when we read the config, debug does not know
anything about this prefix-list.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
At this stage, we should send a SET_CFG reply, not COMMIT_CFG reply.
Commit request is not yet initialized.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
a) Rename rib_init to zebra_rib_init() to better follow how
things are named
b) on shutdown cycle through the rib_dplane_q and free
up any contexts sitting in it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When bgp is shutting down, it calls bgp_fsm_change_status
on everything including a self peer, which goes through
and cleans the tables of the self peer data structures
as if it's a real peer. Add a bit of code to just
not do the work at all. This allows unlocks to flow
a bit further and for the self peer to be deleted
on shutdown.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The MTYPE_BGP memory type was being over used as
both the handler for the bgp instance itself as
well as memory associated with name strings.
Let's separate out the two.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
A route-map can be programmed to remove the route-target which
has been set with 'rt vpn export' command, but fails to remove
it.
Fix this by applying the route-map, then considering the resulting
extended community-list.
Add some tests to catch this issue.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Explain that an export route target list can be configured
alternatively by using route-maps.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add a test to check that the presence of a route-map at
exportation with a 'set extcommunity rt' is enough to allow
the prefix to be exported.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The prefixes unexportation triggers an attempt to create
the VPN prefix node if that prefix was not already present.
For instance, if a given prefix is not exported because of
a route-map filtering, the withdraw process will try to
create the node with the 'bgp_afi_node_get()' command.
Fix this by replacing this call by the 'bgp_safi_node_lookup()'
function.
Fixes: ddb5b4880b ("bgpd: vpn-vrf route leaking")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When exporting BGP prefixes, it is necessary to configure
the route target extended communities with the following
command:
> rt vpn export <RouteTarget>
But the customer may need to configure the route-target to
apply to bgp updates, solely based on a route-map criterium.
by using the below route-map configured like that:
> route-map vpn export <routemapname>
Fix this by allowing to export bgp updates based on the
presence of route-targets on either route-map or vpn
configured rt. the exportation process is stopped
if no route target is available in the ecommunity list.
Fixes: ddb5b4880b ("bgpd: vpn-vrf route leaking")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
