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>
When we get a update on a route that we already have information on
from another router and that route has been leaked ensure that
we do not crash when trying to releak the code when we may want
to modify the as path.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When a prefix in a vrf is imported into evpn as a type5,
copy the asn of the source to make sure it is reflected
in the target vrf.
Ticket: cumuluslinux-2554562
Signed-off-by: Don Slice <dslice@nvidia.com>
When we leak routes and are using a different ASN in the
source vrf from the target vrf, it's possible we could
create loops because of an incomplete as-path (missing
the source vrf ASN). This fix adds the source vrf ASN and
stops the importing of a BGP prefix that has the target
ASN in the as-path in the source vrf.
Signed-off-by: Don Slice <dslice@nvidia.com>
While it's okay to allow overwriting the ASN of a bgp vrf/instance
that is either hidden or automatically created, it's dangerous to
allow it on explicitly defined instances. If that were allowed,
a typo entering the bgp config could take down existing peering,
which would be a bad thing.
Signed-off-by: Don Slice <dslice@nvidia.com>
1. bgp coredump is observed when we delete default bgp instance
when we have multi-vrf; and route-leaking is enabled between
default, non-default vrfs.
Removing default router bgp when routes leaked between non-default vrfs.
- Routes are leaked from VRF-A to VRF-B
- VPN table is created with auto RD/RT in default instance.
- Default instance is deleted, we try to unimport the routes from all VRFs
- non-default VRF schedules a work-queue to process deleted routes.
- Meanwhile default bgp instance clears VPN tables and free the route
entries as well, which are still referenced by non-default VRFs which
have imported routes.
- When work queue process starts to delete imported route in VRF-A it cores
as it accesses freed memory.
- Whenever we delete bgp in default vrf, we skip deleting routes in the vpn
table, import and export lists.
- The default hidden bgp instance will not be listed in any of the show
commands.
- Whenever we create new default instance, handle it with AS number change
i.e. old hidden default bgp's AS number is updated and also changing
local_as for all peers.
2. A default instance is created with ASN of the vrf with the import
statement.
This may not be the ASN desired for the default table
- First problem with current behavior.
Define two vrfs with different ASNs and then add import between.
starting without any bgp config (no default instance)
A default instance is created with ASN of the vrf with the import
statement.
This may not be the ASN desired for the default table
- Second related problem. Start with a default instance and a vrf in a
different ASN. Do an import statement in the vrf for a bgp vrf instance
not yet defined and it auto-creates that bgp/vrf instance and it inherits
the ASN of the importing vrf
- Handle bgp instances with different ASNs and handle ASN for auto created
BGP instance
Signed-off-by: Kantesh Mundaragi <kmundaragi@vmware.com>
This file had a bunch of debugs that were operating on
specific vrf's but not telling you which vrf this was
happening in. Add code to allow operator debugging
to understand what vrf is being worked on.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Adding comments that tell what a variable is doing in
the middle of a function call makes it extremely hard
to read the formatting. Remove.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add counters for redistributed routes, and local aggregates to the
output of "show ip bgp statistics".
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
In the event that a resolution request is sent and
and resolution reply is never received, resolution
requests will continue to be sent until either the
newly created shortcut has been purged or a resolution
reply is finally received.
NHRPD_DEFAULT_PURGE_TIME and NHRPD_PURGE_EXPIRE are values
that were previously hardcoded and moved into macros for
the sake of readability.
Signed-off-by: Joshua Muthii <jmuthii@labn.net>
Use forward references instead of including the main bgpd.h
header in the bgp scripting header to reduce external impact
of changes.
Signed-off-by: Mark Stapp <mjs@cisco.com>
The previous commit modified zebra to reinstall the singleton
nexthops for a nexthop group when a interface event comes up.
Now let's modify zebra to attempt to reuse the nexthop group
when this happens and the upper level protocol resends the
route down with that. Only match if the protocol is the same
as well as the instance and the nexthop groups would match.
Here is the new behavior:
eva(config)# do show ip route 9.9.9.9/32
Routing entry for 9.9.9.9/32
Known via "static", distance 1, metric 0, best
Last update 00:00:08 ago
* 192.168.99.33, via dummy1, weight 1
* 192.168.100.33, via dummy2, weight 1
* 192.168.101.33, via dummy3, weight 1
* 192.168.102.33, via dummy4, weight 1
eva(config)# do show ip route nexthop-group 9.9.9.9/32
% Unknown command: do show ip route nexthop-group 9.9.9.9/32
eva(config)# do show ip route 9.9.9.9/32 nexthop-group
Routing entry for 9.9.9.9/32
Known via "static", distance 1, metric 0, best
Last update 00:00:54 ago
Nexthop Group ID: 57
* 192.168.99.33, via dummy1, weight 1
* 192.168.100.33, via dummy2, weight 1
* 192.168.101.33, via dummy3, weight 1
* 192.168.102.33, via dummy4, weight 1
eva(config)# exit
eva# conf
eva(config)# int dummy3
eva(config-if)# shut
eva(config-if)# no shut
eva(config-if)# do show ip route 9.9.9.9/32 nexthop-group
Routing entry for 9.9.9.9/32
Known via "static", distance 1, metric 0, best
Last update 00:00:08 ago
Nexthop Group ID: 57
* 192.168.99.33, via dummy1, weight 1
* 192.168.100.33, via dummy2, weight 1
* 192.168.101.33, via dummy3, weight 1
* 192.168.102.33, via dummy4, weight 1
eva(config-if)# exit
eva(config)# exit
eva# exit
sharpd@eva ~/frr1 (master) [255]> ip nexthop show id 57
id 57 group 37/43/50/58 proto zebra
sharpd@eva ~/frr1 (master)> ip route show 9.9.9.9/32
9.9.9.9 nhid 57 proto 196 metric 20
nexthop via 192.168.99.33 dev dummy1 weight 1
nexthop via 192.168.100.33 dev dummy2 weight 1
nexthop via 192.168.101.33 dev dummy3 weight 1
nexthop via 192.168.102.33 dev dummy4 weight 1
sharpd@eva ~/frr1 (master)>
Notice that we now no longer are creating a bunch of new
nexthop groups.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If a interface down event caused a nexthop group to remove
one of the entries in the kernel, have it be reinstalled
when the interface comes back up. Mark the nexthop as
usable.
new behavior:
eva# show nexthop-group rib 181818168
ID: 181818168 (sharp)
RefCnt: 1
Uptime: 00:00:23
VRF: default(bad-value)
Valid, Installed
Depends: (35) (38) (44) (51)
via 192.168.99.33, dummy1 (vrf default), weight 1
via 192.168.100.33, dummy2 (vrf default), weight 1
via 192.168.101.33, dummy3 (vrf default), weight 1
via 192.168.102.33, dummy4 (vrf default), weight 1
eva# conf
eva(config)# int dummy3
eva(config-if)# shut
eva(config-if)# do show nexthop-group rib 181818168
ID: 181818168 (sharp)
RefCnt: 1
Uptime: 00:00:44
VRF: default(bad-value)
Depends: (35) (38) (44) (51)
via 192.168.99.33, dummy1 (vrf default), weight 1
via 192.168.100.33, dummy2 (vrf default), weight 1
via 192.168.101.33, dummy3 (vrf default) inactive, weight 1
via 192.168.102.33, dummy4 (vrf default), weight 1
eva(config-if)# no shut
eva(config-if)# do show nexthop-group rib 181818168
ID: 181818168 (sharp)
RefCnt: 1
Uptime: 00:00:53
VRF: default(bad-value)
Valid, Installed
Depends: (35) (38) (44) (51)
via 192.168.99.33, dummy1 (vrf default), weight 1
via 192.168.100.33, dummy2 (vrf default), weight 1
via 192.168.101.33, dummy3 (vrf default), weight 1
via 192.168.102.33, dummy4 (vrf default), weight 1
eva(config-if)# exit
eva(config)# exit
eva# exit
sharpd@eva ~/frr1 (master) [255]> ip nexthop show id 181818168
id 181818168 group 35/38/44/51 proto 194
sharpd@eva ~/frr1 (master)>
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
