Donald Sharp [Tue, 6 Jun 2017 17:20:38 +0000 (13:20 -0400)]
bgpd: Refactor 'struct attr_extra' into 'struct attr'
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>
Donald Sharp [Fri, 26 May 2017 15:54:07 +0000 (11:54 -0400)]
bgpd: On cleanup make sure pointers exist
Test cases create fake bgp structure that is passed to
cleanup. The new evpn code assumed ( and probably rightly so)
that if the bgp structure was created it actually initialized
all useful data structures. Just make the evpn cleanup
functions be smart about attempting to free memory never
allocated.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
vivek [Mon, 15 May 2017 22:01:57 +0000 (15:01 -0700)]
bgpd: Additional configuration for EVPN
Implement configuration options for EVPN. The configuration options include
VNI configuration with RD and Import and Export Route Targets. Also, display
the EVPN configuration.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
vivek [Mon, 15 May 2017 21:42:57 +0000 (14:42 -0700)]
bgpd, zebra: Support for sticky MACs
Implement support for sticky (static) MACs. This includes the following:
- Recognize MAC is static (using NUD_NOARP flag) and inform BGP
- Construct MAC mobility extended community for sticky MACs as per
RFC 7432 section 15.2
- Inform to zebra that remote MAC is sticky, where appropriate
- Install sticky MACs into the kernel with the right flag
- Appropriate handling in route selection
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
vivek [Mon, 15 May 2017 21:34:04 +0000 (14:34 -0700)]
bgpd: EVPN route handling
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>
vivek [Mon, 15 May 2017 21:30:19 +0000 (14:30 -0700)]
bgpd: Implement EVPN enable/disable
Implement the command 'advertise-all-vni' under the EVPN address-family
in order to allow the local system to learn about local VNIs (and MACs
and Neighbors corresponding to those VNIs) and exchange with other EVPN
speakers.
vivek [Wed, 24 May 2017 21:57:34 +0000 (14:57 -0700)]
bgpd: Fix next hop setting for EVPN
The next hop for EVPN routes must be an IPv4 or IPv6 address as per
RFC 7432. Ensure this is correctly handled. Also, ensure there
are correct checks for AFI_L2VPN and nexthop AFI is not AFI_L2VPN.
vivek [Mon, 15 May 2017 19:33:59 +0000 (12:33 -0700)]
bgpd: Separate out RD handling functions
BGP Route Distinguisher (RD) handling is common for different flavors
of BGP VPNs such as BGP/MPLS IP VPNs (RFC 4364) and BGP EVPNs (RFC 7432).
Separate out the RD handling functions into its own files.
Note: No functional change introduced with this commit.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
vivek [Mon, 15 May 2017 19:31:01 +0000 (12:31 -0700)]
bgpd: Refine extended community handling
Define helper functions to form different kinds of route targets. Also,
refine functions that encode extended communities as well as generate
a string from an extended community.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
vivek [Mon, 15 May 2017 05:44:13 +0000 (22:44 -0700)]
zebra: MAC and Neighbor (ARP/ND) handling
Implement handling of MACs and Neighbors (ARP/ND entries) in zebra:
- MAC and Neighbor database handlers
- Read MACs and Neighbors from the kernel, when needed and create
entries in zebra's MAC and Neighbor databases.
- Handle add/update/delete notifications from the kernel for MACs and
Neighbors and update zebra's database appropriately
- Inform locally learnt MACs and Neighbors to client
- Handle MACIP add/delete from client and install appriporiate entries
into the kernel
- Since Neighbor entries will be installed on an SVI, implement the
needed mappings
NOTE: kernel interface is only implemented for Linux/netlink
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
vivek [Mon, 15 May 2017 05:41:04 +0000 (22:41 -0700)]
zebra: MAC and Neighbor hash table definition
Define the MAC and Neighbor (ARP/ND) data structures. These are maintained
as hash tables against the VNI. Also, define context structures used for
performing various operations on these two tables.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
vivek [Mon, 15 May 2017 05:38:26 +0000 (22:38 -0700)]
zebra: VNI and VTEP handling
Implement fundamental handling for VNIs and VTEPs:
- Handle EVPN enable/disable by client (advertise-all-vni)
- Create/update/delete VNIs based on VxLAN interface events and inform
client
- Handle VTEP add/delete from client and install into kernel
- New debug command for VxLAN/EVPN
- kernel interface (Linux/netlink only)
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
vivek [Mon, 15 May 2017 05:31:08 +0000 (22:31 -0700)]
zebra: Layer-2 interface handling
Define interface types of interest and recognize the types. Store layer-2
information (VLAN Id, VNI etc.) for interfaces, process bridge interfaces
and map bridge members to bridge. Display all the additional information
to user (through "show interface").
Note: Only implemented for the netlink interface.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
David Lamparter [Tue, 11 Jul 2017 12:52:06 +0000 (14:52 +0200)]
lib: hash: don't double-init hash list
hash_cmd_init will overwrite _hashes with a new list, while _hashes
already has been initialised from cmd_init(), thread_master_create(), or
any other function that may have created a hash.
Found while valgrind'ing ospf6d/test_lsdb.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Daniel Walton [Fri, 7 Jul 2017 19:09:22 +0000 (19:09 +0000)]
bgpd: peer-group members 'activate' when they shouldn't
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Today if you configure the following where the 'fabric' peer-group has
been deactivated for ipv4 unicast and then assign swp1/swp2 to that
peer-group we end up activating those two peers for ipv4 unicast.
Quentin Young [Mon, 19 Jun 2017 14:22:26 +0000 (14:22 +0000)]
lib, vtysh: hashtable statistics
Adds the ability to name hash tables, and a new cli command that will
show various summary statistics for named hash tables.
Statistics computed are
- load factor
- full load factor (see comments)
- stddev of full load factor
Standard deviation is computed by storing the sum of squares of bucket
lengths. This is somewhat susceptible to overflow. On platforms where a
double is 32 bits, placing 65535 or more elements into a hash table
opens up the potential for overflow, depending on how they are arranged
in buckets (which depends on the hash function). For example, placing
65535 elements into one hash bucket would cause ssq overflow, but
distributing 40000000 elements evenly among 400000 buckets (100 elements
per bucket) would not.
These cases are extremely degenerate, so the vague possibility of
overflow in an informational command is deemed an acceptable tradeoff
for constant time calculation of variance without locks or compromising
efficiency of actual table operations.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
projects / matthieu / frr.git / log