summaryrefslogtreecommitdiffstats
path: root/bgpd/bgp_routemap_nb_config.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* bgpd: add colored extended communities supportFrancois Dumontet2023-06-261-0/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* bgpd: Implement `match source-protocol` for route-mapsDonatas Abraitis2023-05-111-0/+54
| | | | | | | | 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>
* bgpd: Implement Node Target Extended CommunitiesDonatas Abraitis2023-04-141-0/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* yang, bgpd: Fix "aggregator-asn" to support asdotanlan_cs2023-03-161-0/+10
| | | | | | | | | | | | | | The following command is not working: > (routemap) set aggregator as ASNUM A.B.C.D Since "aggregator-asn" has already supported asdot, fixed it with new yang type. Extra ASN validation (leading zeroes for instance) are done in the validate hook of the yang leaf. Signed-off-by: anlan_cs <vic.lan@pica8.com> Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* *: auto-convert to SPDX License IDsDavid Lamparter2023-02-091-14/+1
| | | | | | Done with a combination of regex'ing and banging my head against a wall. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* bgpd: Implement Accumulated IGP Metric Attribute for BGPDonatas Abraitis2022-10-261-0/+52
| | | | | | https://www.rfc-editor.org/rfc/rfc7311.html Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
* Merge pull request #11899 from ↵Russ White2022-09-131-0/+54
|\ | | | | | | | | opensourcerouting/feature/route_validation_extended_community bgpd: Implement Origin Validation State via extended communities
| * bgpd: Handle Origin Validation State extended community via route-map matchDonatas Abraitis2022-09-041-0/+54
| | | | | | | | | | | | | | | | 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>
* | bgpd: add resolution for l3vpn traffic over gre interfacesPhilippe Guibert2022-09-051-0/+53
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* bgpd: Add `set as-path replace <any|ASN>` cmd for route-mapsDonatas Abraitis2022-04-251-0/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ``` 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>
* bgpd, lib: fix inconsistency of match ip/ipv6 next-hop commandsIgor Ryzhov2021-11-191-1/+1
| | | | | | | | | | For IPv4 matching, we have "match ip next-hop address A.B.C.D". For IPv6 matching, we have "match ipv6 next-hop X:X::X:X". To have consistency, let's add "address" keyword to IPv6 commands. Old commands are preserved as hidden for backward compatibility. Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
* bgpd: Check return code for bgp_route_match_addDonald Sharp2021-10-061-2/+9
| | | | | | | | FRR uses bgp_route_match_add and checked the return code in every place but one. Fix so that the return code is looked at and warned against Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* bgpd: Check return from generic_set_addDonald Sharp2021-10-061-5/+19
| | | | | | | | | Coverity found a couple of spots where FRR was ignoring the return code of generic_set_add. Just follow the code pattern for the rest of the usage in the code. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* Merge pull request #9439 from ton31337/feature/set_ext_community_to_noneRuss White2021-09-011-0/+58
|\ | | | | bgpd: Route-map `set extcommunity none`
| * bgpd: Add an ability to set extcommunity to none in route-mapsDonatas Abraitis2021-08-181-0/+58
| | | | | | | | Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
* | lib: remove the dependency on bgpd codeIgor Ryzhov2021-08-241-1/+0
|/ | | | | | The library code should not depend on a specific daemon's code. Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
* bgpd: Keep extcommunity bandwidth commands persistent in route-mapsDonatas Abraitis2021-08-031-7/+2
| | | | | | | | | | ~/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>
* bgpd: Add route-map `match alias` commandDonatas Abraitis2021-07-211-0/+56
| | | | | | | 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>
* bgpd: Avoid more assignments within checks (round 2)Donatas Abraitis2021-06-291-2/+2
| | | | Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
* bgpd: Add "set evpn gateway-ip" clause for route-mapAmeya Dharkar2021-06-081-0/+104
| | | | | | | | | | | | | | | | | | | | | | | | | - 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>
* *: make sure `config.h` or `zebra.h` is firstDavid Lamparter2021-04-231-0/+2
| | | | | | | | | | | | `config.h` has all the defines from autoconf, which may include things that switch behavior of other included headers (e.g. _GNU_SOURCE enabling prototypes for additional functions.) So, the first include in any `.c` file must be either `config.h` (with the appropriate guard) or `zebra.h` (which includes `config.h` first thing.) Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* bgpd: North-bound implementation for bgp rmapsSarita Patra2021-03-301-0/+2637
This commit introduces the implementation for the north-bound callbacks for the bgp-specific route-map match and set clauses. Signed-off-by: NaveenThanikachalam <nthanikachal@vmware.com> Signed-off-by: Sarita Patra <saritap@vmware.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-22 14:08:09 +0100