Description:
The changes involve setting DC bit on ospf hellos and
addition of new DO_NOT_AGE flag.
Signed-off-by: Manoj Naragund <mnaragund@vmware.com>
Description:
Code changes involve following things.
1. an additional structure containing flood reduction related info
per area.
2. a knob variable in the ospf structure for enabling/disabling the feature.
3. initialization of above mentioned variables.
Signed-off-by: Manoj Naragund <mnaragund@vmware.com>
If we got inside the condition of `vrfp->status == VRF_ACTIVE` then
don't make the same check again.
Found by Coverity Scan (CID 1519760)
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Don't attempt to dereference `ifp` directly if it might be null: there
is a check right before this usage: `ifp ? ifp->info : NULL`.
In this context it should be safe to assume `ifp` is not NULL because
the only caller of this function checks that for this `ifindex`. For
consistency we'll check for null anyway in case this ever changes (and
with this the coverity scan warning gets silenced).
Found by Coverity Scan (CID 1519776)
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Testcase: test_pim6_multiple_groups_different_RP_address_p2
was failing because of a bug in framework, Fixed the
bug in this commit.
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
Multicast pim6 static RP tests are failing
when run in parallel using micronet. There
are APIs to clean mcast traffic before
starting new test but these cleanups
are not needed when socat is used.
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
Use "(null)" for empty IP address.
One example in `bgp_zebra_send_remote_macip()` to install mac:
Before:
```
2023/01/18 02:09:09 BGP: [SCHS5-AK960] Tx ADD MACIP, VNI 200 MAC 06:6b:7c:db:83:72 IP flags 0x0 seq 0 remote VTEP 88.88.88.88 esi -
```
After:
```
2023/01/18 20:19:57 BGP: [SCHS5-AK960] Tx ADD MACIP, VNI 200 MAC 06:6b:7c:db:83:72 IP (null) flags 0x0 seq 0 remote VTEP 88.88.88.88 esi -
```
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Under really heavily loaded systems this is insufficient. Looking
at the run output we have this:
"2.1.3.22\/32":[
{
"installed":true,
}
],
"2.1.3.23\/32":[
{
"queued":true,
}
],
So after 10 seconds on the micronet system only 30 of the 100 routes are installed.
Give it more time.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Looks like under heavy load, the test is not giving enough
time to come to steady state. Do this:
a) send more udp packets and for longer
b) Increase time spent waiting
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Don't attempt to encode the pointer address instead pass the pointer
directly so the real contents can be accessed.
(`ri->pref_src` type is `union g_addr *`)
Found by Coverity Scan (CID 1482162)
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Do extra inotify data structure checks and copy the file name to a stack
buffer making sure it is null byte terminated.
Found by Coverity Scan (CID 1465494)
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Changes:
- Convert `unsigned int` to `time_t` to satisfy time truncation warnings
even though at this point we had already used the modulus operator.
- Avoid trying to access outside the bounds of the array
`months` array has a size of 13 elements, but the code inside the loop
uses `i + 1` to peek on the next month.
Found by Coverity Scan (CID 1519752 and 1519769)
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
MPLS VPN networks can either peer with iBGP or eBGP. When
calculating the distance to send to zebra, the imported prefix
is never sent with distance information, even if the vty
command is used under the ipv4 unicast address family:
router bgp 65505 vrf vrf1
address-family ipv4 unicast
distance bgp 26 27 28
[vpn config]
The observation is that the distance sent to zebra for an
imported prefix is still 20:
[..]
VRF vrf1:
B> 192.168.0.0/24 [20/0] via 2.2.2.2 (vrf default) (recursive), label 20, weight 1, 00:00:12
* via 10.125.0.6, ntfp3 (vrf default), label implicit-null/20, weight 1, 00:00:12
The expectation is that the incoming prefix has to follow the
distance that is configured, or the distance derived from the peer
relationship established by the parent prefix.
In the case, an iBGP relationship is done, and no distance
configuration is done, the below show is expected:
[..]
VRF vrf1:
B*> 192.168.0.0/24 [200/0] via 192.168.0.2, r1-gre0 (vrf default), label 20, weight 1, 00:00:12
In the case an iBGP relationship is done, and distance configuration
is performed as below:
[..]
distance bgp 21 201 41
[..]
Then the below show is expected:
[..]
VRF vrf1:
B*> 192.168.0.0/24 [201/0] via 192.168.0.2, r1-gre0 (vrf default), label 20, weight 1, 00:00:12
To get this behaviour, get the peer origin where the prefix is coming
from.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
After calling `rib_unlink` the variable `re` will point to `free()`d
memory, so don't attempt to use it after this point.
Found by Coverity Scan (Coverity ID 1519784)
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
