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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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
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>
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>
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 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>
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>
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>
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>
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>
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>
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>
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>
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
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>
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>
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>
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>
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>
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>
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>
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>
* 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>
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>
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>
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>
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 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 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>
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>
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>
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>
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>
Problem reported due to tab completion showing all possible peers
in every vrf, but when neighbor in wrong vrf entered "no such
neighbor" is the error message. Making it slightly more clear
with "no such neighbor in the view/vrf" to clue the user that they
may have specified the wrong vrf.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
This commit moves the command 'bgp enforce-first-as' from global BGP
instance configuration to peer/neighbor configuration, which can now be
changed by executing '[no] neighbor <neighbor> enforce-first-as'.
End users can now enforce sane first-AS checking on regular sessions
while e.g. disabling the checks on routeserver sessions, which usually
strip away their own AS number from the path.
To ensure backwards-compatibility, a migration routine was added which
automatically sets the 'enforce-first-as' flag on all configured
neighbors if the old global setting was activated. The old global
command immediately disappears after running the migration routine once.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
The current implementation does not respect the AFI+SAFI combination of
a peer when executing a non-soft (hard) clear. An example would be the
command `clear bgp ipv4 unicast *`, which will clear all BGP peers, even
those that do not have IPv4-Unicast activated.
This commit fixes that behavior by applying the same rules to both soft
and hard clear commands, so that peers without a matching AFI+SAFI
combination will be no longer modified.
Additionally, this commit adds warning messages to all `clear bgp
[<afi>] [<safi>] <target>` commands when no matching peers with the given
AFI+SAFI combination could be found.
Both existing and new warning messages have been extended to also
mention the AFI+SAFI combination that is missing, which is more helpful
to the user than a generic expression 'No peer configured'.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
The current implementation of building JSON output is greatly different
for large communities compared to standard communities. This is mainly
noticeable by the missing 'list' attribute, which usually offers an
array of all communities present on a BGP route.
This commit adds the missing functionality of properly returning a
'list' attribute in JSON output and also tries a similar approach like
the standard communities are using to implement this feature.
Additionally, the 'format' specifier has been completely removed from
large communities string/JSON rendering, as the official RFC8092 specifies that
there is only one canonical representation:
> The canonical representation of BGP Large Communities is three
> separate unsigned integers in decimal notation in the following
> order: Global Administrator, Local Data 1, Local Data 2. Numbers
> MUST NOT contain leading zeros; a zero value MUST be represented with
> a single zero. Each number is separated from the next by a single
> colon. For example: 64496:4294967295:2, 64496:0:0.
As the 'format' specifier has not been used/checked and only one
canonical representation exists per today, there was no reason to keep
the 'format' parameter in the function signature.
Last but not least, the struct attribute 'community_entry.config' is no
longer being used for large communities and instead 'lcommunity_str' is
being called to maintain a similar approach to standard communities.
As a side effect, this also fixed a memory leak inside 'community_entry_free'
which did not free the allocated memory for the 'config' attribute when
dealing with a large community.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
Before this fix, both real neighbors and peer-groups were lumped
together in auto-completion and it didn't work at all for
peer-groups. This fix changes that behavior to do the right
thing.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
In the FRR implementation of EVPN,
eBGP leaf-spine peering for EVPN is fully supported by allowing
the next hop to be propagated and not rewritten at each hop.
There are other changes also related to route import to facilitate this.
However, propagating the next hop is not correct in some cases.
Specifically, if the DC is comprised of multiple PODs
with distinct intra-POD and inter-POD VxLAN tunnels,
EVPN routes received from an adjacent POD by a border/exit leaf
must be propagated into the local POD with the next hop rewritten (to self).
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
The loop over all afi's implies that these commands actually need
to loop over all afi's to check the vpn policy. We know the
appropriate afi based upon the node we are in. So just return
the correct afi to look at and then just apply it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Prior to this fix, you could configure importing a vrf from inside
the same vrf. This can lead to unexpected behavior in the leaking
process. This fix disallows that behavior.
Ticket: CM-20539
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Tripped over a crash running the cli_crawler that occurred when the
sequence was doing "import vrf NAME" and "no import vrf NAME" inside
a vrf but a default bgp instance had not been created. This fix
auto-creates the default instance if the "import vrf NAME" is
entered and a default instance does not exist.
Ticket: CM-20532
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Prior to this fix, the import vrf route-map command only worked
if the route-map existed prior to the command. Additionally, if
the import vrf route-map command was issued without an existing
route-map, the imported prefixes were not removed. This fix
resolves both of thes mis-behaviors. bgp-smoke run with same
failures as base.
Ticket: CM-20459
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: CCR-7358
Found that when doing "import vrf default" in another vrf, an
extra line was added to the configuration in error. This fix
resolves that incorrect configuration. Manual testing will be
attached to the defect.
Ticket: CM-20467
Signed-off-by: Don Slice <dslice@cumulustnetworks.com>
Reviewed by: Donald Sharp <sharpd@cumulusnetworks.com>
Added the cli for doing route-map filtering on imported routes via
the new "import vrf route-map <NAME> command.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Implement fixes for route leaking between VRFs through BGP, especially for
the scenario where routes are leaked from a VRF X to multiple other VRFs.
This include making sure that import and export happen via the global VPN
table, setting RD correctly and proper handling for multiple import/export.
Ticket: CM-20256
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
When the `import vrf XXX` command is entered under
an afi/safi for bgp and the XXX vrf bgp instance
does not yet exist, auto-create it using the same
ASN that the we are importing into.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
add the `import vrf XXXX` command
router bgp 4 vrf DONNA
<config>
!
router bgp 4 vrf EVA
<config>
address-family ipv4 uni
import vrf DONNA
!
!
This command will allow for vrf EVA to specify that it would like
to receive the routes from vrf DONNA into it's table.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* Remove unused parameter
* Restore behavior described by function comment
* Eliminate NPD caught by static analysis
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Add support for CLI "auto" keyword in vrf->vpn export label:
router bgp NNN vrf FOO
address-family ipv4 unicast
label vpn export auto
exit-address-family
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
This work is derived from a work done by China-Telecom.
That initial work can be found in [0].
As the gap between frr and quagga is important, a reworks has been
done in the meantime.
The initial work consists of bringing the following:
- Bringing the client side of flowspec.
- the enhancement of address-family ipv4/ipv6 flowspec
- partial data path handling at reception has been prepared
- the support for ipv4 flowspec or ipv6 flowspec in BGP open messages,
and the internals of BGP has been done.
- the memory contexts necessary for flowspec has been provisioned
In addition to this work, the following has been done:
- the complement of adaptation for FS safi in bgp code
- the code checkstyle has been reworked so as to match frr checkstyle
- the processing of IPv6 FS NLRI is prevented
- the processing of FS NLRI is stopped ( temporary)
[0] https://github.com/chinatelecom-sdn-group/quagga_flowspec/
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: jaydom <chinatelecom-sdn-group@github.com>
The following types are nonstandard:
- u_char
- u_short
- u_int
- u_long
- u_int8_t
- u_int16_t
- u_int32_t
Replace them with the C99 standard types:
- uint8_t
- unsigned short
- unsigned int
- unsigned long
- uint8_t
- uint16_t
- uint32_t
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This commit is relying on bgp vpn-policy. It is needed to configure
several bgp vrf instances, and in each of the bgp instance, configure
the following command under address-family ipv4 unicast node:
[no] rt redirect import RTLIST
Then, a function is provided, that will parse the BGP instances.
The incoming ecommunity will be compared with the configured rt redirect
import ecommunity list, and return the VRF first instance of the matching
route target.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
- vpn_leak_to_vpn_active(): check instance type
- vpn_leak_prechange(): qualify with test for active
- vpn_leak_postchange(): remove duplicated call to
vpn_leak_from_vrf_update_all()
- bgp_vty.c: Avoid null-pointer dereference for command "no rt vpn import"
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
PR #1739 added code to leak routes between (default VRF) VPN safi and unicast RIBs in any VRF. That set of changes included temporary CLI including vpn-policy blocks to specify RD/RT/label/&c. After considerable discussion, we arrived at a consensus CLI shown below.
The code of this PR implements the vpn-specific parts of this syntax:
router bgp <as> [vrf <FOO>]
address-family <afi> unicast
rd (vpn|evpn) export (AS:NN | IP:nn)
label (vpn|evpn) export (0..1048575)
rt (vpn|evpn) (import|export|both) RTLIST...
nexthop vpn (import|export) (A.B.C.D | X:X::X:X)
route-map (vpn|evpn|vrf NAME) (import|export) MAP
[no] import|export [vpn|evpn|evpn8]
[no] import|export vrf NAME
User documentation of the vpn-specific parts of the above syntax is in PR #1937
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
- add "debug bgp vpn label" CLI
- improved debug messages for "debug bgp bestpath"
- send vrf label to zebra after zebra informs bgpd of vrf_id
- withdraw vrf_label from zebra if zebra informs bgpd that vrf_id is disabled
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
This commit fixes the handling of incoming parameters passed in
following vty functions:
clear ip bgp ipv6 [safi] prefix []
clear ip bgp [vrf ] ipv6 [safi] prefix []
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
This worked for unnumbered peers but not for numbered peers. This is
before the fix:
router bgp 100
coalesce-time 1000
neighbor FOO peer-group
neighbor FOO remote-as external
neighbor swp1 interface peer-group FOO
neighbor 1.1.1.1 peer-group FOO
!
line vty
exec-timeout 0 0
!
end
cel-redxp-10# wr
Note: this version of vtysh never writes vtysh.conf
Building Configuration...
Integrated configuration saved to /etc/frr/frr.conf
[OK]
cel-redxp-10# conf t
cel-redxp-10(config)# router bgp
cel-redxp-10(config-router)# no neighbor swp1 interface peer-group FOO
cel-redxp-10(config-router)# no neighbor 1.1.1.1 peer-group FOO
cel-redxp-10(config-router)# do show run
Building configuration...
Current configuration:
!
frr version 4.1-dev
frr defaults datacenter
hostname cel-redxp-10
!
service integrated-vtysh-config
!
password cn321
!
log syslog
!
router bgp 100
coalesce-time 1000
neighbor FOO peer-group
neighbor FOO remote-as external
neighbor 1.1.1.1 remote-as external
!
address-family ipv4 unicast
no neighbor 1.1.1.1 activate
exit-address-family
!
line vty
exec-timeout 0 0
!
end
cel-redxp-10(config-router)#
After the fix "no neighbor 1.1.1.1 peer-group FOO" removes the 1.1.1.1
neighbor.
We need a better error message. "Multiple BGP processes are configured"
doesnt makes sense anymore as with l3vni,
we could have multiple auto configured bgp instances.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
We've run across an issue where the local connected
ip address is not being removed in some error condition.
During trackdown it was noticed that we cannot look
at this table for views/vrf's. While we don't have the
bug tracked down yet this will help us figure it out.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Problem reported with output of the command "show bgp vrf all
neighbor x.x.x.x" not limiting the output to that peer in any vrf.
This fix corrects the logic to display by neighbor
(ipv4/ipv6/interface) in any vrf.
Ticket: CM-17377
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
The bestpath multipath-relax setting was added to the output of
"show ip bgp neighbor json" several months ago but this is not
the correct place to display that information and this fix removes
it from there. The multipath-relax setting was also added
to the output of "show ip bgp sum json" which is fine.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Adds ability to specify that peers should be administratively shutdown
when first configured.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Remove the ability to attempt to configure a couple of options on
directly connected neighbors that don't make sense for them, as well as
the soft error handling code.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
If we have configured neighbor 1.1.1.1 for an afi/safi but they have not
activated that afi/safi with us then display "NoNeg" in the state column
of the summary output. This is to make troubleshooting afi/safi
easier.
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
The bgpTimerUp value was incorrectly named, add
a correct name bgpTimerUpMsec and add some
code to allow for deprecation.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
For some reason bgp is calculating the peer uptime
in miliseconds incorrectly. Additionally we have
the peer_uptime function call that should be doing this!
But since we've choosen different names for the json output
we cannot fix it at this point.
uptime contains the number of seconds of uptime here. Just
multiply by 1k and display that( as peer_uptime does )
Fixes: #1585
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Was using 0 as a sentinel value, so user couldn't configure 0 as the
value of the coalesce timer.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
BGP VRF can be created/deleted either via config or via l3vni add/del.
We need to handle various sequences.
1. If user config is presented, an l3vni del should not delete the vrf instance
2. do not write bgp config in show running for auto created vrf
2. If l3vni present, disallow the cli for deleting bgp vrf instance
3. If l3vni is added and vrf config is present set the flags properly
4. if bgp vrf is configured unset the AUTO flag
Ticket: CM-18630
Review: CCR-6906
Testing: Manual
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Since coalesce time is now heuristically adjusted based on peer count,
we need to separate out specific configuration by the user from the
current value. Behavior established is to not adjust if the user has a
value set.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
bgpd supports setting a write-quanta that serves as a hint on how many
packets to write per I/O cycle. Now that input is buffered, it makes
sense to add the equivalent parameter for how many packets are processed
per cycle. This is *not* how many packets are read off the wire per I/O
cycle; rather it is how many packets are processed from the input buffer
in a given cycle after having been read off the wire and sanitized.
Since these values must be used from multiple threads, they have also
been made atomic.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
* Move and modify all network input related code to bgp_io.c
* Add a real input buffer to `struct peer`
* Move connection initialization to its own thread.c task instead of
piggybacking off of bgp_read()
* Tons of little fixups
Primary changes are in bgp_packet.[ch], bgp_io.[ch], bgp_fsm.[ch].
Changes made elsewhere are almost exclusively refactoring peer->ibuf to
peer->curr since peer->ibuf is now the true FIFO packet input buffer
while peer->curr represents the packet currently being processed by the
main pthread.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
* Remove t_write
* Remove t_keepalive
These have been replaced by pthreads and are no longer needed. Since
some code looks at these values to determine if the threads are
scheduled, also add a new bitfield to store the same information.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Building a communities json object every time is
both expensive and memory wasteful. Modify
code to only build the json object when needed.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Fixes a bug whereby all peer-groups would be shown even when a
particular peer-group was specified for display.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Problem reported that we weren't adjusting the keepalive timer
correctly when we negotiated a lower hold time learned from a
peer. While working on this, found we didn't do inheritance
correctly at all. This fix solves the first problem and also
ensures that the timers are configured correctly based on this
priority order - peer defined > peer-group defined > global config.
This fix also displays the timers as "configured" regardless of
which of the three locations above is used.
Ticket: CM-18408
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: CCR-6807
Testing-performed: Manual testing successful, fix tested by
submitter, bgp-smoke completed successfully
When retrieving information about neighbors or summary in json
add some information about what bestPath particulars we have for
this bgp session.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
VARIABLE tokens must be all uppercase, this allows us to support WORD
tokens that begin with an uppercase letter. The "Null0" keyword is an
example of where this is needed.
The only VARIABLE we had that wasn't already all uppercase was
ASN:nn_or_IP-address:nn
1) Add hash names to all hash_create calls
2) Fix community_hash, ecommunity_hash and lcommunity_hash key
creation
3) Fix output of community and lcommunity iterators( why would
we want to see the memory location of the backet? ).
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Some of this was so egregiously stupid, I couldn't look at it without
gouging my eyes out...
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
afi_header_vty_out() is easily replaced with vty_frame(), which means we
can drop a whole batch of "int *write" args as well as the entirety of
bgp_config_write_family_header().
=> AFI/SAFI config writing is now a lot simpler.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
