When we have a pbr-policy applied to an interface and the
rule is installed and then deleted, we would not properly
clean up the bit field for the pmi as well as not note
the rule as properly deleted.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When changing policy on an interface, only delete the old_pbrm
if it is different than the current, this covers the case:
current config:
int swp1
pbr-policy DONNA
To a config entered of:
int swp1
pbr-policy EVA
Additionally there is no need to reinstall if we enter the same
pbr-policy two times in a row.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Consider the following topo VTEP1->SPINE1->VTEP2. ebgp is being used
for evpn route exchange with SPINE just acting as a pass through.
1. VTEP1 was building the type-3 IMET route with the correct PMSI
tunnel type (ingress-replication) and label (VNI)
2. Spine1 was however only parsing the tunnel-type in the attr (was
skipping parsing of the label field altogether) -
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
root@MSP1:~# net show bgp l2vpn evpn route rd 27.0.0.15:4 type multicast
EVPN type-2 prefix: [2]:[ESI]:[EthTag]:[MAClen]:[MAC]
EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]
EVPN type-5 prefix: [5]:[ESI]:[EthTag]:[IPlen]:[IP]
BGP routing table entry for 27.0.0.15:4:[3]:[0]:[32]:[27.0.0.15]
Paths: (1 available, best #1)
Advertised to non peer-group peers:
TORC11(downlink-1) TORC12(downlink-2) TORC21(downlink-3) TORC22(downlink-4) TORS1(downlink-5) TORS2(downlink-6)
Route [3]:[0]:[32]:[27.0.0.15]
5550
27.0.0.15 from TORS1(downlink-5) (27.0.0.15)
Origin IGP, valid, external, bestpath-from-AS 5550, best
Extended Community: RT:5550:1003 ET:8
AddPath ID: RX 0, TX 227
Last update: Thu Feb 7 15:44:22 2019
PMSI Tunnel Type: Ingress Replication, label: 16777213 >>>>>>>
Displayed 1 prefixes (1 paths) with this RD (of requested type)
root@MSP1:~#
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
3. So VTEP2 didn't rx the correct label.
In an all FRR setup this doesn't have any functional consequence but some
vendors are validating the content of the label field as well and ignoring
the IMET route from FRR (say VTEP1 is FRR and VTEP2 is 3rd-party). The
functional consequence of this VTEP2 ignores VTEP1's IMET route and doesn't
add VTEP1 to the corresponding l2-vni flood list.
This commit fixes up the PMSI attr parsing on spine-1 -
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
root@MSP1:~# net show bgp l2vpn evpn route rd 27.0.0.15:4 type multicast
EVPN type-2 prefix: [2]:[ESI]:[EthTag]:[MAClen]:[MAC]
EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]
EVPN type-5 prefix: [5]:[ESI]:[EthTag]:[IPlen]:[IP]
BGP routing table entry for 27.0.0.15:4:[3]:[0]:[32]:[27.0.0.15]
Paths: (1 available, best #1)
Advertised to non peer-group peers:
TORC11(downlink-1) TORC12(downlink-2) TORC21(downlink-3) TORC22(downlink-4) TORS1(downlink-5) TORS2(downlink-6)
Route [3]:[0]:[32]:[27.0.0.15]
5550
27.0.0.15 from TORS1(downlink-5) (27.0.0.15)
Origin IGP, valid, external, bestpath-from-AS 5550, best
Extended Community: RT:5550:1003 ET:8
AddPath ID: RX 0, TX 278
Last update: Thu Feb 7 00:17:40 2019
PMSI Tunnel Type: Ingress Replication, label: 1003 >>>>>>>>>>>
Displayed 1 prefixes (1 paths) with this RD (of requested type)
root@MSP1:~#
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Ticket: CM-23790
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Currently we are hardcoding it at the time of attr building to
ingress-replication. This is just a code clean-up and has no
functional impact.
Ticket: CM-23790
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
CLANG was throwing an error because struct rtadv_rdnss(dnssl) was being
initialized with = {0} instead of {}. Change to be the latter.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Commit b4897fa5 introduced a call to decrement a route-map counter,
applied to a prefix-list in bgp_rfapi_cfg.c. This commit removes
that call.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Compiling an empty C file with most headers included and -Wc++-compat
gives us a build error if we introduce some stupid C++-incompatible
change.
While this won't catch everything, it's a good start.
Signed-off-by: David Lamparter <equinox@diac24.net>
* command_graph.h: stop using "new" as a parameter name as that's a
reserved C++ keyword.
* module.h: avoid using C99 designated initializers since C++ doesn't
support them. This change hurts code readability quite considerably,
so we should try to find a better solution later.
* pw.h: remove unneeded empty structure to silence a C++ warning.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
C++ doesn't support implicit casts from void pointers like C
does. And the libfrr headers have some bits of code that rely on
implicit casts in order to work. To solve this problem, add a new
"static_cast" macro that performs explicit static casts when a C++
compiler is being used, or do nothing otherwise.
NOTE: since macros are only evaluated when they are used, there
might be other macros from libfrr that will need to use "static_cast"
as well. If a header is successfully compiled using a C++ compiler,
there's no guarantee that its macros are compatible with C++. We'll
only know about such macros when they are used by C++ code, then
we'll need to adapt them one by one in the future.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Two different definitions of "enum filter_type" exist in libfrr:
one in lib/filter.h and other in lib/command_match.h. Rename one
of them to resolve a conflict that happens when both headers are
included by the same file.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
These are necessary to use functions defined in these headers from C++.
Signed-off-by: David Lamparter <equinox@diac24.net>
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This code just ensures that v4 and v6 routes are as expected
in the rib. While this test addition is not that complicated it would
have caught some issues while I was attempting to handle the
switchover to a different style of rib processing.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
C++ doesn't have ISO C11 stdatomic.h or "_Atomic inttype", so use
std::atomic instead to get the headers compatible.
Signed-off-by: David Lamparter <equinox@diac24.net>
Add a no-op conversion constructor to tell C++ that union prefixptr
accepts any of its member types.
Signed-off-by: David Lamparter <equinox@diac24.net>
To align with the change to avoid the keyword 'delete', rename
the isis northbound handlers to '_destroy'.
Signed-off-by: Mark Stapp <mjstapp@gmail.com>
Change the northbound lib operation from DELETE to DESTROY;
make the required changes in the users of the northbound, in
the cli, rip, ripng, and isis.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Some misc changes to resolve some c++ compilation errors.
The goal is only to permit an external module - a plugin,
for example - to see frr headers, not to support or encourage
contributions in c++. The changes include: avoiding use
of keywords like 'new', 'delete'; cleaning up implicit
type-casting from 'void *' in several places.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
there are some cases where the bgp deletion will not be complete, while
the vrf identifier of the bgp instance is not completely identified. The
vrf search based on the bgp name is the better protection, since the bgp
vrf instance is created, even if the vrf identifier is not yet known.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
on interface search algorithm, at initialisation, when reading config
file, the vrf backend may not be yet known ( because zebra did not sync
yet with daemon). For that, avoid searching interface name in a separate
vrf. This change of behaviour is induced because the assumption is done
that at config startup, the user is not wrong with the interface
configuration to use. Every usage of vrf_get_backend() should then be
wisely adapted in order to handle that init state.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
other daemons need to sync with zebra to get to know which vrf backend
is available. in that time, there may be interface configuration
available. in that specific case, the vrf backend returned is not known.
A specific return value is sent back. This will be useful to know which
specific algorithm to apply.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
On interface down do not delete the eigrp interface data
structure. Ensure that the address that we have setup the
eigrp data structure ontop of is what we are deleting.
Additionally add a test to show that this is no-longer
crashing eigrp. Future commits will further modify
this test to actually ensure that the eigrp topo is
updated correctly and the rib has the correct data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The ref count for the eigrp topology table was incorrect in a couple
of spots. Let's clean it up.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The prefix data structure was being freed yet still needed in the
future and it's a fundamental part of the eigrp_interface data
structure let's keep it there instead of having it be deleted
and then not.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we schedule a packet for future handling, list the packet
type so that we can see what we are getting with debugs.
Also note which client and how many packets we received from that
client.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Issue: Configure "ip pim rp x.x.x.x 225.0.0.0/4".
Show running config shows "ip pim rp x.x.x.x 224.0.0.0/4"
This is mis-leading.
Root-cause: Internally 225.0.0.0/4 is getting converted to
224.0.0.0/4 group mask, since the prefix length is 4.
Fix: Restrict the user to configure inconsistent group address
mask by throughing a cli error "Inconsistent address and mask".
Signed-off-by: Sarita Patra <saritap@vmware.com>
Issue: Shut the RP interface in the router RP. LHR will get to know
RP becomes not-reachable, so it send a prune towards the RP. On
receiving the prune, RP clear the (*, G) entry, but (S, G) should
not get removed if present.
Now no-shut the RP interface in the router RP. LHR will send a (*, G)
join towards the RP. On receiving join FRR create the (*, G) entry.
Along with this, it also add the interface(join received) in the OIL
of (S, G) and also refresh the (S, G) timer.
Fix: Dont refresh the timer for S, G or (*, G), if the flag for the
channel OIL is PIM_OIF_FLAG_PROTO_ANY.
Signed-off-by: Sarita Patra <saritap@vmware.com>
