ospf6_routemap_rule_match_interface uses route->ospf6 field for matching
so we must fill the field in our temporary variable.
Fixes#10911.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
When an area-range command is applied in an ABR, the more specific prefixes
need to be removed.
r2# sh ipv6 ospf database
AS Scoped Link State Database
Type LSId AdvRouter Age SeqNum Payload
ASE 0.0.0.1 10.254.254.2 53 80000001 ::
ASE 0.0.0.2 10.254.254.2 51 80000001 2001:db8:1::/64
ASE 0.0.0.3 10.254.254.2 51 80000001 2001:db8:3::/64
ASE 0.0.0.4 10.254.254.2 51 80000001 2001:db8:2::/64
ASE 0.0.0.5 10.254.254.2 46 80000001 2001:db8:1::/64
ASE 0.0.0.6 10.254.254.2 46 80000001 2001:db8:3::/64
ASE 0.0.0.7 10.254.254.2 46 80000001 2001:db8:2::/64
ASE 0.0.0.8 10.254.254.2 41 80000001 2001:db8:3::/64
ASE 0.0.0.9 10.254.254.2 41 80000001 2001:db8:1000::1/128 <-- **
ASE 0.0.0.10 10.254.254.2 41 80000001 2001:db8:1000::2/128 <-- **
ASE 0.0.0.12 10.254.254.2 24 80000001 2001:db8:1000::/64
ASE 0.0.0.1 10.254.254.3 52 80000001 2001:db8:2::/64
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
Problem:
ospf6d crash is observed when lsack is received from the neighbour for
AS External LSA.
RCA:
The crash is observed in ospf6_decrement_retrans_count while decrementing
retransmit counter for the LSA when lsack is recived. This is because in
ospf6_flood_interace when new LSA is being added to the neighbour's list
the incrementing is happening on the received LSA instead of the already
present LSA in scope DB which is already carrying counters.
when this new LSA replaces the old one, the already present counters are
not copied on the new LSA this creates counter mismatch which results in
a crash when lsack is recevied due to counter going to negative.
Fix:
The fix involves following changes.
1. In ospf6_flood_interace when LSA is being added to retrans list
check if there is alreday lsa in the scoped db and increment
the counter on that if present.
2. In ospf6_lsdb_add copy the retrans counter from old to new lsa
when its being replaced.
Signed-off-by: Manoj Naragund <mnaragund@vmware.com>
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>
