When creating SPF neighbors and calling spf_adj_list_parse_tlv(), the F_ISIS_SPF_ADJ_METRIC_INFINITY flag is only set to a local variable flags and not set to the SPF neighbor sadj->flags. Additionally, the pseudo node metric pseudo_metric is also not reflected in the F_ISIS_SPF_ADJ_METRIC_INFINITY flag, the metric should be checked using sadj->metric.
Signed-off-by: zhou-run <zhou.run@h3c.com>
When 'ip ospf neighbor-filter <filter-name>' is configured in the startup
configuration, it is in the running configuration but not applied on the
interface.
Signed-off-by: Acee Lindem <acee@lindem.com>
None of the bgp dump code was even tested. Add a bit
of basic stuff that it at least generates a dump file.
This can be extended at a future time.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
zebra_nhg_install_kernel takes a route type. We don't
know it at that particular spot but we should not be passing
in `true`. Let's use ZEBRA_ROUTE_MAX to indicate we do not
know, so that the correct thing is done.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In ospf_multi_vrf_bgp_route_leak, the admin distance for the
redistributed ospf route should be 110, and should remain as 110 after
it's imported into another vrf, and then downloaded to zebra.
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
f1ea52bee9 ("yang: use relative path instead of absolute one for
route-map") has introduced a route-map optimization but some paths
were not changed.
Use relative path instead absolute one everywhere.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Before adding an NHLFE entry, zebra calls nhlfe_nexthop_active_ipv4()/nhlfe_nexthop_active_ipv6() to check if there is a corresponding directly connected route for the next hop prefix of the NHLFE. If such a route exists, it directly overwrites the output interface of the NHLFE's next hop with the output interface of the directly connected route. If the output interface of the directly connected route is different from the output interface of the NHLFE's next hop, deleting the NHLFE entry later will fail because nhlfe_nhop_match() cannot find the same next hop address and output interface, leading to an NHLFE entry leak.
Establishing neighbors in ISIS only requires the existence of the neighbor's IP address and does not need the neighbor's IP address to be in the same subnet as the local IP address. When zebra creates an adjacency label entry, it uses the neighbor's IP address as the next hop. If the neighbor's IP address is not in the same subnet as the local IP address and there is a local directly connected route with the neighbor's IP address prefix, it will result in an issue where the corresponding adjacency label entry in zebra cannot be deleted.
We cannot enforce that ISIS must establish neighbors using IPv4 and IPv6 addresses in the same subnet, but we can ensure that IPv4 or IPv6 addresses in different subnets do not create adjacency labels.
Signed-off-by: zhou-run <zhou.run@h3c.com>
The type of the val field in ecommunity_val is used inconsistently
in a number of places. It should be defined as uint8_t.
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
When parsing the SR-Algorithm TLV in the OSPF Router Information Opaque
LSA, assure that not more than the maximum number of supported
algorithms are copied from the TLV.
Signed-off-by: Acee Lindem <acee@lindem.com>
Apparently logger.warn is being deprecated. So let's
switch over to logger.warning. Clearly it's better
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
