Problems reported that if multiple peers have "remove-private-AS
replace-AS" with each other and all are using private asns, the as-path
gets hosed and continues to grow when a prefix is removed. This fix
disallows removing and replacing the private asn if it matches the
peer's ASN so that normal as-path loop prevention will operate correctly.
Ticket: CM-25489
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Problem reported that if "clear bgp swp1" is issued, an error
message is received saying the name or address is malformed. This
was because of a change in bgp_vty.c that removed the storing
and passing of the interface name for this command. Commit that
caused the problem was ac5dec7e88ce2f8cd2943bb61437046718fb34c2.
Ticket: CM-25737
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
community_val_get() returns ntohl(val) which is used in more places like
community_include(), community_add_val(), but community_del_val() is missing
back conversion htonl().
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
Problem reported that when vrf route-leaking between an unnumbered
peer in one vrf to a numbered peer in another vrf, the nexthop
attribute was missing from the update, causing the session to fail.
determined that we needed to expand the mechanism for verifying if
the route has been learned in the other vrf without an ipv4 nexthop.
Ticket: CM-25610
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Issue1: When a vni in-filter eg:"neighbor X.X.X.X route-map RM-VNI-FILTER in"
is configured under evpn address-family, all the received routes are dropped
regardless of whether the route has a matching vni or not.
(Where RM-VNI-FILTER contains "match evpn vni 100")
Issue2: Routes with 2 labels are not filtered correctly
Issue3: This filter should not get applied for MPLS routes. For MPLS routes,
we need route-map to handle a 3rd state besides match/nomatch called: noop.
Fix1: The handler bgp_update() that services the received route ignored the
route's label while deciding whether to filter it or not.
As part of the fix, the handler now uses the label info to make the
decision about whether to filter the route or not.
Fix2: route_match_vni() now tries to match both the labels within the route
Fix3: route_match_vni() should return noop when it encounters an mpls based
route. For this, route_map library should handle this 3rd state: RMAP_NOOP.
Related fix : Extract tunnel type
This fix relies on PR 4314 #4314 to extract the tunnel type from bgp extended
communities. The information about the route's tunnel type (vxlan or mpls)
is needed to apply "match evpn vni xx" rule. This rule is applicable to
vxlan routes, and should exit safely for mpls based evpn routes.
Signed-off-by: Lakshman Krishnamoorthy lkrishnamoor@vmware.com
Introducing a 3rd state for route_map_apply library function: RMAP_NOOP
Traditionally route map MATCH rule apis were designed to return
a binary response, consisting of either RMAP_MATCH or RMAP_NOMATCH.
(Route-map SET rule apis return RMAP_OKAY or RMAP_ERROR).
Depending on this response, the following statemachine decided the
course of action:
State1:
If match cmd returns RMAP_MATCH then, keep existing behaviour.
If routemap type is PERMIT, execute set cmds or call cmds if applicable,
otherwise PERMIT!
Else If routemap type is DENY, we DENYMATCH right away
State2:
If match cmd returns RMAP_NOMATCH, continue on to next route-map. If there
are no other rules or if all the rules return RMAP_NOMATCH, return DENYMATCH
We require a 3rd state because of the following situation:
The issue - what if, the rule api needs to abort or ignore a rule?:
"match evpn vni xx" route-map filter can be applied to incoming routes
regardless of whether the tunnel type is vxlan or mpls.
This rule should be N/A for mpls based evpn route, but applicable to only
vxlan based evpn route.
Also, this rule should be applicable for routes with VNI label only, and
not for routes without labels. For example, type 3 and type 4 EVPN routes
do not have labels, so, this match cmd should let them through.
Today, the filter produces either a match or nomatch response regardless of
whether it is mpls/vxlan, resulting in either permitting or denying the
route.. So an mpls evpn route may get filtered out incorrectly.
Eg: "route-map RM1 permit 10 ; match evpn vni 20" or
"route-map RM2 deny 20 ; match vni 20"
With the introduction of the 3rd state, we can abort this rule check safely.
How? The rules api can now return RMAP_NOOP to indicate
that it encountered an invalid check, and needs to abort just that rule,
but continue with other rules.
As a result we have a 3rd state:
State3:
If match cmd returned RMAP_NOOP
Then, proceed to other route-map, otherwise if there are no more
rules or if all the rules return RMAP_NOOP, then, return RMAP_PERMITMATCH.
Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
For SRGB, we need to support chunk requests starting at a
specific point in the label space, rather than just asking
for any sufficiently large chunk. To this purpose, we extend
the label manager api to request a chunk with a base value;
if the base is set to 0, the label manager will behave as it
currently does, i.e. fetching the first free chunk big enough
to satisfy the request.
update all the existing calls to get chunks from the label
manager so that they use MPLS_LABEL_BASE_ANY as the base
for the requested chunk
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
When using the maximum-prefix restart option with a BGP peer,
if the peer exceeds the limit of prefixes, bgpd causes the
connection to be closed and sets a timer. It will not attempt
to connect to that peer until the timer expires. But if the
peer attempts to connect to it before the timer expires, it
accepts the connection and starts exchanging routes again.
When accepting a connection from a peer, reject the connection
if the max prefix restart timer is set.
Signed-off-by: Matthew Smith <mgsmith@netgate.com>
Some code to cleanup bgp routemap.c a bit.
Addint to this, if a bgp flowspec entry contains a destination IP address,
then the ip address is compared against the prefix-list referenced into
the route-map used.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Donald Sharp <sharpd@cumulunetworks.com>
when multiple action rules are analysed in the BGP flowspec entry, if at
least the traffic-rate set to 0 is seen, then immediately create a rule
with drop rule. Previously this was not the case in case a forwarding
rule was seen.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
in addition to support for tcpflags, it is possible to filter on any
protocol. the filtering can then be based with iptables.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Unlike MRT dumps, BMP also provides packets sent by the router. Add
another hook for that.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The MRT dump code is already hooked in at the right places to write out
packets; the BMP code needs exactly the same access so let's make this
a hook.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Both of these hooks are necessary for proper operation of extensions
that need to latch on to a particular instance.
- without the delete hook, it's impossible to get rid of stale
references, leading to crashes with invalid instance pointers.
- the config-write hook is necessary because per-instance config needs
to be written inside the "router bgp" block to have the appropriate
context; adding a separate config node can't do that.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
BMP uses this to get notified about any changes to prefixes, at which
point it schedules its own processing to happen later.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
These counters are accessible through BMP and may be useful to monitor
bgpd. A CLI to show them could also be added if people are interested.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
last_reset_cause_size is the length *used* in last_reset_cause[]. It's
straight up used wrong here; we're saving off a reset cause and need to
check against the *available* size in last_reset_cause[].
This could actually have led to (hopefully rare) crashes in the assert
there, since the assert condition might fail incorrectly.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
bgp update messages were not correctly calculating the size
for a labeled-unicast prefix, as they were not accounting
for the label. If the update message was large enough to
overflow the maximum packet size (4096 bytes) this could
cause bgpd to send a malformed update packet.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
not getting displayed.
Neighbour prefix-count is not getting displayed with IPV6 neighbours
and displays the o/p “ % No such neighbor or address family ”.
However, I observed it is working fine for IPV4 neighbour.
Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
The `no redistribute ...` commands were not allowing
the input to be in any order. Fix code to allow this.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
under some conditions, the callback to get a label for
a LU bgp path could be called after the path had already
been freed. In this case we would be reading garbage
and potentially crash. Lock the path info before
queueing the callback, and unlock as the first step
of the callback, exiting gracefully if the path info
is now NULL.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
EVPN route's extended community include
important informations like Mobility sequence,
router mac, and RT values, include the ecomm
in evpn brief output.
Ticket:CM-25353
Testing Done:
Validated in evpn deployment with routes.
TOR#show bgp l2vpn evpn route
...
Network Next Hop Metric LocPrf Weight Path
Extended Community
Route Distinguisher: 27.0.0.11:3
*> [2]:[0]:[0]:[48]:[00:02:00:00:00:04]:[128]:[fe80::202:ff:fe00:4]
36.0.0.11 0 4435 5546 i
RT:5546:1008 ET:8 ND:Router Flag
* [2]:[0]:[0]:[48]:[00:02:00:00:00:36]
36.0.0.11 0 4435 5546 i
RT:5546:1008 RT:5546:4003 ET:8 MM:0, sticky MAC Rmac:44:38:39:ff:ff:01
*> [2]:[0]:[0]:[48]:[00:02:00:00:00:36]
36.0.0.11 0 4435 5546 i
RT:5546:1008 RT:5546:4003 ET:8 MM:0, sticky MAC Rmac:44:38:39:ff:ff:01
* [3]:[0]:[32]:[36.0.0.11]
36.0.0.11 0 4435 5546 i
RT:5546:1008 ET:8
*> [3]:[0]:[32]:[36.0.0.11]
36.0.0.11 0 4435 5546 i
RT:5546:1008 ET:8
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
When we are issuing a new command:
router bgp
bgp default local-preference ..
-or-
bgp cluster-id ...
-or-
bgp disable-ebgp-connected-route-check
Do not tell them that afi/safi's are not configured. There is nothing
to do with this information and it will create confusion in the
end user that we are looking for afi/safi's that are never going to
be configed.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The `neighbor X:X::X default-originate command is complaining
that:
The route-map '(null)' does not exist.
Upon inspection of the code we were passing a NULL
string to the lookup. Testing for null gets us this:
donna.cumulusnetworks.com# conf t
donna.cumulusnetworks.com(config)# router bgp 99
donna.cumulusnetworks.com(config-router)# neighbor 2001:1::1:2 remote-as 99
donna.cumulusnetworks.com(config-router)# neighbor 2001:1::1:2 default-originate
donna.cumulusnetworks.com(config-router)# end
donna.cumulusnetworks.com# show run
Building configuration...
Current configuration:
!
frr version 7.2-dev
frr defaults datacenter
hostname donna.cumulusnetworks.com
log stdout
no ipv6 forwarding
!
ip route 4.5.6.7/32 10.50.11.4
!
router bgp 99
neighbor 2001:1::1:2 remote-as 99
!
address-family ipv4 unicast
neighbor 2001:1::1:2 default-originate
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
FRR has a provision to give exact-match in match clause for
standard community, but this option is missing for lcommunity.
Part 3 : show related changes for match clause
Signed-off-by: vishaldhingra <vdhingra@vmware.com>
FRR has a provision to give exact-match in match clause for
standard community, but this option is missing for lcommunity.
Part 2 : CLI related changes for match clause
Signed-off-by: vishaldhingra <vdhingra@vmware.com>
FRR has a provision to give exact-match in match clause for
standard community, but this option is missing for lcommunity.
Part 1 : Added support in clist lib
Signed-off-by: vishaldhingra <vdhingra@vmware.com>
The `bgp multiple-instance` command has been removed but
we did not properly update the documentation. Let's do so.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This code is not returned anywhere in the system as that bgp
is by default multiple-instance 'only' now. So remove
the last remaining bits of it from the code base.
Remove BGP_ERR_MULTIPLE_INSTANCE_USED too.
Make bgp_get explicitly return BGP_SUCCESS
instead of 0.
Remove the multi-instance error code too.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There exists a state where we may have a rd node but no individual
evpn prefix nodes in the two level table:
(gdb) bt
at bgpd/bgp_evpn_vty.c:1190
filter=FILTER_RELAXED) at lib/command.c:1060
at lib/command.c:1119
vtysh=vtysh@entry=0) at lib/command.c:1273
(gdb) f 5
at bgpd/bgp_evpn_vty.c:1190
1190 bgpd/bgp_evpn_vty.c: No such file or directory.
(gdb) p buf
$1 = "[2]:[0]:[48]:[00:00:00:00:00:00]", '\000' <repeats 240 times>...
(gdb) p json_nroute
$2 = (json_object *) 0x0
(gdb) p rd_header
$3 = 1
(gdb) p buf
$4 = "[2]:[0]:[48]:[00:00:00:00:00:00]", '\000' <repeats 240 times>...
(gdb)
I'm not entirely sure that this is not a `different` problem in that the
rd node should have been removed. But I think preventing the crash
in a show command is probably the right thing to do here.
Fixes: #4501
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
On interface up/down, bgp stores the mac address of the interface
in a bgp_mac_hash table entry and then initiates a rescan
of the evpn l2vpn table. The problem with this scan is that
it is looking at every item in the table when only 1 mac
has changed. So every up/down event causes some major trauma
in the bgp_update processing.
Modify the mac scanning such that we know the mac that is changed
and as such we should reprocess those entries only.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
If we get a callback for a interface change but we do not
actually have to move the mac entry in the hash then
we were accidently leaking the Mac Hash String all over
ourselves. Messy Messy!
Ticket: CM-25351
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When a source bgp vrf instance is deleted, ensure the referencing
of it in vrf route leak show commands.
Ticket:CM-20534 CM-24484
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
two bgp vrf instance has vrf route leak configured,
when a source vrf x is deleted, its leaked routes are cleaned
up from the destination and vpn table.
With this change when a source bgp instance is reconfigured,
export its routes back to destination vrfs where it is configured
as leak.
Ticket:CM-20534 CM-24484
Reviewed By:
Testing Done:
configure vrf leak between two vrf intances,
delete and readd source vrf and checked its routes
exported to vpn table and leaked vrfs table.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
A VRF leak is configured between two vrfs,
bgp VRF X and VRF Y.
When a bgp VRF X is removed, unimport bgp VRF X routes
from VPN and VRF Y.
If VRF X is also importing from bgp VRF Y, remove X from
export list of Y and do required route cleanup.
Ticket:CM-20534 CM-24484
Reviewed By:
Testing Done:
Before deleteing vrf1002:
nl1# show ip route vrf vrf1003 9.9.2.4/32
Routing entry for 9.9.2.4/32
Known via "bgp", distance 200, metric 0, vrf vrf1003, best
Last update 00:04:51 ago
* 200.2.8.2, via swp1.2(vrf vrf1002)
* 200.2.9.2, via swp2.2(vrf vrf1002)
* 200.2.10.2, via swp3.2(vrf vrf1002)
Instance vrf1003:
This VRF is importing IPv4 Unicast routes from the following VRFs:
vrf1002
Import RT(s): 6.0.2.9:2
This VRF is exporting IPv4 Unicast routes to the following VRFs:
vrf1002
RD: 6.0.3.9:3
Export RT: 6.0.3.9:3
After deleting vrf1002:
nl1(config)# no router bgp 64902 vrf vrf1002
nl1# show ip route vrf vrf1003 9.9.2.4/32
Routing entry for 9.9.2.4/32
Known via "bgp", distance 20, metric 0, vrf vrf1003, best
Last update 00:00:32 ago
* 200.3.8.2, via swp1.3
* 200.3.9.2, via swp2.3
* 200.3.10.2, via swp3.3
Instance vrf1003:
This VRF is importing IPv4 Unicast routes from the following VRFs:
vrf1002
Import RT(s):
This VRF is not exporting IPv4 Unicast routes to any other VRF
nl1# show bgp ipv4 vpn
No BGP prefixes displayed, 0 exist
Readd vrf1002:
points back to source vrf
nl1# show ip route vrf vrf1003 9.9.2.4/32
Routing entry for 9.9.2.4/32
Known via "bgp", distance 200, metric 0, vrf vrf1003, best
Last update 00:00:21 ago
* 200.2.8.2, via swp1.2(vrf vrf1002)
* 200.2.9.2, via swp2.2(vrf vrf1002)
* 200.2.10.2, via swp3.2(vrf vrf1002)
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
FRR has no option for the as-set for aggregate route
under IPV6 address family. Added the command to
configure the as-set option for IPV6.
Signed-off-by: vishaldhingra <vdhingra@vmware.com>
show bgp vrfs command is formatted with couple
of things.
show bgp vrfs to inclue bgp vrf instance's
SVI interface.
Move L3vni, RMAC and SVI value in next line.
Ticket:CM-25317
Reviewed By:CCR-8816
Testing Done:
New Output:
TORS1# show bgp vrfs
Type Id routerId #PeersVfg #PeersEstb Name
L3-VNI RouterMAC Interface
DFLT 0 27.0.0.15 2 2 default
0 00:00:00:00:00:00 unknown
VRF 31 45.0.8.2 0 0 vrf3
4003 00:02:00:00:00:4e vlan4003
VRF 35 45.0.2.2 0 0 vrf1
4001 00:02:00:00:00:4e vlan4001
VRF 25 45.0.6.2 0 0 vrf2
4002 00:02:00:00:00:4e vlan4002
Total number of VRFs (including default): 4
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
notify_data_remote_as4 would contain garbage if optlen == 0, and also
as4 is in host byte order while the notify needs network byte order.
Signed-off-by: David Lamparter <equinox@diac24.net>
This is mostly relevant for Solaris, where config.h sets up some #define
that affect overall header behaviour, so it needs to be before anything
else.
Signed-off-by: David Lamparter <equinox@diac24.net>
Skip evpn routes marked for removed from rescan list
when an interface is flapped.
Ticket:CM-24933
Testing Done:
Validated in a scenario where evpn route is marked
for remove as bgp evpn withdrawal is received. Due to
link flap (frr restart of downstream router), the route
was considered for readd via bgp_update. With this
fix, the remove marked routes are skipped from update.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
A router-id change that isn't explicitly configured (a change
from zebra, for example) should not replace a configured vpn
RD/RT.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Field vrf_id is replaced by the pointer of the struct vrf *.
For that all other code referencing to (interface)->vrf_id is replaced.
This work should not change the behaviour.
It is just a continuation work toward having an interface API handling
vrf pointer only.
some new generic functions are created in vrf:
vrf_to_id, vrf_to_name,
a zebra function is also created:
zvrf_info_lookup
an ospf function is also created:
ospf_lookup_by_vrf
it is to be noted that now that interface has a vrf pointer, some more
optimisations could be thought through all the rest of the code. as
example, many structure store the vrf_id. those structures could get
the exact vrf structure if inherited from an interface vrf context.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
vrf_id parameter is replaced with struct vrf * parameter. It is
needed to create vrf structure before entering in the fuction.
an error is generated in case the vrf parameter is missing.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
the vrf_id parameter is replaced by struct vrf * parameter.
this impacts most of the daemons that look for an interface based on the
name and the vrf identifier.
Also, it fixes 2 lookup calls in zebra and sharpd, where the vrf_id was
ignored until now.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Issue:
ip route 15.1.1.0/24 10.112.158.15
ip route 15.1.1.0/32 10.112.158.15
Brought up ebgp session between two FRR routers and
redistributed static routes via BGP and verfied the advertising
routes in the peer.
Verify the command "show ip bgp neighbors <neighbor address>
advertised-routes json". It only shows 15.1.1.0/32 route details.
Root casue:
For both the routes "15.1.1.0/24" and "15.1.1.0/32" the advertised
routes key is the prefix i.e. "15.1.1.0".
Fix:
Modify the key to prefix/prefix-length.
Signed-off-by: Sarita Patra <saritap@vmware.com>
* When the bgp is being deleted and routes are in clear workqueue
and new aggregate address being allocated
* Added flag BGP_FLAG_DELETE_IN_PROGRESS in bgp structure to
bgp instance is being deleted
* When adding aggregate route check this flag and peer_self is valid
Signed-off-by: Soman K S <somanks@vmware.com>
Problem reported with "clear bgp l2vpn evpn * soft" clearing the
wrong afi/safi (cleared ipv6 unicast instead). Determined that
the calling function used the argv_find_and_parse_afi/safi routines
to determine the correct afi/safi to pass on. Since l2vpn/evpn were
missing from the lookup, the command defaulted to ipv6 unicast. This
fix just adds that afi/safi to the lookup routine.
Ticket: CM-25167
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
The BGP_OPT_CONFIG_CISCO command could no longer be set
as such remove it from the system as a viable option to
be used.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Since we no-longer allow you to select multiple-instance
or not from the cli, let's completely remove the flag
as well.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The iana_afi_t and iana_safi_t were being created in zebra.h
and zebra.h is a bit of a dumping ground. When the iana_afi2str and
iana_safi2str functions were created, it was correctly pointed out
that we should just use the internal afi_t and safi_t 2str functions
but to do that we would need to include prefix.h in zebra.h. Which
really is not the right thing to do. This tells us that we need
to break out this code into it's own header.
Move to iana_afi.h the enums and specific functions and remove
from zebra. Convert to using the afi2str and safi2str functions.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Modify the code such that we can auto turn the iana values of afi
and safi to pleasant to read strings.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Issue1: When "neighbor X.X.X.X route-map RM-VNI-FILTER in" is configured under evpn address-family,
all the received routes are dropped regardless of whether the route has a matching vni or not.
Issue2: Routes with 2 labels are not filtered correctly
Issue3: Interpreting the label based on tunnel type, vxlan was not done correctly.
Vxlan label has 24 bits, whereas, MPLS label is 20 bits long
Fix1: The handler bgp_update() that services the received route ignored the route's label while deciding whether to filter it or not. As part of the fix, the handler now uses the label info to make the decision about whether to filter the route or not.
Fix2: route_match_vni() now tries to match both the labels within the route, not just the one.
Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
Say, more than one sequence of a route-map uses the same named entity
in its match clause. After that entity is removed from any one of the
route-map sequences, any further changes made to that entity doesn't
dynamically take effect.
A reference counter, that allows the named entity to keep a count of
the route-maps dependent on it, has been introduced to address this issue.
Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
Set the bgp default nexthop value of IPv6 to the local ipv6 addr of the
tcp connection like IPv4. Fixed the problem of route with empty nexthop
advertised to the peer when zebra is not running.
* bgp_zebra.c: (bgp_zebra_nexthop_set) Set IPv6 bgp default nexthop value.
Signed-off-by: Faicker Mo <faicker.mo@ucloud.cn>
Introducing a 3rd state for route_map_apply library function: RMAP_NOOP
Traditionally route map MATCH rule apis were designed to return
a binary response, consisting of either RMAP_MATCH or RMAP_NOMATCH.
(Route-map SET rule apis return RMAP_OKAY or RMAP_ERROR).
Depending on this response, the following statemachine decided the
course of action:
Action: Apply route-map match and return the result (RMAP_MATCH/RMAP_NOMATCH)
State1: Receveived RMAP_MATCH
THEN: If Routemap type is PERMIT, execute other rules if applicable,
otherwise we PERMIT!
Else: If Routemap type is DENY, we DENYMATCH right away
State2: Received RMAP_NOMATCH, continue on to next route-map, otherwise,
return DENYMATCH by default if nothing matched.
With reference to PR 4078 (https://github.com/FRRouting/frr/pull/4078),
we require a 3rd state because of the following situation:
The issue - what if, the rule api needs to abort or ignore a rule?:
"match evpn vni xx" route-map filter can be applied to incoming routes
regardless of whether the tunnel type is vxlan or mpls.
This rule should be N/A for mpls based evpn route, but applicable to only
vxlan based evpn route.
Today, the filter produces either a match or nomatch response regardless of
whether it is mpls/vxlan, resulting in either permitting or denying the
route.. So an mpls evpn route may get filtered out incorrectly.
Eg: "route-map RM1 permit 10 ; match evpn vni 20" or
"route-map RM2 deny 20 ; match vni 20"
With the introduction of the 3rd state, we can abort this rule check safely.
How? The rules api can now return RMAP_NOOP (or another enum) to indicate
that it encountered an invalid check, and needs to abort just that rule,
but continue with other rules.
Question: Do we repurpose an existing enum RMAP_OKAY or RMAP_ERROR
as the 3rd state (or create a new enum like RMAP_NOOP)?
RMAP_OKAY and RMAP_ERROR are used to return the result of set cmd.
We chose to go with RMAP_NOOP (but open to ideas),
as a way to bypass the rmap filter
As a result we have a 3rd state:
State3: Received RMAP_NOOP
Then, proceed to other route-map, otherwise return RMAP_PERMITMATCH by default.
Signed-off-by:Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
Inconsistent use of a string pointer led to improperly terminated
strings (terminated too soon)
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
When debugging I was having a hard time correlating some data and noticed that
a particular debug was not being very useful.
Signed-off-by: Donald Sharp <sharpd@cumulusnstworks.com>
Was getting a couple of compile errors with newer compilers
when compiling rpki around the prefix length. Convert
them over to prefix2str as that is all it is doing.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The SO_MARK socket option was being used pre vrf to allow for the
separation of the front panel -vs- the management port. This
was facilitated by a ip rule. Since this is undocumented anywhere
in our system( other than old commits see
ed40466af8 ). We should remove this
because this will cause interference with people using rules
and are not aware of this offshoot of functionality.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When issuing a `show bgp neighbor...` command display to the
end user the FD used for communication.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The functions nexthop_same() does not check the resolved
nexthops so I don't think this function is even needed
anymore.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Problem reported with deleting the default BGP instance where there
are vrf instances that depend on it (like l2vpn evpn vrfs). Since
importing for vrf route-leaking also requires the existence of the
default instance, disallowing deleting the BGP default instance if
anyt vrf instance is also defined.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
We already show this information in `show [ip] bgp <prefix`, thus why don't
show it in global output. It's very handy when using at scale and to see
the whole picture instead of resolving neighbor manually.
It will show FQDN only if `bgp default show-hostname` is toggled.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
I mistakenly assumed that something called "FIFO" would primarily be
used by removing items from the front. This isn't the case for the
adv_fifo... so use a DLIST there to make sure deletions from the middle
of the queue are fast.
Signed-off-by: David Lamparter <equinox@diac24.net>
updgrp_hash_key_make() uses the PEER_UPDGRP_AF_FLAGS for the key.
PEER_UPDGRP_AF_FLAGS contains the neigbor flags.
If user do no neighbor <> send community large, then the hash key
does not change and BGP does not send update for large community change.
Added the PEER_FLAG_SEND_LARGE_COMMUNITY in PEER_UPDGRP_AF_FLAGS.
After this the hash key gets changed and update will be processed
with large community.
Signed-off-by: vishaldhingra<vdhingra@vmware.com>
The flag PEER_FLAG_RSERVER_CLIENT is never set on peer->flags
and as such testing the flag for not being set will never
cause the if statement to be not entered.
Conversely setting update to 0 and then testing if (update && ...
will always cause another if statement to be never called, remove
it as well.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
As part of detailed bgp route detail, include the
reason why a route was selected as best path.
robot# show bgp ipv4 uni 223.255.254.0
BGP routing table entry for 223.255.254.0/24
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
annie(192.168.201.136)
64539 15096 6939 7473 3758 55415
192.168.201.136 from annie(192.168.201.136) (192.168.201.136)
Origin IGP, valid, external, bestpath-from-AS 64539, best (First path received)
Last update: Wed May 15 21:15:48 2019
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Store in bgp_node the reason why we choose a particular
best path over another. At this point we do not do
anything other than just store this data when we make
the decision. Future commits will display it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Instead of just passing in the prefix, pass in the particular
bgp_node we are using.
This is setup for a future commit to use this data.
The long term goal is to collect data about why
a particular bgp_path_info was selected as best and
to display that reason.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The bgp_attr_extcom_tunnel_type does not properly
compile with warnings turned on due to recent change.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
It doesn't make much sense for a hash function to modify its argument,
so const the hash input.
BGP does it in a couple places, those cast away the const. Not great but
not any worse than it was.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This diff contains 2 parts:
1. Extract the tunnel type info from bgp extended communities.
2. Make rfapi use this common tunnel type ap
Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
Add an upspecified option to the AFI enum and update
switch statements using it in bgpd and pbrd.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Issue 1:
Getting an empty json without any warning message, while executing
the command "show ip bgp neighbor <x.x.x.x> advertised-routes
json" when the bgp instance is not present or getting created.
Issue 2:
Getting an empty json without any warning message, while executing
the command "show ip bgp vrf/view <name> advertised-routes json"
when the specified view/vrf is not present.
Fix:
Display warning message while executing the above cli commands, when
the bgp instance, specified vrf is not present.
Signed-off-by: Sarita Patra <saritap@vmware.com>
This commit fixes a previous commit:
"bfdd: remove operational bfd sessions from remote daemons"
where the handling of unregister call triggers the deletion of bfd
session.
Actually, the BFD session should not be deleted, while bgp session is
configured with BGP. this permits to receive BFD events up, and permit
quicker reconnecion.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
new vty command is added:
neighbor XXX bfd check-control-plane-failure
this command will enforce the check of bgp controlplane, when bfd
detects changes in the dataplane.
- at configuration, the cbit will be set if that command is executed
- at flapping time, if the command is configured and remote cbit is set
accordingly, then the bfd event will be ignored.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
bfd cbit is a value carried out in bfd messages, that permit to keep or
not, the independence between control plane and dataplane. In other
words, while most of the cases plan to flush entries, when bfd goes
down, there are some cases where that bfd event should be ignored. this
is the case with non stop forwarding mechanisms where entries may be
kept. this is the case for BGP, when graceful restart capability is
used. If BFD event down happens, and bgp is in graceful restart mode, it
is wished to ignore the BFD event while waiting for the remote router to
restart.
The changes take into account the following:
- add a config flag across zebra layer so that daemon can set or not the
cbit capability.
- ability for daemons to read the remote bfd capability associated to a bfd
notification.
- in bfdd, according to the value, the cbit value is set
- in bfdd, the received value is retrived and stored in the bfd session
context.
- by default, the local cbit announced to remote is set to 1 while
preservation of the local path is not set.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Bug: If there are 2 different prefixes under an rd, the
output of "show bgp l2vpn evpn json" would print only one of the
prefixes.
RCA: prefix info was added to the json_object once per rd. Hence,
prefix and rd were added just once, as the loop iterated over all
the prefixes and paths.
This is related to my earlier commit that went in via PR 4283:
https://github.com/FRRouting/frr/pull/4283
Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
The route_map_event_hook callback was passing the `route_map_event_t`
to each individual interested party. No-one is ever using this data
so let's cut to the chase a bit and remove the pass through of data.
This is considered ok in that the routemap.c code came this way
originally and after 15+ years no-one is using this functionality.
Nor do I see any `easy` way to do anything useful with this data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Display a debug message while sending a BGP route if the route is filtered by a
route-map.
Debug for incoming filtered route is already present.
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
This is causing interop issues with vendors. According to the RFC,
receiver should ignore the NEXT_HOP attribute with MP_REACH_NLRI
present.
Signed-off-by: nikos <ntriantafillis@gmail.com>
Each of Lua's major versions are incompatible with each other. Ubuntu,
at least, does not provide a single liblua.so or /usr/include/lua; all
SOs and headers are versioned, e.g. liblua5.3.so and
/usr/include/lua5.3. There's already an m4 macro in the GNU collection
to handle this situation, so let's use that.
This allows building with Lua enabled to work on platforms other than
Fedora.
* Move lib/lua.[ch] -> lib/frrlua.[ch] to prevent path conflicts
* Fix configure.ac search for proper CPP and linker flags
* Add Lua include path to AM_CPPFLAGS
* Update vtysh/extract.pl.in
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This fix aims to reduce the load on BGPD when certain
exisiting configurations are replayed.
Specifically, the fix prevents BGPD from processing
routes when the following already existing configurations
are replayed:
1) A match criteria is configured within a route-map.
2) When "call" is invoked within a route-map.
3) When a route-map is tied to a BGP neighbor.
Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
lcommunity_list_show uses the wrong macro to calculate the style.
Use the correct one LARGE_COMMUNITY_LIST_STANDARD.
Signed-off-by: vishaldhingra<vdhingra@vmware.com>
vrf_id parameter is added to the api of bfd_client_sendmsg().
this permits being registered to bfd from a separate vrf.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
lcomm-list is configured and attached to route-map via match clause.
If you modify the lcomm-list then it is not taking into effect via routemap.
Signed-off-by: vishaldhingra <vdhingra@vmware.com>
This is causing interop issues with vendors. According to the RFC,
receiver should ignore the NEXT_HOP attribute with MP_REACH_NLRI
present.
Signed-off-by: nikos ntriantafillis@gmail.com
This macro:
- Marks ZAPI callbacks for readability
- Standardizes argument names
- Makes it simple to add ZAPI arguments in the future
- Ensures proper types
- Looks better
- Shortens function declarations
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
The vpn variable in bgp_evpn_advertise_svi_ip_vni must
be non-null as such it is impossible to ever need the
!vpn test case.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The label value is set to MPLS_LABEL_NONE at the start
of the function and we never modify it, testing it for
BGP_PREVENT_VRF_2_VRF_LEAK equality will never be true
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Again, the FIFO_* stuff in lib/fifo.h is no different from a simple
unsorted list. Just use DECLARE_LIST here so we can get rid of FIFO_*.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The FIFO_* stuff in lib/fifo.h is no different from a simple unsorted
list. Just use DECLARE_LIST here so we can get rid of FIFO_*.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Prevent the ebgp sender from changing the nexthop( which is same as the ebgp neighbour ipv6 address),
while sending updates to its ipv6 neighbor.So,if the nexthop of the ipv6 route is same as the ipv6
neighbour address do not change the next hop to your own ip.
Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
Prevent IPv6 routes received via a ibgp session with one of its own interface
ip as nexthop from getting installed in the BGP table.
Implemented IPV6 HASH table, where we need to add any ipv6 address as they
gets configured and delete them from the HASH table as the ipv6 addresses
get unconfigured. The above hash table is used to verify if any route learned
via BGP has nexthop which is equal to one of its its connected ipv6 interface.
Signed-off-by: Biswajit Sadhu sadhub@vmware.com
The l2vni (bgpevpn instance) was maintaining a back pointer to the
tenant vrf without locking it. This would result in bgp_terminate crashing
as the tenant-vrf is released before the underlay-vrf (vpn->bgp_vrf->l2vnis
is NULL). Call stack -
BGP: [bt 3] /lib/libfrr.so.0(listnode_delete+0x11) [0x7f041c967f51]
BGP: [bt 4] /usr/lib/frr/bgpd(bgp_evpn_free+0x26) [0x55e3428eea46]
BGP: [bt 5] /lib/libfrr.so.0(hash_iterate+0x4a) [0x7f041c95f00a]
BGP: [bt 6] /usr/lib/frr/bgpd(bgp_evpn_cleanup+0x22) [0x55e3428f0a72]
BGP: [bt 7] /usr/lib/frr/bgpd(bgp_free+0x180) [0x55e342955f50]
PIM: vxlan SG (*,239.1.1.111) term mroute-up del
BGP: [bt 8] /usr/lib/frr/bgpd(bgp_delete+0x43a) [0x55e342959d7a]
BGP: [bt 9] /usr/lib/frr/bgpd(sigint+0xee) [0x55e3428d6a5e]
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Vivek Venkataraman <vivek@cumulusnetworks.com>
Reviewed-by: Chirag Shah <chirag@cumulusnetworks.com>
IMET/type-3 routes are used by VTEPs to advertise the flood mode for BUM
traffic via the PMSI tunnel attribute. If a type-3 route is not rxed from
a remote-VTEP we default to "no-head-end-rep" for that remote-VTEP. In such
cases static-config such as PIM is likely used for BUM flooding.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
IMET route is optional if the flood mode is PIM-SM and serves
no functional purpose. So this change limits type-3 route generation
to flood-mode=head-end-replication.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
If PIM-SM if used for BUM flooding the multicast group address can be
configured per-vxlan-device. BGP receives this config from zebra via
the L2 VNI add/update.
Sample output -
root@TORS1:~# vtysh -c "show bgp l2vpn evpn vni 1000" |grep Mcast
Mcast group: 239.1.1.100
root@TORS1:~#
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
EVPN routes (type-2/type-5) are imported from
default bgp instance (where they are learnt) to
non-default vrf instance.
When a bgp instance (default) is deleted,
unimport evpn routes from vrfs.
In absence of unimport, the imported routes in vrf
has parent path info points to default instance's path
info which is no longer valid (if instance is deleted).
When accessing parent path info leads to a crash
in non-default vrf instance.
The bgp instance is not cleaned up when
'no router bgp ASN' is performed, the instance's
reference count remains for evpn imported routes.
Ticket:CM-24484
Reviewed By:
Testing Done:
Validated via learning EVPN type-2/type-5 routes in symmetric
routing scenario.
The routes are imported to VRFs based on corresponding
L3VNI. When the default instance is removed, the evpn routes
are cleaned up from the VRF instance.
TURTLE(config)# do show bgp vrf vrf3 ipv4 unicast
Network Next Hop Metric LocPrf Weight Path
*> 70.1.0.0/16 0.0.0.0 32768 i
s 70.1.1.24/32 110.0.0.2 0 65100 65002 i
s> 110.0.0.2 0 65100 65002 i
s 70.1.1.43/32 110.0.0.4 0 65100 65004 i
s> 110.0.0.4 0 65100 65004 i
TURTLE(config)# no router bgp 65050
TURTLE(config)# do show bgp vrf vrf3 ipv4 unicast
No BGP prefixes displayed, 0 exist
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
if bfd comes back up, and a bgp reconnection is in progress, theorically
it should be necessary to wait for the end of the reconnection process.
however, since that reconnection process may take some time, update the
fsm by cancelling the connect timer. This done, one just have to call
the start timer.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Bgp periodically tries to reconnect, while the connection
is down. When bfd event comes up, BGP is not aware that bfd connection
is up, then BGP can not adapt its reconnection timer. The modification
is here to force BGP to restart, when BFD event comes up, and BGP has
not yet established.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Co-authored-by: Donald Sharp <sharpd@cumulusnetworks.com>
Co-authored-by: Quentin Young <qlyoung@cumulusnetworks.com>
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This command is added to provide detailed information. It will be
useful in troubleshooting as we will be able to dump all detailed info
using a single command.
"show bgp l2vpn evpn route [detail] ...". Additional filtering
can be done by providing type of the route.
Command will display the detailed content for all rd and macs-ip as
displayed by "show bgp l2vpn evpn route rd <> mac <>" for a single
rd, mac, ip from the global bgp routing table.
Ticket: CM-24397
Signed-off-by: Nitin Soni <nsoni@cumulusnetworks.com>
Reviewed-by:
Testing-Done:
This command is added to provide detailed information. It will be
useful in troubleshooting as we will be able to dump all detailed info
using a single command.
"net show bgp evpn route vni <all|id> [detail]". Additional filtering
can be done by providing vtep ip.
Command will display the detailed content for all vni and macs as
displayed by "net show bgp evpn route vni <> mac <> ip <>" for a single
vni, mac, ip.
Ticket: CM-24397
Signed-off-by: Nitin Soni <nsoni@cumulusnetworks.com>
Reviewed-by:
Testing-Done:
The bgp_path_info_new function whenever it was called
pretty much duplicated the info_make function call. So
convert over to using it and remove the bgp_path_info_new
function so people are not tempted.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The creation of a new `struct bgp_path_info` requires a legitimate
peer being passed in for creation. There exists no code paths
where this is not true. As such checking pi->peer for null convinces
SA that it might happen.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Move &rpki_cmd from VIEW to ENABLE. A non-enabled session could
enter into the rpki command node and exit into glocalb config mode
without having to enable.
Move &show_rpki* from ENABLE to VIEW. Allow non-enabled user to
view cache state and prefix table state.
Signed-off-by: David Teach <dteach@routeviews.org>
Avoid tracking 0.0.0.0/32 nexthop with RIB.
When routes are aggregated,
the originate of the route becomes self.
Do not track nexthop self (0.0.0.0) with rib.
Ticket: CM-24248
Testing Done:
Before fix-
tor-11# show ip nht vrf all
VRF blue:
0.0.0.0
unresolved
Client list: bgp(fd 16)
VRF default:
VRF green:
VRF magenta:
0.0.0.0
unresolved
Client list: bgp(fd 16)
After fix-
tor-11# show ip nht vrf all
VRF blue:
VRF default:
VRF green:
VRF magenta:
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
In order to iterate over MPLS VPN routes, it's necessary to use
two nested loops (the outer loop iterates over the MPLS VPN RDs,
and the inner loop iterates over the VPN routes from that RD).
The bgp_table_stats_walker() function wasn't giving this special
treatment to the MPLS VPN safi as it should, which was leading to
crashes and malfunctioning. Fix this.
Signed-off-by: Renato Westphal <renatowestphal@gmail.com>
pinum (renamed from rinum) was never used for anything useful since
the initial revision ~17 years ago. Get rid of it.
Signed-off-by: Renato Westphal <renatowestphal@gmail.com>
force allocation of entries in order to save memory and then save memory
for people that do not use flowspec.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
while labeled_unicast routes should be fetched in the
unicast table, we cannot set the safi to SAFI_UNICAST
else the peer afc checks and subgroup retrieval will fail
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
bgp entries in bgp_extra_path structure will be allocated as lists, only
when needed, that is to say when bgp fs entries will be received and
installed on the underlying system.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When using remove-private-AS together with local-as
aspath_remove_private_asns() is called before bgp_packet_attribute().
In this case, private AS will always appear in front of change_local_as.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
Currently, as part of bgp clear soft inboud and outbound we don't handle
l2vpn evpn. Now clearing soft for all supported afi safi.
One of the examples where this was a problem -
On applying graceful-shutdown, bgp clear soft inboud and outbound don't
handle AFI L2VPN and SAFI EVPN. Gshut gets applied to EVPN Type 5 routes
by asking peer to refresh the routes (provided we have config - "advertise
ipv4/ipv6 unicast" as part of l2vpn evpn) but is not applied to type 2
and type 3 EVP routes. This fix takes care of l2vpn evpn type2 and type3
routes being readvertised with gshut community.
This fix also fixes similar issues related to following where bgp clear
soft is requred for l2vpn evpn -
-config bgp cluster-id
-config bgp client-to-client reflection
-config bgp default local-preference
-config bgp route-reflector allow-outbound-policy
-config bgp disable-ebgp-connected-route-check
Ticket: CM-22813
Signed-off-by: Nitin Soni <nsoni@cumulusnetworks.com>
Reviewed-by: CCR-8361
Testing-Done:
-With gshut configured on all BGP VRFs (operator has to know about the
auto-created BGP VRFs - we do show them in show commands - and turn on
graceful-shutdown in all of them.
-We announce all EVPN routes (type-2, type-3 and type-5) with GSHUT and
we mark IPv4/IPv6 routes in a VRF that are based on received EVPN type-2
or type-5 routes with local pref 0.
-On the receiver side, when EVPN routes are received with GSHUT, the
correct handling takes place (to treat them with local preference 0, and
hence not select them)
-When the gshut configuration is removed on all BGP VRFs, we re-announce
all of our EVPN routes without GSHUT and receiver does the appropriate
thing. Also, we no longer mark EVPN-based IPv4/IPv6 routes with local
pref 0.
-evpn-smoke
-bgp-smoke
We have the same warn message in 3 spots, which makes it extremely
hard to figure out which of the 3 has gone terribly wrong.
Add a bit of code to disambiguate the 3 situations.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This replaces manual checks of the flag with a wrapper macro to convey
the meaning "is evpn enabled on this vrf?"
Signed-off-by: Tuetuopay <tuetuopay@me.com>
Sponsored-by: Scaleway
During L3VNI add, non-default RD value is not replayed
correctly. Instead of picking non-default value it picks
up auto RD value which is derived based on router-id.
Indentation issue: Remove additional space from
L3VNI running config output.
Ticket:CM-24320
Reviewed By:CCR-8437
Testing Done:
Bring up evpn configuration with L3vni up with non-default
RD value, perform peerlink flap, l3vni flap which removes
all VNIS and readds with RD and RT values.
The configured RD and RTs are replayed.
Post L3VNI flap
router bgp 5546 vrf vrf2
!
address-family l2vpn evpn
rd 45.0.66.2:6
route-target import 20001:1
route-target export 20001:1
exit-address-family
TORC11# show bgp l2vpn evpn vni 4002
VNI: 4002 (known to the kernel)
Type: L3
Tenant VRF: vrf2
RD: 45.0.66.2:6
Originator IP: 36.0.0.11
Advertise-gw-macip : n/a
Import Route Target:
20001:1
Export Route Target:
20001:1
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
When a bgp-peer comes up prior to l3vnis are up in bgpd.
The EVPN routes (type-2/type-5) are learnt via peer.
The routes can have one of interface's MAC in rmac attribute.
The self rmac check would bypass as l3vni is not present.
Once l3vni has come up in bgpd, while installing evpn
routes in vrf table, perform rmac attribute check against self mac.
The routes with rmac of ours will be removed via re-scan
of routes during bgp_mac_rescan_all_evpn_tables when
interface mac is added to bgp.
Ticket:CM-24224
Reviewed By:CCR-8423
Testing Done:
Signed-off-by: Chirag Shah <chirag@cumulunetworks.com>
Rename {bgp,zvrf}_def{ault} to {bgp,zvrf}_evpn where it makes sense,
i.e. when they contain the EVPN instance.
Signed-off-by: Tuetuopay <tuetuopay@me.com>
Sponsored-by: Scaleway
For default RT, this uses the correct ASN to derive the RT (ASN of the
EVPN VRF).
It also stores them in the EVPN VRF's hash tables rather than in the
default's one.
Signed-off-by: Tuetuopay <tuetuopay@me.com>
Sponsored-by: Scaleway
This change stores the mapping in the hash table of the EVPN VRF rather
than the one of the default VRF.
Signed-off-by: Tuetuopay <tuetuopay@me.com>
Sponsored-by: Scaleway
This sends local routes in overlay VRFs to the EPVN VRF when
redistribute configurations are present, rather than to the default VRF.
Signed-off-by: Tuetuopay <tuetuopay@me.com>
Sponsored-by: Scaleway
If the EVPN VRF is not the default one (i.e. with advertise-all-vni),
this allows showing its information with `show bgp l2evpn evpn ...`
commands. They do not require adding `vrf VRFNAME` since we only
support a single EVPN VRF. The same is true for zebra-specific commands
(e.g. `show evpn ...`).
Configuration commands are not restricted to the default VRF but to
the EVPN one, that is to the one bearing `advertise-all-vni`.
Signed-off-by: Tuetuopay <tuetuopay@me.com>
Sponsored-by: Scaleway
This makes the instance bearing the advertise-all-vni config option
register to zebra as the EVPN one, forwarding it the option.
Signed-off-by: Tuetuopay <tuetuopay@me.com>
Sponsored-by: Scaleway
Found that previous fix for this issue caused collatoral damage and
reverted that fix. This fix clears the vrf_bitmaps when the vrf is
disabled/deleted and then re-applies the redist config when the vrf
is re-enabled.
Ticket: CM-24231
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
The evpn route prefix len was being hardcoded to 224 bits while the
length of a mac-ip addr is actually 288. Because of this many problems were
seen in the evpn-tests. The sample below is from a test that does a vm-move
to verify extended-evpn-mac-mobility - IP1-M1 => IP2->M1. You can see two
local neighs but only one was inserted into the per-vni route table.
root@TORC11:~# net show evpn arp vni 1001 |grep "2001:fee1:0:1::10\|2001:fee1:0:1::11"
2001:fee1:0:1::10 local active 00:54:6f:7c:74:64
2001:fee1:0:1::11 local active 00:54:6f:7c:74:64
root@TORC11:~# net show bgp l2vpn evpn route vni 1001 |grep "2001:fee1:0:1::10\|2001:fee1:0:1::11"
*> [2]:[0]:[48]:[00:54:6f:7c:74:64]:[128]:[2001:fee1:0:1::11]
root@TORC11:~#
Similarly other traffic loss problems were seen because of one prefix updating
another prefix's route.
I think the 224-bits came from the packet format definition of type-2 routes.
However the way FRR maintains the key is very different than the format in
the packet so it seems best to just sizeof the addr.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
VRF route leak auto RD and RT uses router-id,
when a router-id changes for a bgp instance, change
associated vpn RD and RT values. Withdraw
old RD/RT routes from vpn and with new
RD/RT values advertise new routes to vpn.
One of the sceanrio is restarting frr:
A router-id change may not have reflected
for bgp vrf instance X, while import vrf X
under bgp vrf instance Y.
Once router-id changes for bgp VRF X,
change RD and RTs from export VRF and
imported VRFs. Readvertise routes with new
values to VPN.
Ticket:CM-24149
Reviewed By:CCR-8394
Testing Done:
Validated via configured multiple bgp VRF instances
and enable route leaks among them, restart frr
and all instance received correct RD and RT values.
Checked 'show bgp vrf all ipv4 unicast route-leak'
and vpn table 'show bgp ipv4 vpn all' output.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
VRF Route Leak's
show bgp vrf all ipv4 unicast route-leak
is not supported with `all` keyword.
Testing Done:
bl1# show bgp vrf all ipv4 unicast route-leak
Instance default:
This VRF is not importing IPv4 Unicast routes from any other VRF
This VRF is not exporting IPv4 Unicast routes to any other VRF
Instance vrf3:
This VRF is importing IPv4 Unicast routes from the following VRFs:
vrf1
Import RT(s): 144.1.1.2:10
This VRF is exporting IPv4 Unicast routes to the following VRFs:
vrf1
RD: 144.1.3.2:9
Export RT: 144.1.3.2:9
Instance vrf1:
This VRF is importing IPv4 Unicast routes from the following VRFs:
vrf3
Import RT(s): 144.1.3.2:9
This VRF is exporting IPv4 Unicast routes to the following VRFs:
vrf3
RD: 144.1.1.2:10
Export RT: 144.1.1.2:10
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
The "show bgp ipv6 summary" output displays incorrect number of peers count.
sonic# show bgp ipv6 summary
IPv6 Unicast Summary:
BGP router identifier 10.1.0.1, local AS number 65100 vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 5, using 103 KiB of memory
Peer groups 1, using 64 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2003::1 4 65099 0 0 0 0 0 never Active
2088::1 4 65100 0 0 0 0 0 never Active
3021::2 4 65100 0 0 0 0 0 never Active
Total number of neighbors 3
sonic#
In the above output, the peers count displays as 5 but the actual peer count is 3, i.e.. 3 neighbors are activated in ipv6 unicast address family.
Displayed peer count (5) is the number of the neighbors activated in a BGP instance.
Fix : Now the peers count displays the number of neighbors activated per afi/safi.
After Fix:
sonic# show bgp ipv6 summary
IPv6 Unicast Summary:
BGP router identifier 10.1.0.1, local AS number 65100 vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 3, using 62 KiB of memory
Peer groups 1, using 64 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2003::1 4 65099 0 0 0 0 0 never Active
2088::1 4 65100 0 0 0 0 0 never Active
3021::2 4 65100 0 0 0 0 0 never Active
Total number of neighbors 3
sonic#
Signed-off-by: Akhilesh Samineni <akhilesh.samineni@broadcom.com>
Views are perfectly valid and should be allowed to connect.
In a bgp instance scenario the vrf_id will always be UNKNOWN,
so allow it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
After a router reboot the L3 network via it converges before the L2
network. This is because MLAG intentionally holds down bridge-access
and vxlan-network ports for some time (MLAG init-delay) to prevent traffic
from switching to a router that is not fully ready. This also means that
routes (from vrf-peering sessions) that qualify for evpn type-5
advertisments are available long before the L3-VNI is available for that
tenant VRF. In these windows bgpd was adding these evpn-type-5 routes with
a L3-VNI of 0 (which was not fixed up after the L3-VNI became available) -
BGP routing table entry for 100.0.0.1:2:[5]:[0]:[0]:[32]:[200.1.1.1]
Paths: (1 available, best #1)
Advertised to non peer-group peers:
MSP1(uplink-1) MSP2(uplink-2)
Route [5]:[0]:[0]:[32]:[200.1.1.1] VNI 0 >>>>>>>>
65001 65535
36.0.0.9 from 0.0.0.0 (27.0.0.9)
Origin incomplete, metric 0, valid, sourced, local, bestpath-from-AS 65001, best
Extended Community: ET:8 RT:5544:4001 Rmac:44:38:39:ff:ff:01
AddPath ID: RX 0, TX 327
Last update: Wed Feb 27 18:37:10 2019
Fix is to defer creating type-5 routes till the L3-VNI is available for
that tenant VRF (this was already being done for most cases; fixup takes
care of some that missed the check).
Ticket: CM-24022
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgp update can contain router mac address same as one of SVIs
mac address, during processing of evpn route in bpg_update()
check for the flag is set and filter the route from installing.
This check is done prior to attribute lookup or storing in database.
Parse check and set is done once during attribute parse
because all the NLRIs containing evpn prefix
(type-2/type-5) will have same exntended community applicable.
Ticket:CM-23674
Reviewed By:CCR-8336
Testing Done:
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Any evpn bgp update message comes with router mac extended
community, which can potentially contain the madd adddress
same as any of the local SVIs (L3VNI) MAC address.
Set route mac exist and during route processing in
bgp_update() filter the route.
Ticket:CM-23674
Reviewed By:CCR-8336
Testing Done:
Configure L3vni mac on TORS1 which is similar to TORC11
L3vni MAC. When TORC11 received the EVPN update with
Router mac extended community, this check rejected the
BGP update message.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Found in testing that in a certain sequence, a neighbor's peer-group
membership would be lost. This fix resolves that issue. Additionally
found that "no neighbor swp1 remote-as 2" would sometimes leave the
config with "neighbor swp1 remote-as 0" rather than removing from the
config. That one is also resolved.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
With leaking of IPv4 or IPv6 unicast routes whose source is a EVPN
type-2 or type-5 route between VRFs, the determination of whether
the route's source is EVPN has to be made recursively. This is used
during route install to pass along appropriate parameters to zebra.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Refine check that looks for VPN routes imported into a VRF because
a VRF can have other imported routes too like IPv4 and IPv6 unicast
routes sourced from EVPN type-2 and type-5 routes.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
The code that causes the bottleneck has been written generically to
handle the below two cases:
a) When a new aggregate-address is configured.
b) When new routes, that can be aggregated under an existing
aggregate-address, are received.
This change optimizes the code that handles case-(b).
Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
With this commit:
1) The code to manage the large-communities attribute of the routes that are
aggregatable under a configured aggregate-address is introduced.
2) The code to compute the aggregate-route's large-communities attribute is
introduced.
Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
With this commit:
1) The code to manage the extended-communities attribute of the routes that are
aggregatable under a configured aggregate-address is introduced.
2) The code to compute the aggregate-route's extended-communities attribute is
introduced.
Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
With this commit:
1) The code to manage the communities attribute of the routes that are
aggregatable under a configured aggregate-address is introduced.
2) The code to compute the aggregate-route's communities attribute is
introduced.
Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
With this commit:
1) 'struct bgp_aggregate' is moved to bgp_route.h from bgp_route.c
2) Hashes to accommodate the as-path, communities, extended-communities and
large-communities attributes of all the routes aggregated by an
aggregate route is introduced in 'struct bgp_aggregate'.
3) Place-holders for the aggregate route's as-path, communities,
extended-communities and large-communities attributes are introduced in
'struct bgp_aggregate'.
4) The code to manage the as-path of the routes that are aggregatable under
a configured aggregate-address is introduced.
5) The code to compute the aggregate-route's as-path is introduced.
Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
Refine check on whether a route can be injected into EVPN to allow
EVPN-sourced routes to be injected back into another instance.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
The check on which routes are exportable is a superset, so remove the
route sub-type checks. Also, this change is needed to handle EVPN-imported
leaked routes correctly.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
IPv4 or IPv6 unicast routes which are imported from EVPN routes
(type-2 or type-5) and installed in a BGP instance and then leaked
do not need any nexthop tracking, as any tracking should happen in
the source instance.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
A non-imported route or a non-VPN imported route is a candidate to be
exported into the VPN routing table for leaking to other BGP instances
or advertisement into BGP/MPLS VPN. The former is a local or learnt
IPv4 or IPv6 route. The latter is an IPv4 or IPv6 route that is based
on a received EVPN type-2 or type-5 route.
Implement a function to specify if a route can be exported into VPN
and use in the appropriate places.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
IPv4 or IPv6 unicast routes which are imported from EVPN routes
(type-2 or type-5) and installed in a BGP instance can be leaked
to another instance.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
In the case of EVPN symmetric routing, the tenant VRF is associated with
a VNI that is used for routing and commonly referred to as the L3 VNI or
VRF VNI. Corresponding to this VNI is a VLAN and its associated L3 (IP)
interface (SVI). Overlay next hops (i.e., next hops for routes in the
tenant VRF) are reachable over this interface. Howver, in the model that
is supported in the implementation and commonly deployed, there is no
explicit Overlay IP address associated with the next hop in the tenant
VRF; the underlay IP is used if (since) the forwarding plane requires
a next hop IP. Therefore, the next hop has to be explicit flagged as
onlink to cause any next hop reachability checks in the forwarding plane
to be skipped.
https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement
section 4.4 provides additional description of the above constructs.
Use existing mechanism to specify the nexthops as onlink when installing
these routes from bgpd to zebra and get rid of a special flag that was
introduced for EVPN-sourced routes. Also, use the onlink flag during next
hop validation in zebra and eliminate other special checks.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
In the case of EVPN symmetric routing, the tenant VRF is associated with
a VNI that is used for routing and commonly referred to as the L3 VNI or
VRF VNI. Corresponding to this VNI is a VLAN and its associated L3 (IP)
interface (SVI). Overlay next hops (i.e., next hops for routes in the
tenant VRF) are reachable over this interface.
https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement
section 4.4 provides additional description of the above constructs.
Use the L3 interface exchanged between zebra and bgp in route install.
This patch in conjunction with the earlier one helps to eliminate some
special code in zebra to derive the next hop's interface.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
In the case of EVPN symmetric routing, the tenant VRF is associated with
a VNI that is used for routing and commonly referred to as the L3 VNI or
VRF VNI. Corresponding to this VNI is a VLAN and its associated L3 (IP)
interface (SVI). Overlay next hops (i.e., next hops for routes in the
tenant VRF) are reachable over this interface.
https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement
section 4.4 provides additional description of the above constructs.
The implementation currently derives this L3 interface for EVPN tenant
routes using special code that looks at route flags. This patch
exchanges the L3 interface between zebra and bgpd as part of the L3-VNI
exchange in order to eliminate some this special code.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
When a IPv4 or IPv6 route that was formerly allowed by the route-map
to be injected into EVPN gets an updated set of attributes that now
causes it to be filtered, the route needs to be pulled out of EVPN.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Withdraw flag is not sufficient to call bgp_update vs. bgp_withdraw()
processing for a given BGP evpn update message.
When a bgp update needs to be treated as an implicit withdraw
(e.g., due to malformed attribute), the code wasn't handling
things properly.
Rearranging attribute pass field to type-5 route processing and aligning
similar to done for other routes (type2/type-3).
Ticket:CM-24003
Reviewed By:CCR-8330
Testing Done:
Singed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
A few code paths weren't handling the vpnv6 nexthop lenghts as
expected, which was leading to problems like imported vpnv6 routes
not being marked as valid when they should. Fix this.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
BGP IPv6 routes should never contain the NEXT_HOP attribute
(MP_REACH_NLRI should be used instead).
This reverts commit 75cd35c697.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
peer_flag_modify() will always return BGP_ERR_INVALID_FLAG because
the action was not defined for PEER_FLAG_IFPEER_V6ONLY flag.
```
global PEER_FLAG_IFPEER_V6ONLY = 16384;
global BGP_ERR_INVALID_FLAG = -2;
probe process("/usr/lib/frr/bgpd").statement("peer_flag_modify@/root/frr/bgpd/bgpd.c:3975")
{
if ($flag == PEER_FLAG_IFPEER_V6ONLY && $action->type == 0)
printf("action not found for the flag PEER_FLAG_IFPEER_V6ONLY\n");
}
probe process("/usr/lib/frr/bgpd").function("peer_flag_modify").return
{
if ($return == BGP_ERR_INVALID_FLAG)
printf("return BGP_ERR_INVALID_FLAG\n");
}
```
produces:
action not found for the flag PEER_FLAG_IFPEER_V6ONLY
return BGP_ERR_INVALID_FLAG
$ vtysh -c 'conf t' -c 'router bgp 20' -c 'neighbor eth1 interface v6only remote-as external'
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
Display only ipv4 neighbors when 'show bgp ipv4 neighbors' command is issued.
Display only ipv6 neighbors when 'show bgp ipv6 neighbors' command is issued.
Take the address family of the peer address into account, while displaying the neighbors.
Signed-off-by: Akhilesh Samineni <akhilesh.samineni@broadcom.com>
The community_delete and lcommunity_delete functionality was
creating a special string that needed to be specially parsed.
Remove all this string creation and just pass the pertinent
data into the appropriate functions.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The struct prefix *prefix is really a const struct prefix *
This was causing compile warns->errors on some compilers
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
In order to iterate over MPLS VPN routes, it's necessary to use
two nested loops (the outer loop iterates over the MPLS VPN RDs,
and the inner loop iterates over the VPN routes from that RD).
The add-path code wasn't doing this, which was leading to lots of
crashes when add-path was enabled for the MPLS VPN SAFI. This patch
fixes the problem.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
If path->net is NULL in the bgp_path_info_free() function, then
bgpd would crash in bgp_addpath_free_info_data() with the following
backtrace:
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007ff7b267a42a in __GI_abort () at abort.c:89
#2 0x00007ff7b39c1ca0 in core_handler (signo=11, siginfo=0x7ffff66414f0, context=<optimized out>) at lib/sigevent.c:249
#3 <signal handler called>
#4 idalloc_free_to_pool (pool_ptr=pool_ptr@entry=0x0, id=3) at lib/id_alloc.c:368
#5 0x0000560096246688 in bgp_addpath_free_info_data (d=d@entry=0x560098665468, nd=0x0) at bgpd/bgp_addpath.c:100
#6 0x00005600961bb522 in bgp_path_info_free (path=0x560098665400) at bgpd/bgp_route.c:252
#7 bgp_path_info_unlock (path=0x560098665400) at bgpd/bgp_route.c:276
#8 0x00005600961bb719 in bgp_path_info_reap (rn=rn@entry=0x5600986b2110, pi=pi@entry=0x560098665400) at bgpd/bgp_route.c:320
#9 0x00005600961bf4db in bgp_process_main_one (safi=SAFI_MPLS_VPN, afi=AFI_IP, rn=0x5600986b2110, bgp=0x560098587320) at bgpd/bgp_route.c:2476
#10 bgp_process_wq (wq=<optimized out>, data=0x56009869b8f0) at bgpd/bgp_route.c:2503
#11 0x00007ff7b39d5fcc in work_queue_run (thread=0x7ffff6641e10) at lib/workqueue.c:294
#12 0x00007ff7b39ce3b1 in thread_call (thread=thread@entry=0x7ffff6641e10) at lib/thread.c:1606
#13 0x00007ff7b39a3538 in frr_run (master=0x5600980795b0) at lib/libfrr.c:1011
#14 0x000056009618a5a3 in main (argc=3, argv=0x7ffff6642078) at bgpd/bgp_main.c:481
Add a null-check protection to fix this problem.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
For VRF route leak, enable route map filter based
on "source-vrf" check.
Implemented match filter rule for "source-vrf" which
compares leaked routes original vrf_id (where it leaked from)
during importing into target VRF.
Ticket:CM-23776
Reviewed By:
Testing Done:
Configure vrf route leak from vrf1 to vrf2,
configure import vrf under vrf2 along with route-map
with source-vrf filter.
Add and remove source-vrf filter and checked routes
were added and removed to vrf2 table via vpn (default) table.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
"When building without VNC, automake sees that the `bgpd_bgpd_CFLAGS`
variable exists, although it is only set in the VNC-enabled case... but
since the variable exists, it unconditionally drops `AM_CFLAGS` for the
two bgp targets and uses `bgpd_bgpd_CFLAGS` instead, which will
contain... _nothing_."
This was breaking builds of bgpd binaries with MSAN enabled.
Signed-off-by: David Lamparter <equinox@diac24.net>
Signed-off-by: Quentin Young <qlyoung@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>
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>
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>
Made changes and updated the routemap applied counter in the following flows.
1.Increment when route map attached to a list.
2.Decrement when route map removed / modified from a list.
3.Increment/decrement when route map create/delete callback triggered.
4.Besides ,This counter need not be updated when a route map is got updated.
i.e changing/adding a match value to the existing routemap.
In BGP , same update api called for all three add/delete/update operation .
But this counter have to be updated only for routemap addition.
Addressed this specific change by identifying the routemap operation based
on routemap pointer.
Signed-off-by: RajeshGirada <rgirada@vmware.com>
- some target_CFLAGS that needed to include AM_CFLAGS didn't do so
- libyang/sysrepo/sqlite3/confd CFLAGS + LIBS weren't used at all
- consistently use $(FOO_CFLAGS) instead of @FOO_CFLAGS@
- 2 dependencies were missing for clippy
Signed-off-by: David Lamparter <equinox@diac24.net>
the maximum value for stalepath timer is extended to 4095 to align with
bgp restart timer value.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
rfc of bgp graceful restart mechanism permits to increase the
restart timer, since its value is encoded on 12 bit.
So make available the possibility to extend it.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Executed some evpn related tests with valgrind and saw some errors
related to uninitialized memory and overlapping memcpy. This commit
fixes those.
Ticket: CM-21218
Signed-off-by: Nitin Soni <nsoni@cumulusnetworks.com>
Reviewed-by: CCR-8249
the list of iprules is displayed in the 'show bgp ipv4 flowspec detail'
The list of iprules is displayed, only if it is installed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
two kind of rules are being set from bgp flowspec: ipset based rules,
and ip rule rules. default route rules may have a lower priority than
the other rules ( that do not support default rules). so, if an ipset
rule without fwmark is being requested, then priority is arbitrarily set
to 1. the other case, priority is set to 0.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
because ip rule creation is used to not only handle traffic marked by
fwmark; but also for conveying traffic with from/to rules, a check of
the creation must be done in the linked list of ip rules.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
adding/suppressing flowspec to pbr is supported. the add and the remove
code is being added. now,bgp supports the hash list of ip rule list.
The removal of bgp ip rule is done via search. The search uses the
action field. the reason is that when a pbr rule is added, to replace an
old one, the old one is kept until the new one is installed, so as to
avoid traffic to be cut. This is why at one moment, one can have two
same iprules with different actions. And this is why the algorithm
covers this case.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
now, ip rule can be created from two differnt ways; however a single
zebra API has been defined. so make it consistent by adding a parameter
to the bgp zebra layer. the function will handle the rest.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Before, it was not possible to create any rules. Now, it is possible to
have flowspec rules relying only on ip rule command. The check is done
here.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
that iprule list stands for the list of fs entries that are created,
based only on ip rule from/to rule.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
instead of using ipset based mechanism to forward packets, there are
cases where it is possible to use ip rule based mechanisms (without
ipset). Here, this applies to simple fs rules with only 'from any' or
'to any'.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
main bgp structure that contains fs information is being cleaned.
some fields are removed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
bgp instance is disabling the label allocated to reach vrf entity.
previously, only vrf disabling was removing the label. now, when bgp
leaves, bgp instance also frees the label used.
PR=62306
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Acked-by: Julien Floret <julien.floret@6wind.com>
When a interface based peer is setup and if it is part of a peer
group we should ignore this and just use the PEER_FLAG_CAPABILITY_ENHE
no matter what.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
bgp would crash with various `show bgp neighbor json` commands
based upon whether or not it did a pretty print of the output
or not. This is because we were freeing the data 2 times.
Cleanup so that we free the json data 1 time.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When an inactive-neigh delete is rxed bgp will not have a local path to
remove (and re-run path selection). Instead it simply re-installs the
current best remote path if any.
Ticket: CM-23018
Testing Done: evpn-min
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Move the info filling for zebra mac-ip install (sent by bgpd) to a
common place.
The commit also fixes missing ROUTER flag for one of the cases
added in a code branch that doesn't have the ROUTER changes -
[
6d8c603a
bgpd: use IP address as tie breaker if the MM seq number is the same
]
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Route-map filtering is based on the value of
"bgp->adv_cmd_rmap[afi][safi].map". For example, we advertise routes in
bgp_evpn_advertise_type5_routes() based on the value of
"bgp->adv_cmd_rmap[afi][safi].map". This variable gets populated in vty
handler bgp_evpn_advertise_type5. This variable will not get populated
if we have not yet applied the route-map configuration. The fix is to
correctly populate "bgp->adv_cmd_rmap[afi][safi].map" in
bgp_route_map_process_update() if it has not been populated before.
Ticket: CM-23263
Signed-off-by: Nitin Soni <nsoni@cumulusnetworks.com>
Reviewed-by: CCR-8163
Problem reported that with certain sequences of defining the
remote-as on the peer-group and the members, the configuration would
become wrong, with configured remote-as settings not reflected in
the config but peers unable to come up. This fix resolves these
inconsistencies.
Ticket: CM-19560
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
when removing bgp instance, the parsing of rm->info contexts must be
protected. Also, the main level of hierarchy of rds must not be
allocated more than once.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Now that all daemons receive the VRF backend from zebra, we can get
rid of vrf_is_mapped_on_netns() in favor of using the more convenient
vrf_is_backend_netns() function, which doesn't require any argument.
This commit also fixes the following problem:
debian(config)# ip route 50.0.0.0/8 blackhole vrf FAKE table 2
% table param only available when running on netns-based vrfs
Even when zebra was started with the --vrfwnetns, the error
above would be displayed since the VRF FAKE didn't exist, which
would make vrf_is_mapped_on_netns() return 0 incorrectly. Using
vrf_is_backend_netns() this problem doesn't happen anymore.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
strlen is the same as sizeof when the memory is dynamically allocated
but it is not the same when the memory being looked at is an array.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The current invocation of frr_pthread_set_name was causing it reset the os_name.
There is no need for this, we now always create the pthread appropriately
to have both name and os_name. So convert this function to a simple
call through of the pthread call now.
Before(any of these changes):
sharpd@robot ~/frr1> ps -L -p 16895
PID LWP TTY TIME CMD
16895 16895 ? 00:01:39 bgpd
16895 16896 ? 00:00:54
16895 16897 ? 00:00:07 bgpd_ka
After:
sharpd@donna ~/frr1> ps -L -p 1752
PID LWP TTY TIME CMD
1752 1752 ? 00:00:00 bgpd
1752 1753 ? 00:00:00 bgpd_io
1752 1754 ? 00:00:00 bgpd_ka
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When using an `import vrf` mechanism we are marking
the vrf label as BGP_PREVENT_VRF_2_VRF_LEAK, and then sending
this down to zebra. Since zebra knows nothing about this special
value, convert it to a value that it does know MPLS_LABEL_NONE.
This bug was introduced by: 13b7e7f007
And shows up with this error message in the zebra log:
2019/01/09 08:25:16 ZEBRA: Extended Error: Label >= configured maximum in platform_labels
2019/01/09 08:25:16 ZEBRA: [EC 4043309093] netlink-cmd (NS 0) error: Invalid argument, type=RTM_NEWROUTE(24), seq=8, pid=3321825991
2019/01/09 08:25:16 ZEBRA: [EC 4043309103] LSP Install Failure: 4294967294
And zebra kept the label as:
donna.cumulusnetworks.com# show mpls table
Inbound Outbound
Label Type Nexthop Label
-------- ------- --------------- --------
-2 BGP GREEN
-2 BGP BLUE
After this fix, neither the labels are stored in zebra nor do we see
the log error message.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Further refine the previous commit to store the hash value in
both the `struct community_list` as well as the `struct rmap_community`
structures. This allows us to know a priori what our hash value
is. This change cuts another couple of seconds of convergence
off to ~55 seconds and further reduces cpu load of bgp:
16 40061.706 433732 92 330102 129 1242965 RWTEX TOTAL
Down from ~43 seconds previously.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The community_list_lookup function in a situation where you have
a large number of communities and route-maps that reference them
becomes a very expensive operation( effectively a linked list walk
per route per route-map you apply per peer that has a routemap that
refereces a community, ecommunity or lcommunity. This is a very
expensive operation.
In my testbed, I have a full bgp feed that feeds into 14 namespace
view based bgp processes and finally those 14 feed into a final
namespace FRR instance that has route-maps applied to each
incoming peer for in and out:
!
router bgp 65033
bgp bestpath as-path multipath-relax
neighbor 192.168.41.1 remote-as external
neighbor 192.168.42.2 remote-as external
neighbor 192.168.43.3 remote-as external
neighbor 192.168.44.4 remote-as external
neighbor 192.168.45.5 remote-as external
neighbor 192.168.46.6 remote-as external
neighbor 192.168.47.7 remote-as external
neighbor 192.168.48.8 remote-as external
neighbor 192.168.49.9 remote-as external
neighbor 192.168.50.10 remote-as external
neighbor 192.168.51.11 remote-as external
neighbor 192.168.52.12 remote-as external
neighbor 192.168.53.13 remote-as external
neighbor 192.168.54.14 remote-as external
!
address-family ipv4 unicast
neighbor 192.168.42.2 prefix-list two-in in
neighbor 192.168.42.2 route-map two-in in
neighbor 192.168.42.2 route-map two-out out
neighbor 192.168.43.3 prefix-list three-in in
neighbor 192.168.43.3 route-map three-in in
neighbor 192.168.43.3 route-map three-out out
neighbor 192.168.44.4 prefix-list four-in in
neighbor 192.168.44.4 route-map four-in in
neighbor 192.168.44.4 route-map four-out out
neighbor 192.168.45.5 prefix-list five-in in
neighbor 192.168.45.5 route-map five-in in
neighbor 192.168.45.5 route-map five-out out
neighbor 192.168.46.6 prefix-list six-in in
neighbor 192.168.46.6 route-map six-in in
neighbor 192.168.46.6 route-map six-out out
neighbor 192.168.47.7 prefix-list seven-in in
neighbor 192.168.47.7 route-map seven-in in
neighbor 192.168.47.7 route-map seven-out out
neighbor 192.168.48.8 prefix-list eight-in in
neighbor 192.168.48.8 route-map eight-in in
neighbor 192.168.48.8 route-map eight-out out
neighbor 192.168.49.9 prefix-list nine-in in
neighbor 192.168.49.9 route-map nine-in in
neighbor 192.168.49.9 route-map nine-out out
neighbor 192.168.50.10 prefix-list ten-in in
neighbor 192.168.50.10 route-map ten-in in
neighbor 192.168.50.10 route-map ten-out out
neighbor 192.168.51.11 prefix-list eleven-in in
neighbor 192.168.51.11 route-map eleven-in in
neighbor 192.168.51.11 route-map eleven-out out
neighbor 192.168.52.12 prefix-list twelve-in in
neighbor 192.168.52.12 route-map twelve-in in
neighbor 192.168.52.12 route-map twelve-out out
neighbor 192.168.53.13 prefix-list thirteen-in in
neighbor 192.168.53.13 route-map thirteen-in in
neighbor 192.168.53.13 route-map thirteen-out out
neighbor 192.168.54.14 prefix-list fourteen-in in
neighbor 192.168.54.14 route-map fourteen-in in
neighbor 192.168.54.14 route-map fourteen-out out
exit-address-family
!
This configuration on my machine before this change takes about 2:45 to converge
and bgp takes:
Total thread statistics
16 151715.050 493440 307 3464919 335 7376696 RWTEX TOTAL
CPU time as reported by 'show thread cpu'.
After this change BGP takes 58 seconds to converge and uses:
Total thread statistics
-------------------------
16 42954.284 350319 122 295743 157 1194820 RWTEX TOTAL
almost 43 seconds of CPU time.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The community_list_lookup function is being changed in a future
commit. As such we want to use the `struct rmap_community` data
structure for storing compiled information about communities,ecommunities
or lcommunities.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The End of Rib notification in BGP is useful to know no matter
the circumstances. So change this from a debug message to
an info and cleanup the message a bit and add vrf we are in.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
in bgp, even if the main vrf implementation relies on tables, the fact
is some vrf implementation rely on network namespaces, and then the
table used is the default table from the network namespace. Use the
wording vrf instead of table.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Certain EVPN configuartions should only be applied
under DEFAULT VRF bgpd instance.
reject the cli for non default bgp instance
Ticket:CM-18950
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
redirect IP nh of flowspec entry is retrieved so that the nexthop
IP information is injected into the nexthop tracking, and is associated
to the bgp_path structure. This permits validating or unvalidating the
bgp_path for injection in zebra or not.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This commit is the last missing piece to complete BGP LU support in bgpd. To this moment, bgpd (and zebra) supported auto label assignment only for prefixes leaked from VRFs to vpn and for MPLS SR prefixes. This adds auto label assignment to other routes types in bgpd. The following enhancements have been made:
* bgp_route.c:bgp_process_main_one() now sets implicit-null local_label to all local, aggregate and redistributed routes.
* bgp_route.c:bgp_process_main_one() now will request a label from the label pool for any prefix that loses the label for some reason (for example, when the static label assignment config is removed)
* bgp_label.c:bgp_reg_dereg_for_label() now requests labels from label pool for routes which have no associated label index
* zebra_mpls.c:zebra_mpls_fec_register() now expects both label and label_index from the calling function, one of which must be set to MPLS_INVALID_LABEL or MPLS_INVALID_LABEL_INDEX, based on this it will decide how to register the provided FEC.
Signed-off-by: Anton Degtyarev <anton@cumulusnetworks.com>
These two commands previously required the whole original command but
we should allow the user to shorten out this since the data at the
end is not required to figure out what to delete.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The ability to shorten the extended community commands for routemaps
upon removal should be allowed.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Allow user to enter `no set community` to remove the community
set for the route-map.
Fixes: #3491
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Default vrf name has been changed in show route. Because the default vrf
name can be configured in zebra, the default vrf name in bgp is changed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
if default vrf is not Default, then nexthop vrf name returned may be
"Default", which is not the correct name of default vrf. change it
accordingly.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The confederation identifier is a `as_t` type which is a
uint32_t underneath the covers. Display it using a %u
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
cf. https://wiki.debian.org/NonFreeIETFDocuments
These MIBs were in our git purely for documentation purposes, they are
not installed and not needed for building SNMP support.
Signed-off-by: David Lamparter <equinox@diac24.net>
Looks like we missed some code in a non-normal compiled
code path for the bgp_path_info conversion.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add some code that will reject local mac's from
being installed and add some code that will cause
a rescan when we have a local mac change.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com.
Add a bit of code that allows us to dump the mac hash. Future
commits will actually add entries to the mac hash and then operate
on it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When you have configured soft reconfiguration inbound
for evpn allow it to notice and send in the evpn data
as appropriate.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The `struct bgp_route_evpn` and `struct overlay_index` data
structures are exactly the same. Reduce to 1.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
During L3VNI add delete, configured non-default
route-target is not replayed correctly.
Non-default route-target should only be deleted
during unconfiguring under bgp vrf instance,
during delete of l3vni only unmap from the VRF.
during addition of l3vni map back to the VRF
Ticket:CM-21482
Testing Done:
Bring up evpn configuration with L3vni up with
non-default route-target.
Perform delete/add of L3vni and validated non-default
route-target is mapped back to vrf.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Fully revert the rest of the e23b9ef6d2 commit as that it was breaking
route leaking between vrf's.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
I bulk-fixed "recieved" as a misspelling in 0437e10... but didn't notice
there was a JSON value among these.
Signed-off-by: David Lamparter <equinox@diac24.net>
The adj_out data structure is a linked list of adjacencies
1 per update group. In a large scale env where we are
not using peer groups, this list lookup starts to become
rather costly. Convert to a better data structure for this.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Don't show the configuration line `rfp full-table-download off` by
default as it is not the default value, instead only show
`rfp full-table-download on` (the non-default value) when it is
configured.
This standardizes this knob to the FRR default behavior.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
EVPN route's attribute changes,
mark attribute change flag to imported unicast route.
A scenario where AS_PATH attribute have changed for an EVPN type-5
route, set attribute change
to imported route.
Ticket:CM-23008
Reviewed By:
Testing Done:
Validated via marking EVPN route with AS_PATH prepand.
At the receiving VTEP, ensure attribute change flag is set to
imported unicast route and bgp update sent to VTEPs subsequent
bgp peers with AS_PATH prepend update.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
1. "show bgp ipv4/ipv6 [json]"
2. "show bgp ipv4/ipv6 neighbor <peer> routes [json]"
3. "show bgp ipv4/ipv6 neighbors <peer> advertised-routes [json]"
In the above show commands, when a BGP path is displayed, we do not display the
local preference if it is EBGP route. Route calculation assumes the default
local preference. But, we can change the default local preference using
configuration in FRR. In this case, user should know the default local
preference value that is being used in the route calculation. Thus, adding a
new field 'default local preferece' in the show commands where a BGP path is
displayed.
When a BGP path is displayed in the above show commands, as-path does not
include the local AS. So, user has to execute another show command to display
the local-AS. To avoid this, adding a new field local-AS to above show commands.
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
label pool finalisation must be delayed after route deletion on bgp.
otherwise a crash will happen, while labels will be released.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
previous change was to fix rnh module in Zebra for leaked routes
this reverts that fix, so probably reintroduces the problem.
Signed-off-by: Lou Berger <lberger@labn.net>
when converting bgp fs entries to bgp pbr entries, the fields of the
flowspec are analysed. In the case src ip or dst ip is set to 0.0.0.0,
that field is ignored, thus preventing from injecting a rule that can
not be injected into the pbr. This can be done by avoiding mentioning
the field in the bitmask structure used to convert data to pbr entries.
PR=61620
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Acked-by: Emmanuel Vize <emmanuel.vize@6wind.com>
that new option will overwrite simpson draft. There is a new ecommunity
option whose type is 0x1 and subtype is 0xc. That option is defined
here on iana.org/assignments/bgp-extended-communities page:
- bgp-extended-communities.xhtml#trans-ipv4
It contains the IP address to redirect traffic to. The understanding of
the draft is the following one:
- if that community is only present, then the ip contained inside will
be chosen as nexthop.
- if that community is provided along with simpson extended community,
then only the new redirect ip draft will be used. however, both will be
displayed.
- in other cases, if there is only the simpson extended community, then
the nexthop IP of the NLRI will be chosen.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When "default-originate ipv4" is configured, a type-5 route is installed in
the local node and advertised to the peer with auto-rd.
When the above was followed by configuring an RD in IP VRF, Type-5 are
generated for only the non-default routes.
Fixed this issue by withdrawing the default route with auto-rd and advertising
the route with confiured RD.
Signed-off-by: Kishore Aramalla karamalla@vmware.com
A while ago all FRR configuration commands were converted to use the
QOBJ infrastructure to keep track of configuration objects. This
means the configuration lock isn't necessary anymore because the
QOBJ code detects when someones tries to edit a configuration object
that was deleted and react accordingly (log an error and abort the
command). The possibility of accessing dangling pointers doesn't
exist anymore since vty->index was removed.
Summary of the changes:
* remove the configuration lock and the vty_config_lockless() function.
* rename vty_config_unlock() to vty_config_exit() since we need to
clean up a few things when exiting from the configuration mode.
* rename vty_config_lock() to vty_config_enter() to remove code
duplication that existed between the three different "configuration"
commands (terminal, private and exclusive).
Configuration commands converted to the new northbound model don't
need the configuration lock either since the northbound API also
detects when someone tries to edit a configuration object that
doesn't exist anymore.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
When a VNI is unconfigured it deletes all of its import and export
route-targets. There is a export route-target link list and import
route-target linked list. There are redudant loops in the
route-target deletion code. In the first iteration it deleted the
route-target and freed the RT node, but not list node.
In the 2nd iteration it tries to free the RT node again, resulting in
the double free of RT node.
Signed-off-by: "Kishore Aramalla karamallavmware.com"
Null check of 'rn' returned by bgp_node_lookup() because it could be
deferenced afterwards into bgp_nexthop_get_node_info()
Signed-off-by: F. Aragon <paco@voltanet.io>
* The function bgp_router_id_zebra_bump() will check for active bgp
peers before chenging the router ID.
If there are established peers, router ID is not modified
which prevents the flapping of established peer connection
* Added field in bgp structure to store the count of established peers
Signed-off-by: kssoman <somanks@vmware.com>
Duplicate address detection configuration clis
under bgp l2vpn evpn config mode.
- Enabled/Disable (global knob) for feature.
- Configure cli for duplicate detection action
freeze and freze until time (auto-recovery).
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Enable/disable duplicate address detection
there are 3 actions
warning-only: Default action which generates
only frr warning (syslog) to user for any
duplicate detecton
freeze: Permanently freezes address, manual
intervene required.
freeze with time: An address will recover once
the time has expired (auto-recovery).
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
The bgp_connected_set_node_info and bgp_connected_get_node_info
function names were slightly backwards lets fix them up
to bgp_node_set_bgp_connected_ref_info and bgp_node_get_bgp_connected_ref_info
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The bgp_distance_set_node_info and bgp_distance_get_node_info
function names were slightly backwards lets fix them up
to bgp_node_get_bgp_distance_info and bgp_node_set_bgp_distance_info
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The bgp_static_set_node_info and bgp_static_get_node_info
function names were slightly backwards rename to
bgp_node_get_bgp_static_info and bgp_node_set_bgp_static_info
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The bgp_aggregate_set_node_info and bgp_aggregate_get_node_info
functions names were slightly backwards, rename to
bgp_node_get_bgp_aggregate_info and bgp_node_set_bgp_aggregate_info
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The bgp_nexthop_set_node_info and bgp_nexthop_get_node_info
function names were slightly backwards, rename to bgp_node_set and get
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The show_adj_route_vpn function was incredibly hard to read because
of the incredibly deep indentation. fix this up some.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Cleanup the bgp_route_map_process_update code to be a bit
easier to read as that it approached the right side of the
80 column limit a whole bunch and became hard to read.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Fix the missed usage of bgp_static_get_node_info and also
cleanup the function around it that was using it to make
it a bit more readable.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The bgp_info data is stored as a void pointer in `struct bgp_node`.
Abstract retrieval of this data and setting of this data
into functions so that in the future we can move around
what is stored in bgp_node.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The ordering of data within the `struct bgp_node`
was causing extra padding of data. Moving the version
to a bit different spot allows for more efficient packing
of data.
Pre-change:
(gdb) p sizeof(struct bgp_node)
$1 = 152
(gdb)
Post-change:
(gdb) p sizeof(struct bgp_node)
$1 = 144
(gdb)
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There is no reason that bgp should be including zebra
headers into it's code base, it is a violation of
their respective name spaces.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Missing endline was resulting in garbled output in vtysh in some cases, for example, when there were no peers configured and the user has issued "bgp disable-ebgp-connected-route-check" command.
Signed-off-by: Anton Degtyarev <anton@cumulusnetworks.com>
In rare cases when the default BGP instance is instantiated after VRF bgp instances (see comment to bgp_mplsvpn.c:vpn_leak_postchange_all() for an example), the "router bgp" command needs to call vpn_leak_postchange_all() to start the route leaking process. The issue was it was never checked if the "router bgp" command was used to create the default BGP instance or just to enter into "router bgp" command context. This resulted in vpn_leak_postchange_all() executed every time (and vpn routes re-announced to all peers) when the user was entering "router bgp" command context.
Signed-off-by: Anton Degtyarev <anton@cumulusnetworks.com>
if zebra is not started, then vrf identifiers are not available. This
prevents import/exportation to be available. This commit permits having
import/export available, even when zebra is not started.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
It's been a year since we added the new optional parameters
to instantiation. Let's switch over to the new name.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The motivation for this patch is to address a concerning behavior of
tx-addpath-bestpath-per-AS. Prior to this patch, all paths' TX ID was
pre-determined as the path was received from a peer. However, this meant
that any time the path selected as best from an AS changed, bgpd had no
choice but to withdraw the previous best path, and advertise the new
best-path under a new TX ID. This could cause significant network
disruption, especially for the subset of prefixes coming from only one
AS that were also communicated over a bestpath-per-AS session.
The patch's general approach is best illustrated by
txaddpath_update_ids. After a bestpath run (required for best-per-AS to
know what will and will not be sent as addpaths) ID numbers will be
stripped from paths that no longer need to be sent, and held in a pool.
Then, paths that will be sent as addpaths and do not already have ID
numbers will allocate new ID numbers, pulling first from that pool.
Finally, anything left in the pool will be returned to the allocator.
In order for this to work, ID numbers had to be split by strategy. The
tx-addpath-All strategy would keep every ID number "in use" constantly,
preventing IDs from being transferred to different paths. Rather than
create two variables for ID, this patch create a more generic array that
will easily enable more addpath strategies to be implemented. The
previously described ID manipulations will happen per addpath strategy,
and will only be run for strategies that are enabled on at least one
peer.
Finally, the ID numbers are allocated from an allocator that tracks per
AFI/SAFI/Addpath Strategy which IDs are in use. Though it would be very
improbable, there was the possibility with the free-running counter
approach for rollover to cause two paths on the same prefix to get
assigned the same TX ID. As remote as the possibility is, we prefer to
not leave it to chance.
This ID re-use method is not perfect. In some cases you could still get
withdraw-then-add behaviors where not strictly necessary. In the case of
bestpath-per-AS this requires one AS to advertise a prefix for the first
time, then a second AS withdraws that prefix, all within the space of an
already pending MRAI timer. In those situations a withdraw-then-add is
more forgivable, and fixing it would probably require a much more
significant effort, as IDs would need to be moved to ADVs instead of
paths.
Signed-off-by Mitchell Skiba <mskiba@amazon.com>
When we have a late registration of the Extended Nexthop capability
for BGP and the peer already has nexthop information stored, go
through and enable RA on the important interfaces.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
If we attempt to register nexthops before we have the zebra
connection, they will not be installed. After we have noticed
that we are up, re-install them.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Allow some debug notification when we are unable to talk
to zebra due to the connection not being there yet.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This change is a fixup to -
7b5e18 - bgpd: use IP address as tie breaker if the MM seq number is the
same
And is being done in response to review comments. This commit brings no
functional change; simply moves around code for easier maintanence.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Same sequence number handling is specified by RFC 7432 -
[
If two (or more) PEs advertise the same MAC address with the same
sequence number but different Ethernet segment identifiers, a PE that
receives these routes selects the route advertised by the PE with the
lowest IP address as the best route.
If the PE is the originator of the MAC route and it receives the same
MAC address with the same sequence number that it generated, it will
compare its own IP address with the IP address of the remote PE and
will select the lowest IP. If its own route is not the best one, it
will withdraw the route.
]
To implement that specification this commit uses nexthop IP as a tie
breaker between two paths of equal seq number with lower IP winning.
Now if a local path already exists with the same sequence number but higher
(local-VTEP) IP it is evicted (deleted and withdrawn from the peers) and
the winning new remote path is installed in zebra. This is existing code
and handled implicitly via evpn_route_select_install.
If a local path is rxed from zebra with the same sequence as the
current remote winner it is rejected (not installed in the bgp
routing tables) and zebra is asked to re-install the older/remote winner.
This is a race condition that can only happen if bgp's add and zebra's add
cross paths. Additional handling has been added in this commit via
evpn_cleanup_local_non_best_route to take care of the race condition.
Ticket: CM-22674
Reviewed By: CCR-7937
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
This is needed to install the remote dst when a more preferred local
path is removed.
Ticket: CM-22685
Reviewed By: CCR-7936
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
local mac add/del comes from zebra. the hidden commands help verify
various race conditions between bgp and zebra.
Ticket: CM-22687
Reviewed By: CCR-7939
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Problems were reported with the name of the default vrf and the
default bgp instance being different, creating confusion. This
fix changes both to "default" for consistency.
Ticket: CM-21791
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: CCR-7658
Testing: manual testing and automated tests before pushing
Both of these are testing/demo-style tools that don't make sense as part
of a normal installation. So don't install them.
NB: this is only the executables, libospfclient and the RFP code are not
affected.
Signed-off-by: David Lamparter <equinox@diac24.net>
FRR_DAEMON_INFO should now contain an array of 'frr_yang_module_info'
structures describing the YANG modules implemented by the daemon.
This array will be used by frr_init() function to load all YANG modules
and initialize the northbound callbacks during the daemon initialization.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
* Cast when assigning should be to uint16_t
* Restored comment documenting strange behavior
* Further increased PREFIX_STRLEN to 80 chars
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
The tx_id_buf was not being set to anything in some cases,
make sure it's a null string before using.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
community_free, lcommunity_free and ecommunity_free are similar type of functions. Most of the places, these three are called together. The signature of community_free is different from other two functions. Modified the community_free API signature to align with other two functions to avoid any confusion. There is no functionality impact with this and this is just to avoid any confusion.
Testing: manual testing and show commands
Signed-off-by: Sri Mohana Singamsetty msingamsetty@vmware.com
as prefix is opaque for flowspec, and json needs to have a non empty
full of meaning value in prefix, the proposal is to encode the
displayable form of flowspec entry.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
zclient->redist[afi][type] is a hash table and not an integer since a
while ago when VRF support was introduced. As such, zclient->redist[][]
should never be manipulated directly, the vrf_bitmap_*() helper functions
should be used instead. This fixes a few crashes found by the CLI fuzzer.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The routing table data structure can create intermediate route nodes
during its normal operation, so we always need to check if the 'info'
pointer of a route node is NULL or not before dereferencing it.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The vnc_direct_del_rn_group_rd() function can be called with the 'afi'
parameter set to AFI_L2VPN on some specific cases. Remove the assert to
fix the crash.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Other parts of the rfapi code check if the 'rfg->rfapi_import_table'
pointer is NULL or not before using it. Do the same here to fix a crash
detected by the CLI fuzzer.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The rfapiDeleteRemotePrefixesIt() function checks on several places if
'p' is NULL or not. Introduce an additional NULL check to prevent a
crash from happening.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The rfapi code wasn't checking if strtoul() succeeded or not when parsing
the list of labels. Fix the affected commands by not allowing the user
to enter a non-numeric input.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Other parts of the rfapi code also check if these pointers are NULL or
not before using them.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The peer->group pointer is set only if the PEER_STATUS_GROUP flag is
set in the peer. Add a protection to prevent a NULL pointer dereference.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Like community_cmp() and ecommunity_cmp(), the lcommunity_cmp() function
also needs to handle NULL pointers for correct operation.
Without this fix, bgpd can crash when entering the following commands:
vtysh -c "configure terminal" -c "ip large-community-list standard WORD deny"
vtysh -c "configure terminal" -c "no ip large-community-list expanded WORD"
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The bgp_damp_config_clean() function was deallocating some arrays without
resetting the variables that represent their sizes. This was leading to
some crashes because other parts of the code iterate over these arrays
by looking at their corresponding sizes, which could be invalid.
Fixes the following segfaults (which only happen under certain
circumstances):
vtysh -c "configure terminal" -c "router bgp 1" -c "bgp dampening"
vtysh -c "configure terminal" -c "router bgp 1" -c "no bgp dampening"
vtysh -c "configure terminal" -c "router bgp 1" -c "no bgp dampening 45"
vtysh -c "" -c "clear ip bgp dampening"
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The ->hash_cmp and linked list ->cmp functions were sometimes
being used interchangeably and this really is not a good
thing. So let's modify the hash_cmp function pointer to return
a boolean and convert everything to use the new syntax.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Recent changes to the nht code in bgp caused us to actually
keep a true count of v6 nexthop paths when using v4 over v6.
This change introduced a race condition on shutdown on who
got to the bnc cache first( the v4 table or not ). Effectively
we were allowing the continued existence of the path->nexthop
pointing to the freed bnc. This was especially true when
we had route leaking. So when we free the bnc make sure
we clean up the path->nexthop variables pointing at it too.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
If you are using bgp unnumbered( or interface based peers )
when we detect an error give the user a bit more of a clue
what they may have done wrong.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add the ability to aggregate routes to handle
extended communities. Make the actions similiar
to what we do for normal communities.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The evpn_vtep_ip_cmp function must return positive and negative
numbers for when we are doing sorted linked list inserts.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The purpose of adding a l2vni as an sorted list is
shot in the foot when the l2vni compare function only
returns 0 or 1. This will cause subtle crashes when
we add sorted and we end up with multiple list node pointing
to the same thing.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add the '[no] flood <disable|head-end-replication>' command
to the l2vpn evpn afi/safi sub commands for bgp. This command
when entered as 'flood disable' will turn off type 3 route
generation for the transmittal of the type 3 route necessary
for BUM replication on the remote VTEP. Additionally it will
turn off the BUM handling via the new zebra command,
ZEBRA_VXLAN_FLOOD_CONTROL.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Allow the modification of whether or not we will allow
BUM flooding on the vxlan bridge. To do this allow
the upper level protocol to specify via the ZEBRA_VXLAN_FLOOD_CONTROL
zapi message.
If flooding is disabled then BUM traffic will not be forwarded
to other VTEP's.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
1. "show bgp ipv4 json"
- Added "network" field which displays a prefix in 'prefix/prefixlen' format.
2. "show bgp ipv6 json"
- Added "network" field which displays a prefix in 'prefix/prefixlen' format.
- JSON does not have "prefix", "prefixLen" fields which are present in IPv4
command. Added these fields as they are useful.
3. "show bgp ipv4/ipv6 neighbor <neighbor_addr> advertised-routes json"
- Added "network" field.
4. "show bgp ipv4/ipv6 summary json"
- Added "pfxSnt" for peers. This count is obtained from corresponding
update_subgroup.
5. "show bgp neighbor json"
- Added "sentPrefixCounter"
Signed-off-by: Ameya Dharkar <adharkar@vmware.org>
When executing vpn route-map config for importation, the running-config
records vrf import route-map instead. Actually, this is a problem when
restarting configuring when using vpn route-map. The choice is done to
move to vrf format, when at least one import list is created for vrfs.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When a subgroup splits to form a new subgroup because of policy changes
for a peer, new subgroup copies adj out(state about advertised routes)
from the parent subgroup. At the same time, it should also copy
scount(advertised prefix count) to the new subgroup for the count to be
in sync with the adj_out for the subgroup.
Signed-off-by: Ameya Dharkar <adharkar@vmware.org>
When cleaning up a interface string, from the linked list we were
dropping the name pointer which held the allocated martian address
intf string.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Track the memory type associated with the bartian address
interface a bit better, instead of using MTYPE_TMP.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Do a straight conversion of `struct bgp_info` to `struct bgp_path_info`.
This commit will setup the rename of variables as well.
This is being done because `struct bgp_info` is not descriptive
of what this data actually is. It is path information for routes
that we keep to build the actual routes nexthops plus some extra
information.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we add/remove peers we need to do a bit better job
of tracking them in the bgp->peerhash.
1) When we have the doppelganger take over, make sure the
winner is the one represented in the peerhash.
2) When creating the doppelganger, leave the current one
in place instead of blindly replacing it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Cleanup calls where we were passing in the su for
peer creation a tiny bit.
Creating a peer from the cli will always have a conf_if *or*
a su but not both. While a doppelganger will have both.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The bgp->peerhash is a secretive bit of data that we use
to quickly lookup data about peers. Unfortunately
since we had not way to look at it, we had no way
of knowing if it had gotten in or out of sync.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
1. "show bgp ipv4 json"
- Corresponding CLI has "network" field which displays a prefix in
'prefix/prefixlen' format. Added this "network" field to JSON as well.
- Following fields have different names in JSON and CLI.
CLI JSON
metric med
locPrf localPref
path aspath
Added fields "metric", "locPrf" and "path" in JSON for CLI/JSON
consistency. Older JSON fields med, localPref, aspath will be
deprecated in future.
2. "show bgp ipv6 json"
- Similar changes as "show bgp ipv4 json"
- JSON does not have "prefix", "prefixLen" fields which are present in IPv4
command. Added these fields as they are useful.
3. "show bgp ipv4/ipv6 neighbor <neighbor_addr> advertised-routes json"
- Added "network" field.
- Added locPrf, path fields for CLI/JSON consistency. localPref, aspath will
be deprecated in future.
4. "show bgp ipv4/ipv6 summary json"
- Added "pfxRcd" for CLI/JSON consistency.
"prefixReceivedCount" will be deprecated in future.
- Added "pfxSnt" for peers. This count is obtalned from corresponding
update_subgroup. This needed a fix in the code where we copy fields
for a split update_subgroup from the parent update_subgrp.
New subgrp should inherit subgrp->scount(Count of advertized prefixes)
of the parent subgrp.
5. "show bgp neighbor json"
- Added "sentPrefixCounter"
6. "show bgp ipv4/ipv6 <prefix> json"
- Added "metric" field for CLI/JSON consistency.
"med" will be deprecated in future.
Signed-off-by: Ameya Dharkar <adharkar@vmware.org>
The existing commands "ip as-path", "ip community list", "ip extcommunity
list" & "ip largecommunity list" is used to configure both for ipv4 and
ipv6. So the prefix "ip" is removed from these commands.
All the configuration, show related configuration, show running config
& boot up with write memory is also verified with the provided fix.
Signed-off-by: Sarita Patra <saritap@vmware.com>
When this description code was added, it was all dead code since none of
the bools that checked if the communities were present were ever changed
from 0.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Testing Done: bgp-smoke completed with no new failures
While testing 5549 support using global addresses, discovered that
ipv6 nexthop tracking thru a route-reflector didn't work. Since
the next-hop used for remote nexthops resolves to the link-local
of the route-reflector, we need to track it in order to react to
interface down events. Also tripped over a crash in certain cases
which is also resolved in this fix.
During peer startup there exists the possibility that both
locally and remote peers try to start communication at the
same time. In addition it is possible for local configuration
to change at the same time this is going on. When this happens
try to notice that the remote peer may be in opensent or openconfirm
and if so we need to restart the connection from both sides.
Additionally try to write a bit of extra code in peer_xfer_conn
to notice when this happens and to emit a error message to
the end user about this happening so that it can be cleaned up.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Problem reported that frr-relaod.py was not installing an aggregate
properly. Problem was actually that frr-reload.py does the command
twice, and the second time the aggregate command was entered, it would
appear in the config but the aggregate was removed from the bgp table
and not advertised to peers. Solved by noticing when an aggregate
was marked for deletion (info_invalid) and allowing the re-entry if
the old one was being removed.
Ticket: CM-22509
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Problem encountered where using the aggregate-address command in an
evpn environment did not work properly. Depending on the order of
actions, the aggregate may not be created or removed when either the
commands were issued or routes come and go.
Ticket: CM-20585
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Please note this is a Proof of Concept and not actually something
that is ready to commit at this point. The file tools/lua.scr
contains some documentation on how we expect it to work currently.
Additionally not all bgp values have been hooked up into the
ability to lua script yet.
There is still significant work to be done here:
1) Add the ability to pass in more data and to adjust the return values
as appropriate.
To set it up:
1) copy tools/lua.scr into /etc/frr (or whereever the config
directory is )
2) Create a route-map match command:
!
router bgp 55
neighbor 10.50.11.116 remote-as external
!
address-family ipv4 unicast
neighbor 10.50.11.116 route-map TEST in
exit-address-family
!
route-map TEST permit 10
match command mooey
!
3) In the lua.scr file make sure that you have a function
named 'mooey' ( as the above example does ):
function mooey ()
zlog_debug(string.format("Family: %d: %s %d ifindex: %d aspath: %s localpref: %d",
prefix.family, prefix.route,
nexthop.metric, nexthop.ifindex, nexthop.aspath, nexthop.localpref))
nexthop.metric = 33
nexthop.localpref = 13
return 3
end
This example script modifies the metric and localpref currently. I've also provided
a zlog_debug function in lua to allow some simple debugging.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
In bgp if we have not configured bgp we were ignoring
interface based callbacks. Leading to states where
we may not be processing interface information.
Leading to states where we do not actually keep
ifp data. As an example:
Suppose vrf A and vrf B. A has interface swp1.
At the same time we only have a `router bgp 9 vrf B`
When we received the callback for moving swp1
from vrf A to vrf B we were not processing the
move at all and BGP would not consider the interface
part of vrf B at all.
This commit makes bgp pay attention to interface
events irrelevant if bgp is using that vrf. This
is now consistent with how the lib/if* expects
to work and the rest of the daemons in FRR.
Signed-off-by: Donald Sharp <sharpd@cumulsnetworks.com>
Wrapper the get/set of the table->info pointer so that
people are not directly accessing this data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The bgp_nexthop_cache data is stored as a void pointer in `struct bgp_node`.
Abstract retrieval of this data and setting of this data
into functions so that in the future we can move around
what is stored in bgp_node.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The bgp_connected_ref data is stored as a void pointer in `struct bgp_node`.
Abstract retrieval of this data and setting of this data
into functions so that in the future we can move around
what is stored in bgp_node.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The bgp_static data is stored as a void pointer in `struct bgp_node`.
Abstract retrieval of this data and setting of this data
into functions so that in the future we can move around
what is stored in bgp_node.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The bgp_distance data is stored as a void pointer in `struct bgp_node`.
Abstract retrieval of this data and setting of this data
into functions so that in the future we can move around
what is stored in bgp_node.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The aggregate data is stored as a void pointer in `struct bgp_node`.
Abstract retrieval of this data and setting of this data
into functions so that in the future we can move around
what is stored in bgp_node.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Track the refcount a bit differently as that it is possible
to get into situations where we have multiple calls for the
same ifc. So let's just keep a list of the ifc's off of
each `struct bgp_addr` and then keep the hash entry based
upon list count or not.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The `struct bgp_addr` is not needed for anything other than
the address hash. Isolate this data structure so that it
is not polluting up the name space.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There were checks for null pointer after being dereferenced. Checks have
been removed (we've discussed the no need of adding assert()'s because
of similar code not requiring them).
Signed-off-by: F. Aragon <paco@voltanet.io>
All I can see is an unneccessary complication. If there's some purpose
here it needs to be documented...
Signed-off-by: David Lamparter <equinox@diac24.net>
Currently we only support RFC 5549 in bgp via
using the `neighbor swp1 interface remote-as ...`
command. This causes the extended capability
data to be traded as part of the open message.
Additionally at that point in time we notify
zebra to turn on the RA code for that interface
so that the zebra trick of turning the v6 nexthop
into a 169.254.0.1 nexthop and adding a neighbor
entry works.
This code change does 2 things:
1) Modify bgp to pass the extended capability
if we are attempting to establish a v4/unicast
session over a v6 peer. In the past we limited
this to just the LL based peer.
2) Modify the nexthop tracking code to notice
when it receives nexthop data about the global v6
peer to turn on RA code on those interfaces we will
be using. This will allow the v4 route with a v6
nexthop received in zebra to auto translate this
correctly.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Corrections so that the BGP daemon can work with the label manager properly
through a label-manager proxy. Details:
- Correction so the BGP daemon behind a proxy label manager gets the range
correctly (-I added to the BGP daemon, to set the daemon instance id)
- For the BGP case, added an asynchronous label manager connect command so
the labels get recycled in case of a BGP daemon reconnection. With this,
BGPd and LDPd would behave similarly.
Signed-off-by: F. Aragon <paco@voltanet.io>
For tracking the last state of the penalty (struct bgp_damp_info) a 'double'
type was used instead of using the 'unsigned int' being used in the structure.
Detected using ./configure CFLAGS=-Wfloat-equal CC=clang
Signed-off-by: F. Aragon <paco@voltanet.io>
When using `no bgp fast-external-failover` and a interface moves
from one vrf into another we would not fully process the change.
Fix this code path.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The peer->nexthop.ifp pointer must be set when parsing the
attributes in bgp_mp_reach_parse, notice this
and fail gracefully.
Rework bgp_nexthop_set to remove the HAVE_CUMULUS and to
fail the nexthop_set when we have a zebra connection and
no ifp pointer, as that not havinga zebra connection and
no ifp pointer is legal.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When the origin changed we must honor and update the aggregate
to the peer. This code adds a bit of code to the bgp_aggregate_info_same
code to see if the origin has changed and to indicate that it has.
Fixes: #2993
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Whether or not RPKI is enabled during build shouldn't really influence
vtysh; the user can always manually install bgpd_rpki.so later and it
should work. This also means that the behaviour of "RPKI module not
loaded" is consistent regardless of whether it was a compile-time or
runtime decision.
Signed-off-by: David Lamparter <equinox@diac24.net>
config.h (or, transitively, zebra.h) must be the first include file
listed for autoconf things like _GNU_SOURCE and _POSIX_C_SOURCE to work
correctly.
Signed-off-by: David Lamparter <equinox@diac24.net>
Since we're now building through one large Makefile, we can easily put
things with their daemons and crossreference nicely.
Signed-off-by: David Lamparter <equinox@diac24.net>
Note: no more --with-rfp-path on configure - badly messing with the
build system like this really isn't how to do a conditional external
dependency.
Signed-off-by: David Lamparter <equinox@diac24.net>
Switch bgp and ripngd to use the new aggregate table and
route data structures. This was mainly a search and replace
operation.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Problem reported that some bgp and ospf json commands did not return
any json output at all if the bgp/ospf instance did not exist.
Additionally, some bgp and ospf json commands did not return any json
output if the instance existed but no neighbors were defined. This
fix makes these commands more consistent in returning empty braces for
json output and issue a message if not using json output. Additionally,
made the flag "use_json" a bool to make it consistent since previously,
it had been defined as an int, char, u_char, and bool at various places.
Ticket: CM-21040
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Because a VRF name can be used for default VRF, or an alias of an
already created VRF can be passed as parameter, the default VRF name
must be found out. This avoids creating double BGP instances for
example.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The Vrf aliases can be known with a specific hook. That hook will then,
from zebra propagate the information to the relevant zapi clients.
The registration hook function is the same for all daemons.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Coded as part of #2684 and most code written while participating at
BornHack@2018.
bgp_route.c: Changes regarding adding explanations for the IANA
well-known communities added in #2684
Signed-off-by: Christoffer <netravnen@gmail.com>
While perusing CONFDATE I noticed that we had a couple
CONFDATE 201805, which we were not picking up( for other
reasons and fixed in a different PR ). But upon investigation
of these I noticed that the commits where in 201805, so these
CONFDATES should be in 2019
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
If a command returns a nonzero exit status and VTYSH has a corresponding
command, VTYSH will skip executing its own version. If this happens in a
command that changes CLI nodes we get node desynchronization.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Several zlog_warns were being used to tell the end
user that bgp had detected a bug. These all look like information
added during development that can be noted as debugs or logged
as an error situation.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
A warn with a backtrace does not need another warn
to file an issue with Quagga, so just remove it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Scan all bgp vrf instances and respective L3VNI against the VNI which is being configured.
Ticket:CM-21859
Testing Done:
Configure l3vni,
try to configure same vni as l2vni under router bgp, address-family
l2vpn evpn.
The configuration is rejected.
show evpn vni
VNI Type VxLAN IF # MACs # ARPs # Remote VTEPs Tenant VRF
4001 L3 vx-4001 0 0 n/a vrf1
TOR(config)# router bgp 5546
TOR(config-router)# address-family l2vpn evpn
TOR(config-router-af)# vni 4001
% Failed to create VNI
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Root Cause: In the function bgp_show_table(), we are creating a
json object and a json array with the same name as “json_paths”.
First it will create a json object variable "json_paths" pointing
to the memory allocated for the json object. Then it will create
a json array for each bap node rn (if rn->info is available) with
the same name as json_paths. Because of this, json_paths which was
pointing to the memory allocated for the json object earlier, now
will be overwritten with the memory allocated for the json array.
As per the existing code, at the end of each iteration loop of bgp
node, it will deallocate the memory used by the json array and
assigned NULL to the variable json_paths. Since we don’t have the
pointer pointing to the memory allocated for json object, will be
not able to de-allocate the memory, which is a memory leak here.
Fix: Removing this json object since it is never getting used in
this function.
Testing: Reproduced the memory leak with valgrind.
With the fix, memory leak gets resolved and checked with valgrind.
Signed-off-by: Sarita Patra saritap@vmware.com
In some situations rtrlib does not release the locks for its internal
data structures before calling a callback. This can lead to deadlocks
when a lot of routes must be revalidated because the sync socket buffer
will fill up and block the rtrlib thread. The bgpd main thread then
waits for rtrlibs internal locks to be released indefinitely.
This is fixed by using nonblocking sockets instead of blocking ones and
setting a flag to revalidate everything, if it would block.
Signed-off-by: Marcel Röthke <marcel.roethke@haw-hamburg.de>
* Added parameter in bgp_redistribute_set() to indicate change
in redistribute option
* If there is change, call bgp_redistribute_unreg() to withdraw routes
Signed-off-by: kssoman <somanks@vmware.com>
Make the wart slightly less bad... also there is still a possible write
after free here. This needs to be fixed again, properly, by some
structure changes.
Signed-off-by: David Lamparter <equinox@diac24.net>
e.g.
pimd/pim_oil.c: In function ‘pim_channel_oil_dump’:
pimd/pim_oil.c:51:19: error: ‘%d’ directive writing between 1 and 11 bytes into a region of size 10 [-Werror=format-overflow=]
Build on gcc-8.2.0 is warning-free after this patch.
Signed-off-by: David Lamparter <equinox@diac24.net>
Avoid memory leak in bgp flowspec list.
Usage of bool parameter instead of int, to handle the number of entries
PBR.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Implement procedures similar to what is specified in
https://tools.ietf.org/html/draft-malhotra-bess-evpn-irb-extended-mobility
in order to support extended mobility scenarios in EVPN. These are scenarios
where a host/VM move results in a different (MAC,IP) binding from earlier.
For example, a host with an address assignment (IP1, MAC1) moves behind a
different PE (VTEP) and has an address assignment of (IP1, MAC2) or a host
with an address assignment (IP5, MAC5) has a different assignment of (IP6,
MAC5) after the move. Note that while these are described as "move" scenarios,
they also cover the situation when a VM is shut down and a new VM is spun up
at a different location that reuses the IP address or MAC address of the
earlier instance, but not both. Yet another scenario is a MAC change for an
attached host/VM i.e., when the MAC of an attached host changes from MAC1 to
MAC2. This is necessary because there may already be a non-zero sequence
number associated with MAC2. Also, even though (IP, MAC1) is withdrawn before
(IP, MAC2) is advertised, they may propagate through the network differently.
The procedures continue to rely on the MAC mobility extended community
specified in RFC 7432 and already supported by the implementation, but
augment it with a inheritance mechanism that understands the relationship
of the host MACIP (ARP/neighbor table entry) to the underlying MAC (MAC
forwarding database entry). In FRR, this relationship is understood by the
zebra component which doubles as the "host mobility manager", so the MAC
mobility sequence numbers are determined through interaction between bgpd
and zebra.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
The code for this was always there but was not kicking in because of an
incorrect dependency on is_evpn_enabled. This API attempts to locate the
default instance from bgp_master's instance list. Only the instance
currently being deleted has already been removed from the instance list
by the time bgp_delete->bgp_zebra_instance_deregister is executed.
Symptom of this bug used to show up when a default instance is deleted
and created again. In that case bgp_zebra_instance_register would not be
effective as zebra ignores the register as dup (dereg didn't happen in the
first place) so bgpd wouldn't reload already configured L2-VNIs.
root@cel-sea-03:~# net show bgp l2vpn evpn vni |grep 1000
* 1000 L2 169.253.0.11:9 6646:1000 6646:1000 vrf1
root@cel-sea-03:~# grep "router bgp" /etc/frr/frr.conf
router bgp 6646
root@cel-sea-03:~# sed -i 's/6646/6656/' /etc/frr/frr.conf
root@cel-sea-03:~# grep "router bgp" /etc/frr/frr.conf
router bgp 6656
root@cel-sea-03:~# systemctl reload frr
root@cel-sea-03:~# net show bgp l2vpn evpn vni |grep 1000
root@cel-sea-03:~#
Fix simply changes the order of dereg to make
bgp_zebra_instance_deregister actually happen (by doing it before the
default instance is removed from the master list).
Ticket: CM-21566
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
In bgp_keepalives.c, it was noticed that we were
ensuring that we called an intialization function first,
but this is a development escape in that once this
was fixed we never see it. So if a developer moves
this assumption around, let's crash the program and
lead them to this spot instead of silently ignoring
the problem.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There exists a few places where actual debugs were being
displayed as warns. Convert them over to debugs and
guard as appropriate.
Signed-off-by: Donald Sharp <sharpd@cumulsunetworks.com>
backet->data must be non-NULL( look at hash_get ) as such
we do not need to check for NULL values for this when
we retrieve data from the backet.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* Use the correct license header
* Stop headers from including themselves
* Use uniform relative include conventions
* Ensure that sources include what they use
* Turn off clang-format around struct array blocks
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Classful networking has been obsolete for ages and there is currently an
inconsistency between `show ip route` and `show bgp`, where the first
one always displays the CIDR mask while the second one hides classful
network masks.
This commit adjusts the behavior of `show bgp` to always show the CIDR
mask for a route, even when it is classful.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
Problem reported that when systemctl restart networking or switchd
performed, not all imported prefixes were successfully restored.
Ticket: CM-21684
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Ensure that the presence of L3VNI is checked before we generate
Router MAC and L3 Route Target extended communities. Without this
check, the router would send an all-zeros RMAC in some situations,
which may cause problems for receivers.
Ticket: CM-21014
Testing Done:
a) Verification of failed scenario
b) Interop verification by Scott Laffer
c) evpn-smoke
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
There is no need to check for failure of a ALLOC call
as that any failure to do so will result in a assert
happening. So we can safely remove all of this code.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Don't show BFD commands with timers since it might confuse users
("show running-config" won't display timers in client daemons anymore),
but keep accepting this command from previous configurations.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
When BFD timers are configured, don't show it anymore in the daemon
side. This will help us migrate the timers command from daemons to
`bfdd`.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
When calling route_map_finish, every place that we do we must
first set the deletion event to NULL, or we will create an infinite
loop, if we are using the delayed route-map application code.
As such we might as well just make the route_map_finish code
do this work, as that there is really no viable alternative here
and route_map_finish should only be called on shutdown.
This fixes an infinite loop in zebra on shutdown when there
are route-maps.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When a bgp instance is stopped, with a `no router bgp..`
make sure any timers associated with the instance are stopped
as well.
This issue was discovered when a customer issued a `no router bgp`
while a maxmed timer was operative. The max-med timer used the
`struct bgp *` as the passed in value for the thread. The
thread eventually popped after the cleanup and attempted to use
data off in lala land and crashed
Ticket: CM-21895
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The dn_count for dynamic Peers was not being updated when
using json output.
Signed-off-by: Dongling Duan <dlduan@amazon.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Updated the list with listed well-known communities from document IANA's https://www.iana.org/assignments/bgp-well-known-communities/bgp-well-known-communities.txt with last update date as of 2018-03-07.
- GRACEFUL_SHUTDOWN moved to 2nd entry in all lists in touched code.
- Added ACCEPT_OWN - [RFC7611]
- Added ROUTE_FILTER_TRANSLATED_v4 - currently [draft-l3vpn-legacy-rtc]
- Added ROUTE_FILTER_v4 - currently [draft-l3vpn-legacy-rtc]
- Added ROUTE_FILTER_TRANSLATED_v6 - currently [draft-l3vpn-legacy-rtc]
- Added ROUTE_FILTER_v6 - currently [draft-l3vpn-legacy-rtc]
- Added LLGR_STALE - currently [draft-uttaro-idr-bgp-persistence]
- Added NO_LLGR - currently [draft-uttaro-idr-bgp-persistence]
- Added accept-own-nexthop - currently [draft-agrewal-idr-accept-own-nexthop]
- Added BLACKHOLE - [RFC7999]
- Added NOPEER - [RFC3765]
Avoid displaying default configured local preference as
part of bgp route's detail output.
Local preference is for iBGP learnt route's. The value could be
default (100) or configured value (via routemap or local pref config cmd).
show bgp afi safi (brief output) does not display,
if the local pref attribute is not set.
Similarly, show bgp afi safi detail route output should display
if the the attribute is set, and should not display configured value.
This way both output would be consistent.
The configured local preference can be seen via running-config.
Ticket:CM-12769
Reviewed By:
Testing Done:
eBGP output:
show bgp ipv4 45.0.3.0/24
BGP routing table entry for 45.0.3.0/24
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
MSP1(uplink-1) MSP2(uplink-2)
Local
0.0.0.0 from 0.0.0.0 (27.0.0.9)
Origin incomplete, metric 0, weight 32768, valid,sourced, bestpath-from-AS Local, best
AddPath ID: RX 0, TX 7
Last update: Thu Jul 26 02:10:02 2018
iBGP output:
show bgp ipv4 unicast 6.0.0.16/32
BGP routing table entry for 6.0.0.16/32
Paths: (1 available, best #1, table default)
Not advertised to any peer
Local
6.0.0.16 (metric 20) from tor-12(6.0.0.16) (6.0.0.16)
Origin incomplete, metric 0, localpref 100, valid, internal, bestpath-from-AS Local, best
AddPath ID: RX 0, TX 13
Last update: Thu Jul 26 05:26:18 2018
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
The bi->net pointer that is being unlocked had a commit
that removed the `bi->net = NULL;` recently. This code
was preventing a use after free crash being experienced
in other code paths. While commit 37e679629f was fixing
a different code path crash.
Make the parent->net pointer aware it may be locked/freed
from multiple places and to not NULL the pointer to it
unless we have actually freed the data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There is a default BGP VPN and BGP VRF instance in L3VPN configuration.
The routes are imported and exported between BGP VPN and BGP VRF.
Suppose there is one route in BGP VRF and exported to BGP VPN.
In BGP VPN there is bgp_info struct with bgp_info_extra struct has parent pointer pointing to the bgp_info of BGP VRF.
We take the lock for bgp_node and bgp_info of BGP VRF in the context of BGP VPN.
bgp_info has a back pointer to bgp_node via net.
Now when we have done "no rd vpn" in BGP VRF then in bgp_info_extra_free we have to free the parent resources.
In this context only unlocking is required. It should not set the BGP VRF (bgp_info->net) to NULL.
Signed-off-by: vishaldhingra vdhingra@vmware.com
Adding EVPN prefix of Type 2, 3 and 5 routes to bgp updates
prefix filters.
Ticket:CM-14476
Testing Done:
Configure multiple evpn options under 'debug bgp updates prefix'.
Below is the running-config output.
MAC-IP route with just MAC:
debug bgp updates prefix l2vpn evpn type macip mac
00:02:00:0a:0a:0a
MAC-IP route with MAC and IP:
debug bgp updates prefix l2vpn evpn type macip mac
00:02:00:00:00:0c ip 45.0.1.9
MAC-IP route with just MAC and IPv6:
debug bgp updates prefix l2vpn evpn type
macip mac 00:02:00:00:00:0a ip 2001:fee1:0:1::8
Type-3:
debug bgp updates prefix l2vpn evpn type multicast ip 27.0.1.19
Type-5:
debug bgp updates prefix l2vpn evpn type prefix
ip 2060:1:1:1::/64
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
When configuring an interface, the no local-install any command appears,
and leads to confusions. because the effect of that command differs if
it is executed after local-install <interfaces> or before executing
local-install <interfaces>, the proposal fix here is to suppress that
command from the vty available commands.
PR=59595
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Acked-by: Alain Ritoux <alain.ritoux@6wind.com>
because the IP destination criterium may match several entries, the show
command may return more than one entry.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When adding an entry, a check is done in order to flush previously
configured entries. The whole parameters are checked so as to not remove
some entries that have ipset entries equal, but not iptable settings.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Instead of relying on jhash_1word for some parameters that are not 32
bit size, the jash(pointer, len) function is used.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Because one flowspec entry can create 1-N bgp pbr entries, the list is
now updated and visible. Also, because the bgp_extra structure is used,
this list is flushed when the bgp_extra structure is deleted.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
EVPN ND ext community support NA flag R-bit, to have proxy ND.
Set R-bit in EVPN NA if a given router is default gateway or there is a
local
router attached, which can be determine based on local neighbor entry.
Implement BGP ext community attribute to generate and parse R-bit and
pass along zebra to program neigh entry in kernel.
Upon receiving MAC/IP update with community type 0x06 and sub_type 0x08,
pass the R-bit to zebra to program neigh entry.
Set NTF_ROUTER in neigh entry and inform kernel to do proxy NA for EVPN.
Ref:
https://tools.ietf.org/html/draft-ietf-bess-evpn-na-flags-01
Ticket:CM-21712, CM-21711
Reviewed By:
Testing Done:
Configure Local vni enabled L3 Gateway, which would act as router,
checked
show evpn arp-cache vni x ip <ip of svi> on originated and remote VTEPs.
"Router" flag is set.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
This commit removes various parts of the bgpd implementation code which
are unused/useless, e.g. unused functions, unused variable
initializations, unused structs, ...
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
The current behavior of the `bgp default shutdown` command is to set the
state of all newly configured peers to shutdown. This leads to a problem
when restarting bgpd, because all peers will then be seen as newly
configured, which leads to all peers being set to shutdown after each
restart.
This behavior is undesired and not common when comparing the
implementation against other vendors. This commit moves the `bgp default
shutdown` configuration underneath the peer-group and peer
configuration, to ensure that existing peers will not be set to shutdown
after a daemon restart.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
In Symmetric routing case, L3VNI stores evpn MAC_IP routes
as IP_PREFIX routes in associated bgp_vrf and fib.
When vxlan device for l3vni goes down, triggers l3vni delete
in bgp.
As part l3vni delete, evpn ip prefix routes associated
with the vni need to be withdrawn from zebra as well
bgpinfo needs to be freed.
bgp_delete does not free bgp_info associated
to evpn ip prefix routes (link to bgp_vrf).
Call to uninstall_evpn_route_entry_in_vrf() properly
cleanup bgp_info as well triggers appropriate updates.
Ticket:CM-21443
Testing Done:
On DUT, bringup symmetric routing configuration, learn
EVPN Type-2 and Type-3 Routes.
Type-2 MAC_IP routes will be stored as ip_prefix in vrf table
during l3vni bring up.
Remove L3vni, deletes all ip_prefix routes from the zebra, kernel
vrf route table and bgp_info is freed.
Check the show bgp memory stats for bgp_info post l3vni flap.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
The warning given by PVS-Studio is related to per-element overflow (there is
no real overflow, because of how elements are mapped in the union). This
same warning is typically reported by Coverity, too.
Signed-off-by: F. Aragon <paco@voltanet.io>
If a cache server was added after rpki was started it's tr_socket would
not be initialized. This would lead to a segfault if the rtr manager
ever decides to switch to that socket or if rpki support is stopped.
Signed-off-by: Marcel Röthke <marcel.roethke@haw-hamburg.de>
Issue 2473
VRF-VPN route-leaking configuration commands assumed existence of
default bgp instance. If a non-default vrf configuration occurred
before the default vrf configuration, it would result in a (NULL)
dereference to the non-existent default vrf.
This change 1) detects non-existence of default vrf and skips corresponding
RIB updating that normally occurs during configuration changes of the
route-leaking parameters; and 2) when the default bgp instance is defined,
runs the deferred RIB updating.
In vpn_leak_to_vrf_update_all(), replace early return if bgp_vpn is NULL
with assert, as the former would lead to subtly wrong RIB contents. The
underlying issue that led to commit 73aed5841a
should be fixed by the above changes.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
This correction fixes three bugs detected by Clang scan:
Bug Group: Logic error
Bug Type: Dereference of null pointer
File: bgpd/bgp_evpn.c
Function: bgp_evpn_unconfigure_import_rt_for_vrf
Line: 4246
File: isisd/isis_spf.c
Function: isis_print_paths
Line: 69 (two bugs of same type in one line)
Signed-off-by: F. Aragon <paco@voltanet.io>
In order to make EVPN behavior work without special casing
the code, bring the evpn commands under HAVE_CUMULUS into
the fold.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The return value can be ignored because in case of error both the 'afi'
and 'safi' variables are set to the invalid values (AFI_MAX, SAFI_MAX),
and the invalid values are handled properly afterwards in the 'default'
blocks.
Signed-off-by: F. Aragon <paco@voltanet.io>
Some values for icmp type/code can not be encoded like port source or
port destination. This is the case of 0 value that is authorized for
icmp.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
As the other enumerate list, icmp type and code are handled as the other
combinations. The icmp type and code options are the last options to be
injected into PBR. If icmp type is present only, all the filtering will
apply to this icmp type. if icmp code is present only, then all the
combination will be done with icmp type ranging from 0 to 255 values.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The recursive algorithm was taking into account the fact that all the
bpof structures were filled in. Because the dscp value was not given,
the pkt_len parsing could not be achieved. Now the iteration takes into
account each type according to the previous one, thus guaranting all
parameters to be parsed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The flowspec fragment attribute is taken into account to be pushed in
BGP policy routing entries. Valid values are enumerate list of 1, 2, 4,
or 8 values. no combined value is supported yet.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
As fragment bitmask and tcpflags bitmask in flowspec protocol is encoded
in the same way, it is not necessary to differentiate those two fields.
Moreover, it overrides the initial fragment limit set to 1. It is now
possible to handle multiple framgent values.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The packet length can be injected from fs entry with an enumerate list;
the negation of the value is also taken into account.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
So as to add or remove entries with flowspec or operations like tcp
flags or dscp enum list, a mechanism is put in place that adds
recursivity.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
If one dscp value or an enumerate list of or values of dscp are
provided, then the bgp pbr entries created will take into account the
dscp values.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Before adding/removing to zebra, flowspec entries parses the list of
combinations or avaialble and creates contexts in order to be injected
to zebra.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
tcp flags combinations ( or enumerates) are hosted in a structure that
will be analysed later, when wanting to inject that information to
zebra.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The flowspec enumerate list can either be and values or or values.
In the latter case, a list is created that will be used later.
Also, the API supports the check for both and or or operations. This API
does not permit to handle both and and or operations at the same time.
The list will have to be either and or or. An other API retrieves the
operator unary value that is used: and or or. or 0 is the two operators
are used at the same time.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Because the Flowspec entries are parsed first, then injected to Zebra,
there are cases where the install feedback from zebra is not received.
This leads to unnecessary add route events, whereas one should be
enough.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Those flags can be shared between BGP and Zebra. That is why
those flags are moved to common pbr.h header file.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
To handle FS params between FS RIB and BGP PBR entities, a structure
intermediate named bgp_pbr_filter is used, and contains all filtering
information that was before passed as a parameter.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
To know which entry is set/unset, a debug handler is present, that
displays which entry is injected/removed to/from zebra.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
It is possible for flowspec entries containing ICMP rule to insert PBR
entries based on ICMP type and ICMP code.
Flowspec ICMP filtering can either have icmp type or icmp code or both.
Not all combinations are permitted:
- if icmp code is provided, then it is not possible to derive the
correct icmp value. This will not be installed
- range of ICMP is authorised or list of ICMP, but not both.
- on receiving a list of ICMPtype/code, each ICMP type is attempted to
be associated to ICMP code. If not found, then ICMPtype is combined
with all known ICMP code values associated to that ICMP type.
- if a specific ICMP type/code is needed, despite the ICMP code/type
combination does not exist, then it is possible to do it by forging a
FS ICMP type/code specific for that.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Issue 2381: interface based routes not marked "up" when they originate
in zebra, redistributed to bgp vrf, then imported to vpn and then
imported by another vrf.
Routes that are redistributed into BGP from zebra should not get
nexthop tracking (the assumption is that the originating protocol
is responsible to export or withdraw the route according to its own
notion of nexthop status).
The vpn-vrf route-leaking code checks the source route sub_type to
decide whether to use nexthop tracking on the resulting leaked route.
A route that is redistributed from zebra into bgp will have
sub_type==BGP_ROUTE_REDISTRIBUTE. If it is leaked to the vpn RIB,
the resulting vpn RIB route will have sub_type==BGP_ROUTE_IMPORTED.
If THAT vpn route is leaked to another vrf, the original code will
examine only the leak-source route sub_type and, since it is
not BGP_ROUTE_REDISTRIBUTE, will wrongly try to use nexthop tracking
on the new route in the final vrf.
This change modifies the leak function to track back up the
parent links to the ultimate parent of the leak source route
and look at that route's sub_type instead.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
The route_map_walk_update_list callback function
never uses the return code, so just remove it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
route_map_mark_updated has a `int del_later` variable
that is passed in but never used. Just remove it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When bgp vrf is configured with non-default
RD value, config flag is set.
Upon removing non-default RD value the flag was not reset,
thus displayed default RD value in running-config.
router bgp 5550 vrf vrf1
rd 45.0.2.2:5
Unset the RD configuration flag under bgp_vrf instance.
Ticket:CM-20206
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
This commit fixes the issue mentioned in #2419, which is caused by a
double-free. The problem of the current implementation is that
*bgp_input_modifier* already frees the passed attributes under specific
circumstances, which can then lead to a double-free as *bgp_attr_undup*
does not check if the attributes are set to NULL.
As it is not transparent to the function caller if the attributes get
freed or not and the similar function *bgp_output_modifier* also does
not flush the passed attributes, the line has been removed altogether.
All callers of *bgp_input_modifier* already deal by themself with
freeing/flushing/unduping BGP attributes, so it is safe to remove.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
This commit finalizes the previous commits which introduced a generic
approach for making all BGP peer and address-family attributes
overrideable by keeping track of the configuration origin in separate
internal structures.
First of all, the test suite was greatly extended to also check the
internal data structures of peer/AF attributes, so that inheritance for
internal values like 'peer->weight' is also being checked in all cases.
This revealed some smaller issues in the implementation, which were also
fixed in this commit. The test suite now fully passes and covers all the
usual situations that should normally occur.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
This commit introduces BGP peer-group overrides for the last set of
peer-level attrs which did not offer that feature yet. The following
attributes have been implemented: description, local-as, password and
update-source.
Each attribute, with the exception of description because it does not
offer any inheritance between peer-groups and peers, is now also setting
a peer-flag instead of just modifying the internal data structures. This
made it possible to also re-use the same implementation for attribute
overrides as already done for peer flags, AF flags and AF attrs.
The `no neighbor <neigh> description` command has been slightly changed
to support negation for no parameters, one parameter or * parameters
(LINE...). This was needed for the test suite to pass and is a small
change without any bigger impact on the CLI.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
This commit implements BGP peer-group overrides for the timer flags,
which control the value of the hold, keepalive, advertisement-interval
and connect connect timers. It was kept separated on purpose as the
whole timer implementation is quite complex and merging this commit
together with with the other flag implementations did not seem right.
Basically three new peer flags were introduced, namely
*PEER_FLAG_ROUTEADV*, *PEER_FLAG_TIMER* and *PEER_FLAG_TIMER_CONNECT*.
The overrides work exactly the same way as they did before, but
introducing these flags made a few conditionals simpler as they no
longer had to compare internal data structures against eachother.
Last but not least, the test suite has been adjusted accordingly to test
the newly implemented flag overrides.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
This commit cleans up some ugly leftovers from previous flag-override
implementation and refactors the AF-flag override implementation to
match the same behavior the newly added peer-flag override
implementation has.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
The current implementation of the overrides for peer address-family
attributes suffered a bug, which caused all peer-specific attributes to
be lost when the peer was added to a peer-group which already had that
specific address-family active.
This commit extends the *peer_group2peer_config_copy_af* function to
respect overridden flags properly. Additionally, the arguments of the
macros *PEER_ATTR_INHERIT* and *PEER_STR_ATTR_INHERIT* have been
reordered to be more consistent and easy to read.
This commit also adds further test cases to the BGP peer attributes test
suite, so that this kind of error is being caught in future commits. The
missing AF-attribute *distribute-list* has also been added to the test
suite.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
The current implementation of peer flags (e.g. shutdown, passive, ...)
only has partial support for overriding flags of a peer-group when the
peer is a member. Often settings might get lost if the user toys around
with the peer-group configuration, which can lead to disaster.
This commit introduces the same override implementation which was
previously integrated to support proper peer flag/attribute override on
the address-family level. The code is very similar and the global
attributes now use their separate state-arrays *flags_invert* and
*flags_override*.
The test suite for BGP peer attributes was extended to also check peer
global attributes, so that the newly introduced changes are covered. An
additional feature was added which allows to test an attribute with an
*interface-peer*, which can be configured by running `neighbor IF-TEST
interface`. This was introduced so that the dynamic runtime inversion of
the `extended-nexthop` flag, which is only enabled by default for
interface peers, can also be tested.
Last but not least, two small changes have been made to the current bgpd
implementation:
- The command `strict-capability-match` can now also be set on a
peer-group, it seems like this command slipped through while
implementing peer-groups in the very past.
- The macro `COND_FLAG` was introduced inside lib/zebra.h, which now
allows to either set or unset a flag based on a condition. The syntax
for using this macro is: `COND_FLAG(flag_variable, flag, condition)`
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
When evpn configured wiht route-map with vni which is not
configured. Upon receiving evpn routes (i.e Type-2, Type-3),
route-map match will be triggered. Since there is no l2vni
exists in db, some of the member fields in bgp_info (i.e.
dummy_info_extra) are passed uninitialized to evpn filter match cb.
This results in inaccessible memory causes crash.
Fix is to memset the bgp_info prior to passing to evpn filter cb.
In evpn vni filter cb, ensure to have NULL check for member filed
of the bgp_info.
memset bgp_info at few places where it is passed to route_match.
Ticket:CM-21335
Reviewed By:
Testing Done:
Configure route-map with not configured l2vni
Simulate to learn l2vpn type-2, 3 route
Restart frr.service with below config
address-family l2vpn evpn
neighbor fear route-map EVPN_VNI out
route-map EVPN_VNI deny 10
match evpn vni 140010
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Crash w/ an assert if someone calls bgp_delete with a
NULL parameter as opposed to crashing when we dereference
the pointer a bit later.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The process of BGP shutdown hard free's memory irrelevant to
the fact that another process may be using that memory still
in route leaking scenario's.
As a temporary fix find the default instance and free it
last.
Ticket: CM-21068
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The bgp_info_extra_free code was the correct place to free
up data associated with the bgp_info pointer when we are
deleting the bgp_info node.
Additionally, if we have a parent pointer, we may not have a net
pointer. So make sure we do.
Finally clean up the bgp_info_extra_free code so it is a bit
easier to read. Use variables instead of multiple level
of casting.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
L2VNI route-distinguisher and route-target configuartions
should only applied under DEFAULT VRF bgpd instance.
Add newline to each vni display.
router bgp 65006
address-family l2vpn evpn
vni 1000101
route-target import 1:1000101
do not allow under
router bgp 65006 vrf RED
Ticket:CM-20204
Reviewed By:
Testing Done:
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
* Move configure flag propagations out of user flags
* Use AC_SUBST to transfer flag values to Automake
* Set default AM_CFLAGS and AM_CPPFLAGS in common.am and change child
Makefiles to modify these base variables
* Add flag override to turn off all sanitizers when building clippy
* Remove LSAN suppressions blacklist as it's no longer needed
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
With a new version of clang 6.0, the compiler is detecting more
issues where we may be possibly be truncating the output string.
Fix by increasing the size of the output string to make the compiler
happy.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The labeled unicast and unicast tables have been combined
into the unicast table. Additionally we have a restriction
where if you configure labeled unicast you cannot configure
unicast. This created a bug with 'show bgp ipv4 labeled-unicast summ'
command where we were displaying NoNeg, because v4 has been intentionally
turned off.
Modify the code so that when we are looking up if we have negotiated
a capapbility we use the correct one, while still using the appropriate
table for prefix count.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
These two functions are functionally the same, except
bgp_aggregate_route is meant to handle the addition and
deletion of routes, while aggregate_add is meant for all of them.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The aggregated route was being sent in updates to peers every
time a route changed that we were aggregating. Modify
the code such that we only send aggregated route updates
if we actually have something different to tell the peer.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The function bgp_aggregate_delete function was forward
declared and not static. Move it so we can clean that
up.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This is a transitional commit, to get us where we want to go.
Seperate out the install/removal of the aggregate route from
the bgp_aggregate_delete and bgp_aggregate_route functions.
In the future we'll write a bit of code to determine if the
aggregate add has actually changed any information we care
about.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We were allowing useless aggregation commands (/32 and /128).
These were being silently accepted and nvgenned and then
just ignored.
When a user enters a value that should be rejected tell
them and reject.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Make bgp_aggregate_route easier to read. It was indented so many
levels that it was extremely hard to figure out what it was doing.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The #define AGGREGATE_NEXTHOP_CHECK has not been used
for a very very long time. Since this is effectively
dead code, let's remove it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The safi passed in to short-circuit the aggregate lookup
adds code complexity and little speed improvements for
the case where we actually may have aggregates configured!
Since bgp_table_top_nolock() actually tells us if there
are any aggregates installed and safely returns if there
is nothing to do, trust it. As that we know for those
safi's were we don't want to have, we dissallow the
creation via the cli anyways.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The bgp_aggregate_set/unset functions are only called from the cli
invocations which control what AFI/SAFI we are looking at. Tests
for safi are unimportant.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The bgp data structures:
bgp->vnihash
bgp->vrf_export_rtl
bgp->vrf_import_rtl
bgp->l2vnis
Must always be valid data structures. So remove the tests
that ensure that they are.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we are determining the state of a peer, we sometimes
detect that we should update the peer->su. The bgp->peer_hash
keeps a hash of peers based upon the peer->su. This requires
us to release the stored value before we re-insert it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Programs that link to libnetsnmp must be compiled using a special set
of flags as specified by the "net-snmp-config --base-cflags" command
(whose output is stored in the SNMP_CFLAGS variable). The problem is
that "net-snmp-config --base-cflags" can output -std=c99 in addition to
other compiler flags in some platforms, and this breaks the build since
FRR souce code makes use of some GNU compiler extensions (e.g. allow
trailing commas in function parameter lists). In order to solve this
problem, append -std=gnu99 after SNMP_CFLAGS in all makefiles where this
variable is used. This way the -std=c99 flag will be overwritten when it's
present. Source files that don't link to libnetsnmp will be compiled using
either -std=gnu99 or -std=gnu11 depending on the compiler availability.
Fixes#1617.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This command needs to be deprecated. It partially implements
a refusal to create multiple instances. If you do not need
multiple instances, just don't create them in the cli instead.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This command needs to be deprecated. It sets a small variety
of options via the BGP_OPT_CONFIG_CISCO flag. Set for removal
in 1 year.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Cleanup the leaked ecommunity data that we may have on shutdown.
Cleanup leaked vrf name strings on shutdown.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There exists cases where we will attempt to hard delete
the bgp instance( say a `no router bgp` is issued )
when we have vrf route leaking. If we do have this
lock the bgp instance of the originator and do not
let it be deleted out from under us until we are
finished processing.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we are shutting down, there exists a code path
where the connected table leaks some memory. Cleanup
the code to remove the memory.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The rearrangement of where the decision point of
filling in the aggregate information, must have allowed
SA to find a path of code where we may use ifindex uninitialized.
While I don't think this is possible to happen, make this issue
go away.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We have 2 code paths that were duplicating a bunch of code
for the deletion of connected prefixes.
This simplifies the code path and makes the code look a bit
cleaner.
I did not touch the _add path because the v4 if statement
had some code I did not have time to look into. Future project.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The call to str2prefix_rd when we get to this point of the
code cannot fail. As such let's just ignore the return code.
Found by Coverity SA.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Issue Found by Coverity Scan. When we call peer_clear we
are checking the return code in every other call. Add
a bit of extra code to notice the failure and note it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The if statement had a second instance of the same variable
to test as part of the statement.
Found by SA.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The aggregate-address command is not creating the null0
route. This got lost somewhere in the last year or so.
Add this ability back for BGP route installs into
zebra.
We need this aggregate route installed into the rib
because we are drawing this traffic to us irrelevant
of the number of routes we do have for that prefix.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This commit fixes all outstanding style/formatting issues as detected by
'git clang-format' or 'checkpath' for the new peer-group override
implementation, which spanned across several commits.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
The previous commit introduced very strict unit tests which check all
three involved components (config input, config output, internal data
structures) which revealed two more bugs in the peer-group override
implementation.
This commit fixes overrides for 'allowas-in <number>' and
'unsuppress-map', which both had a small mistake/typo causing those
issues.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
This commit fixes peer-group overrides for inverted AF flags. This
implementation is currently only being used by the three 'send-community'
flags. Commit 70ee29b4d introduced generic support for overriding AF
flags, but did not support inverted flags.
By introducing an additional array on the BGP peer structure called
'af_flags_invert' all current and future flags which should work in an
inverted way can now also be properly overridden.
The CLI commands will work exactly the same way as before, just that 'no
<command>' now sets the flag and override whereas '<command>' will unset
the flag and remove the override.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
This commit adds the same peer-group override capabilites as d122d7cf7
for all filter/map options that can be enabled/disabled on each
address-family of a BGP peer.
All currently existing filter/map options are being supported:
filter-list, distribute-list, prefix-list, route-map and unsuppress-map
To implement this behavior, a new peer attribute 'filter_override' has
been added together with various PEER_FT_ (filter type) constants for
tracking the state of each filter in the same way as it is being done
with 'af_flags_override'.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
The current implementation for overriding peer-group configuration on a
peer member consists of several bandaids, which introduce more issues
than they fix. A generic approach for implementing peer-group overrides
for address-family flags is clearly missing.
This commit implements a generic and sane approach to overriding
peer-group configuration on a peer-member. A separate peer attribute
called 'af_flags_override' which was introduced in 04e1c5b is being used
to keep track of all address-family flags, storing whether the
configuration is being inherited from the parent-group or overridden.
All address-family flags are being supported by this implementation
(note: flags, not filters/maps) except 'send-community', which currently
breaks due to having the three flags enabled by default, which is not
being properly handled within this commit; all flags are supposed to
have an 'off'/'false' state by default.
In the interest of readability and comprehensibility, the flag
'send-community' is being fixed in a separate commit.
The following rules apply when looking at the new peer-group override
implementation this commit provides:
- Each peer-group can enable every flag (except the limitations noted
above), which gets automatically inherited to all members.
- Each peer can enable each flag independently and/or modify their
value, if available. (e.g.: weight <value>)
- Each command executed on a neighbor/peer gets explicitely set as an
override, so even when the peer-group has the same kind of
configuration, both will show up in 'show running-configuration'.
- Executing 'no <command>' on a peer will remove the peer-specific
configuration and make the peer inherit the configuration from the
peer-group again.
- Executing 'no <command>' on a peer-group will only remove the flag
from the peer-group, however not from peers explicitely setting that
flag.
This guarantees a clean implementation which does not break, even when
constantly messing with the flags of a peer-group. The same behavior is
present in Cisco devices, so people familiar with those should feel safe
when dealing with FRRs peer-groups.
The only restriction that now applies is that single peer cannot
disable a flag which was set by a peer-group, because 'no <command>' is
already being used for disabling a peer-specific override. This is not
supported by any known vendor though, would require many specific
edge-cases and magic comparisons and will most likely only end up
confusing the user. Additionally, peer-groups should only contain flags
which are being used by all peer members.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
