Move the "longer-prefixes" option from show_ip_bgp_cmd to
show_ip_bgp_json_cmd so that is has access to JSON output.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Move the "route-map" option from show_ip_bgp_cmd to
show_ip_bgp_json_cmd so that is has access to JSON output.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Move the "filter-list" option from show_ip_bgp_cmd to
show_ip_bgp_json_cmd so that is has access to JSON output.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Move the "prefix-list" option from show_ip_bgp_cmd to
show_ip_bgp_json_cmd so that is has access to JSON output.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Move the "community-list" option from show_ip_bgp_cmd to
show_ip_bgp_json_cmd so that is has access to JSON output.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
There's no need to have different calls to bgp_show() when the only
difference is one argument that corresponds to a "void *" parameter.
Code duplication should be reduced to a minimum to avoid bugs like
the one fixed in the previous commit.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Like done in the other places (when "all" isn't used), pass the
actual alias name to bgp_show() instead of a null pointer.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Duplicate a couple of definitions in order to remove the bgpd
includes from this libfrr header. This is necessary to fix some
name collisions like PREFIX_LIST_IN being defined differently on
multiple daemons (as soon as other daemons start including
route_opaque.h).
Including daemon headers on libfrr headers is a bad practice and
should be avoided whenever possible.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
In some cases, zebra may install a nexthop-group id that is
different from the id of the nhe struct attached to a
route-entry. This happens for a singleton recursive nexthop,
for example, where a route is installed with the resolving
nexthop's id.
The installed value is the most useful value - that corresponds
to information in the kernel on linux/netlink platforms that
support nhgs. Display both values if they differ in ascii
output, and include both values in the json form.
Signed-off-by: Mark Stapp <mstapp@nvidia.com>
This is needed for the following two reasons:
1. To be able to remove the northbound HACK in if_update_to_new_vrf. It
is totally wrong to rewrite the configuration datastore when some
operational state changes. It is a hard blocker for storing a
configuration data in a management daemon which knows nothing about
the operational state.
2. To allow changing the VRF of the interface using FRR CLI or any other
frontend in the future. If the VRF is a part of the key, it can't be
changed. If the VRF is a simple leaf, it becomes possible to change
it and thus move the interface between VRFs. For now I mark the leaf
as a "config false" as it's not yet possible to control it from FRR.
But we can't simply remove the VRF from the key, because it is needed to
distinguish interfaces when using netns based VRFs, as it is possible to
have multiple interfaces with the same name in different namespaces. To
handle this, I came up with an idea to store both VRF and an interface
name in the "name" leaf using the pattern "vrfname:ifname". For example,
if there's an interface "eth0" in VRF "red" then its "name" leaf will be
"red:eth0".
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
When the VRF interface is coming up, we don't need to fixup VRF ids - it
was already done in static_vrf_enable when the interface was created.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
add a parameter to resolver api that is the vrf identifier. this permits
to make resolution self to each vrf. in case vrf netns backend is used,
this is very practical, since resolution can happen on one netns, while
it is not the case in an other one.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Since f60a1188 we store a pointer to the VRF in the interface structure.
There's no need anymore to store a separate vrf_id field.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
There exist systems that do not explicity have a python soft-link
on their system. Let's explicity call out which python we want
to be using with exabgp.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
For IPv4 matching, we have "match ip next-hop address A.B.C.D".
For IPv6 matching, we have "match ipv6 next-hop X:X::X:X".
To have consistency, let's add "address" keyword to IPv6 commands.
Old commands are preserved as hidden for backward compatibility.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
The bgp gr topotests had run times that were greater than 10 minutes each.
Just brute force break up the tests to 4 different sub parts.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Description:
When changing the area from normal to NSSA, previous area's
ASBR router's type-5 also calculated and added to routing table along
with Type-7 lsas.
Made a change in route calculation such that it will not consider Type-5
lsas in calculation if it is originated from NSSA ASBR router.
These lsas will be age out at MAX age.
log:
frr(config-router)# do show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
K>* 0.0.0.0/0 [0/0] via 10.112.157.253, ens160, 00:32:47
C>* 10.112.156.0/23 is directly connected, ens160, 00:32:47
S>* 22.22.22.2/32 [1/0] is directly connected, ens192, weight 1, 00:20:03
O>* 33.33.33.0/24 [110/20] via 100.1.1.220, ens192, weight 1, 00:08:55
via 100.1.1.220, ens192, weight 1, 00:08:55
O 100.1.1.0/24 [110/10] is directly connected, ens192, weight 1, 00:21:32
C>* 100.1.1.0/24 is directly connected, ens192, 00:23:11
frr(config-router)# do show ip ospf route
============ OSPF network routing table ============
N 100.1.1.0/24 [10] area: 0.0.0.1
directly attached to ens192
============ OSPF router routing table =============
R 2.2.2.2 [10] area: 0.0.0.1, ASBR
via 100.1.1.220, ens192
============ OSPF external routing table ===========
N E2 33.33.33.0/24 [10/20] tag: 0
via 100.1.1.220, ens192
via 100.1.1.220, ens192
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
Problem Statement:
==================
on rp_change, PIM processes all the upstream in a loop and for selected
upstreams PIM has to send join/prune based on the RPF changed.
join and prune packets are not getting aggregated in a single packet.
Root Cause Analysis:
====================
on pim_rp_change pim_upstream_update() gets called for selected upstreams.
This API calculates to whom it has to send join and to whom it has to
send prune via API pim_zebra_upstream_rpf_changed(). This API peprares
the upstream_switch_list list per interface and inserts the group and
sources.
Now PIM is still in the pim_upstream_update() API context, i.e PIM
is still processing the same upstream. In the last there is a
call to pim_zebra_update_all_interfaces() which processes the
upstream_switch_list list, sends the packets out and clears the list.
Fix:
====
Don't process the upstream_switch_list in the upstream context.
process all the upstreams prepare the upstream_switch_list and then
process in one go. This will club all the S,G entries.
It also saves list cleanup with respect to memory allocation and
deallocation multiple times.
Signed-off-by: Vishal Dhingra <rac.vishaldhingra@gmail.com>
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Description:
- Changing the expected output for selected route in the script.
- With our changes for VRF-Lite fix best path selection,
during best path selection, while comparing the paths for imported routes,
we should correctly refer to the original route i.e. the ultimate path.
In this case, when we have ibgp route and imported ibgp route
for the same prefix, we do compare IGP metric which is same for both,
So we proceed to comparing router-ids and selecting the best path.
- Before our changes, ibgp route was preferred because of IGP metric.
With our fix, expected output for selected route is changed to
imported ibgp route because of the lower router-id.
- Corresponding changes for expected advertised route and
the large community are made.
Co-authored-by: Kantesh Mundaragi <kmundaragi@vmware.com>
Signed-off-by: Iqra Siddiqui <imujeebsiddi@vmware.com>
