| Age | Commit message (Collapse) | Author | 
 | 
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>
 | 
 | 
To match source peer on the outgoing direction.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
 | 
 | 
Signed-off-by: Christian Hopps <chopps@labn.net>
 | 
 | 
Signed-off-by: Farid Mihoub <farid.mihoub@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.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>
 | 
 | 
opensourcerouting/feature/bgpd_node_target_extended_community
bgpd: Add Node Target Extended Communities support
 | 
 | 
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
 | 
 | 
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>
 | 
 | 
*: convert to SPDX License identifiers
 | 
 | 
Add the ability to turn on `debug routemap detail` for FRR.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
 | 
 | 
Done with a combination of regex'ing and banging my head against a wall.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
 | 
 | 
https://www.rfc-editor.org/rfc/rfc7311.html
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>
 | 
 | 
opensourcerouting/feature/route_validation_extended_community
bgpd: Implement Origin Validation State via extended communities
 | 
 | 
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>
 | 
 | 
```
route-map tstas permit 10
 set as-path replace 1
exit
```
Before:
```
donatas-laptop(config-router-af)# do show ip bgp 10.10.10.10/32
BGP routing table entry for 10.10.10.10/32, version 13
Paths: (1 available, best #1, table default)
  Advertised to non peer-group peers:
  192.168.10.65
  65000 1 2 3 123
    192.168.10.65 from 192.168.10.65 (10.10.10.11)
      Origin IGP, metric 0, valid, external, best (First path received)
      Last update: Mon Apr 25 10:39:50 2022
```
After:
```
donatas-laptop(config-router-af)# do show ip bgp 10.10.10.10/32
BGP routing table entry for 10.10.10.10/32, version 15
Paths: (1 available, best #1, table default)
  Advertised to non peer-group peers:
  192.168.10.65
  65000 65010 2 3 123
    192.168.10.65 from 192.168.10.65 (10.10.10.11)
      Origin IGP, metric 0, valid, external, best (First path received)
      Last update: Mon Apr 25 10:40:16 2022
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
 | 
 | 
Before:
```
route-map lua permit 10
exit
```
After:
```
route-map lua permit 10
 match script rm
exit
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
 | 
 | 
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
 | 
 | 
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.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>
 | 
 | 
bgpd: Route-map `set extcommunity none`
 | 
 | 
The library code should not depend on a specific daemon's code.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
 | 
 | 
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
 | 
 | 
~/frr# vtysh -c 'conf' -c 'route-map testas permit 10' -c 'set extcommunity bandwidth 321'
~/frr# vtysh -c 'show route-map testas' | grep 321
    extcommunity bandwidth 321 non-transitive
~/frr# vtysh -c 'sh run' | grep 321
~/frr#
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.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>
 | 
 | 
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
 | 
 | 
Again, see previous commits.
Signed-off-by: David Lamparter <equinox@diac24.net>
 | 
 | 
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>
 | 
 | 
Use the northbound back-end instead of the old route map CLI.
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>
 | 
 | 
These exported items are going to be used by the new northbound CLI.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
 | 
 | 
Signed-off-by: David Lamparter <equinox@diac24.net>
 |