mirror of
https://git.proxmox.com/git/mirror_frr
synced 2025-04-28 21:06:50 +00:00
7bae48960e
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> |
||
|---|---|---|
| .github | ||
| alpine | ||
| babeld | ||
| bfdd | ||
| bgpd | ||
| debian | ||
| doc | ||
| docker | ||
| eigrpd | ||
| fpm | ||
| gdb | ||
| grpc | ||
| include | ||
| isisd | ||
| ldpd | ||
| lib | ||
| m4 | ||
| mgmtd | ||
| mlag | ||
| nhrpd | ||
| ospf6d | ||
| ospfclient | ||
| ospfd | ||
| pathd | ||
| pbrd | ||
| pceplib | ||
| pimd | ||
| pkgsrc | ||
| python | ||
| qpb | ||
| redhat | ||
| ripd | ||
| ripngd | ||
| sharpd | ||
| snapcraft | ||
| staticd | ||
| tests | ||
| tools | ||
| vrrpd | ||
| vtysh | ||
| watchfrr | ||
| yang | ||
| zebra | ||
| .clang-format | ||
| .dockerignore | ||
| .flake8 | ||
| .git-blame-ignore-revs | ||
| .gitignore | ||
| .isort.cfg | ||
| .pylintrc | ||
| .travis.yml | ||
| bootstrap.sh | ||
| buildtest.sh | ||
| config.version.in | ||
| configure.ac | ||
| COPYING | ||
| Makefile.am | ||
| README.md | ||
| stamp-h.in | ||
| version.h | ||
FRRouting
FRR is free software that implements and manages various IPv4 and IPv6 routing protocols. It runs on nearly all distributions of Linux and BSD and supports all modern CPU architectures.
FRR currently supports the following protocols:
- BGP
- OSPFv2
- OSPFv3
- RIPv1
- RIPv2
- RIPng
- IS-IS
- PIM-SM/MSDP
- LDP
- BFD
- Babel
- PBR
- OpenFabric
- VRRP
- EIGRP (alpha)
- NHRP (alpha)
Installation & Use
For source tarballs, see the releases page.
For Debian and its derivatives, use the APT repository at https://deb.frrouting.org/.
Instructions on building and installing from source for supported platforms may be found in the developer docs.
Once installed, please refer to the user guide for instructions on use.
Community
The FRRouting email list server is located here and offers the following public lists:
| Topic | List |
|---|---|
| Development | dev@lists.frrouting.org |
| Users & Operators | frog@lists.frrouting.org |
| Announcements | announce@lists.frrouting.org |
For chat, we currently use Slack. You can join by clicking the "Slack" link under the Participate section of our website.
Contributing
FRR maintains developer's documentation which contains the project workflow and expectations for contributors. Some technical documentation on project internals is also available.
We welcome and appreciate all contributions, no matter how small!
Security
To report security issues, please use our security mailing list:
security [at] lists.frrouting.org