Zebra receiving a macip_del message will automatically call
into the set_master function( a pim function ). Add missing
break statement
Ticket: CM-16841
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Don Slice <dslice@cumulusnetworks.com>
Now we have a single command for IPv4 static routes and another one for
IPv6 static routes (+ one command for IPv4 multicast static routes).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Fully specified routes are useful when you need to ensure that the
nexthop address is reachable through the specified interface.
Addresses Issue #641.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This is a preliminary step to join both functions into one later.
The main idea here is to make these functions have separate arguments
for the nexthop address and the nexthop interface, and adjust the call
sites appropriately. Having an argument that could be a nexthop address
OR a nexthop interface was making the code very hard to follow. With
this simplification, a lot of code duplication was removed and now both
functions look very similar.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
We don't need to enforce that the interface exists because the route can
be activated later once the interface becomes available. We already do
this for IPv4 routes and IPv6 routes with both a nexthop address and a
nexthop interface.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
- The 'reject' keyword was being lost
- Hide the "ip route A.B.C.D A.B.C.D" config options since these will be
displayed as "ip route A.B.C.D/X"
The pimregX devices when created by the kernel are put into
the default vrf. When pim gets the callback that the device
exists, check to see if it is a pimregX device and if so
move it into the appropriate vrf.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This current implementation unfortunately must
ask the kernel for all mroutes because vrf's
do not have the ability to request a single
mroute at this time.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
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>
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.
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>
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>
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>
