| Age | Commit message (Collapse) | Author |
|---|
|
When a MPLS channel is reloaded, it should reload all regular MPLS-aware
channels. This causes re-evaluation of routes in FEC map and possibly
reannouncement of MPLS routes.
|
|
|
|
This allows changing label policy or label range without restart.
|
|
|
|
Fields import_target / export_target link to config structures, must be
updated during reconfiguration.
|
|
Use mpls_new_label() / mpls_free_label() also for static labels, to keep
track of allocated labels and to enforce label ranges.
Static label allocations always use static label range, regardless of
configured label range.
|
|
Instead of just using route attributes, static routes with
static MPLS labels can be defined just by e.g.:
route 10.1.1.0/24 mpls 100 via 10.1.2.1 mpls 200;
|
|
|
|
Allow to shorten label range over unused area.
|
|
Add command to show MPLS label ranges and their stats.
|
|
|
|
Add function lmap_last_one_in_range() for finding the last active label
in a label range.
|
|
The L3VPN protocol implements RFC 4364 BGP/MPLS VPNs using MPLS backbone.
It works similarly to pipe. It connects IP table (one per VRF) with (global)
VPN table. Routes passed from VPN table to IP table are stripped of RD and
filtered by import targets, routes passed in the other direction are extended
with RD, MPLS labels and export targets in extended communities. A separate
MPLS channel is used to announce MPLS routes for the labels.
|
|
The new labeling policy MPLS_POLICY_VRF assigns one label to all routes
(from the same FEC map associated with one VRF), while replaces their
next hops with a lookup to a VRF table. This is useful for L3VPN
protocol.
|
|
When MPLS is active, received routes on MPLS-aware SAFIs (ipvX-mpls,
vpnX-mpls) are automatically labeled according to active label policy and
corresponding MPLS routes are automatically generated. Also routes sent
on MPLS-aware SAFIs announce local labels when it should be done.
|
|
When MPLS is active, static IP/VPN routes are automatically labeled
according to active label policy and corresponding MPLS routes are
automatically generated.
|
|
The MPLS subsystem manages MPLS labels and handles their allocation to
MPLS-aware routing protocols. These labels are then attached to IP or VPN
routes representing label switched paths -- LSPs.
There was already a preliminary MPLS support consisting of MPLS label
net_addr, MPLS routing tables with static MPLS routes, remote labels in
next hops, and kernel protocol support.
This patch adds the MPLS domain as a basic structure representing local
label space with dynamic label allocator and configurable label ranges.
To represent LSPs, allocated local labels can be attached as route
attributes to IP or VPN routes with local labels as attributes.
There are several steps for handling LSP routes in routing protocols --
deciding to which forwarding equivalence class (FEC) the LSP route
belongs, allocating labels for new FECs, announcing MPLS routes for new
FECs, attaching labels to LSP routes. The FEC map structure implements
basic code for managing FECs in routing protocols, therefore existing
protocols can be made MPLS-aware by adding FEC map and delegating
most work related to local label management to it.
|
|
|
|
In general, private_id is sparse and protocols may want to map some
internal values directly into it. For example, L3VPN needs to
map VPN route discriminators to private_id.
OTOH, u32 is enough for global_id, as these identifiers are dense.
|
|
Both toggles are on by default but if some implementation needs one or
another to be switched off separately, then it's possible now.
|
|
|
|
|
|
|
|
Add a new protocol offering route aggregation.
User can specify list of route attributes in the configuration file and
run route aggregation on the export side of the pipe protocol. Routes are
sorted and for every group of equivalent routes new route is created and
exported to the routing table. It is also possible to specify filter
which will run for every route before aggregation.
Furthermore, it will be possible to set attributes of new routes
according to attributes of the aggregated routes.
This is a work in progress.
Original work by Igor Putovny, subsequent cleanups and finalization by
Maria Matejka.
|
|
|
|
All these must be declared as bytestring. Allows operators to delete
unwanted attributes breaking the Internet:
https://blog.benjojo.co.uk/post/bgp-path-attributes-grave-error-handling
|
|
|
|
|
|
|
|
|
|
Undefined paths and clists should use typed f_val with empty adata
instead of just void f_val. Use common initializer to handle both
variables and eattrs.
|
|
Remove warning when function-like syntax is used for calling
add/remove/... methods.
Fix argument offset in error messages for function-like syntax.
|
|
|
|
|
|
When no matching method is found, print an error response containing
position and type of infringing argument and a set of expected types.
|
|
List of arguments for function calls is constructed in reverse and then
reverted. This was done in function_call grammar rule. Do the reverse
directly in var_list grammar rule. This fixes reverse order of arguments
in method calls.
|
|
The C-style syntax does not really fit into rest of our syntax.
|
|
- Extend method descriptors with type signature
- Daisy chain method descriptors for the same symbol
- Dispatch methods for same symbol based on type signature
- Split add/delete/filter operations to multiple methods
- Replace ad-hoc dispatch of old-style syntax with scope-based dispatch
- Also change method->arg_num to count initial arg
It still needs some improvements, like better handling of untyped
expressions and better error reporting when no dispatch can be done.
The multiple dispatch could also be extended to dispatch regular
function-like expressions in a uniform way.
|
|
|
|
|
|
Macro METHOD_R() is used for simplest methods, there is no place to
define argument types, so let's force it to be 0.
|
|
No need to have toksym in symbol_known, as defined symbols are preferred
(by scope) to keywords anyway. Adding it just creates grammar conflicts.
|
|
|
|
|
|
|
|
|
|
Methods can now be called as x.m(y), as long as x can have its type
inferred in config time. If used as a command, it modifies the object,
if used as a value, it keeps the original object intact.
Also functions add(x,y), delete(x,y), filter(x,y) and prepend(x,y) now
spit a warning and are considered deprecated.
It's also possible to call a method on a constant, see filter/test.conf
for examples like bgp_path = +empty+.prepend(1).
Inside instruction definitions (filter/f-inst.c), a METHOD_CONSTRUCTOR()
call is added, which registers the instruction as a method for the type
of its first argument. Each type has its own method symbol table and
filter parser switches between them based on the inferred type of the
object calling the method.
Also FI_CLIST_(ADD|DELETE|FILTER) instructions have been split to allow
for this method dispatch. With type inference, it's now possible.
|
|
|
|
|
|
|
