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>
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>
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>
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>
Added improved error message text to other places that could also
encounter the same condition. In testing found that in certain
case, duplicate error messages were previously issued. This fix
also removes the duplicates.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
There exists code paths where the rn was being used after free.
This eliminates these code paths.
Fixes: CM-21019
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This commit tries to adapt a similar codeflow within the `show bgp [afi]
[safi] neighbor <neighbor> advertised-routes` command compared to its
`received-routes` and `filtered-routes` opponents. Some branching code
has been restructured to achieve this.
Additionally, this commit fixes a memory leak within `received-routes`
(and `filtered-routes`, although the issue has been present before the
previous commit!) where the previous implementation forgot to
deduplicate the BGP attributes.
When a user called `<...> received-routes route-map <RM-TEST>` and that
routemap changed any AS path or community parameters, the duplicated
memory for these parameters was never freed. This has been fixed by
ensuring to call `bgp_attr_undup()` accordingly.
Signed-off-by: Pascal Mathis <mail@pascalmathis.com>
This commit changes the behavior of `show bgp [afi] [safi] neighbor
<neighbor> received-routes [json]` to return all received prefixes
instead of filtering rejected/denied prefixes.
Compared to Cisco and Juniper products, this is the usual way how this
command is supposed to work, as `show bgp [afi] [safi] neighbor
<neighbor> routes` will already return all accepted prefixes.
Additionally, the new command `show bgp [afi] [safi] neighbor <neighbor>
filtered-routes` has been added, which returns a list of all prefixes
that got filtered away, so it can be roughly described as a subset of
"received prefixes - accepted prefixes".
As the already available `filtered_count` variable inside
`show_adj_route` has not been used before, the last output line
summarizing the amount of prefixes found was extended to also mention
the amount of filtered prefixes if present.
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>
Imported routes in a VRF routing table have a reference to their parent
route entry which resides in the EVPN or IPVPN routing table. Ensure that
this reference uses appropriate locking so that the parent entry doesn't
get freed prematurely.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
(cherry picked from commit 13cb6b22ba9d558b1b4a1e8752f63f13242462a7)
Conflicts:
bgpd/bgp_mplsvpn.c
Ticket: CM-20471
Testing Done:
a) Ran vrf_route_leak tests without fix and hit crash, ran twice with fix
and did not see the crash.
b) Ran evpn-smoke and ensured there were no new failures.
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>
We install type-5 routes as ipv4/ipv6 unicast routes in the vrf table.
along with these routes, we also install the RMAC
and the nexthop Neigh entries.
There might be scenarios were the bestpath has changed and
we are now pointing to a new nexthop with a different RMAC.
As per BGP logic, we just send an update for the route and the nexthop
is replaced. However, this causes problem because the RMAC and neigh entry
corresponding to the previous nexthop are still lingering in the system.
We need to clear those entries for proper functoning.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
A newly added ipv4/ipv6 route in BGP RIB might be advertised as type-5 EVPN route.
The user might have configured a route-map for advertising type-5 routes.
We need to apply this route-map while advertising ipv4/ipv6 routes as type-5.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
EVPN prefix depends on the EVPN route type.
Currently, in FRR we have a prefix_evpn/evpn_addr which relates to a evpn prefix.
We need to convert this to encompass an union of various EVPN route-types.
This diff handles the necessary code changes to adopt the new struct evpn_addr.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Add a policy-route API to handle flowspec entry.
The entry is analysed, converted, and
selected if it is possible to inject the flowspec entry in local policy
routing entries.
redirect IP and redirect VRF actions are handled. The former extracts
the IPv4 address to redirect traffic to. The latter calculates the
matching VRF to redirect traffic to.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
As part of recent vpn-vrf leaking changes, it is now possible for a
route to refer to a nexthop in a different vrf. There is also a new
route flag that means "when announcing this route, indicate myself
as the next-hop."
route_vty_out(): nexthops are appended with:
"@VRFID" (where VRFID is the numerical vrf id) when different from
the route's vrf;
"<" when the route's BGP_INFO_ANNC_NH_SELF is set
This change also shows the route table's vrf id in the table header.
route_vty_out_detail(): show nexthop's vrf and announce-nh-self flag if
appropriate.
Both functions are also augmented to add json elements nhVrfId, nhVrfName,
and announceNexthopSelf as appropriate.
The intent of these changes is to make it easier to understand/debug
the relationship between a route and its nexthops.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
The vrf 2 vrf route leaking auto-derives RD and RT and
installs the routes into the appropriate vpn table.
These routes when a operator configured ipv[4|6] vpn
neighbors were showing up off box. The RD and RT
values choosen are localy significant but globaly
useless and may cause confusion.
Put a special bit of code in to notice that we
should not be advertising these routes off box.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Here we have a block conditional on the nullity of a pointer, followed
by a dereferennce of the same pointer. Move the deref into the
conditional block.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Most presumably, the nexthop IP is present, only when ECOM redirect IP
is present. The nexthop is displayed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Routes that have labels must be sent via a nexthop that also has labels.
This change notes whether any path in a nexthop update from zebra contains
labels. If so, then the nexthop is valid for routes that have labels.
If a nexthop update has no labeled paths, then any labeled routes
referencing the nexthop are marked not valid.
Add a route flag BGP_INFO_ANNC_NH_SELF that means "advertise myself
as nexthop when announcing" so that we can track our notion of the
nexthop without revealing it to peers.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
This command gives detail about a FS entry which contains an IP that
matches one of the rules of the FS entry. The output is the same output
as when one does show bgp ipv4 flowspec detail
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The json format is returd when requested from the two commands:
- show bgp ipv4 flowspec
- show bgp ipv4 flowspec detail
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The show bgp ipv4 flowspec routine is made available, displays the
flowspec rules contained in the BGP FIB database, as well as the actions
to be done on those rules. Two routines are available:
show bgp ipv4 flowspec
show bgp ipv4 flowspec detail
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Flowspec entries do not need aggregation feature.
Actually, all flowspec entries are unique.
So, some check is done against aggregate functionalities in the code.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Ensure that only EVPN routes are flagged as such when installing into or
withdrawing from zebra, the earlier check broke L3VPN or VRF route-leaked
routes. Also, fix an incorrect check related to imported routes in path
selection.
Updates: bgpd: Use BGP_ROUTE_IMPORTED for EVPN [vivek]
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.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>
When uninstalling routes from zebra, ensure that the BGP instance for
which processing is being done is used to derive the VRF. It is incorrect
to derive the VRF from the peer when dealing with scenarios like VRF route
leaking, EVPN symmetric/external routing etc., where the peer which sourced
the route could belong to a different VRF.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Ticket: CM-18413
Reviewed By: CCR-6778
Testing Done: Manual testing of BGP route withdraw/delete, bgp-min
When a peer is removed the routes are withdrawn via bgp_process_main_one
As such we need to put a bit of code in to handle this situation
for the vpn/vrf route leaking code.
I think this code path is also called for when a vrf's route is
changed and I believe we will end up putting a bit more code
here to handle the nexthop changes.
I've also started trying to document the bgp_process_main_one
function a bit better.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Set EVPN routes imported into a VRF to (sub)type BGP_ROUTE_IMPORTED and
use this for passing appropriate information to zebra. This is needed
because relying on the Router MAC for this purpose was incorrect and
impacted routing to/from external destinations, particularly for IPv6.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
In bgp_update_receive the first thing we do is establish
that the peer->status is Established. We then do a bunch
of work and call bgp_nlri_parse where we break out for
each address family. Each AFI is then checking for
being peer->status is Established again. There is no
point in checking this again.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
- 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>
Received PMSI tunnel attributes (in EVPN type-3 route) were not recognized.
Parse them and display the tunnel type when looking at routes. Note that
the only tunnel type currently supported is ingress replication (IR). A
warning message will be logged if the received tunnel type is something
else, but the attribute is otherwise ignored.
Updates: a21bd7a (bgpd: add PMSI_TUNNEL_ATTRIBUTE to EVPN IMET routes)
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Type-5 routes can be useful in multiple scenarios such as advertise-subnet,
default-originate etc. Currently, the code has a restriction that to allow
advertising type-5 routes, user has to first enable advertise ipvX command.
This restriction is not necessary and should be removed.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
EVPN type-2 and type-5 routes received with a L3 VNI and corresponding RTs
are installed into the appropriate BGP RIB. Ensure that these routes are not
re-injected back into EVPN as type-5 routes when type-5 advertisement is
enabled; only regular IPv4 routes (and IPv6 routes in future) in the RIB
should be injected into EVPN.
As a benefit of this change, no longer restrict that EVPN type-5 routes
should be non-host routes - i.e., allow /32 IPv4 routes (and /128 IPv6
routes in future).
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Ticket: CM-19456
Reviewed By: CCR-7117
Testing Done:
1. Manual replication of problem and verification of fix
2. evpn-min
Turns out we had 3 different ways to define labels
all of them overlapping with the same meanings.
Consolidate to 1. This one choosen is consistent
naming wise with what the *bsd and linux kernels
use.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When an IPv4 or IPv6 unicast route is injected into EVPN as a type-5 route
(upon user configuration), ensure that the source route (best path)'s path
attributes are used to build the EVPN type-5 route. This will result in
correct AS_PATH and ORIGIN attributes for the type-5 route so that it doesn't
appear that all type-5 routes are locally sourced. This is necessary to
ensure that external paths (IPv4 or IPv6 from EBGP peer) are preferred over
internal EVPN paths, if both exist.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ticket: CM-19051
Reviewed By: CCR-7009
Testing Done: Verify failed scenario
In EVPN symmetric routing, not all subnets are presents everywhere.
We have multiple scenarios where a host might not get learned locally.
1. GARP miss
2. SVI down/up
3. Silent host
We need a mechanism to resolve such hosts. In order to achieve this,
we will be advertising a subnet route from a box and that box will help
in resolving the ARP to such hosts.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
When doing symmetric routing,
EVPN type-2 (MACIP) routes need to be advertised with two labels (VNIs)
the first being the L2 VNI (identifying the VLAN) and
the second being the L3 VNI (identifying the VRF).
The receive processing needs to handle one or two labels too.
Ticket: CM-18489
Review: CCR-6949
Testing: manual and bgp/evpn/mpls smoke
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
-Werror=sign-compare is failing with signed/unsigned usage
in the conditional expression.
Fixes: #1593
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Problems reported with inconsistent use of parameters for bgp network
statements. Converted 12 DEFUNs to 2 DEFPY statements, making the
parameter use consistent with the exception of keeping the "backdoor"
keywork ipv4 only. Also verified that if a route-map or label-index
is specified in the "no" case it matches what had been previously
defined. Manual testing looks good and bgp-smoke will be performed
before pushing.
Ticket: CM-16860
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: CCR-7056
The json code was freeing json_paths and then
turning around and free'ing it again. Newer
versions of json-c have started to assert
this bad behavior.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When bgp has a metric butt-load of routes w/ ecmp, this command
can take an inordinate amount of time to run and complete via
vtysh.
Converting the bgp route output in this case back to not
using the json pretty-print drops ~2 minutes of runtime
off.
It is assumed that if users would like pretty output they
can run it through an appropriate tool via a pipe command.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The prefix_rd2str uses a buffer size of RD_ADDRSTRLEN.
Modify the code to consistently use this for all of BGP.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ignoring the return from argv_find_and_parse_afi
makes the SA system assume that you could pass a AFI_MAX
value to bgp_show_route. Which in turn would cause
an array out of bounds read.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
So we have the ability to apply speculative route-maps to
neighbor display to see what the changes would look like
via some show commands. When we do this we make a
shallow copy of the attr data structure and then pass
it around for applying the routemap. After we've applied
this route-map and displayed it we really need to clean
up memory that the route-map application applied.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we are applying an experimental route-map type
to a peer( as part of a show command ) save and
restore the peer's ->rmap_type.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we display the advertised-routes and we don't have a route-map
to apply do not re-apply the route-map. This does two things:
1) Fixes a display issue with the show command.
2) More importantly stops leaking memory like a sieve for when
you have a full bgp table.
Fixes: #1345
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This commit fixes a bug where json output would display
',,,,,,,' because we were deciding to not display information
about some routes due to a selection criteria.
Signed-off-by: Donald Sharp <sharpd@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>
The creation of the json object for the aspath
is both memory intensive and expensive to
create. Only create the json object when
it is needed and stash it for further usage
at that point.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When BGP is being redistributed prefixes, allow it to
understand the nexthop type.
This fixes the issue where a blackhole route was being interpreted
to having a nexthop of 1.0.0.0( ruh-roh!!! ). This broke
downstream neighbors as that they would receive a 1.0.0.0 nexthop,
which is bad, very very bad.
This commit sets us up for the future where we can match
a route-map against a nexthop type. In that bgp is
now at least nominally paying attention to the type.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ignore the return value of some functions in the places we know they
can't fail, and other small fixes.
Regarding the change in bgpd/rfapi/rfapi_rib.c, asserting that
rfapiRaddr2Qprefix() didn't fail is the common idiom inside the rfapi
code.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
These commands don't belong in the BGP_IPV6L_NODE node anymore. A similar
change was done for BGP_IPV4L_NODE in commit 9bedbb1e5.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The json option for displaying a bgp table
with route Distinguishers in it was not properly
working. This code cleans this issue up.
Additionally attempt to make the code a bit
easier to read and handle.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Perf results at scale( >1k peers) showed a non-trivial
amount of time spent in bgp_multiaccess_check_v4. Upon
function examination we are looking up the nexthops
connected node in each call as well as having to unlock
it after each iteration. Rewrite to lookup the nexthop
node once.
This should reduce the node lookup by aproximately 1/2
which should yield some performance results. There are
probably better things to do here but would require
deeper thought.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This fixes the broken indentation of several foreach loops throughout
the code.
From clang's documentation[1]:
ForEachMacros: A vector of macros that should be interpreted as foreach
loops instead of as function calls.
[1] http://clang.llvm.org/docs/ClangFormatStyleOptions.html
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
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
bgp_route.c:6393:7: error: ‘len’ may be used uninitialized in this function
gcc 5.4.0 isn't intelligent enough to notice it's set on all paths.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
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>
Some differences compared to the old API:
* Now the redistributed routes are sent using address-family
independent messages (ZEBRA_REDISTRIBUTE_ROUTE_ADD and
ZEBRA_REDISTRIBUTE_ROUTE_DEL). This allows us to unify the ipv4/ipv6
zclient callbacks in the client daemons and thus remove a lot of
duplicate code;
* Now zebra sends all nexthops of the redistributed routes to the client
daemons, not only the first one. This shouldn't have any noticeable
performance implications and will allow us to remove an ugly exception
we had for ldpd (which needs to know all nexthops of the redistributed
routes). The other client daemons can simply ignore the nexthops if
they want or consult just the first one (e.g. ospfd/ospf6d/ripd/ripngd).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
There are several code paths that dump nodes to the queue for route
processing in a loop. This patch tries to reduce memory allocations/freeing
(work item, list node) and thread scheduling overhead by batching the nodes
in a simple queue list.
In the past when route processing wasn't event driven (bgp_scan()), this used
to have a noticeable impact in table loading, convergence time and memory heap
fragmentation due to reduced alloc's/free's.
Signed-off-by: Jorge Boncompte <jbonor@gmail.com>
When the MAC changes for a local neighbor, ensure that the neighbor data
structure as well as the link between the neighbor and MAC data structures
is updated correctly.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-17565
Reviewed By: CCR-6605
Testing Done: Manual, evpn-smoke
Ensure that the registration for the "in" label for a unicast prefix
is done only in the default instance. The zebra label manager as well
as other code in BGP only has support for assigning labels in the
default instance.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-17110
Reviewed By: CCR-6588
Testing Done: Manual tests, mpls
There are two parts to this commit:
1. create a database of self tunnel-ip for used in martian nexthop check
In a CLAG setup, the tunnel-ip (VNI UP) notification comes before the clag-anycast-ip comes up in the system.
This was causing our self next hop check to fail and we were instaling routes with martian nexthop in zebra.
We need to keep this info in a seperate database for all local tunnel-ip.
This database will be used in parallel with the self next hop database to martian nexthop checks.
2. When a local VNI comes up, update the tunnel-ip database and filter routes in the RD table if necessary
In case of EVPN we might receive routes from clag peer before the clag-anycast ip and VNI is up on the system.
We will store the routes in the RD table for later processing.
When VNI comes UP, we loop thorugh all the routes and install them in zebra if required.
However, we were missing the martian nexthop check in this code path.
From now onwards, when a VNI comes UP,
we will first update the tunnel-ip database
We then loop through all the routes in RD table and apply martian next hop filter if required.
Things not covered in this commit but are required:
This processing is needed in general when an address becomes a connected address.
We need to loop through all the routes in BGP and apply martian nexthop filter if necessary.
This will be taken care in a seperate bug
Ticket:CM-17271/CM-16911
Reviewed By: ccr-6542
Testing Done: Manual
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
When issuing a 'show ip bgp' command and the nexthop is
a interface, if the interface name was greater than 7 characters
we would arbitrarily start a new-line and setup the next
line to start at the wrong spot.
Modify the interface field to allow 16 characters than 7( to
match v6 display ), and if the interface name is greater than
16 characters properly setup the next line for display
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
1. provision to add match clause with a vni under route-map
Ticket: CM-16349
Review: CCR-6190
Unit-test: Manual (logs attached to ticket)
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
1. Added support to create mac filters
2. Enabled route-map commands for EVPN address family
3. Provision to add mac filters under match clause in route-maps
Ticket: CM-16349
Review: CCR-6190
Unit-test: Manual (logs attached to ticket)
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
If you are doing multipath in a VRF and bounce one of the multipaths for
a prefix, bgp is not updating the zebra entry for that prefix with the
new multipaths. We start with:
cel-redxp-10# show bgp vrf RED ipv4 unicast 6.0.0.16/32
BGP routing table entry for 6.0.0.16/32
Paths: (4 available, best #4, table RED)
Advertised to non peer-group peers:
spine-1(swp1) spine-2(swp2) spine-3(swp3) spine-4(swp4)
104 65104 65002
fe80::202:ff:fe00:2d from spine-4(swp4) (6.0.0.12)
(fe80::202:ff:fe00:2d) (used)
Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 104
AddPath ID: RX 0, TX 21
Last update: Tue Aug 1 18:28:33 2017
102 65104 65002
fe80::202:ff:fe00:25 from spine-2(swp2) (6.0.0.10)
(fe80::202:ff:fe00:25) (used)
Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 102
AddPath ID: RX 0, TX 20
Last update: Tue Aug 1 18:28:33 2017
103 65104 65002
fe80::202:ff:fe00:29 from spine-3(swp3) (6.0.0.11)
(fe80::202:ff:fe00:29) (used)
Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 103
AddPath ID: RX 0, TX 17
Last update: Tue Aug 1 18:28:33 2017
101 65104 65002
fe80::202:ff:fe00:21 from spine-1(swp1) (6.0.0.9)
(fe80::202:ff:fe00:21) (used)
Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 101, best
AddPath ID: RX 0, TX 8
Last update: Tue Aug 1 18:28:33 2017
cel-redxp-10#
cel-redxp-10# show ip route vrf RED 6.0.0.16/32
Routing entry for 6.0.0.16/32
Known via "bgp", distance 20, metric 0, vrf RED, best
Last update 00:00:25 ago
* fe80::202:ff:fe00:21, via swp1
* fe80::202:ff:fe00:25, via swp2
* fe80::202:ff:fe00:29, via swp3
* fe80::202:ff:fe00:2d, via swp4
cel-redxp-10#
And then on spine-1 we bounce all peers
spine-1# clear ip bgp *
spine-1#
On the leaf (cel-redxp-10) we remove the route from spine-1
cel-redxp-10# show ip route vrf RED 6.0.0.16/32
Routing entry for 6.0.0.16/32
Known via "bgp", distance 20, metric 0, vrf RED, best
Last update 00:00:01 ago
* fe80::202:ff:fe00:25, via swp2
* fe80::202:ff:fe00:29, via swp3
* fe80::202:ff:fe00:2d, via swp4
cel-redxp-10#
So far so good. The problem is when the session to spine-1 comes back up
bgp will mark the flag from spine-1 as `multipath` but does not update
zebra. We end up in a state where BGP has 4 paths flags as multipath but
only 3 paths are in the RIB.
This reverts commit c14777c6bf.
clang 5 is not widely available enough for people to indent with. This
is particularly problematic when rebasing/adjusting branches.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The label initializer & nhrpd variable are just to shut up GCC 7,
the other two are actual bugs.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
This allows frr-reload.py (or anything else that scripts via vtysh)
to know if the vtysh command worked or hit an error.
Most of the attributes in 'struct attr_extra' allow for
the more interesting cases of using bgp. The extra
overhead of managing it will induce errors as we add
more attributes and the extra memory overhead is
negligible on anything but full bgp feeds.
Additionally this greatly simplifies the code for
the handling of data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
bgpd: Fix missing label set
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Core EVPN route handling functionality. This includes support for the
following:
- interface with zebra to learn about local VNIs and MACIPs as well as
to install remote VTEPs (per VNI) and remote MACIPs
- create/update/delete EVPN type-2 and type-3 routes
- attribute creation, route selection and install
- route handling per VNI and for the global routing table
- parsing of received EVPN routes and handling by route type
- encoding attributes for EVPN routes and EVPN prefix creation (for
Updates)
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Ensure that the AFI/SAFI is relevant to the FIB before attempting to install
or remove the route from zebra.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ensure that the check for martian next hop is correct, including for MP
nexthops, if IPv4.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
labeled-unicast routes are installed in the unicast table, to make
troubleshooting easier we need "show bgp ipv4 labeled-unicast x.x.x.x"
to show the x.x.x.x route in the unicast table.
* Pass ->text to functions that now do full string matching
* Remove cases for l2vpn and evpn where they cannot occur
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
- All ipv4 labeled-unicast routes are now installed in the ipv4 unicast
table. This allows us to do things like take routes from an ipv4
unicast peer, allocate a label for them and TX them to a ipv4
labeled-unicast peer. We can do the opposite where we take routes from
a labeled-unicast peer, remove the label and advertise them to an ipv4
unicast peer.
- Multipath over a labeled route and non-labeled route is not allowed.
- You cannot activate a peer for both 'ipv4 unicast' and 'ipv4
labeled-unicast'
- The 'tag' variable was overloaded for zebra's route tag feature as
well as the mpls label. I added a 'mpls_label_t mpls' variable to
avoid this. This is much cleaner but resulted in touching a lot of
code.
Based on suggestions made in the FRR technical meeting, making the
label-index range 2^20-16 for the max label size minus the reserved
labels.
Ticket: CM-16513
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Added the ability to set the label-index value based on criteria other
than the network statement. Manual testing looks good and added to the
ticket.
Ticket: CM-16513
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: CCR-6339
Problem reported with the inability to define "network x❌x::/64 label-index" to
the config. Found that the install_element was pointing to the wrong node.
Ticket: CM-16615
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Problem seen in testing import-check using labeled-unicast address-family. When
transitioning from "no bgp network import-check" to "bgp network import-check",
previously installed networks were not removed. This fix resolves this.
Ticket: CM-16512
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Modify EVPN prefix to use the generic IP address structure. Add support
for EVPN type-2 and type-3 prefix dump. Fix references to modified fields
as needed.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Static encap routes don't have an MPLS label. Also, use %u instead of
%d to print the label.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The FSF's address changed, and we had a mixture of comment styles for
the GPL file header. (The style with * at the beginning won out with
580 to 141 in existing files.)
Note: I've intentionally left intact other "variations" of the copyright
header, e.g. whether it says "Zebra", "Quagga", "FRR", or nothing.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
These commands were causing bgpd to crash if a static VPN route was
configured.
While here, fix a bug in bgp_static_add() and bgp_static_delete().
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Pass pointer to pointer instead of assigning by return value. See
previous commit message.
To ensure that the behavior stays functionally correct, any assignments
with the result of a thread_add* function have been transformed to set
the pointer to null before passing it. These can be removed wherever the
pointer is known to already be null.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
The way thread.c is written, a caller who wishes to be able to cancel a
thread or avoid scheduling it twice must keep a reference to the thread.
Typically this is done with a long lived pointer whose value is checked
for null in order to know if the thread is currently scheduled. The
check-and-schedule idiom is so common that several wrapper macros in
thread.h existed solely to provide it.
This patch removes those macros and adds a new parameter to all
thread_add_* functions which is a pointer to the struct thread * to
store the result of a scheduling call. If the value passed is non-null,
the thread will only be scheduled if the value is null. This helps with
consistency.
A Coccinelle spatch has been used to transform code of the form:
if (t == NULL)
t = thread_add_* (...)
to the form
thread_add_* (..., &t)
The THREAD_ON macros have also been transformed to the underlying
thread.c calls.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Crash uncovered when workqueue item was pulled with safi set to 7
(SAFI_LABELED_UNICAST) without labled-unicast being configured.
Also fixed minor issue removing aggregate-address command due to bad
index.
Ticket: CM-16169
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
If you specified A.B.C.D, the code would still try to
read A.B.C.D/M and not find it and pass in a NULL pointer
which crashed the code.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
The initial implementation was against draft-keyupate-idr-bgp-prefix-sid-02
This updates our label-index implementation up to draft-ietf-idr-bgp-prefix-sid-05
- changed BGP_ATTR_LABEL_INDEX to BGP_ATTR_PREFIX_SID
- since there are multiple TLVs in BGP_ATTR_PREFIX_SID you can no longer
rely on that flag to know if there is a label-index for the path. I
changed bgp_attr_extra_new() to init the label_index to
BGP_INVALID_LABEL_INDEX
- put some placeholder code in for the other two TLVs (IPv6 and
Originator SRGB)
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
- cleaned up the "show bgp ipv4 labeled-unicast x.x.x.x" output
- fixed some json keys to use camelCase
- bgp_attr_label_index() was clearing BGP_ATTR_LABEL_INDEX because it
was comparing mp_update->afi against SAFI_LABELED_UNICAST instead of
mp_update->safi
- added BGP_ATTR_LABEL_INDEX to attr_str
1) Some commands were installed in the wrong node
2) Fix output to show labeled information to correctly display
3) Whitespace issue in route-map command
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* Fix a segfault when the "show bgp large-community" command is given
without any optional large communities;
* Fix parsing of optional large communities. Without this fix a
"Large-community malformed" error is shown even for valid large
communities.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Implement BGP Prefix-SID IETF draft to be able to signal a labeled-unicast
prefix with a label index (segment ID). This makes it easier to deploy
global MPLS labels with BGP, even without other aspects of Segment Routing
implemented.
This patch implements the handling of the BGP-Prefix-SID Label Index
attribute. When received from a peer and the index is acceptable, the local
label is picked up from the SRGB and is programmed as the incoming label as
well as advertised to peers. If the index is not acceptable, no local label
is assigned. The outgoing label will always be the one advertised by the
downstream neighbor.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Implement BGP Prefix-SID IETF draft to be able to signal a labeled-unicast
prefix with a label index (segment ID). This makes it easier to deploy
global MPLS labels with BGP, even without other aspects of Segment Routing
implemented.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Implement BGP Prefix-SID IETF draft to be able to signal a labeled-unicast
prefix with a label index (segment ID). This makes it easier to deploy
global MPLS labels with BGP, even without other aspects of Segment Routing
implemented.
This patch implements configuration of the global label block (SRGB) and
configuration of a label-index for a network in BGP.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Implement support for negotiating IPv4 or IPv6 labeled-unicast address
family, exchanging prefixes and installing them in the routing table, as
well as interactions with Zebra for FEC registration. This is the
implementation of RFC 3107.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Implement support for activating the labeled-unicast address family in
BGP and relevant configuration for this address family.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Code inspection showed a bunch more spots where
we were assigning the safi inside of a if statement
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When outputting routes associated with a 'struct bgp'
do not force the safi to bee SAFI_EVPN and cause output
to be hosed.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The original code on shutdown assumed a 'forced' mode
if there was no process_main_queue. This construct
was violated by commit 2e02b9b2d1
due to not fully understanding the shutdown process.
If we are shutting down, don't store work to do later,
just gracefully don't do it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The buffer needs to be set to length 0 if nothing is written into
it, otherwise bgpd will log uninitialized memory, disclosing information
and possibly leading to a crash.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
As the prefix call function for mac handling has prefix_ prepended
before, the change must be propagated to all locations where those
functions are called.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
EVPN code adaptation to replace old mac string internal utility with the
new one available in lib folder.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Transmission and Reception routines have a part of code that is
conditionnally compiled to the usage of HAVE_EVPN. Also, each time a
subfield of prefix evpn is reached, like in configuration also, then a
conditionnaly compilation with HAVE_EVPN is used.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This commit fixes the nexthop display behaviour when an evpn entry is
matched. The commit handles both cases where IPv4 or IPv6 nexthop is
detected.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
In case a manual set of MPLS, ENCAP, or EVPN entry is set, then the
nexthop attribute localted in attr->extra structure must be changed too.
In standard cases, where IPv4 IGP nexthop address is picked up, the same
address ie chosen.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
A new vty command available under evpn address family. This command
takes following format:
(af-evpn)# [no] network <A.B.C.D/M|X:X::X:X/M> rd ASN:nn_or_IP-address:nn ethtag WORD
label WORD esi WORD gwip A.B.C.D routermac WORD
[route-map WORD]
Among new parameters, ethtag stands for the ethernet tag indentifier.
ESI stands for the ethernet segment identifier, and must be entered in
following format: 00:11:22:33:44:55:66:77:88:99.
gwip stands for the gateway IP address contained in RT5 message. A
check is done on that value since if gwip is ipv4, then ip prefix must
be ipv4. The same for ipv6.
RouterMAc is the gateway mac address sent as extended community
attribute.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
L2VPN route prefix are composed of ethtag, mac address and ip address.
vty command "show bgp l2vpn rd <>" show macip prefix in the following
template: [ethtag][macaddress/len][ipaddress/len]
Signed-off-by: Julien Courtat <julien.courtat@6wind.com>
e
This patch introduces show show bgp evpn commands to dump
NLRI entries configured or received on BGP, related to EVPN
New command introduced is the following:
show [ip] bgp l2vpn evpn [all | rd <rd name> ] [overlay]
Like for MPLS, similar set of commands is added for EVPN:
show [ip] bgp l2vpn evpn [all|rd <RDNAME>]
show [ip] bgp l2vpn evpn all neighbor <NEIGHBOR> routes
show [ip] bgp l2vpn evpn all neighbor <NEIGHBOR> advertised-routes
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
For each received routermac extended community, the mac address is
copied into routermac extended community context. For each emission,
a check is done against routermac extended community, if L2VPN is
enabled. If enabled, the extended community is appended.
Signed-off-by: Philippe Gubiert <philippe.guibert@6wind.com>
This field can be either IPv4 or IPv6 address and is filled in in
bgp_static configuration structure.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
As per draft-ietf-idr-tunnel-encaps-02, section 3.2.1, BGP Encap
attribute supports vxlan tunnel type. A new tunnel attribute has been
appended to subtlv list, describing the vxlan network identifier to
be used for the routing information of the BGP update message.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The commit introduces the changes to be done to carry route type 5 EVPN
information in bgp extra attribute information. The commit also handles
the update processing for route type 5 information, including ESI,
gatewayIP and label information.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This patch introduces code to receive a NLRI message with route type
5, as defined in draft-ietf-bess-evpn-prefix-advertisement-02. It
It increases the number of parameters to extract from the NLRI and
to store into bgp extra information structure. Those parameters are
the ESI (ethernet segment identifier), the gateway IP Address (which
acts like nexthop attribute but is contained inside the NLRI itself)
and the ethernet tag identifier ( that acts for the VXLan Identifier)
This patch updates bgp_update() and bgp_withdraw() api, and then does the
necessary adapations for rfapi.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
To handle BGP NLRI EVPN messages, bgp is modified to handle AFI_L2VPN
and SAFI_EVPN values.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This fix addresses these things:
1) Clean up documentation as requested
2) Fix a wrong search for "exact-match"
3) Fix possible crash.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
- route_set_lcommunity would do nothing (and leak memory) if attr->extra
wasn't up yet
- an if() arch in bgp_show_table() was duplicated (with no effect)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(to match surrounding code)
"git diff -w" should be almost empty.
Copyright edited to say FRR, this is not GNU Zebra :)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
When bgp_vty_find_and_parse_afi_safi_vrf detects
a invalidly named vrf, it warns the user. There
is no need for the calling function to warn
again.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This bgp_show_type enumerate was duplicated and modified in several
places. The commit takes the enumerate with the biggest enumerate, so
that it can be used by all the functions using this enumerate.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The commit is removed duplicated command show ip bgp ipv4|ipv6 enca|vpn
command that is conflicting between bgp_route.c and
bgp_mplsvpn.c/bgp_encap.c files. The fix is integrating the call to
specific mpls or encap settings from inside bgp_show_route() function.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
1) Make [<view|vrf> WORD] consistent
2) Fix inconsistent help string
3) Fix the show .. vrf all command
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Create bgp_vty_find_and_parse_afi_safi_vrf that
will parse the
`show [ip] bgp [<view|vrf> WORD] [<ipv4|ipv6> [<unicast|multicast|vpn|encap>]]'
part of a command and to return the correct spot we are in the command.
Cleanup 'dampening parameters' part of this command.
Consolidate the creation of the bgp data structure to be a bit cleaner.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The original commit for large communities broke
'show ip bgp' and 'show bgp ipv4 unicast' and
their ilk. This commit fixes this as well
as some vtysh parse errors identified.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
BGP Large Communities are a novel way to signal information between
networks. An example of a Large Community is: "2914:65400:38016". Large
BGP Communities are composed of three 4-byte integers, separated by a
colon. This is easy to remember and accommodates advanced routing
policies in relation to 4-Byte ASNs.
This feature was developed by:
Keyur Patel <keyur@arrcus.com> (Arrcus, Inc.),
Job Snijders <job@ntt.net> (NTT Communications),
David Lamparter <equinox@opensourcerouting.org>
and Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Job Snijders <job@ntt.net>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Use KEEP_OLD_VPN_COMMANDS define to brace some vty commands used by bgp
to configure or show vpnvx contexts using old method, that is to say
using vty keyword vpnv4 or vpnv6 command.
In addition to this, the commit adds two new commands under route-map
with new format:
[no] set ipv4|ipv6 vpn nexthop <IPv4 Address> | <IPv6 Address>
It also add following command in old format:
[no] set vpnv6 nexthop <IPv6 Address>
Note that the commit does not take into account the availability of old
commands that are not available in new format.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com
To remove commands duplicated in bgp_mplsvpn/_encap
Also until vpn/encap specific show pieces are merged into
generic afi/safi show.
Signed-off-by: Lou Berger <lberger@labn.net>
As nexthop attribute for vpnv6 also contains a blank RD and a blank tag,
the IPv6 address length increases from 16 to 24 bytes. The same was
observed for vpnv4 nexthop, but was missing for VPNv6.
The same is done for martian nexthop debugging.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
I modified the 'show ....' command to be one long line.
Upon reflection and porting the large-community code
I have decided that we need to put this back to the way
it was before.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
As nexthop attribute for vpnv6 also contains a blank RD and a blank tag,
the IPv6 address length increases from 16 to 24 bytes. The same was
observed for vpnv4 nexthop, but was missing for VPNv6.
The same is done for martian nexthop debugging.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add the next commands:
network X:X::X:X/M rd ASN:nn_or_IP-address:nn tag WORD [route-map WORD]
no network X:X::X:X/M rd ASN:nn_or_IP-address:nn tag WORD
Also, fix show running-config for vpnv6 network, as well as modiying
bgp_static_set_safi, and take into account matching afi table.
Signed-off-by: Liu Xiaofeng <xiaofeng.liu@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Introduce internal and IANA defintions for AFI/SAFI and mapping
functions and modify code to use these. This refactoring will
facilitate adding support for other AFI/SAFI whose IANA values
won't be suitable for internal data structure definitions (e.g.,
they are not contiguous).
The commit adds some fixes related to afi/safi testing with 'make check
' command.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Ticket: CM-11416
Reviewed By: CCR-3594 (mpls branch)
Testing Done: Not tested now, tested earlier on mpls branch
Added defines and parse utility functions
Fix vty code that treated vpn&encap as AFIs
and some other related vty printing/handline issues
Note: Includes branch specific changes (due to new parser)
Signed-off-by: Lou Berger <lberger@labn.net>
thread.c fails to build properly on systems that do
not have a CLOCK_MONOTONIC. Therefore there is
no need for bgp to have knowledge of it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This patch enable the support of graceful restart for routes sets with
vpnv4 address family format. In this specific case, data model is
slightly different and some additional processing must be done when
accessing bgp tables and nodes.
The clearing stale algorithm takes into account the specificity where
the 2 node level for MPLS has to be reached.
Signed-off-by: Julien Courtat <julien.courtat@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Modify the 'show ip bgp ...' output to be a bit clearer
on what work it did.
Modify:
root@dell-s6000-02 ~/quagga# vtysh -c "show ip bgp"
BGP table version is 7, local router ID is 6.0.0.9
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 6.0.0.5/32 169.254.0.1 0 0 65101 ?
*> 6.0.0.6/32 169.254.0.17 0 0 65101 ?
*> 6.0.0.7/32 169.254.0.33 0 0 65104 ?
*> 6.0.0.8/32 169.254.0.49 0 0 65104 ?
*> 6.0.0.9/32 0.0.0.0 0 32768 ?
*= 6.0.0.10/32 169.254.0.49 0 65104 65200 ?
*= 169.254.0.33 0 65104 65200 ?
*= 169.254.0.17 0 65101 65200 ?
*> 169.254.0.1 0 65101 65200 ?
Displayed 6 out of 9 total prefixes
To
.....
Displayed 6 routes and 9 total paths
Issue #11
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This contains bgp memory leak fixes as well as cleanups to VRF/namespace
handling and has been run through extended testing in Cumulus' testbed:
Tested-by: Donald Sharp <sharpd@cumulusnetworks.com>
For unicast routes do not change the output of the 'show ip bgp' command.
This will allow people with existing scripts to continue to work.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Additionally:
* Add [ip] to a couple bgp show commands
* Quick refactor of a couple ISIS commands
* Quick refactor of a couple OSPF6 commands
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
* show ip bgp vpnv4 all <A.B.C.D|A.B.C.D/M> [json]
* show...vpnv4 <all|rd ...> summary...
* Fix placement of AF+SAFI specifiers for BGP clear commands
* Add more [ip]'s for bgp commands
* clean up some doc strings
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
The "Weight" column is off:
BGP table version is 0, local router ID is 10.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, =
multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 4.1.1.2/32 9.9.9.2 0 32768 ?
*> 4.1.1.4/32 9.9.9.2 0 32768 ?
Displayed 2 out of 2 total prefixes
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
(cherry picked from commit 65c7395b07e8c592c847d4a1e22fc89ddf448341)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
It seems these two were at some point copied in from rsync; replace with
more recent versions that will hopefully become available in glibc as
well.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* bgpd parses NLRIs twice, a first pass "sanity check" and then a second pass
that changes actual state. For most AFI/SAFIs this is done by
bgp_nlri_sanity_check and bgp_nlri_parse, which are almost identical.
As the required action on a syntactic error in an NLRI is to NOTIFY and
shut down the session, it should be acceptable to just do a one pass
parse. There is no need to atomically handle the NLRIs.
* bgp_route.h: (bgp_nlri_sanity_check) Delete
* bgp_route.c: (bgp_nlri_parse) Make the prefixlen size check more general
and don't hard-code AFI/SAFI details, e.g. use prefix_blen library function.
Add error logs consistent with bgp_nlri_sanity_check as much as possible.
Add a "defense in depth" type check of the prefixlen against the sizeof
the (struct prefix) storage - ala bgp_nlri_parse_vpn.
Update standards text from draft RFC4271 to the actual RFC4271 text.
Extend the semantic consistency test of IPv6. E.g. it should skip mcast
NLRIs for unicast safi as v4 does.
* bgp_mplsvpn.{c,h}: Delete bgp_nlri_sanity_check_vpn and make
bgp_nlri_parse_vpn_body the bgp_nlri_parse_vpn function again.
(bgp_nlri_parse_vpn) Remove the notifies. The sanity checks were
responsible for this, but bgp_update_receive handles sending NOTIFY
generically for bgp_nlri_parse.
* bgp_attr.c: (bgp_mp_reach_parse,bgp_mp_unreach_parse) Delete sanity check.
NLRI parsing done after attr parsing by bgp_update_receive.
Arising out of discussions on the need for two-pass NLRI parse with:
Lou Berger <lberger@labn.net>
Donald Sharp <sharpd@cumulusnetworks.com>
* bgp_packet.c: (bgp_update_receive) Lots of repeated code, doing same
thing for each AFI/SAFI. Except when it doesn't, e.g. the IPv4/VPN
case was missing the EoR bgp_clear_stale_route call - the only action
really needed for EoR.
Make this function a lot more regular, using common, AFI/SAFI
independent blocks so far as possible.
Replace the 4 separate bgp_nlris with an array, indexed by an enum.
The distinct blocks that handle calling bgp_nlri_parse for each
different AFI/SAFI can now be replaced with a loop.
Transmogrify the nlri SAFI from the SAFI_MPLS_LABELED_VPN code-point
used on the wire, to the SAFI_MPLS_VPN safi_t enum we use internally
as early as possible.
The existing code was not necessarily sending a NOTIFY for NLRI
parsing errors, if they arose via bgp_nlri_sanity_check. Send the
correct NOTIFY - INVAL_NETWORK for the classic NLRIs and OPT_ATTR_ERR
for the MP ones.
EoR can now be handled in one block. The existing code seemed broken
for EoR recognition in a number of ways:
1. A v4/unicast EoR should be an empty UPDATE. However, it seemed
to be treating an UPDATE with attributes, inc. MP REACH/UNREACH,
but no classic NLRIs, as a v4/uni EoR.
2. For other AFI/SAFIs, it was treating UPDATEs with no classic
withraw and with a zero-length MP withdraw as EoRs. However, that
would mean an UPDATE packet _with_ update NLRIs and a 0-len MP
withdraw could be classed as an EoR.
This seems to be loose coding leading to ambiguous protocol
situations and likely incorrect behaviour, rather than simply being
liberal. Be more strict about checking that an UPDATE really is an
EoR and definitely is not trying to update any NLRIs.
This same loose EoR parsing was noted by Chris Hall previously on
list.
(bgp_nlri_parse) Front end NLRI parse function, to fan-out to the correct
parser for the AFI/SAFI.
* bgp_route.c: (bgp_nlri_sanity_check) We try convert NLRI safi to
internal code-point ASAP, adjust switch for that. Leave the wire
code point in for defensive coding.
(bgp_nlri_parse) rename to bgp_nlri_parse_ip.
* tests/bgp_mp_attr_test.c: Can just use bgp_nlri_parse frontend.
* bgp_route.h: (bgp_nlri_sanity_check) The bulk of the args are equivalent
to a (struct bgp_nlri), consolidate.
* bgp_route.c: (bgp_nlri_sanity_check) Make this a frontend for all afi/safis.
Including SAFI_MPLS_LABELED_VPN.
(bgp_nlri_sanity_check_ip) Regular IP NLRI sanity check based on the
existing code, and adjusted for (struct bgp_nlri *) arg.
* bgp_attr.c: (bgp_mp_reach_parse) Adjust for passing (struct bgp_nlri *)
to bgp_nlri_sanity_check.
Get rid of special-casing to not sanity check VPN.
(bgp_mp_unreach_parse) Ditto.
* bgp_mplsvpn.c: Use the same VPN parsing code for both the sanity
check and the actual parse.
(bgp_nlri_parse_vpn) renamed to bgp_nlri_parse_vpn_body and made
internal.
(bgp_nlri_parse_vpn_body) Added (bool) argument to control whether it
is sanity checking or whether it should update routing state for each
NLRI. Send a NOTIFY and reset the session, if there's a parsing
error, as bgp_nlri_sanity_check_ip does, and as is required by the
RFC.
(bgp_nlri_parse_vpn) now a wrapper to call _body with update.
(bgp_nlri_sanity_check_vpn) wrapper to call parser without
updating.
* bgp_mplsvpn.h: (bgp_nlri_sanity_check_vpn) export for
bgp_nlri_sanity_check.
* bgp_packet.c: (bgp_update_receive) Adjust for bgp_nlri_sanity_check
argument changes.
* test/bgp_mp_attr_test.c: Extend to also test the NLRI parsing functions,
if the initial MP-attr parsing has succeeded. Fix the NLRI in the
VPN cases. Add further VPN tests.
* tests/bgpd.tests/testbgpmpattr.exp: Add the new test cases.
This commit a joint effort of:
Lou Berger <lberger@labn.net>
Donald Sharp <sharpd@cumulusnetworks.com>
Paul Jakma <paul.jakma@hpe.com> / <paul@jakma.org>
Until today the admin distance cannot be configured for any IPv6
routing protocol. This patch implements it for bgp.
Signed-off-by: Maitane Zotes <maz@open.ch>
Signed-off-by: Roman Hoog Antink <rha@open.ch>
This patch is part of the previously submitted patch set on VPN and
Encap SAFIs. It fixes an issue identified by NetDEF CI.
Ensure temp stack structures are initialized Add protection against
double frees / post free access to bgp_attr_flush
Signed-off-by: Lou Berger <lberger@labn.net>
Ticket: CM-13053
Reviewed By: dslice@cumulusnetworks.com
'neighbor x.x.x.x weight' was implemented as a per-peer knob instead of
a per-peer per-afi-safi option. This makes it configurable per-peer
per-afi-safi so that we can do things like soft clear that afi/safi when
weight is modified.
When running 'show bgp ipv4 uni summ' (or any variation thereof)
If you have a large # of routes, the json package starts taking
up a tremendous amount of memory and processing power.
Modify the code to output the json as we go instead of gathering
it all up and outputting at the end.
Ticket: CM-13060
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
If a command is put into the VIEW_NODE, it is going into the
ENABLE_NODE as well. This is especially true for show commands.
As such if a command is in both consolidate it down to VIEW_NODE.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The RESTRICTED_NODE command is not used, introduces code
complexity and provides no additional levels of security.
The only way to get into RESTRICTED_NODE is to add, under
vty configuration the command 'anonymous restricted', and
then telnet to a daemon, provide a password, then type
'enable' and fail to enter the password three times.
Then the user can enter a very limited set of commands to
monitor bgp and only bgp behavior.
This commit removes both the RESTRICTED_NODE usage as well
as the lib/* usage of the code
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This patch improves zebra,ripd,ripngd,ospfd and bgpd so that they can
make use of 32-bit route tags in the case of zebra,ospf,bgp or 16-bit
route-tags in the case of ripd,ripngd.
It is based on the following patch:
commit d25764028829a3a30cdbabe85f32408a63cccadf
Author: Paul Jakma <paul.jakma@hpe.com>
Date: Fri Jul 1 14:23:45 2016 +0100
*: Widen width of Zserv routing tag field.
But also contains the changes which make this actually useful for all
the daemons.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
This feature adds an L3 & L2 VPN application that makes use of the VPN
and Encap SAFIs. This code is currently used to support IETF NVO3 style
operation. In NVO3 terminology it provides the Network Virtualization
Authority (NVA) and the ability to import/export IP prefixes and MAC
addresses from Network Virtualization Edges (NVEs). The code supports
per-NVE tables.
The NVE-NVA protocol used to communicate routing and Ethernet / Layer 2
(L2) forwarding information between NVAs and NVEs is referred to as the
Remote Forwarder Protocol (RFP). OpenFlow is an example RFP. For
general background on NVO3 and RFP concepts see [1]. For information on
Openflow see [2].
RFPs are integrated with BGP via the RF API contained in the new "rfapi"
BGP sub-directory. Currently, only a simple example RFP is included in
Quagga. Developers may use this example as a starting point to integrate
Quagga with an RFP of their choosing, e.g., OpenFlow. The RFAPI code
also supports the ability import/export of routing information between
VNC and customer edge routers (CEs) operating within a virtual
network. Import/export may take place between BGP views or to the
default zebera VRF.
BGP, with IP VPNs and Tunnel Encapsulation, is used to distribute VPN
information between NVAs. BGP based IP VPN support is defined in
RFC4364, BGP/MPLS IP Virtual Private Networks (VPNs), and RFC4659,
BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN . Use
of both the Encapsulation Subsequent Address Family Identifier (SAFI)
and the Tunnel Encapsulation Attribute, RFC5512, The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP Tunnel
Encapsulation Attribute, are supported. MAC address distribution does
not follow any standard BGB encoding, although it was inspired by the
early IETF EVPN concepts.
The feature is conditionally compiled and disabled by default.
Use the --enable-bgp-vnc configure option to enable.
The majority of this code was authored by G. Paul Ziemba
<paulz@labn.net>.
[1] http://tools.ietf.org/html/draft-ietf-nvo3-nve-nva-cp-req
[2] https://www.opennetworking.org/sdn-resources/technical-library
Now includes changes needed to merge with cmaster-next.
These commands were ported forward from these
commits:
f9b6c39 bgpd: Add back old forms of 'show <afi> <safi>' for compatibility
bf1ae6c bgpd: drop machineparse / random "show" improvements
651b402 bgpd: encap show commands
35c3686 bgpd: VPNv6 show commands
135ca15 bgpd: cleanup vty bgp_node_afi/safi utils
This is the first drop of those commits. The files have
changed too much and the diffs to extensive to try to do it
in one piece. Break it up into smaller code chunks.
Original Code:
Signed-off-by: Lou Berger <lberger@labn.net>
Forward Port:
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Found that the logic had been changed to determine whether the next-hop
is a v4 or v6 address. This caused an unnumbered interface to be seen
as ipv4 instead of ipv6 so the swp port was not correctly displayed.
Changed it back. Manual testing attaced to the ticket and bgp-min will
be run before committing.
Ticket: CM-12759
Signed-off-by: Don Slice
Reviewed-by: CCR-5166
In multipath selection, there can be a scenario where the set of route
entries selected as multipath can be the same (i.e., from the same peers)
but one or more of these may have a change to the BGP next hop. In this
case, the route needs to be installed again in zebra even if the best
route entry selected has not changed, otherwise the zebra RIB may have
a different set of next hops (and first hops) than what the routing
protocol selected.
This patch handles this scenario by re-installing the route if any BGP
attribute has changed for any of the multipaths. Not all BGP attributes
are of relevance to the zebra RIB, but this approach follows existing
logic used in the code (e.g., when BGP attributes for the best route
entry has changed).
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Sid Khot <sidkhot@cumulusnetworks.com>
Ticket: CM-12390
Reviewed By: CCR-5135
Testing Done: Manual, bgp-smoke
(cherry picked from commit e10720512e)
After BGP path selection, even if the best route entry selected has not
changed, ensure that the route is installed again in zebra if any non-best
but multipath route entry has a nexthop resolution change.
In the absence of this fix, if a non-best multipath route entry had a
nexthop resolution change (such as being resolved over two first hops instead
of one), the route would get reinstalled into zebra only in some situations
(i.e., when the best route entry had its IGP change flag set). If the route
does not get reinstalled by BGP, the corresponding route in the zebra RIB
would not have all the first hops.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Sid Khot <sidkhot@cumulusnetworks.com>
Ticket: CM-12390
Reviewed By: CCR-5134
Testing Done: Manual, bgp-smoke
(cherry picked from commit 3064bf43a7)
In multipath selection, there can be a scenario where the set of route
entries selected as multipath can be the same (i.e., from the same peers)
but one or more of these may have a change to the BGP next hop. In this
case, the route needs to be installed again in zebra even if the best
route entry selected has not changed, otherwise the zebra RIB may have
a different set of next hops (and first hops) than what the routing
protocol selected.
This patch handles this scenario by re-installing the route if any BGP
attribute has changed for any of the multipaths. Not all BGP attributes
are of relevance to the zebra RIB, but this approach follows existing
logic used in the code (e.g., when BGP attributes for the best route
entry has changed).
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Sid Khot <sidkhot@cumulusnetworks.com>
Ticket: CM-12390
Reviewed By: CCR-5135
Testing Done: Manual, bgp-smoke
After BGP path selection, even if the best route entry selected has not
changed, ensure that the route is installed again in zebra if any non-best
but multipath route entry has a nexthop resolution change.
In the absence of this fix, if a non-best multipath route entry had a
nexthop resolution change (such as being resolved over two first hops instead
of one), the route would get reinstalled into zebra only in some situations
(i.e., when the best route entry had its IGP change flag set). If the route
does not get reinstalled by BGP, the corresponding route in the zebra RIB
would not have all the first hops.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Sid Khot <sidkhot@cumulusnetworks.com>
Ticket: CM-12390
Reviewed By: CCR-5134
Testing Done: Manual, bgp-smoke
There are cases where customers desire the ability to override the
default behavior of installing ipv6 prefixes with a link-local next-hop
if both a link-local and global ipv6 next-op is present in the bgp table.
This fix provides this ability and will allow the global to be used as the
next-hop. This also retains the ability to manually set the ipv6 next-hop
global value as before, and if so, this manual entry will be used for the
next-hop.
Ticket: CM-11480
Signed-off-by: Don Slice
Reviewed By: CCR-4983
Testing Done: Manual testing results attached to the ticket. bgp-min and
bgp-smoke will be completed before committing.
Prior to this change, bgp always identified the routing table used as
the default in the output of "show ip bgp x.x.x.x". This fix changes
the behavior to use the correct table name.
Ticket: CM-10239
Signed-off-by: Don Slice
Reviewed-by: Donald Sharp
This reverts commit ff75b6c05b.
lib/table.c's route_common() can create a rn for a prefix that BGP has
never RXed. For example here we RX 10.1.8.0/24 from neighbor 10.0.0.2,
notice how the 10.1.0.0/20 entry is created. We would later assert on
this prefix because its info was NULL.
2016/06/16 23:37:21.418426 BGP: 10.0.0.2 rcvd UPDATE w/ attr: nexthop 10.0.0.2, origin i, localpref 100, metric 0, community 99:7, path
2016/06/16 23:37:21.418442 BGP: 10.0.0.2 rcvd UPDATE wlen 0 wpfx 0 attrlen 36 alen 4 apfx 1
2016/06/16 23:37:21.418458 BGP: bgp_node_create called
2016/06/16 23:37:21.418475 BGP: route_node_get called for 10.1.8.0/24, route_node_new 10.1.0.0/20, match (nil)
2016/06/16 23:37:21.418519 BGP: bgp_node_create called
2016/06/16 23:37:21.418536 BGP: route_node_get called for 10.1.8.0/24, route_node_new(2) 10.1.8.0/24, match 0x2013cd0
2016/06/16 23:37:21.418554 BGP: 10.0.0.2 rcvd 10.1.8.0/24
If rn->info is NULL then avoiding the group_announce_route() call in
bgp_proces_main() also feels risky as this code path generates WITHDRAWs
for prefixes that no longer have a bestpath which would be the case if
there are no paths.
Ticket: CM-11344
Reviewed By: dwalton, dsharp
Testing Done: built and tested amd64 debs
This patch adds the peerID JSON attribute for routes for show ip bgp json.
It also corrects the bgpTimerLastWrite in show ip bgp neigh json as well
as adds bgpInUpdateElapsedTimeMsecs, lastErrorCodeSubcode, and connectRetryTimer.
These are needed for the bgp4 mib implementation (rfc 4273) from the json
output of vtysh commands.
VPNv6 changes picked from upstream needed fixes and updates due to some
fundamental changes implemented by Cumulus (BGP update-groups, RFC 5549
and nexthop setting etc.) which aren't present upstream.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Updates: 945c8fe, 8ecd326, bb86c60, 93b73df, f4c8985
This accelerates handling of incoming Withdraw messages for routes that
don't exist in the table to begin with. Cisco IOS 12.4(24)T4 has a bug
in this regard - it sends withdraws instead of doing nothing for
prefixes that are filtered.
Pulling up the adj_in removal in Quagga should have no ill effect, but
we can avoid the costly iteration over all rsclients if there was no
adj_in entry.
Performance impact of this change on routeserver with 3 buggy peers,
startup/sync time:
before patch: 143.12 seconds (user cpu)
after patch: 7.01 seconds (user cpu)
Many thanks to Nick Hilliard & INEX for providing real-world test data!
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Acked-by: Paul Jakma <paul@jakma.org>
This changes the existing _vpnv4 functions for MPLS-VPN into
SAFI-agnostic functions, renaming them from *_vpnv4 to *_safi.
Also adds route-map support while at it.
Signed-off-by: Lou Berger <lberger@labn.net>
Reviewed-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit a76d9ca3584c1751a592457c167c1e146648ceb6)
Conflicts:
bgpd/bgp_route.c
* bgp_nexthop.c: (bgp_scan) There is little point queueing an rn with no routing
information for processing.
* bgp_route.c: (bgp_process) Do nothing on rn's with no routes. Add an assert
for now, to try catch any other cases, but prob should be removed.
(bgp_best_selection) rn with no routes == finish early.
(cherry picked from commit 91b9e8547a7c5697d5d7481f9476778077024019)
Conflicts:
bgpd/bgp_nexthop.c
bgpd/bgp_route.c
My original su_remote == NULL check is not correct. It seems that
* bgp_route.c: (bgp_info_cmp) Some bgp_info is compared with su_remote=NULL
and it's supposed to be perfectly legal. E.g. configured subnet announces
("network a.b.c.d/n"). Ensure bgp_info_cmp is robust if such a path gets
as far as the neighbour address comparison step.
(cherry picked from commit 2820a01eed1c616d490ddbfd17793c19597459d1)
Conflicts:
bgpd/bgp_route.c
Using #ifdef inside preprocessor macro argument lists is not guaranteed
to work. In reality it mostly does, but we don't need these ifdefs for
HAVE_IPV6 anymore, so let's get rid of the warning nonetheless.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit 94bad67cd8fe7ad023a40547a1153a414d70fa0a)
Conflicts:
bgpd/bgp_route.c
Fix lots of warnings. Some const and type-pun breaks strict-aliasing
warnings left but much reduced.
* bgp_advertise.h: (struct bgp_advertise_fifo) is functionally identical to
(struct fifo), so just use that. Makes it clearer the beginning of
(struct bgp_advertise) is compatible with with (struct fifo), which seems
to be enough for gcc.
Add a BGP_ADV_FIFO_HEAD macro to contain the right cast to try shut up
type-punning breaks strict aliasing warnings.
* bgp_packet.c: Use BGP_ADV_FIFO_HEAD.
(bgp_route_refresh_receive) fix an interesting logic error in
(!ok || (ret != BLAH)) where ret is only well-defined if ok.
* bgp_vty.c: Peer commands should use bgp_vty_return to set their return.
* jhash.{c,h}: Can take const on * args without adding issues & fix warnings.
* libospf.h: LSA sequence numbers use the unsigned range of values, and
constants need to be set to unsigned, or it causes warnings in ospf6d.
* md5.h: signedness of caddr_t is implementation specific, change to an
explicit (uint_8 *), fix sign/unsigned comparison warnings.
* vty.c: (vty_log_fixed) const on level is well-intentioned, but not going
to fly given iov_base.
* workqueue.c: ALL_LIST_ELEMENTS_RO tests for null pointer, which is always
true for address of static variable. Correct but pointless warning in
this case, but use a 2nd pointer to shut it up.
* ospf6_route.h: Add a comment about the use of (struct prefix) to stuff 2
different 32 bit IDs into in (struct ospf6_route), and the resulting
type-pun strict-alias breakage warnings this causes. Need to use 2
different fields to fix that warning?
general:
* remove unused variables, other than a few cases where they serve a
sufficiently useful documentary purpose (e.g. for code that needs
fixing), or they're required dummies. In those cases, try mark them as
unused.
* Remove dead code that can't be reached.
* Quite a few 'no ...' forms of vty commands take arguments, but do not
check the argument matches the command being negated. E.g., should
'distance X <prefix>' succeed if previously 'distance Y <prefix>' was set?
Or should it be required that the distance match the previously configured
distance for the prefix?
Ultimately, probably better to be strict about this. However, changing
from slack to strict might expose problems in command aliases and tools.
* Fix uninitialised use of variables.
* Fix sign/unsigned comparison warnings by making signedness of types consistent.
* Mark functions as static where their use is restricted to the same compilation
unit.
* Add required headers
* Move constants defined in headers into code.
* remove dead, unused functions that have no debug purpose.
(cherry picked from commit 7aa9dcef80b2ce50ecaa77653d87c8b84e009c49)
Conflicts:
bgpd/bgp_advertise.h
bgpd/bgp_mplsvpn.c
bgpd/bgp_nexthop.c
bgpd/bgp_packet.c
bgpd/bgp_route.c
bgpd/bgp_routemap.c
bgpd/bgp_vty.c
lib/command.c
lib/if.c
lib/jhash.c
lib/workqueue.c
ospf6d/ospf6_lsa.c
ospf6d/ospf6_neighbor.h
ospf6d/ospf6_spf.c
ospf6d/ospf6_top.c
ospfd/ospf_api.c
zebra/router-id.c
zebra/rt_netlink.c
zebra/rt_netlink.h
This patch addresses David's comments and contains:
1.Addition of show ip bgp dampening command tree
2.Addition of show ip bgp dampening parameters to display BGP dampening
parameters.
Signed-off-by: Balaji.G <balajig81@gmail.com>
(cherry picked from commit 3921cc54445417aa1ca22668063701a626e93098)
RFC 2439, Section 4.2; the values pair up for hysteresis.
Signed-off-by: Balaji.G <balajig81@gmail.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit aa7dbb1067b7d02e1354fe1e5664ccb7d259d649)
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Ticket: CM-10644
Reviewed By:
Testing Done:
The JSON outputs of a bunch of BGP commands were broken due to the
addition of VRF support. This fixes them all. Also replaces the use
of "-" in some of the JSON variable names with camel case names.
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-10002
superm-redxp-05# conf t
superm-redxp-05(config)# route-map FOO permit 10
superm-redxp-05(config-route-map)# set community ?
AA:NN Community number in AA:NN format (where AA and NN are <0-65535>) or local-AS|no-advertise|no-export|internet or additive
none No community attribute
superm-redxp-05(config-route-map)# set community 2:2
superm-redxp-05(config-route-map)# set community 2:70000
% Malformed communities attribute
superm-redxp-05(config-route-map)# set community 70000:2
% Malformed communities attribute
superm-redxp-05(config-route-map)#
Key BGP 'show' commands have been expanded to support 'vrf all':
show ip bgp vrf all summary
show ip bgp vrf all neighbors
show ip bgp vrf all nexthop
show ip bgp vrf all update-group
show ip bgp vrf all
show bgp vrf all summary
show bgp vrf all update-group
show bgp vrf all
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Ticket: CM-10402
Reviewed By: CCR-4466
Testing Done: Manual
Ensure commands dealing with update-groups and peer-groups support VRFs.
Also implement a new command "show bgp vrfs" to show summary information of
all configured VRFs. Some additional code cleanup in this area.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ticket: CM-9247
Reviewed By: CCR-4267
Testing Done: Manual
bgp_update_main was only called by bgp_update.
bgp_update only called bgp_update_main.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reivewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Various changes and fixes related to VRF registration, deletion,
BGP exit etc.
- Define instance type
- Ensure proper handling upon instance create, delete and
VRF add/delete from zebra
- Cleanup upon bgp_exit()
- Ensure messages are not sent to zebra for unknown VRFs
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-9128, CM-7203
Reviewed By: CCR-4098
Testing Done: Manual
When attempting to use the 'show bgp ipv4 vpnv4 statistics' cli, the safi
choosen is BGP_MPLS_LABELED_VPN which is #defined to 128. The afi/safi
combination is fed to bgp->rib, which limits the size of the safi to BGP_SAFI_MAX
which is #defined to 5. The correct value to use is BGP_MPLS_VPN
The bgp code differentiates between the actual safi value for BGP_MPLS_LABELED_VPN
used defined by RFC 4364, to a internal SAFI value used to limit array size.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
During CR for nexthop upstream it was noticed that usage
of prefix2str was not consistent. This fixes this problem
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The json keyword was being read incorrectly.
Basically some commands read a variable # of arguments
and in ospf the command values were being placed into
argc and argv. With a variable # of arguments their
existed a possibility that less arguments would be read
from the cli than were being tested for in the command function
handler. This caused core dumps in some situations.
All code to read to decide to use the json keyword has
been centralized through a function and all code
converted to use it, irrelevant if it exhibited the bug
Ticket: CM-8278
Reviewed by: CCR-3830
Testing: OSPF no longer crashes and all other test suites still run
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This patch addresses three main issues:
a. Passing along the global IPv6 nexthop received from the EBGP peer to
IBGP peers but setting the link-local IPv6 nexthop to ourselves when
advertising EBGP-learnt routes to IBGP peers (in the absence of outbound
route-map or other overrides). The fix is to not send a link-local IPv6
nexthop in this case.
b. Passing along the link-local IPv6 nexthop received from one peer to
another peer which is (or may be) on a different subnet. This violates the
semantics of link-local IPv6 address. The fix is to set the nexthop to
ourselves in the situation where the nexthop normally has to be passed
but is a link-local IPv6 address.
c. Different behavior wrt nexthop advertisement for BGP unnumbered peering
if it is setup using link-local IPv6 address versus IPv4 /30 or /31. The
fix is to make the behavior consistent as long as the interface config is
the same in both cases.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Ticket: CM-7846, CM-8043
Reviewed By: CCR-3749
Testing Done: Manual testing, bgpsmoke (on 2.5-br)
Note: Imported from 2.5-br patch bgpd-fix-link-local-nexthop-setting.patch
will be deprecated in the future
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ticket: CM-8144
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-8122
per draft-ietf-idr-ix-bgp-route-server-09:
2.3.2.2.2. BGP ADD-PATH Approach
The [I-D.ietf-idr-add-paths] Internet draft proposes a different
approach to multiple path propagation, by allowing a BGP speaker to
forward multiple paths for the same prefix on a single BGP session.
As [RFC4271] specifies that a BGP listener must implement an implicit
withdraw when it receives an UPDATE message for a prefix which
already exists in its Adj-RIB-In, this approach requires explicit
support for the feature both on the route server and on its clients.
If the ADD-PATH capability is negotiated bidirectionally between the
route server and a route server client, and the route server client
propagates multiple paths for the same prefix to the route server,
then this could potentially cause the propagation of inactive,
invalid or suboptimal paths to the route server, thereby causing loss
of reachability to other route server clients. For this reason, ADD-
PATH implementations on a route server should enforce send-only mode
with the route server clients, which would result in negotiating
receive-only mode from the client to the route server.
This allows us to delete all of the following code:
- All XXXX_rsclient() functions
- peer->rib
- BGP_TABLE_MAIN and BGP_TABLE_RSCLIENT
- RMAP_IMPORT and RMAP_EXPORT
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Vivek Venkataraman <vivek@cumulusnetworks.com
Ticket: CM-8014
This implements addpath TX with the first feature to use it
being "neighbor x.x.x.x addpath-tx-all-paths".
One change to show output is 'show ip bgp x.x.x.x'. If no addpath-tx
features are configured for any peers then everything looks the same
as it is today in that "Advertised to" is at the top and refers to
which peers the bestpath was advertise to.
root@superm-redxp-05[quagga-stash5]# vtysh -c 'show ip bgp 1.1.1.1'
BGP routing table entry for 1.1.1.1/32
Paths: (6 available, best #6, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
r1(10.0.0.1) r2(10.0.0.2) r3(10.0.0.3) r4(10.0.0.4) r5(10.0.0.5) r6(10.0.0.6) r8(10.0.0.8)
Local, (Received from a RR-client)
12.12.12.12 (metric 20) from r2(10.0.0.2) (10.0.0.2)
Origin IGP, metric 0, localpref 100, valid, internal
AddPath ID: RX 0, TX 8
Last update: Fri Oct 30 18:26:44 2015
[snip]
but once you enable an addpath feature we must display "Advertised to" on a path-by-path basis:
superm-redxp-05# show ip bgp 1.1.1.1/32
BGP routing table entry for 1.1.1.1/32
Paths: (6 available, best #6, table Default-IP-Routing-Table)
Local, (Received from a RR-client)
12.12.12.12 (metric 20) from r2(10.0.0.2) (10.0.0.2)
Origin IGP, metric 0, localpref 100, valid, internal
AddPath ID: RX 0, TX 8
Advertised to: r8(10.0.0.8)
Last update: Fri Oct 30 18:26:44 2015
Local, (Received from a RR-client)
34.34.34.34 (metric 20) from r3(10.0.0.3) (10.0.0.3)
Origin IGP, metric 0, localpref 100, valid, internal
AddPath ID: RX 0, TX 7
Advertised to: r8(10.0.0.8)
Last update: Fri Oct 30 18:26:39 2015
Local, (Received from a RR-client)
56.56.56.56 (metric 20) from r6(10.0.0.6) (10.0.0.6)
Origin IGP, metric 0, localpref 100, valid, internal
AddPath ID: RX 0, TX 6
Advertised to: r8(10.0.0.8)
Last update: Fri Oct 30 18:26:39 2015
Local, (Received from a RR-client)
56.56.56.56 (metric 20) from r5(10.0.0.5) (10.0.0.5)
Origin IGP, metric 0, localpref 100, valid, internal
AddPath ID: RX 0, TX 5
Advertised to: r8(10.0.0.8)
Last update: Fri Oct 30 18:26:39 2015
Local, (Received from a RR-client)
34.34.34.34 (metric 20) from r4(10.0.0.4) (10.0.0.4)
Origin IGP, metric 0, localpref 100, valid, internal
AddPath ID: RX 0, TX 4
Advertised to: r8(10.0.0.8)
Last update: Fri Oct 30 18:26:39 2015
Local, (Received from a RR-client)
12.12.12.12 (metric 20) from r1(10.0.0.1) (10.0.0.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
AddPath ID: RX 0, TX 3
Advertised to: r1(10.0.0.1) r2(10.0.0.2) r3(10.0.0.3) r4(10.0.0.4) r5(10.0.0.5) r6(10.0.0.6) r8(10.0.0.8)
Last update: Fri Oct 30 18:26:34 2015
superm-redxp-05#
Ticket: CM-7861
Reviewed by: CCR-3651
Testing: See bug
bgp is using both bm->master and master pointers interchangebly
for thread manipulation. Since they are the same thing consolidate
to one pointer.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-7593
Reviewed By: CCR-3563
Testing Done: Manual verification of failed scenario (2.5-br)
When BGP receives an update to a redistributed route and the type of
the source has changed (e.g., from OSPF to static), the source route
type is not being updated in the RIB entry. This can lead to problems
such as the route being incorrectly deleted if redistribution for the
prior source is unconfigured.
Fix the code to update the source route type.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Vipin Kumar <vipin@cumulusnetworks.com>
As part of the debian build process for jessie we are seeing
some compile issues. This addresses these issues
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
bgp is using both bm->master and master pointers interchangebly
for thread manipulation. Since they are the same thing consolidate
to one pointer.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
is empty
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-7475
Reviewed By: Donald Sharp
Testing Done:
If the BGP table is empty, intead of returning
{'alert': 'No BGP network exists', 'routerId': '10.0.9.2',
'tableVersion': 180}
we should return
{'routerId': '10.0.9.2', 'routes': {}, 'tableVersion': 180}
This provides a more consistent json interface which is easier to script
against.
This patch adds a hostname capability. The node's hostname and
domainname are exchanged in the new capability and used in show command
outputs based on a knob enabled by the user. The hostname and domainname
can be a maximum of 64 chars long, each.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed-by: Vivek Venkataraman <vivek@cumulusnetworks.com>
Ticket: CM-5660
Reviewed By: CCR-2563
Testing Done:
Ticket: CM-4109
Reviewed-by: CCR-3414
Testing: See bug
Fixup of these memory issues:
(A) peer->clear_node_queue was accidently removed. Add back in.
(B) Clean up bm->process_main_queue and bm->process_rsclient_queue initialization
(C) Some memory leaks
(D) Clean up unused threads
Ticket: CM-7177
Reviewed-by: CCR-3396
Testing: See bug
This code change does several small things:
(A) Fix a couple detected memory leaks
(B) Fix all malloc operations to use the correct XMALLOC operation in bgpd and parts of lib
(C) Adds a few new memory types to make it easier to detect issues
Ticket: CM-6789
Reviewed By: CCR-3263
Testing Done: Manual Testing and smoke tests
Whenever some sort of output is encountered, added a json version with
proper logic as well.
Ticket : CM-7047
Reviewed by : CCR-3321
Testing : Trivial
In function bgp_aggregate_add, variables 'aspath' and 'community' are
malloced but not guaranteed to be freed before the function returns.
BGP: Display Link local addr and ifname as part of 5549 support
As part of BGP unnumbered and RFC 5549 support, the implementation will honor the
link local address as the NH if present and so it'd be useful to display that
info along with the interface name, when displaying the BGP route summary. That
is what this patch aims to do.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
"bgp confederation id X" are the same value.
router bgp 1
bgp router-id 10.1.1.1
bgp confederation identifier 1
bgp confederation peers 24 35
neighbor 10.1.1.2 remote-as 24
neighbor 10.1.1.2 update-source lo
neighbor 10.1.1.3 remote-as 1
neighbor 10.1.1.3 update-source lo
The customer does this because they want to peer to 10.1.1.2 as a
confed-external peer but peer with 10.1.1.3 as a normal iBGP peer.
The bug was that we thought 10.1.1.3 was an EBGP peer so we did not send him
LOCALPREF which caused the Juniper to send us a NOTIFICATION. I confirmed
that quagga also sends a NOTIFICATION in this scenario.
The fix is to add a check to see if router bgp X and bgp confederation
identifier X are equal because that is a factor in determining if a peer is
EBGP or IBGP
Additional issues fixed in the this patch:
We were not properly removing all AS_CONFED_SEQUENCEs/SETs from the aspath
when advertising a route to an ebgp peer. This was due to two issues:
We only called aspath_delete_confed_seq() if confederations were
configured. We can RX as aspath with CONFED segments even if
confederations are not configured.
aspath_delete_confed_seq() was implemented based on the original confed
RFC 3065 which basically said "remove all of the leading
AS_CONFED_SEQUENCEs/SETs" where the new confed RFC 5065 says "remove ALL
of the AS_CONFED_SEQUENCEs/SETs"
peer-groups did not work for confed-external peers. peer_calc_sort() always
returned BGP_PEER_EBGP for a confederations where the remote-as was not
specified. The reason was the peer->as_type was AS_UNSPECIFIED but we checked
if (peer->as_type != AS_SPECIFIED)
return (peer->as_type == AS_INTERNAL ? BGP_PEER_IBGP : BGP_PEER_EBGP);
After fixing that I found that when we got to the else where we checked for
peer1 we could only possibly return BGP_PEER_IBGP or BGP_PEER_EBGP, we need
to also be able to return BGP_PEER_CONFED. I changed this to return
peer1->sort.
"show ip bgp x.x.x.x" would always display "Local" for the aspath. This is
because we were calling aspath_counts_hop() to determine if the aspath was
empty. This is wrong though because CONFED segments do not count towards
aspath hopcount. The fix is to null check aspath->segments to determine if
the aspath is actually empty.
"show ip bgp x.x.x.x" and "show ip bgp neighbor" always displayed
"internal" or "external" and never "confed-internal" or "confed-external".
This made troubleshooting difficult because I couldn't tell exactly what
kind of peer I was dealing with. I added the confed-internal and
confed-external output...also added a "peer-type" field in the json output
for 'show ip bgp x.x.x.x'
"show ip bgp peer-group" did not list the peer-group name if we hadn't
determined the "type" (internal, external, etc) for the peer-group
an implicit withdraw as is done for the NEXT_HOP attribute in the
update itself.
Note: Check is implemented only for IPv6 for the global nexthop. The
code will quietly ignore an invalid IPv6 link-local nexthop, if present;
this is the existing behavior and is not changed.
Signed-off-by: Vivek Venkataraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
