| Age | Commit message (Collapse) | Author |
|---|
|
Fix several issues in sourcing AIGP attribute:
1) AIGP should not be set as default for a redistributed route or a
static network. It should be set by config instead.
2) AIGP sourced by "set aigp-metric igp-metric" in a route-map does
not set the correct value for a redistributed route.
3) When redistribute a connected route like loopback, the AGIP (with
value 0) is sourced by "set aigp-metric igp-metric", but the
attribute is not propagated as the attribute flag is not set.
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
(cherry picked from commit f65356d8bb9a43b1725fafdbd30aba0de9d214fa)
|
|
The nexthop metric should be added to AIGP when calculating the
bestpath in bgp_path_info_cmp().
Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
(cherry picked from commit 081422e8e71085d3a3d4d2ff0bc1e1abaff0d52e)
|
|
If we receive MP_UNREACH_NLRI, we should stop handling remaining NLRIs if
no mandatory path attributes received.
In other words, if MP_UNREACH_NLRI received, the remaining NLRIs should be handled
as a new data, but without mandatory attributes, it's a malformed packet.
In normal case, this MUST not happen at all, but to avoid crashing bgpd, we MUST
handle that.
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit c37119df45bbf4ef713bc10475af2ee06e12f3bf)
|
|
Avoid crashing bgpd.
```
(gdb)
bgp_mp_reach_parse (args=<optimized out>, mp_update=0x7fffffffe140) at bgpd/bgp_attr.c:2341
2341 stream_get(&attr->mp_nexthop_global, s, IPV6_MAX_BYTELEN);
(gdb)
stream_get (dst=0x7fffffffe1ac, s=0x7ffff0006e80, size=16) at lib/stream.c:320
320 {
(gdb)
321 STREAM_VERIFY_SANE(s);
(gdb)
323 if (STREAM_READABLE(s) < size) {
(gdb)
34 return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
(gdb)
Thread 1 "bgpd" received signal SIGSEGV, Segmentation fault.
0x00005555556e37be in route_set_aspath_prepend (rule=0x555555aac0d0, prefix=0x7fffffffe050,
object=0x7fffffffdb00) at bgpd/bgp_routemap.c:2282
2282 if (path->attr->aspath->refcnt)
(gdb)
```
With the configuration:
```
neighbor 127.0.0.1 remote-as external
neighbor 127.0.0.1 passive
neighbor 127.0.0.1 ebgp-multihop
neighbor 127.0.0.1 disable-connected-check
neighbor 127.0.0.1 update-source 127.0.0.2
neighbor 127.0.0.1 timers 3 90
neighbor 127.0.0.1 timers connect 1
address-family ipv4 unicast
redistribute connected
neighbor 127.0.0.1 default-originate
neighbor 127.0.0.1 route-map RM_IN in
exit-address-family
!
route-map RM_IN permit 10
set as-path prepend 200
exit
```
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit b08afc81c60607a4f736f418f2e3eb06087f1a35)
|
|
This reverts commit 8b531b110756bf8627b5716f433190a0748b5e76.
(cherry picked from commit 166e52d6a31c517861be316af6c5737e43c2f48f)
|
|
Add the ability to store a raw copy of the incoming BGP Link-State
attributes and to redistribute them as is to other routes.
New types of data BGP_ATTR_LS and BGP_ATTR_LS_DATA are defined.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
|
|
Just reuse an existing more-readable code.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
To be consistent and error-safe.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
bgpd,lib,yang: add colored extended communities support
|
|
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
|
|
Adds a generalized martian reimport function used for triggering a
relearn/reimport of EVPN routes that were previously filtered/deleted
as a result of a "self" check (either during import or by a martian
change handler). The MAC-VRF SoO is the first consumer of this function,
but can be expanded for use with Martian Tunnel-IPs, Interface-IPs,
Interface-MACs, and RMACs.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
|
|
*: convert to SPDX License identifiers
|
|
Done with a combination of regex'ing and banging my head against a wall.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
|
|
To filter out routes with unwanted prefixes.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Just forgot this _somehow_ :)
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
The idea is to drop unwanted attributes from the BGP UPDATE messages and
continue by just ignoring them. This improves the security, flexiblity, etc.
This is the command that Cisco has also.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
This reverts commit 16aa1809e7c8caad37e8edd4e5aaac4f344bc7d3, reversing
changes made to f616e716089b16d9a678846282a6ac5c55e31a56.
|
|
When the last IPv4 address of an interface is deleted, Linux removes all
routes includes BGP ones using this interface without any Netlink
advertisement. bgpd keeps them in RIB as valid (e.g. installed in FIB).
The previous patch invalidates the associated nexthop groups in zebra
but bgpd is not notified of the event.
> 2022/05/09 17:37:52.925 ZEBRA: [TQKA8-0276P] Not Notifying Owner: connected about prefix 29.0.0.0/24(40) 3 vrf: 7
Look for the bgp_path_info that are unsynchronized with the kernel and
flag them for refresh in their attributes. A VPN route leaking update is
calles and the refresh flag triggers a route refresh to zebra and then a
kernel FIB installation.
Signed-off-by: Louis Scalbert <louis.scalbert@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>
|
|
At bgpd startup, VRF instances are sent from zebra before the
interfaces. When importing a l3vpn prefix from another local VRF
instance, the interfaces are not known yet. The prefix nexthop interface
cannot be set to the loopback or the VRF interface, which causes setting
invalid routes in zebra.
Update route leaking when the loopback or a VRF interface is received
from zebra.
At a VRF interface deletion, zebra voluntarily sends a
ZEBRA_INTERFACE_ADD message to move it to VRF_DEFAULT. Do not update if
such a message is received. VRF destruction will destroy all the related
routes without adding codes.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
|
|
If 'network import-check' is defined on the source BGP session, prefixes
that are stated in the network command cannot be leaked to the other
VRFs BGP table even if they are present in the origin VRF RIB if the
'rt import' statement is defined after the 'network <prefix>' ones.
When a prefix nexthop is updated, update the prefix route leaking. The
current state of nexthop validation is now stored in the attributes of
the bgp path info. Attributes are compared with the previous ones at
route leaking update so that a nexthop validation change now triggers
the update of destination VRF BGP table.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
|
|
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Just do not reset next-hop for MPLS VPN routes.
Example of 172.16.255.1/32 (using extended next-hop capability):
```
pe2# sh bgp ipv4 vpn
BGP table version is 4, local router ID is 10.10.10.20, 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
Route Distinguisher: 192.168.1.2:2
*>i10.0.0.0/24 2001:db8:1::1 0 100 0 65000 ?
UN=2001:db8:1::1 EC{192.168.1.2:2} label=1111 type=bgp, subtype=0
*>i172.16.255.1/32 2001:db8::1 0 100 0 65000 ?
UN=2001:db8::1 EC{192.168.1.2:2} label=1111 type=bgp, subtype=0
*>i192.168.1.0/24 2001:db8:1::1 0 100 0 65000 ?
UN=2001:db8:1::1 EC{192.168.1.2:2} label=1111 type=bgp, subtype=0
*>i192.168.2.0/24 2001:db8:1::1 100 0 65000 ?
UN=2001:db8:1::1 EC{192.168.1.2:2} label=1111 type=bgp, subtype=0
Route Distinguisher: 192.168.2.2:2
*> 10.0.0.0/24 192.168.2.1@4< 0 50 0 65000 ?
UN=192.168.2.1 EC{192.168.2.2:2} label=2222 type=bgp, subtype=5
*> 172.16.255.1/32 192.168.2.1@4< 50 0 65000 ?
UN=192.168.2.1 EC{192.168.2.2:2} label=2222 type=bgp, subtype=5
*> 192.168.1.0/24 192.168.2.1@4< 50 0 65000 ?
UN=192.168.2.1 EC{192.168.2.2:2} label=2222 type=bgp, subtype=5
*> 192.168.2.0/24 192.168.2.1@4< 0 50 0 65000 ?
UN=192.168.2.1 EC{192.168.2.2:2} label=2222 type=bgp, subtype=5
Displayed 8 routes and 8 total paths
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
https://www.rfc-editor.org/rfc/rfc7311.html
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
In order to send correct SRv6 L3VPN advertisement, we need to save
srv6_locator_chunk in vpn_policy. With this information, we can
construct correct SRv6 L3VPN advertisement packets.
Signed-off-by: Ryoga Saito <ryoga.saito@linecorp.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>
|
|
RFC9234 is a way to establish correct connection roles (Customer/
Provider, Peer or with RS) between bgp speakers. This patch:
- Add a new configuration/terminal option to set the appropriate local
role;
- Add a mechanism for checking used roles, implemented by exchanging
the corresponding capabilities in OPEN messages;
- Add strict mode to force other party to use this feature;
- Add basic support for a new transitive optional bgp attribute - OTC
(Only to Customer);
- Add logic for default setting OTC attribute and filtering routes with
this attribute by the edge speakers, if the appropriate conditions are
met;
- Add two test stands to check role negotiation and route filtering
during role usage.
Signed-off-by: Eugene Bogomazov <eb@qrator.net>
|
|
When we use network/redistribute local_preference is configured inproperly
when using route-maps something like:
```
network 100.100.100.100/32 route-map rm1
network 100.100.100.200/32 route-map rm2
route-map rm1 permit 10
set local-preference +10
route-map rm2 permit 10
set local-preference -10
```
Before:
```
root@spine1-debian-11:~# vtysh -c 'show bgp ipv4 unicast 100.100.100.100/32 json' | jq '.paths[].locPrf'
10
root@spine1-debian-11:~# vtysh -c 'show bgp ipv4 unicast 100.100.100.200/32 json' | jq '.paths[].locPrf'
0
```
After:
```
root@spine1-debian-11:~# vtysh -c 'show bgp ipv4 unicast 100.100.100.100/32 json' | jq '.paths[].locPrf'
110
root@spine1-debian-11:~# vtysh -c 'show bgp ipv4 unicast 100.100.100.200/32 json' | jq '.paths[].locPrf'
90
```
Set local-preference as the default value configured per BGP instance, but
do not set LOCAL_PREF flag by default.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
bgp_attr.h has function declarations that are
not properly aligned with our standard on how
to do so. Fix.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
opensourcerouting/feature/reuse_bgp_attr_set_community_for_flags
bgpd: Reuse bgp_attr_set_[el]community() for setting attribute flags
|
|
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
revert recent bgp attr->extra changes
|
|
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
This reverts commit 2703b7db19cebad82772d5210132dab412b855c3.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
|
|
This reverts commit fc6ba64f04696416a1216bb57a7fd72efc5a0904.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
|
|
bgp_attr_undup does the same thing as bgp_attr_flush – frees the
temporary data that might be allocated when applying a route-map. There
is no need to have two separate functions for that.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
|
|
bgpd: Move attr->pmsi_tnl_type to attr->extra->pmsi_tnl_type
|
|
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
This is an extra work before moving attr->ecommunity to attra_extra struct.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
bgpd: Move out ipv6_ecommunity struct from attr to attr_extra
|
|
Rename addpath_encode[d] to addpath_capable to be consistent.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
This is the initial work to move all non IPv4/IPv6 AFI related
attributes/structs to attr->extra to avoid unnecesarry allocations.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
|
|
Add support for Prefix-SID (Type 5)
|
|
Description:
Change is intended for fixing the following issues related to vrf route leaking:
Routes with special nexthops i.e. blackhole/sink routes when imported,
are not programmed into the FIB and corresponding nexthop is set as 'inactive',
nexthop interface as 'unknown'.
While importing/leaking routes between VRFs, in case of special nexthop(ipv4/ipv6)
once bgp announces route(s) to zebra, nexthop type is incorrectly set as
NEXTHOP_TYPE_IPV6_IFINDEX/NEXTHOP_TYPE_IFINDEX
i.e. directly connected even though we are not able to resolve through an interface.
This leads to nexthop_active_check marking nexthop !NEXTHOP_FLAG_ACTIVE.
Unable to find the active nexthop(s), route is not programmed into the FIB.
Whenever BGP leaks routes, set the correct nexthop type, so that route gets resolved
and correctly programmed into the FIB, in the imported vrf.
Co-authored-by: Kantesh Mundaragi <kmundaragi@vmware.com>
Signed-off-by: Iqra Siddiqui <imujeebsiddi@vmware.com>
|
|
This patch enables frr to advertise SRv6 SID information with SID
structure Sub-Sub-TLV.
Signed-off-by: Ryoga Saito <contact@proelbtn.com>
|
|
draft-ietf-bess-srv6-services-07 defines new SID structure Sub-Sub-TLV.
This patch adds SID structure information to bgp_attr_srv6_l3vpn. This
patch also defines default SID stucture used by following patches.
Signed-off-by: Ryoga Saito <contact@proelbtn.com>
|
