Add a mechanism in route-map to filter out route-map which have a list
of extended communities greater than the given number.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add a mechanism in route-map to filter out route-map which have a list
of communities greater than the given number.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This would give more details why at some point we return deny, no match, etc.
Before this we have sometimes (I don't know why), e.g.:
```
Route-map: null, prefix: 192.168.2.0/24, result: deny
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Add the abilty to track how much time is spent in routemaps.
Example of the new output:
eva# show route-map
ZEBRA:
route-map: FOO Invoked: 1000000 (323 milliseconds total) Optimization: enabled Processed Change: false
deny, sequence 10 Invoked 1000000 (320 milliseconds total)
Match clauses:
Set clauses:
Call clause:
Action:
Exit routemap
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
add support of color extended community, conforming to RFC 9012.
This extended community will be added to the existing one, RT,SOO
and Node Target. The configuration will be made through the
route-map service.
find above a configuration example:
router bgp 65001
bgp router-id 192.168.1.1
no bgp ebgp-requires-policy
no bgp network import-check
neighbor 192.168.1.2 remote-as external
neighbor 192.168.1.3 remote-as external
neighbor 192.168.1.4 remote-as external
address-family ipv4 unicast
network 10.10.10.10/24 route-map rmap
exit-address-family
!
route-map rmap permit 10
set extcommunity color 55555 200
exit
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
The main idea is to filter routes by matching source (originating) protocol
for outgoing direction. For instance, filter outgoing routes to an arbitrary
router that are static only. Or filter out only routes learned from RIP.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
kttps://datatracker.ietf.org/doc/html/draft-ietf-idr-node-target-ext-comm
unet> sh r1 vtysh -c 'sh ip bgp nei 192.168.1.2 adver'
BGP table version is 1, local router ID is 192.168.1.1, vrf id 0
Default local pref 100, local AS 65001
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.10.10.10/32 0.0.0.0 0 32768 i
Total number of prefixes 1
unet> sh r1 vtysh -c 'sh ip bgp nei 192.168.1.3 adver'
BGP table version is 1, local router ID is 192.168.1.1, vrf id 0
Default local pref 100, local AS 65001
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.10.10.10/32 0.0.0.0 0 32768 i
Total number of prefixes 1
unet> sh r2 vtysh -c 'show ip bgp 10.10.10.10/32'
% Network not in table
unet> sh r3 vtysh -c 'show ip bgp 10.10.10.10/32'
BGP routing table entry for 10.10.10.10/32, version 1
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
192.168.1.1
65001
192.168.1.1 from 192.168.1.1 (192.168.1.1)
Origin IGP, metric 0, valid, external, best (First path received)
Extended Community: NT:192.168.1.3 NT:192.168.1.4
Last update: Tue Apr 11 23:19:33 2023
unet>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
There are lib debugs being set but never show up in
`show debug` commands because there was no way to show
that they were being used. Add a bit of infrastructure
to allow this and then use it for `debug route-map`
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When a route imported from l3vpn is analysed, the nexthop from default
VRF is looked up against a valid MPLS path. Generally, this is done on
backbones with a MPLS signalisation transport layer like LDP. Generally,
the BGP connection is multiple hops away. That scenario is already
working.
There is case where it is possible to run L3VPN over GRE interfaces, and
where there is no LSP path over that GRE interface: GRE is just here to
tunnel MPLS traffic. On that case, the nexthop given in the path does not
have MPLS path, but should be authorized to convey MPLS traffic provided
that the user permits it via a configuration command.
That commit introduces a new command that can be activated in route-map:
> set l3vpn next-hop encapsulation gre
That command authorizes the nexthop tracking engine to accept paths that
o have a GRE interface as output, independently of the presence of an LSP
path or not.
A configuration example is given below. When bgp incoming vpnv4 updates
are received, the nexthop of NLRI is 192.168.0.2. Based on nexthop
tracking service from zebra, BGP knows that the output interface to reach
192.168.0.2 is r1-gre0. Because that interface is not MPLS based, but is
a GRE tunnel, then the update will be using that nexthop to be installed.
interface r1-gre0
ip address 192.168.0.1/24
exit
router bgp 65500
bgp router-id 1.1.1.1
neighbor 192.168.0.2 remote-as 65500
!
address-family ipv4 unicast
no neighbor 192.168.0.2 activate
exit-address-family
!
address-family ipv4 vpn
neighbor 192.168.0.2 activate
neighbor 192.168.0.2 route-map rmap in
exit-address-family
exit
!
router bgp 65500 vrf vrf1
bgp router-id 1.1.1.1
no bgp network import-check
!
address-family ipv4 unicast
network 10.201.0.0/24
redistribute connected
label vpn export 101
rd vpn export 444:1
rt vpn both 52:100
export vpn
import vpn
exit-address-family
exit
!
route-map rmap permit 1
set l3vpn next-hop encapsulation gre
exit
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add an ability to match via route-maps. An additional route-map command
`match rpki-extcommunity <invalid|notfound|valid>` added.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Description:
- When there are multiple policies configured with
route-map then the first matching policy is not
getting applied on default route originated with
default-originate.
- In BGP we first run through the BGP RIB and then
pass it to the route-map to find if its permit or
deny. Due to this behaviour the first route in
BGP RIB that passes the route-map will be applied.
Fix:
- Passing extra parameter to routemap_apply so that
we can get the preference of the matching policy,
keep comparing it with the old preference and finally
consider the policy with less preference.
Co-authored-by: Abhinay Ramesh <rabhinay@vmware.com>
Signed-off-by: Iqra Siddiqui <imujeebsiddi@vmware.com>
Why would this be in a vector to loop over with strcmp()'ing each
item... that just makes no sense. Use a hash instead.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
To ensure this, add a const modifier to functions' arguments. Would be
great do this initially and avoid this large code change, but better
late than never.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Sometimes it's needed to match by fields of one object but set fields of
another object. The following commit is an example.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Will be handy to filter BGP prefixes by using BGP community alias
instead of numerical community values.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
Adding the "clear ipv6 ospf6 command" . It resets
the ospfv3 datastructures and clears the database
as well as route tables. It resets the neighborship
by restarting the interface state machine.
If the user wants to change the router-id, this
command updates the router-id to the latest static
router-id and starts the neighbor formation with
the new router-id.
Signed-off-by: Yash Ranjan <ranjany@vmware.com>
- Add following set clause for route-maps
"set evpn gateway-ip <ipv4|ipv6 >A.B.C.D|X:X::X:X"
- When this route-map is applied as outboubd policy in BGP, it will set the
gateway-ip in BGP attribute For EVPN type-5 routes.
Example configuration:
route-map RMAP-EVPN_GWIP permit 5
set evpn gateway-ip ipv4 50.0.2.12
set evpn gateway-ip ipv6 50:0:2::12
router bgp 101
bgp router-id 10.100.0.1
neighbor 10.0.1.2 remote-as 102
!
address-family l2vpn evpn
neighbor 10.0.1.2 activate
neighbor 10.0.1.2 route-map RMAP-EVPN_GWIP out
advertise-all-vni
exit-address-family
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
Currently we have a "route-map optimization" command which is entered
from inside the route-map entry but actually applies to the whole
route-map. In addition, this command is not shown in the running-config
and not stored to the startup-config during "write".
Let's add a new command on the config node level to control this setting
and show it in the running-config to make possible to save it during
"write".
The old command is saved for the backward compatibility but hidden and
marked as deprecated.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
This commit introduces the changes to the library route-map
north-bound callback implementation in order to align it to
the modified yang definitions.
Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
Signed-off-by: Sarita Patra <saritap@vmware.com>
Back when I put this together in 2015, ISO C11 was still reasonably new
and we couldn't require it just yet. Without ISO C11, there is no
"good" way (only bad hacks) to require a semicolon after a macro that
ends with a function definition. And if you added one anyway, you'd get
"spurious semicolon" warnings on some compilers...
With C11, `_Static_assert()` at the end of a macro will make it so that
the semicolon is properly required, consumed, and not warned about.
Consistently requiring semicolons after "file-level" macros matches
Linux kernel coding style and helps some editors against mis-syntax'ing
these macros.
Signed-off-by: David Lamparter <equinox@diac24.net>
The route_map_object_t was being used to track what protocol we were
being called against. But each protocol was only ever calling itself.
So we had a variable that was only ever being passed in from route_map_apply
that had to be carried against and everyone was testing if that variable
was for their own stack.
Clean up this route_map_object_t from the entire system. We should
speed some stuff up. Yes I know not a bunch but this will add up.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
For the sake of Segment Routing (SR) and Traffic Engineering (TE)
Policies there's a need for additional infrastructure within zebra.
The infrastructure in this PR is supposed to manage such policies
in terms of installing binding SIDs and LSPs. Also it is capable of
managing MPLS labels using the label manager, keeping track of
nexthops (for resolving labels) and notifying interested parties about
changes of a policy/LSP state. Further it enables a route map mechanism
for BGP and SR-TE colors such that learned BGP routes can be mapped
onto SR-TE Policies.
This PR does not introduce any usable features by now, it is just
infrastructure for other upcoming PRs which will introduce 'pathd',
a new SR-TE daemon.
Co-authored-by: Renato Westphal <renato@opensourcerouting.org>
Co-authored-by: GalaxyGorilla <sascha@netdef.org>
Signed-off-by: Sebastien Merle <sebastien@netdef.org>
Having a fixed set of parameters for each northbound callback isn't a
good idea since it makes it difficult to add new parameters whenever
that becomes necessary, as several hundreds or thousands of existing
callbacks need to be updated accordingly.
To remediate this issue, this commit changes the signature of all
northbound callbacks to have a single parameter: a pointer to a
'nb_cb_x_args' structure (where x is different for each type
of callback). These structures encapsulate all real parameters
(both input and output) the callbacks need to have access to. And
adding a new parameter to a given callback is as simple as adding
a new field to the corresponding 'nb_cb_x_args' structure, without
needing to update any instance of that callback in any daemon.
This commit includes a .cocci semantic patch that can be used to
update old code to the new format automatically.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
* This commit implements the code style suggestions from Polychaeta.
* This commit also introduces a CLI to toggle the optimization and, a hidden
CLI to display the contents of the constructed prefix tree.
Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
* This commit introduces the building blocks.
A per-route-map prefix tree is introduced.
This tree will consist of the prefixes defined within the prefix-lists
that are added to the match clause of that route-map.
Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com>
Keep a list of hook contexts used by northbound so we don't lose the
pointer when free()ing the route map index entry data.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Based on the route map old CLI, implement the route map handling using
the exported functions.
Use a curry-like programming pattern avoid code repetition when
destroying match/set entries. This is needed by other daemons that
implement custom route map functions and need to pass to lib their
specific destroy functions.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
