Currently, when we check the new prefix-list entry for duplication, we
only take filled in fields into account and ignore optional fields.
For example, if we already have `ip prefix-list A 0.0.0.0/0 le 32` and
we try to add `ip prefix-list A 0.0.0.0/0`, it is treated as duplicate.
We should always compare all prefix-list fields when doing the check.
Fixes#9355.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
When OSPF is disabled on interface and enabled again, the IP which is
not matching the prefix-list is getting originated as External LSA.
Fixes: #9362
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Description:
Changes to cover all the following GR helper exit scenarios.
1. Upon receiving max age grace lsa.( successful graceful restart)
2. Topo change
3. Grace timer expiry.
4. User changes( like config deletion , interface down)
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
Description:
1. changes to process GRACE LSA packet.
2. Validation changes to enter Helper role.
3. Helper functionality during graceful restart.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
```
exit1-debian-9# show ip bgp large-community-list
(1-500) large-community-list number
LCOMMUNITY_LIST_NAME large-community-list name
large-testas
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
```
exit1-debian-9# show ip bgp community-list ?
(1-500) community-list number
COMMUNITY_LIST_NAME community-list name
testas
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
Previous:
- frrscript_load: push Lua function onto stack
- frrscript_call: calls Lua function
Now:
- frrscript_load: checks Lua function
- frrscript_call: pushes and calls Lua function (first clear the stack)
So now we just need one frrscript_load for consecutive frrscript_call.
frrscript_call does not recompile or reload the script file, it just
keys it from the global Lua table (where it should already be).
Signed-off-by: Donald Lee <dlqs@gmx.com>
Fix:
When summarised Type-5 LSA is removed, the corresponding Type-7
LSAs also need to be removed from area.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Fix:
1. The assert at line ospf6_asbr.c:2849 is not required.
2. When Individual LSAs are present and summarisation is configured
we need to remove such LSAs and originate the summarised ones.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
When calling rib_add_multipath_nhe ensure that we have
well aligned return codes that mean something so that
interersted parties can properly handle the situation.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When receiving a route via zapi, if the route is rejected
there exists a code path where we would not free the corresponding
re created.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The pathspace folder in /var/run needs the x permission for the group too
Otherwise vtysh fails when running it with groups frrvty and frr:
$ vtysh -N gateway
% Can't open configuration file /etc/frr/gateway/vtysh.conf due to 'Permission denied'.
vtysh_connect(/var/run/frr/gateway/zebra.vty): stat = Permission denied
Signed-off-by: Steffen Neubauer <s.neubauer@syseleven.de>
If there's no route table in a VRF, it's a hard bug - staticd will crash
on any subsequent action with this route anyway. So let's assert the
existence of a route table instead of returning an unrecoverable error.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
in bgp_io.c upon packet read of some error we are storing
the peer pointer on a thread to call bgp_packet_process_error.
In this case an event is generated that is not guaranteed to be
run immediately. It could come in *after* the peer data structure
is deleted and as such we now are writing into memory that we
no longer possibly own as a peer data structure.
Modify the code so that the peer can track the thread associated
with the read error and then it can wisely kill that thread
when deleting the peer data structure.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When bgp receives the admin distance from a redistribution statement
let's store that distance for later usage.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
