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>
Some interfaces are special, they have the same `ifindex` with pimreg.
Use macro for `ifindex` of pimreg.
And adjust log.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
With this configuration:
```
bfd
peer 33:33::66 local-address 33:33::88 vrf vrf8 interface enp1s0
exit
!
exit
```
The bfd session can't be established with error:
```
bfdd[18663]: [YA0Q5-C0BPV] control-packet: wrong vrfid. [mhop:no peer:33:33::66 local:33:33::88 port:2 vrf:61]
```
The vrf check should use the carefully adjusted `vrfid`, which is
based on globally/reliable interface. We can't believe the
`bvrf->vrf->vrf_id` because the `/proc/sys/net/ipv4/udp_l3mdev_accept`
maybe is set "1" in VRF-lite backend even with security drawback.
Just correct the vrf check.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
When setting an loopback's cost, set the value to 0, unless the operator
has assigned a value for the loopback's cost.
RFC states:
If the state of the interface is Loopback, add a Type 3
link (stub network) as long as this is not an interface
to an unnumbered point-to-point network. The Link ID
should be set to the IP interface address, the Link Data
set to the mask 0xffffffff (indicating a host route),
and the cost set to 0.
FRR is going to allow this to be overridden if the operator specifically
sets a value too.
Fixes: #13472
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The new create range attribute is send to add to ranges, but not use if the prefix already exist in the ranges.
Signed-off-by: ryndia <dindyalsarvesh@gmail.com>
1. Fix OSPF opaque LSA processing to preserve the stale opaque
LSAs in the Link State Database for 60 seconds consistent with
what is done for other LSA types.
2. Add a topotest that tests for cases where ospfd is restarted
and a stale OSPF opaque LSA exists in the OSPF routing domain
both when the LSA is purged and when the LSA is reoriginagted
with a more recent instance.
Signed-off-by: Acee <aceelindem@gmail.com>
This test demonstrates that a label is allocated for each
ipv6 next-hop. IPv6 test introduces link local ipv6 addresses
as next hops, and compared to IPv4, one can have two different
next-hops depending if the next-hop is defined by a global
address (static route redistributed) or a bgp peer.
This test checks that:
- The labels are correctly allocated per connected next-hop.
- The default label is used for non connected prefixes.
- The withdraw operation frees the MPLS entry.
- If a recursive route is redistributed by BGP, then the nexthop
tracking will find the appropriate nexthop entry, and the
associated label will be found out.
- When a prefix moves from one peer to one another behind the
vrf, then the MPLS switching operation for return
traffic is changing the outgoing interface to use.
- When the 'label vpn export <value>' MPLS label value is changed,
then the modification is propagated to prefixes which use that value.
- Also, when unconfiguring the per-nexthop allocation mode, check
that the MPLS entries and the VPNv4 entries of r1 are changed
accordingly.
- Reversely, when re-configuring the per-nexthop allocation mode,
check that the allocation mode reuses the other label values.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
A new test suite checks for the mpls label allocation
per nexthop mode. This test checks that:
- The labels are correctly allocated per connected
next-hop.
- The default label is used for non connected prefixes
- The withdraw operation frees the mpls entry.
- If a recursive route is redistributed by BGP, then the nexthop
tracking will find the appropriate nexthop entry, and the associated
label will be found out.
- When a prefix moves from one peer to one another behind the vrf,
then the MPLS switching operation for return traffic is changing
the outgoing interface to use.
- When the 'label vpn export <value>' MPLS label value is changed,
then the modification is propagated to prefixes which use that value.
- When unconfiguring the per-nexthop allocation mode, check
that the MPLS entries and the VPNv4 entries of r1 are changed
accordingly.
- Reversely, when re-configuring the per-nexthop allocation mode,
check that the allocation mode reuses the other label values.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The following command is made available to list the labels
allocated per-nexthop, along with the paths registered to it.
> # show bgp vrf vrf1 label-nexthop
> Current BGP label nexthop cache for IP, VRF vrf1
> 192.0.2.11, label 20 #paths 3
> if r1-eth1
> Last update: Mon Jan 16 18:52:11 2023
> 192.0.2.12, label 17 #paths 2
> if r1-eth1
> Last update: Mon Jan 16 18:52:08 2023
> 192.0.2.14, label 18 #paths 1
> if r1-eth1
> Last update: Mon Jan 16 18:52:07 2023
> 192.168.255.13, label 19 #paths 1
> if r1-eth2
> Last update: Mon Jan 16 18:52:10 2023
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
A timer attribute is added for each label nexthop entry, in order
to know when the last change occured.
The timer value will be used for troubleshooting by a show
command in the next commit.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The label allocation per nexthop mode requires to use a nexthop
tracking context. For redistributed routes, a nexthop tracking
context is created, and the resolution helps to know the real
nexthop ip address used. The below configuration example has
been used:
> vrf vrf1
> ip route 172.31.0.14/32 192.0.2.14
> ip route 172.31.0.15/32 192.0.2.12
> ip route 172.31.0.30/32 192.0.2.30
> exit
> router bgp 65500 vrf vrf1
> address-family ipv4 unicast
> redistribute static
> label vpn export per-nexthop
> [..]
The static routes are correctly imported in the BGP IPv4 RIB.
Contrary to label allocation per vrf mode, some nexthop tracking
are created/or reused:
> # show bgp vrf vrf1 nexthop
> 192.0.2.12 valid [IGP metric 0], #paths 3, peer 192.0.2.12
> if r1-eth1
> Last update: Fri Jan 13 15:49:42 2023
> 192.0.2.14 valid [IGP metric 0], #paths 1
> if r1-eth1
> Last update: Fri Jan 13 15:49:42 2023
> 192.0.2.30 valid [IGP metric 0], #paths 1
> if r1-eth1
> Last update: Fri Jan 13 15:49:51 2023
> [..]
This results in having a BGP VPN route for each of the static
routes:
> # show bgp ipv4 vpn
> [..]
> Route Distinguisher: 444:1
> *> 172.31.0.14/32 192.0.2.14@9< 0 32768 ?
> *> 172.31.0.15/32 192.0.2.12@9< 0 32768 ?
> *> 172.31.0.30/32 192.0.2.30@9< 0 32768 ?
> [..]
Without that patch, only the redistributed routes that rely on a
pre-existing nexthop tracking context could be exported.
Also, a command in the code about redistributed routes is modified
accordingly, to explain that redistribute routes may be submitted
to nexthop tracking in the case label allocation per next-hop is
used.
note:
VNC routes have been removed from the redistribution,
because of a test failure in the bgp_l3vpn_to_bgp_direct test.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This is a preliminary work to export redistributed routes from
a given VRF in an VPN network. The exportation works well, when
the label allocation is based on an per-vrf mode, but not on
a per nexthop mode.
To associate a label with a connected nexthop, the nexthop
tracking contexts are used. Until today, there was no tracking
context for redistributed routes. But when using this vpn
allocation mode, one needs to know whether the route is directly
connected or not. When using the nexthop tracking context, the
nexthop attribute of the bgp update needs to have the nexthop
properly set. This was not the case for the mp_nexthop_global_in
attribute which was empty.
This commit is mandatory in order to later use nexthop tracking
context.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
BGP MPLSVPN next hop label allocation was using only the next-hop
IP address. As MPLSVPN contexts rely on bnc contexts, the real
nexthop interface is known, and the LSP entry to enter can apply
to the specific interface. To illustrate, the BGP service is able
to handle the following two iproute2 commands:
> ip -f mpls route add 105 via inet 192.0.2.45 dev r1-eth1
> ip -f mpls route add 105 via inet 192.0.2.46 dev r1-eth2
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This commit introduces a new method to associate a label to
prefixes to export to a VPNv4 backbone. All the methods to
associate a label to a BGP update is documented in rfc4364,
chapter 4.3.2. Initially, the "single label for an entire
VRF" method was available. This commit adds "single label
for each attachment circuit" method.
The change impacts the control-plane, because each BGP update
is checked to know if the nexthop has reachability in the VRF
or not. If this is the case, then a unique label for a given
destination IP in the VRF will be picked up. This label will
be reused for an other BGP update that will have the same
nexthop IP address.
The change impacts the data-plane, because the MPLs pop
mechanism applied to incoming labelled packets changes: the
MPLS label is popped, and the packet is directly sent to the
connected nexthop described in the previous outgoing BGP VPN
update.
By default per-vrf mode is done, but the user may choose
the per-nexthop mode, by using the vty command from the
previous commit. In the latter case, a per-vrf label
will however be allocated to handle networks that are not directly
connected. This is the case for local traffic for instance.
The change also include the following:
- ECMP case
In case a route is learnt in a given VRF, and is resolved via an
ECMP nexthop. This implies that when exporting the route as a BGP
update, if label allocation per nexthop is used, then two possible
MPLS values could be picked up, which is not possible with the
current implementation. Actually, the NLRI for VPNv4 stores one
prefix, and one single label value, not two. Today, RFC8277 with
multiple label capability is not yet available.
To avoid this corner case, when a route is resolved via more than one
nexthop, the label allocation per nexthop will not apply, and the
default per-vrf label will be chosen.
Let us imagine BGP redistributes a static route using the `172.31.0.20`
nexthop. The nexthop resolution will find two different nexthops fo a
unique BGP update.
> r1# show running-config
> [..]
> vrf vrf1
> ip route 172.31.0.30/32 172.31.0.20
> r1# show bgp vrf vrf1 nexthop
> [..]
> 172.31.0.20 valid [IGP metric 0], #paths 1
> gate 192.0.2.11
> gate 192.0.2.12
> Last update: Mon Jan 16 09:27:09 2023
> Paths:
> 1/1 172.31.0.30/32 VRF vrf1 flags 0x20018
To avoid this situation, BGP updates that resolve over multiple
nexthops are using the unique per-vrf label.
- recursive route case
Prefixes that need a recursive route to be resolved can
also be eligible for mpls allocation per nexthop. In that
case, the nexthop will be the recursive nexthop calculated.
To achieve this, all nexthop types in bnc contexts are valid,
except for the blackhole nexthops.
- network declared prefixes
Nexthop tracking is used to look for the reachability of the
prefixes. When the the 'no bgp network import-check' command
is used, network declared prefixes are maintained active,
even if there is no active nexthop.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This commit introduces the necessary structs and apis to
create the cache entries that store the label information
associated to a given nexthop.
A hash table is created in each BGP instance for all the
AFIs: IPv4 and IPv6. That hash table is initialised.
An API to look and/or create an entry based on a given
nexthop.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
A new label type is introduced: LP_TYPE_NEXTHOP. This new
label type will be used in next commits to allocate labels
for a specific nexthop IP address.
The commit changes add vty and json outputs to display
the new label type and the label values associated.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
A new VTY command is introduced in ipv4 unicast and ipv6 unicast
address family, under a BGP instance.
> r1# label vpn export allocation-mode per-nexthop|per-vrf
This command will update the label values associated for each
BGP update to export to the global instance. Two modes are
available: per-nexthop and per-vrf. The latter is the default
one.
With this commit only, configuring label allocation per nexthop
will only reset the BGP updates, and the per-vrf mode label
allocation will be chosen.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This commit addresses an issue with an MPLS VPN network
redistributing static routes that are exported to the VPN,
and where the labels are allocated per next-hop.
For that purpose, the nexthop of the static routes is
checked against the nexthop tracking. The validation
of a valid nexthop will trigger the use of a unique
label for all prefixes using that destination.
However, the nexthop fails to be validated, with the
following message:
> evaluate_paths: prefix 172:31::14/128 (vrf vrf1), ignoring path due to
> martian or self-next-hop
The reason is due to the way the attr is created.
By default, the ATTR_NEXTHOP attribute is set for
all prefixes, whereas this flag should only be valid
for IPv4. In the case there is an IPv6 nexthop, remove
the ATTR_NEXTHOP flag.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The 'show mpls table json' command displays the outgoing interface
name only when the nexthop type is either NEXTHOP_TYPE_IFINDEX or
NEXTHOP_TYPE_IPV6_IFINDEX. add the interface name for the nexthop
type NEXTHOP_TYPE_IPV4_IFINDEX.
Fixes: ("b78b820d46d6") MPLS: Display enhancements and JSON support
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This commit addresses the case where a service wants to install
an LSP entry to a next-hop located in a VRF instance. The incoming
MPLS packet is on the namespace and has to be directed to a nexthop
located behind an interface that sits in a specific VRF instance.
The below iproute command can illustrate:
> ip link add vrf1 type vrf table 10
> ip link set dev vrf1 up
> ip link set dev eth0 master vrf1
> ip a a 192.0.2.1/24 dev eth0
> ip -f mpls route add 105 via inet 192.0.2.45 dev eth0
If a service uses the ZEBRA_MPLS_LABELS messages, then the LSP
message is ignored: from zebra perspective, the MPLS entries are
visible via the 'show mpls table' command, but no LSP entry is
installed in the kernel.
The issue is in the nhlfe_nexthop_active_ipv[4/6] function: the
outgoing interface mentioned in the nexthop is searched in the
main VRF, whereas the interface is in a separate VRF. The interface
is not found, and the nhlfe to install is considered not active.
To address this issue, reuse the incoming vrf_id parameter transmitted
in the nexthop structure from the ZEBRA_MPLS_LABELS message. When
creating an NHLFE entry, the vrf_id is used instead of the DEFAULT_VRF.
And the nhlfe entry can be considered as active.
One alternate solution to reuse the vrf_id parameter in the mpls network
context would be to modify the search function in nhlfe_nexthop_active..()
function: looking for an existing ifindex in the zns. However, this
solution may not fit later when netns backend would be used.
Note that some changes have not been done yet and are considered
sufficient for now:
- The 'nhlfe_find' API: the assumption is done that only the linux vrf
backend is used for now.
- The 'mpls_lsp_install()' API: It is currently used by the CLI command
which does not handle the interface parameter, and the SRTE service, whih
always sends LSPs towards a nexthop located in the VRF_DEFAULT.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The ZEBRA_MPLS_LABELS_[ADD/DELETE/REPLACE] messages may change an
LSP entry based on an incoming MPLS entry, followed by a given
next-hop.
Having a next hop with no label information inside is rejected
by the zebra layer. As illustration, the following ZAPI message
would be rejected, because the next hop does not contain any
label information.
> ip -f mpls route add 105 via inet 192.0.2.45
At the same time, such configuration is desirable to be
supported:
An attempt has been done to configure the next-hop with an implicit-
null label. But the message is rejected by the kernel:
> ip -f mpls route add 104 as 3 via inet 192.0.2.45
> Error: Implicit NULL Label (3) can not be used in encapsulation.
The commit proposes to accept ZEBRA_MPLS_LABELS_[XX] messages with
a nexthop that does not contain any label information.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Added topotest cases for the modification of added
prefix lists.
Author: Vijay kumar Gupta <vijayg@vmware.com>
Signed-off-by: Samanvitha B Bhargav <bsamanvitha@vmware.com>
