Currently the nexthop tracking code is only sending to the requestor
what it was requested to match against. When the nexthop tracking
code was simplified to not need an import check and a nexthop check
in b8210849b8 for bgpd. It was not
noticed that a longer prefix could match but it would be seen
as a match because FRR was not sending up both the resolved
route prefix and the route FRR was asked to match against.
This code change causes the nexthop tracking code to pass
back up the matched requested route (so that the calling
protocol can figure out which one it is being told about )
as well as the actual prefix that was matched to.
Fixes: #10766
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Problem Statement:
=================
The feature is not enabled, needs to be enabled by doing required
initialization.
RCA:
====
Changes to support the feature is present, but the feature macro
needs to be enabled.
Fix:
====
This commit has changes to enable the code.
Risk:
=====
Medium
Need to ensure all existing ospf6 related topotests pass. to ensure
packet processing is not impacted.
Tests Executed:
===============
Have tested the functionality with enabling openssl and also disabling
openssl.
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
Problem Statement:
==================
RFC 7166 support for OSPF6 in FRR code.
RCA:
====
This feature is newly supported in FRR
Fix:
====
Core functionality implemented in previous commit is
stitched with rest of ospf6 code as part of this commit.
Risk:
=====
Low risk
Tests Executed:
===============
Have executed the combination of commands.
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
Problem Statement:
==================
Implement RFC 7166 support for OSPF6 in FRR code.
RCA:
====
This feature is newly supported in FRR.
Fix:
====
Changes are done to implement ospf6 ingress and egress
packet processing.
This commit has the core functionality.
It supports below debugability commands:
---------------------------------------
debug ospf6 authentication [<tx|rx>]
It supports below clear command:
--------------------------------
clear ipv6 ospf6 auth-counters interface [IFNAME]
It supports below show commands:
--------------------------------
frr# show ipv6 ospf6 interface ens192
ens192 is up, type BROADCAST
Interface ID: 5
Number of I/F scoped LSAs is 2
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication trailer is enabled with manual key ==> new info added
Packet drop Tx 0, Packet drop Rx 0 ==> drop counters
frr# show ipv6 ospf6 neighbor 2.2.2.2 detail
Neighbor 2.2.2.2%ens192
Area 1 via interface ens192 (ifindex 3)
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication header present ==> new info added
hello DBDesc LSReq LSUpd LSAck
Higher sequence no 0x0 0x0 0x0 0x0 0x0
Lower sequence no 0x242E 0x1DC4 0x1DC3 0x23CC 0x1DDA
frr# show ipv6 ospf6
OSPFv3 Routing Process (0) with Router-ID 2.2.2.2
Number of areas in this router is 1
Authentication Sequence number info ==> new info added
Higher sequence no 3, Lower sequence no 1656
Risk:
=====
Low risk
Tests Executed:
===============
Have executed the combination of commands.
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
Problem Statement:
==================
RFC 7166 support for OSPF6 in FRR code.
RCA:
====
This feature is newly supported in FRR
Fix:
====
Changes are done to add support for two new CLIs to configure
ospf6 authentication trailer feature.
One CLI is to support manual key configuration.
Other CLI is to configure key using keychain.
below CLIs are implemented as part of this commit. this configuration
is applied on interface level.
Without openssl:
ipv6 ospf6 authentication key-id (1-65535) hash-algo <md5|hmac-sha-256> key WORD
With openssl:
ipv6 ospf6 authentication key-id (1-65535) hash-algo <md5|hmac-sha-256|hmac-sha-1|hmac-sha-384|hmac-sha-512> key WORD
With keychain support:
ipv6 ospf6 authentication keychain KEYCHAIN_NAME
Running config for these command:
frr# show running-config
Building configuration...
Current configuration:
!
interface ens192
ipv6 address 2001:DB8:1::2/64
ipv6 ospf6 authentication key-id 10 hash-algo hmac-sha-256 key abhinay
!
interface ens224
ipv6 address 2001:DB8:2::2/64
ipv6 ospf6 authentication keychain abhinay
!
Risk:
=====
Low risk
Tests Executed:
===============
Have executed the combination of commands.
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
Problem Statement:
==================
As of now there is no support for ospf6 authentication.
To support ospf6 authentication need to have keychain support for
managing the auth key.
RCA:
====
New support
Fix:
====
Enabling keychain for ospf6 authentication feature.
Risk:
=====
Low risk
Tests Executed:
===============
Have verified the support for ospf6 auth trailer feature.
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
if r1 has a route received from a neighbor and the same route
configured as static, the administrative distance will determine
which route to use
r1(config)# ipv6 route 1:1::1/128 Null0 70
r1# sh ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv3, I - IS-IS, B - BGP, 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
S>* 1:1::1/128 [70/0] unreachable (blackhole), weight 1, 00:00:12
O 1:1::1/128 [110/20] via fe80::1833:c9ff:fe7b:3e43, r1-r2-eth0, weight 1, 00:00:49
The static route is selected. If we now change the administrative distance
in ospf6, the OSPF route should be selected
r1(config)# router ospf6
r1(config-ospf6)# distance 50
r1# sh ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv3, I - IS-IS, B - BGP, 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
S>* 1:1::1/128 [70/0] unreachable (blackhole), weight 1, 00:00:39
O 1:1::1/128 [110/20] via fe80::1833:c9ff:fe7b:3e43, r1-r2-eth0, weight 1, 00:01:16
However the distance is not applied as there are no changes in the routing table
This commit will force the update of the routing table with the new configured distance
r1# sh ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv3, I - IS-IS, B - BGP, 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
O>* 1:1::1/128 [50/20] via fe80::8cb7:e6ff:fef5:2344, r1-r2-eth0, weight 1, 00:00:03
S 1:1::1/128 [70/0] unreachable (blackhole), weight 1, 00:00:19
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
This PR will include if the area is NSSA in the output of "show ipv6 ospf"
r2# show ipv6 ospf
...
Area 0.0.0.0
Number of Area scoped LSAs is 8
Interface attached to this area: r2-eth1
SPF last executed 20.46717s ago
Area 0.0.0.1[Stub]
Number of Area scoped LSAs is 9
Interface attached to this area: r2-eth0
SPF last executed 20.46911s ago
Area 0.0.0.2[NSSA]
Number of Area scoped LSAs is 14
Interface attached to this area: r2-eth2
SPF last executed 20.46801s ago
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
Opaque data takes up a lot of memory when there are a lot of routes on
the box. Given that this is just a cosmetic info, I propose to disable
it by default to not shock people who start using FRR for the first time
or upgrades from an old version.
Fixes#10101.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
VRF name should not be printed in the config since 574445ec. The update
was done for NB config output but I missed it for regular vty output.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Fixes#9720. When updating an ECMP inter-area route, we compute
a new route and check whether that already exists. If so, we keep the old
route and only update its nexthops. Previously, we merged the new route's
nexthops into the old one's, but this way, it's impossible to remove
nexthops from the old route, resulting in stale nexthops.
This commit fixes this by first removing all nexthops from the old route and
then copying all nexthops from the new route into it. If the new route has
fewer nexthops, the old one will have as well afterwards.
Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org>
Update ospfd and ospf6d to send opaque route attributes to
zebra. Those attributes are stored in the RIB and can be viewed
using the "show ip[v6] route" commands (other than that, they are
completely ignored by zebra).
Example:
```
debian# show ip route 192.168.1.0/24
Routing entry for 192.168.1.0/24
Known via "ospf", distance 110, metric 20, best
Last update 01:57:08 ago
* 10.0.1.2, via eth-rt2, weight 1
OSPF path type : External-2
OSPF tag : 0
debian#
debian# show ip route 192.168.1.0/24 json
{
"192.168.1.0\/24":[
{
"prefix":"192.168.1.0\/24",
"prefixLen":24,
"protocol":"ospf",
"vrfId":0,
"vrfName":"default",
"selected":true,
[snip]
"ospfPathType":"External-2",
"ospfTag":"0"
}
]
}
```
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Currently the ospf6d's commands with non-exist vrfs can't give the error
informations to users.
This commit adds a macro "OSPF6_CMD_CHECK_VRF" to give error information
if with non-exist vrfs. As usual, skip the checking process in the case
of json.
So one command can call this macro to do the checking process in its
end. At that time it need know json style or not, so add "json" parameter for
several related functions.
BTW, suppress the build warning of the macro `OSPF6_FIND_VRF_ARGS`:
"Macros starting with if should be enclosed by a do - while loop to avoid
possible if/else logic defects."
Signed-off-by: anlan_cs <anlan_cs@tom.com>
Comparison of the two pointer is confusing, they have no relevance
except the time both of them are empty.
Additionly modify one variable name and correct some comment words, they
are same in both ospfd and ospf6d.
Signed-off-by: anlan_cs <anlan_cs@tom.com>
The OSPF6_LSA_UNAPPROVED flag is set in the function above
ospf6_lsa_translated_nssa_new, so there is no need to set
the flag again
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
When running topotest ospf6_topo2 we can see a log message with wrong lsa id
2021/12/20 23:14:40.330 OSPF6: [V8P0C-HB5Z2] ASBR[default:Status:3]: Update
2021/12/20 23:14:40.330 OSPF6: [Z489N-JAJ6P] ASBR[default:Status:3]: Already ASBR
2021/12/20 23:14:40.330 OSPF6: [Z9D0B-12SBJ] Redistribute 2001:db8:2::/64 (connected)
2021/12/20 23:14:40.330 OSPF6: [N66XP-ANN4G] Advertise as AS-External Id:8.70.41.177 prefix 2001:db8:2::/64 metric 2 (**)
2021/12/20 23:14:40.330 OSPF6: [K4Y9R-C22T6] Advertise new AS-External Id:0.0.0.3 prefix 2001:db8:2::/64 metric 2
2021/12/20 23:14:40.330 OSPF6: [PKX0N-KNRQR] Originate AS-External-LSA for 2001:db8:2::/64
This PR removes the log (instead of fixing it) as same information is printed
in the following entry
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
Since ospf6Enabled and attachedToArea are denoting the same thing.
It is decided to remove ospf6Enabled from json output to make
CLI and json output similar.
Fixes: #9286
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Currently, it is possible to rename the default VRF either by passing
`-o` option to zebra or by creating a file in `/var/run/netns` and
binding it to `/proc/self/ns/net`.
In both cases, only zebra knows about the rename and other daemons learn
about it only after they connect to zebra. This is a problem, because
daemons may read their config before they connect to zebra. To handle
this rename after the config is read, we have some special code in every
single daemon, which is not very bad but not desirable in my opinion.
But things are getting worse when we need to handle this in northbound
layer as we have to manually rewrite the config nodes. This approach is
already hacky, but still works as every daemon handles its own NB
structures. But it is completely incompatible with the central
management daemon architecture we are aiming for, as mgmtd doesn't even
have a connection with zebra to learn from it. And it shouldn't have it,
because operational state changes should never affect configuration.
To solve the problem and simplify the code, I propose to expand the `-o`
option to all daemons. By using the startup option, we let daemons know
about the rename before they read their configs so we don't need any
special code to deal with it. There's an easy way to pass the option to
all daemons by using `frr_global_options` variable.
Unfortunately, the second way of renaming by creating a file in
`/var/run/netns` is incompatible with the new mgmtd architecture.
Theoretically, we could force daemons to read their configs only after
they connect to zebra, but it means adding even more code to handle a
very specific use-case. And anyway this won't work for mgmtd as it
doesn't have a connection with zebra. So I had to remove this option.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
