In BGP, doing policy-routing requires to use table identifiers.
Flowspec protocol will need to have that. 1 API from bgp zebra has been
done to get the table chunk.
Internally, onec flowspec is enabled, the BGP engine will try to
connect smoothly to the table manager. If zebra is not connected, it
will try to connect 10 seconds later. If zebra is connected, and it is
success, then a polling mechanism each 60 seconds is put in place. All
the internal mechanism has no impact on the BGP process.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This commit is connecting the table manager with remote daemons by
handling the queries.
As the function is similar in many points with label allocator, a
function has been renamed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The range is given from table manager from zebra daemon.
There are 2 ranges available for table identifier:
- [1;252] and [256;0xffffffff]
If the wished size enters in the first range, then the start and end
range of table identifier is given within the first range.
Otherwise, the second range is given, and an appropriate range is given.
Note that for now, the case of the VRF table identifier used is not
taken into account. Meaning that there may be overlapping. There are two
cases to handle:
- case a vrf lite is allocated after the zebra and various other daemons
started.
- case a vrf lite is initialised and the daemons then start
The second case is easy to handle. For the former case, I am not so
sure.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.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>
Upon a 'ip netns del' event, the associated vrf with netns backend is
looked for, then the internal contexts are first disabled, then
suppressed.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The vrf netns usage makes a crash, when deleting vrf, due to the hash
list of rules not initialised for non default VRF.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Because vrf with netns backend may be used, the correct zns must be
found prior any modifications.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When we are removing a rule from the zns->rules_hash, free up
the rule from the hash and free the memory.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we get a rule that is supposed to replace
an existing rule, make it look like a rule replace
semantics.
Install new rule, then delete the old original rule.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This patch fixes two bugs with respect to static route configuration
inside vrf contexts:
* Entering a negative form of a static route created the static route.
* Once created, static routes could not be deleted.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
When a route_delete is received allow the deletion
to occur in the passed in tableid if the vrf is VRF_DEFAULT.
This now matches route_add behavior in rib_add_multipath
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ensure that we have properly decoded the zapi_route sent to us
and if we cannot decode, log and move on.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we have a case where the user re-enters the same
ip route line, we need to delete the memory we just
malloc'ed.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
PR #1739 added code to leak routes between (default VRF) VPN safi and unicast RIBs in any VRF. That set of changes included temporary CLI including vpn-policy blocks to specify RD/RT/label/&c. After considerable discussion, we arrived at a consensus CLI shown below.
The code of this PR implements the vpn-specific parts of this syntax:
router bgp <as> [vrf <FOO>]
address-family <afi> unicast
rd (vpn|evpn) export (AS:NN | IP:nn)
label (vpn|evpn) export (0..1048575)
rt (vpn|evpn) (import|export|both) RTLIST...
nexthop vpn (import|export) (A.B.C.D | X:X::X:X)
route-map (vpn|evpn|vrf NAME) (import|export) MAP
[no] import|export [vpn|evpn|evpn8]
[no] import|export vrf NAME
User documentation of the vpn-specific parts of the above syntax is in PR #1937
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
When figuring out whom to call and if we actually can legally
call into the handler array actually use the number of elements
in the array instead of the size of the array.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When specifying a ip route:
ip route 4.3.2.0/24 192.168.201.1 vrf DONNA
Accept DONNA even if it has not been created yet.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
If a user enters a route inside a non kernel existant vrf:
vrf BLOOP
ip route 4.3.2.0/24 192.168.201.1
!
They should be able to enter it over and over and over and
over and over no matter how futile it is.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Currently if I try to use a nexthop-vrf that has
not been specified yet we get a failure from the cli.
Add code to zebra so that if we fail to find the nexthop-vrf
we auto create it, instead of failing the install.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add to the function prototypes the names of variables
to hopefully make it easier for people to program against
this header.
Signed-off-by: Donald Sharp<sharpd@cumulusnetworks.com>
When we are signaling to a client from zebra that a nexthop
has changed, include the labels on the nexthop as well.
Upper level protocols need to know if the labels exist
in order to make intelligent decisions about what to do.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The application of a label to a route entry needs to
look at all non-recursive nexthops to be attached to
instead of just the first one.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
the rib_wib_table function was uncalled by anyone remove
and additionally remove it's static function it called.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we receive an arbitrary table over the netlink bus
save it for later perusal and sweep any routes that
we may have created from an earlier run.
The current redistribute code is limited to
ZEBRA_KERNEL_TABLE_MAX. I left this alone for the
moment because I believe it needs to be converted
to a RB tree instead of a flat array. Which is more
work for the future. Additionally this proposed
change might necessitate some cli changes or rethinks.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
It is possible for clients to install routes into tables
that they desire. Modify the code to delete these routes
from these tables as well.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When zebra detects that the originator has dissapeared
delete all rules associated with that client.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
There were several places where when I am attempting
to debug zebra functionality that I would really
like to have the ability to know what vrf I think
I am operating on.
Add the vrf_id to a bunch of zlog_debug messages
to help figure out issues when they happen.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Vty commands that link netns context to a vrf is requiring some
privileges. The change consists in retrieving the privileges at the
vrf_cmd_init() called by the relevant daemon. Then use it.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
In order to create the netns context, the zebra parser at startup needs
to have its privileges raised.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
