Christian Franke [Thu, 23 Feb 2017 13:27:00 +0000 (14:27 +0100)]
bgpd: fix bgp_info_addpath_{rx,tx}_str if addpath info is not present
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>
Quentin Young [Fri, 17 Feb 2017 18:19:27 +0000 (18:19 +0000)]
*: remove QUAGGA_NO_DEPRECATED_INTERFACES
This define is used only to guard macros in lib/linklist.h which
themselves are not used anywhere in the codebase and have been marked
deprecated since anno domini 2005
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Renato Westphal [Wed, 14 Dec 2016 19:39:28 +0000 (17:39 -0200)]
ldpd: use red-black trees to store 'adj' elements
Using red-black trees instead of linked lists brings the following
benefits:
1 - Elements are naturally ordered (no need to reorder anything before
outputting data to the user);
2 - Faster lookups/deletes: O(log n) time complexity against O(n).
The insert operation with red-black trees is more expensive though,
but that's not a big issue since lookups are much more frequent.
Renato Westphal [Wed, 14 Dec 2016 15:53:07 +0000 (13:53 -0200)]
ldpd: use red-black trees to store 'l2vpn_pw' elements
Using red-black trees instead of linked lists brings the following
benefits:
1 - Elements are naturally ordered (no need to reorder anything before
outputting data to the user);
2 - Faster lookups/deletes: O(log n) time complexity against O(n).
The insert operation with red-black trees is more expensive though,
but that's not a big issue since lookups are much more frequent.
Renato Westphal [Wed, 14 Dec 2016 14:34:57 +0000 (12:34 -0200)]
ldpd: use red-black trees to store 'l2vpn_if' elements
Using red-black trees instead of linked lists brings the following
benefits:
1 - Elements are naturally ordered (no need to reorder anything before
outputting data to the user);
2 - Faster lookups/deletes: O(log n) time complexity against O(n).
The insert operation with red-black trees is more expensive though,
but that's not a big issue since lookups are much more frequent.
Renato Westphal [Wed, 14 Dec 2016 12:42:45 +0000 (10:42 -0200)]
ldpd: use red-black trees to store 'l2vpn' elements
Using red-black trees instead of linked lists brings the following
benefits:
1 - Elements are naturally ordered (no need to reorder anything before
outputting data to the user);
2 - Faster lookups/deletes: O(log n) time complexity against O(n).
The insert operation with red-black trees is more expensive though,
but that's not a big issue since lookups are much more frequent.
Renato Westphal [Wed, 14 Dec 2016 11:14:52 +0000 (09:14 -0200)]
ldpd: use red-black trees to store 'nbr_params' elements
Using red-black trees instead of linked lists brings the following
benefits:
1 - Elements are naturally ordered (no need to reorder anything before
outputting data to the user);
2 - Faster lookups/deletes: O(log n) time complexity against O(n).
The insert operation with red-black trees is more expensive though,
but that's not a big issue since lookups are much more frequent.
Renato Westphal [Tue, 13 Dec 2016 18:19:15 +0000 (16:19 -0200)]
ldpd: use red-black trees to store 'tnbr' elements
Using red-black trees instead of linked lists brings the following
benefits:
1 - Elements are naturally ordered (no need to reorder anything before
outputting data to the user);
2 - Faster lookups/deletes: O(log n) time complexity against O(n).
The insert operation with red-black trees is more expensive though,
but that's not a big issue since lookups are much more frequent.
Renato Westphal [Tue, 13 Dec 2016 17:29:35 +0000 (15:29 -0200)]
ldpd: use red-black trees to store 'iface' elements
Using red-black trees instead of linked lists brings the following
benefits:
1 - Elements are naturally ordered (no need to reorder anything before
outputting data to the user);
2 - Faster lookups/deletes: O(log n) time complexity against O(n).
The insert operation with red-black trees is more expensive though,
but that's not a big issue since lookups are much more frequent.
Renato Westphal [Sat, 3 Dec 2016 23:14:44 +0000 (21:14 -0200)]
ldpd: use red-black trees to store 'lde_map' elements
Using red-black trees instead of linked lists brings the following
benefits:
1 - Elements are naturally ordered (no need to reorder anything before
outputting data to the user);
2 - Faster lookups/deletes: O(log n) time complexity against O(n).
The insert operation with red-black trees is more expensive though,
but that's not a big issue since lookups are much more frequent.
Chirag Shah [Fri, 27 Jan 2017 19:33:01 +0000 (11:33 -0800)]
pimd: ifdown sequnce stale report entry
Ticket: CM-14652
Testing Done: Tested via sending IGMP report and flap port and verified pim upstream and mroute, the entry is deleted. Run pim-smoke
Even after Report received port down event, IGMP entry alawys exists in upstream, mroute, kernel.
The entry exist because it was recreated after delete due missing check if group has no more source list,
mode is exclude, last source address was * means (*, G) so do not trigger to create entry.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Chirag Shah [Sat, 21 Jan 2017 23:18:08 +0000 (15:18 -0800)]
pimd: mroute entries unresolved IIF issue
Ticket:CM-14056
Reviewed By:sharpd, CCR-5603
Testing Done: verified multiple ifdown/ifup event on submitter setup and dev setup with 2k s,g entries, ran pim-smoke.
1. during ifdown event, pim vif for bridge was not resetting vif_index to -1 due to errno received from
kernel during vif del sequence. It could be timing issue where kernel may have delete prior to pimd sending request.
For vif_del even kernel returns error, reset vif_index to -1 in pimd DB so next if up event VIF receives new vif_index
and reprograms in kernel.
2. during mroute del sequence reset mfcc_parent to MAXVIF.
3. during mroute add check if parent mfcc_parent is MAXVIF then do not download to kernel such mroute entry.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Chirag Shah [Thu, 12 Jan 2017 03:36:50 +0000 (19:36 -0800)]
pimd: non-null register checksum incorrect
Ticket: CM-12041
Reviewed By: sharpd, CCR-5556
Testing Done: Tested on Local setup generating PIM Register (Data/Null) and processing both Tx/Rx with correct checksum.
Provided quagga debian to submitter and checksum cases passed on submitter setup.
1. PIM Register msg checksum only accounts for 8 bytes (4 bytes for PIM header and next 4 byetes before data payload).
In PIM header checksum calculation checked PIM packet type (in this case REGISTER type) then only pass 8 bytes as length
rather than full packet length.
2. PIM Register Rx path also handled with 8 byte and full pim lenth checksum.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Philippe Guibert [Tue, 14 Feb 2017 11:11:29 +0000 (12:11 +0100)]
bgpd: set the returned buffer to '\0' in case is returns nothing
In the case where extended communities to str function is called with a
filtering mecanism, then the case that the returned buffer is not inited
may happen. Hence the change done.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Tue, 14 Feb 2017 10:54:33 +0000 (11:54 +0100)]
lib: prefix2str initialises incoming buffer in case erroneous EVPN pfx
In the case, evpn prefix is requested to be transformed into string, and
if the evpn prefix is not an evpn route type 5 entry, then the prefix is
returning an initialised string that mentions the vpn prefix is unknown.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When configuring l2vpn evpn address-family, the show running indicates
that the address-family l2vpn evpn address-family has been configured,
and not evpn, as it was done before this commit. This is a bug fix.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
To know if overlay index is the same between two route information,
then the two overlay index field is compared. If both fields are set to
null, then the comparison should be equal, then return true, which was
not done.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
With the changed API, some adaptations are done in rfapi code, and in
bgpd evpn code. For evpn code, the internal storage of routermac addr is
kept as struct ethaddr structure. Also the evpn add_routermac api has as
incoming parameter a struct ethaddr param.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
lib: simplify str2mac and use struct ethaddr structure
This commit simplified the string to mac conversion, since it uses
sscanf, instead of depicting each incoming character one by one, and
doing self analysis. Also,this commit changes the internal usage of the
mac address representation in mac handling function.
Signed-off-by: Lou Berger <lberger@labn.net> Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
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>
The introduction of AFI_L2VPN prefix makes usage of AFI_ETHER deprecated
and is of no usage currently. The latter define is linked to AFI_L2VPN.
For that, the prefix enumerate has the AFI_ETHER value removed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
lib: handle str2mac case where buffer is allocated by the function
The case where no buffer is passed to the str2mac function is handled.
In that case, a buffer is allocated. Then the check against the buffer
length is not done.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
lib: add string to macaddress and reverse function
As mac-address structure is to be used as a prefix field, two new
functions permit handling mac address in order to convert it. either
from string to internal value, or the reverse operation.
Internal representation of a mac address is a 6 byte char value standing
for the 6 byte value the mac address has.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Mon, 30 Jan 2017 13:57:55 +0000 (14:57 +0100)]
bgpd: fix rfapi call to ecom2str with correct number of parameters
This commit is a complement for bgpd: handling router mac extended
community. As API of bgp_ecommunity ecom2str() function changed, rfapi
file has diverged with this API. The commit adds the correct number of
parameters.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Mon, 23 Jan 2017 13:47:35 +0000 (14:47 +0100)]
tests: fix bgp print in tests
This commit is a fix from previous commit: Quagga: AFI/SAFI mappings
IANA to/from internal values. It removes the printf that was used for
troubleshooting the afi/safi change, in respect to testing.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Tue, 17 Jan 2017 21:26:33 +0000 (22:26 +0100)]
bgpd: use HAVE_EVPN to disable evpn frame handling
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>
Philippe Guibert [Fri, 20 Jan 2017 13:02:49 +0000 (14:02 +0100)]
bgpd: update mp_nexthop field in case mp-bgp entry is created
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>
Philippe Guibert [Thu, 27 Oct 2016 06:02:36 +0000 (08:02 +0200)]
bgpd: enhance network command for evpn route type 5
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>
Julien Courtat [Tue, 18 Oct 2016 09:05:26 +0000 (11:05 +0200)]
bgpd: fix display of ethernet vpn route prefix in vty
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>
Philippe Guibert [Wed, 10 Aug 2016 08:46:53 +0000 (10:46 +0200)]
bgpd: introduction of vxlan tunnel attribute
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>
As per draft-ietf-bess-evpn-inter-subnet-forwarding-01, chapter 6.1,
a new extended community called router's MAC Extended Community is
provided. This community is appended to extended community list.
Note that a show API has been changed in order to be able to not
display (or not) this new type.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
bgpd: enhance reception of bgp ext. community default gateway
This fix permits processing of default gateway extended
community if present. This option, if router mac option is not
present, will replace it.
Also, when exporting route entry to VRF RIB, if VRF is layer 2
type, then the ecommunity related to mac address and router mac
are stripped.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Tue, 17 Jan 2017 21:21:40 +0000 (22:21 +0100)]
lib: add define of compilation for EVPN in prefix.c
Because the prefix structure may include or not evpn sub structure, then
HAVE_EVPN compilation define is also used in prefix.c, because it
references the sub field evpn of prefix structure.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This patch introduces the ability to make route type 5 message
when EVPN is enabled. Picked up paramters are collected from the
bgp extra attribute structure and are the ESI, the ethernet tag
information. In addition to this, nexthop attribute is collected too.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This patch appends nexthop attribute to EVPN message, in addition
to appending gateway IP in RT-5 NLRI itself. In reception, if
both informations are stored, then the GW IP information will
supersede the NLRI nexthop attribute.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
bgpd: route type 5 internal structures plus processing
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>
Philippe Guibert [Mon, 23 Jan 2017 13:42:02 +0000 (14:42 +0100)]
tests: update bgp_nlri_parse function usage in bgp testing
Because the bgp_nlri_parse function has been extended with one parameter,
when doing bgp testing against some packets, the correct call to
bgp_nlri_parse must be done.
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>
Philippe Guibert [Wed, 26 Oct 2016 10:21:53 +0000 (12:21 +0200)]
bgpd: enhance structures and esi and mac functions to handle EVPN
EVPN introduces new objects to be handled: Ethernet Segment Identifier,
and MAC Address.
For Route type 5 message, it also involves gateway IP field that can be
either IPv4 or IPv6 address. This commit introduces those main structures.
It also introduces some functions to convert esi and mac address to
string, and vice-versa.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Introduction of EVPN address-family node that is reachable under
BGP node, like follow: address-family evpn. Under that node, only
some commands are available for configuring a neighbor or setting
some basic settings like attribute unchanged behaviour. Currently,
no vty command is available for setting NLRI entries for EVPN.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
projects / mirror / frr.git / log