This fix updates the nexthop length of a bgp update to be
transmitted to a remote peer. Before the previous commit,
the ipv6 nexthop length was internally set to 32 bytes which
was not correct, as it should be 48 bytes which is conform
to the vpnv6 encoding format.
However, without the previous match, even if internally, the
nexthop length was set to 32, the real nexthop length was set
to 48 bytes, and everything was operating ok.
Now, if we use the following route-map, and attach it to
outgoing for vpnv6 address family, then we have a malformed
packet detected, and the peering breaks.
> route-map rmap permit 1
> set ipv6 next-hop global 5:5::3:6
> set ipv6 next-hop local fe80:55::333:222
Maintain the mp_nexthop_len to 48 bytes if it was already set
to 48 previously.
Fixes: 35ac9b53f2 ("bgpd: fix vpnv6 nexthop encoding")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
fpm:netlink format doesn't indicate the protocol information
in routes of BGP, OSPF and other protocols. Routes of those
protocols just indicate protocol as zebra.
The below route is actually BGP route but 'proto': 11
indicates that it is zebra.
{'attrs': [('RTA_DST', 'dummy'),
('RTA_PRIORITY', 0),
('RTA_GATEWAY', 'dummy'),
('RTA_OIF', 2)],
'dst_len': 32,
'family': 2,
'flags': 0,
'header': {'flags': 1025,
'length': 60,
'pid': 3160253895,
'sequence_number': 0,
'type': 24},
'proto': 11,
'scope': 0,
'src_len': 0,
'table': 254,
'tos': 0,
'type': 1}
with this change it is now seen with 'proto': 186
indicates that it is BGP.
{'attrs': [('RTA_DST', 'dummy'),
('RTA_PRIORITY', 0),
('RTA_GATEWAY', 'dummy'),
('RTA_OIF', 2)],
'dst_len': 32,
'family': 2,
'flags': 0,
'header': {'flags': 1025,
'length': 60,
'pid': 3160253895,
'sequence_number': 0,
'type': 24},
'proto': 186,
'scope': 0,
'src_len': 0,
'table': 254,
'tos': 0,
'type': 1}
Signed-off-by: Spoorthi K <spk@redhat.com>
This change updates the nexthop attribute length
accordingly to the safi used. Actually, with the
previous commit, the length calculated was not
aligned with the real nexthop length. Such packet
received by remote peer was malformed, and this
was resulting in breaking vpnv6 peering.
Fix this by updating appropriately the real
nexthop length.
Fixes: 35ac9b53f2 ("bgpd: fix vpnv6 nexthop encoding")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Use a larger storage to keep the `time_t` that is platform agnostic and
use the appropriated printing primitive.
Found by Coverity Scan (CID 1519793)
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
When show ip ospf border-routers json (without vrf)
specificed, it leads to crash if there no border-routers
information.
Fix:
Do not free json object if use_vrf flag (means vrf option
is not passed) is not set.
Ticket:#3229017
Issue:3229017
Testing Done:
with fix:
l1# show ip ospf border-routers json
{
}
l1# show ip ospf vrf default border-routers json
{
}
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Some babeld commands doesn't have the corresponding negative commands
defined, so those commands doesn't work with frr-reload.py.
This PR adds those missing commands.
Signed-off-by: Yuxiang Zhu <vfreex@gmail.com>
Use the correct function parameters type to avoid truncation and other
signal issues.
Found by Coverity Scan (CID 1519802)
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Don't directly use `time()` for generating sequence numbers for two
reasons:
1. `time()` can go backwards (due to NTP or time adjustments)
2. Coverity Scan warns every time we truncate a `time_t` variable for
good reason (verify that we are Y2K38 ready).
Found by Coverity Scan (CID 1519812, 1519786, 1519783 and 1519772)
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Use bigger storage for handling time variables so we don't truncate.
Found by Coverity Scan (CID 1519735)
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
babeld's `--terminal` option doesn't work because it replaces `stdin`
with `/dev/null`. It seems to me this function can be removed as `frr_run`
handles that in daemon mode.
Signed-off-by: Yuxiang Zhu <vfreex@gmail.com>
In ipv6 vpn, when the global and the local ipv6 address are received,
when re-transmitting the bgp ipv6 update, the nexthop attribute
length must still be 48 bytes.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
RFC7611 introduces new extended community ACCEPT_OWN and is already
implemented for FRR in the previous PR. However, this PR broke
compatibility about importing VPN routes.
Let's consider the following situation. There are 2 routers and these
routers connects with iBGP session. These routers have two VRF, vrf10
and vrf20, and RD 0:10, 0:20 is configured as the route distinguisher
of vrf10 and vrf20 respectively.
+- R1 --------+ +- R2 --------+
| +---------+ | | +---------+ |
| | VRF10 | | | | VRF10 | |
| | RD 0:10 +--------+ RD 0:10 | |
| +---------+ | | +---------+ |
| +---------+ | | +---------+ |
| | VRF20 +--------+ VRF20 | |
| | RD 0:20 | | | | RD 0:20 | |
| +---------+ | | +---------+ |
+-------------+ +-------------+
In this situation, the VPN routes from R1's VRF10 should be imported to
R2's VRF10 and the VPN routes from R2's VRF10 should be imported to R2's
VRF20. However, the current implementation of ACCEPT_OWN will always
reject routes if the RD of VPN routes are matched with the RD of VRF.
Similar issues will happen in local VRF2VRF route leaks. In such cases,
the route reaked from VRF10 should be imported to VRF20. However, the
current implementation of ACCEPT_OWN will not permit them.
+- R1 ---------------------+
| +------------+ |
| +----v----+ +----v----+ |
| | VRF10 | | VRF20 | |
| | RD 0:10 | | RD 0:10 | |
| +---------+ +---------+ |
+--------------------------+
So, this commit add additional condition in RD match. If the route
doesn't have ACCEPT_OWN extended community, source VRF check will be
skipped.
[RFC7611]: https://datatracker.ietf.org/doc/html/rfc7611
Signed-off-by: Ryoga Saito <ryoga.saito@linecorp.com>
After implementing ACCEPT_OWN extended community, bgpd can't import VPN
routes to the VRFs whose RD is matched with that of VPN routes. This
commit adds new test to check the effect of the next commit.
Signed-off-by: Ryoga Saito <ryoga.saito@linecorp.com>
The input queue limit does not belong under router bgp. This
is a dev escape and should just be removed.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Consider this scenario:
Lots of peers with a bunch of route information that is changing
fast. One of the peers happens to be really slow for whatever
reason. The way the output queue is filled is that bgpd puts
64 packets at a time and then reschedules itself to send more
in the future. Now suppose that peer has hit it's input Queue
limit and is slow. As such bgp will continue to add data to
the output Queue, irrelevant if the other side is receiving
this data.
Let's limit the Output Queue to the same limit as the Input
Queue. This should prevent bgp eating up large amounts of
memory as stream data when under severe network trauma.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Use `getpid()` to initialize the sequence number. This change silences
Coverity Scan warning about truncated use of `time()` which in this case
is not a problem.
Found by Coverity Scan (CID 1519828)
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
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>
