This fix updates the nexthop length of a bgp update to be
transmitted to a remote peer. Before the previous commit,
the ipv6 nexthop length was internally set to 32 bytes which
was not correct, as it should be 48 bytes which is conform
to the vpnv6 encoding format.
However, without the previous match, even if internally, the
nexthop length was set to 32, the real nexthop length was set
to 48 bytes, and everything was operating ok.
Now, if we use the following route-map, and attach it to
outgoing for vpnv6 address family, then we have a malformed
packet detected, and the peering breaks.
> route-map rmap permit 1
> set ipv6 next-hop global 5:5::3:6
> set ipv6 next-hop local fe80:55::333:222
Maintain the mp_nexthop_len to 48 bytes if it was already set
to 48 previously.
Fixes: 35ac9b53f2 ("bgpd: fix vpnv6 nexthop encoding")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Previous commits have introduced a new 8 bits nh_flag in the attr
struct that has increased the memory footprint.
Move the mp_nexthop_prefer_global boolean in the attr structure that
takes 8 bits to the new nh_flag in order to go back to the previous
memory utilization.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Use %pI4/%pI6 where possible, otherwise at least atjust stack buffer sizes
for inet_ntop() calls.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Some results:
```
====
PCRE
====
% ./a.out "^65001" "65001"
comparing: ^65001 / 65001
ret status: 0
[14:31] donatas-pc donatas /home/donatas
% ./a.out "^65001_" "65001"
comparing: ^65001_ / 65001
ret status: 0
=====
PCRE2
=====
% ./a.out "^65001" "65001"
comparing: ^65001 / 65001
ret status: 0
[14:30] donatas-pc donatas /home/donatas
% ./a.out "^65001_" "65001"
comparing: ^65001_ / 65001
ret status: 1
```
Seems that if using PCRE2, we need to escape outer `()` chars and `|`. Sounds
like a bug.
But this is only with some older PCRE2 versions. With >= 10.36, I wasn't able
to reproduce this, everything is fine and working as expected.
Adding _FRR_PCRE2_POSIX definition because pcre2posix.h does not have
include's guard.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Rather than running selected source files through the preprocessor and a
bunch of perl regex'ing to get the list of all DEFUNs, use the data
collected in frr.xref.
This not only eliminates issues we've been having with preprocessor
failures due to nonexistent header files, but is also much faster.
Where extract.pl would take 5s, this now finishes in 0.2s. And since
this is a non-parallelizable build step towards the end of the build
(dependent on a lot of other things being done already), the speedup is
actually noticeable.
Also files containing CLI no longer need to be listed in `vtysh_scan`
since the .xref data covers everything. `#ifndef VTYSH_EXTRACT_PL`
checks are equally obsolete.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
==1174993== 252 (120 direct, 132 indirect) bytes in 3 blocks are definitely lost in loss record 77 of 100
==1174993== at 0x483AB65: calloc (vg_replace_malloc.c:760)
==1174993== by 0x493C8D5: qcalloc (memory.c:116)
==1174993== by 0x378E38: aspath_dup (bgp_aspath.c:698)
==1174993== by 0x2A39E2: route_set_aspath_replace (bgp_routemap.c:2259)
==1174993== by 0x4965C71: route_map_apply_ext (routemap.c:2664)
==1174993== by 0x27BCC8: bgp_input_modifier (bgp_route.c:1657)
==1174993== by 0x281AB9: bgp_update (bgp_route.c:3992)
==1174993== by 0x286368: bgp_nlri_parse_ip (bgp_route.c:5890)
==1174993== by 0x264D20: bgp_nlri_parse (bgp_packet.c:347)
==1174993== by 0x2682FE: bgp_update_receive (bgp_packet.c:1921)
==1174993== by 0x26AA67: bgp_process_packet (bgp_packet.c:2822)
==1174993== by 0x498F5FD: thread_call (thread.c:2008)
==1174993== by 0x49253DA: frr_run (libfrr.c:1198)
==1174993== by 0x1EEC38: main (bgp_main.c:520)
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
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>
Implement the ability to match type-2 and type-5 routes
via a route-map and a prefix-list.
Add some library code to convert an evpn prefix into
a general ipv4/ipv6 prefix for type-2 and type-5 routes.
evpn prefix is really just another subtype of prefix so all
the info needed can be extracted right there.
Add a special handler to bgp_routemap for evpn type routes
when applying the outbound route-map. This calls the library
code to convert the evpn_prefix to a ipv4/ipv6 prefix and
run it through the plist code. In this we assume type-2 routes
are a /32.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Handle ORF REMOVE_ALL events as well, because now we just silently return, and
a stale dynamic prefix-list is used instead of the new one.
Before this, soft clear/route refresh was needed. Don't know the reason, but
we didn't send updates when modifying the filters.
Probably due to a massive change of filters and to avoid automatic updates :/
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Allow the end operator to match `match peer <PEERGROUPNAME>`
in a route-map. If the end operator defines interface
based peers and peer-groups that have names that overlap
the interface based peer will match first.
Fixes: #11316
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Before:
```
spine1-debian-11(config-route-map)# bgp community alias 65001:65001 test1
spine1-debian-11(config)# route-map rm permit 10
spine1-debian-11(config-route-map)# set community 65001:65001
% Malformed communities attribute
```
After:
```
spine1-debian-11(config)# bgp community alias 65001:65001 test1
spine1-debian-11(config)# route-map rm permit 10
spine1-debian-11(config-route-map)# set community 65001:65001
spine1-debian-11(config-route-map)#
```
Same for large-communities.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When the peer is configured for the first time:
```
neighbor P1 peer-group
neighbor P1 remote-as external
neighbor P1 advertise-map ADV exist-map EXIST
neighbor 10.10.10.1 peer-group P1
```
Conditional advertisements route-maps are not updated and cond. advertisements
do not work until FRR restarted. BGP sessions clear does not help.
Or even changing peer-group for a peer, causes this bug to kick in.
```
no neighbor 10.10.10.1
neighbor 10.10.10.1 peer-group P2
```
With this fix, cond. advertisements start working immediatelly.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
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>
Description:
EVPN routes marked as imported routes,
having bgp path info's extra, where as
they are not truly imported routes,
so original bgp info will be null.
Co-authored-by: Kantesh Mundaragi <kmundaragi@vmware.com>
Signed-off-by: Iqra Siddiqui <imujeebsiddi@vmware.com>
```
exit1-debian-9(config-route-map)# match ip route-source prefix-list ?
<cr>
PREFIXLIST_NAME IP prefix-list name
p1 p2
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
```
exit1-debian-9(config)# route-map test1 permit 10
exit1-debian-9(config-route-map)# match community ?
(1-99) Community-list number (standard)
(100-500) Community-list number (expanded)
COMMUNITY_LIST_NAME Community-list name
testas
exit1-debian-9(config-route-map)# match large-community ?
(1-99) Large Community-list number (standard)
(100-500) Large Community-list number (expanded)
LCOMMUNITY_LIST_NAME Large Community-list name
LCL-ORIGINATED-ALL
exit1-debian-9(config-route-map)#
```
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
if_lookup_by_name_all_vrf doesn't work correctly with netns VRF backend
as the same index may be used in multiple netns simultaneously.
Use the appropriate VRF when looking for the interface.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
