dd2d28ea99
RFC7611 introduces new extended community ACCEPT_OWN and is already
implemented for FRR in the previous PR. However, this PR broke
compatibility about importing VPN routes.
Let's consider the following situation. There are 2 routers and these
routers connects with iBGP session. These routers have two VRF, vrf10
and vrf20, and RD 0:10, 0:20 is configured as the route distinguisher
of vrf10 and vrf20 respectively.
+- R1 --------+ +- R2 --------+
| +---------+ | | +---------+ |
| | VRF10 | | | | VRF10 | |
| | RD 0:10 +--------+ RD 0:10 | |
| +---------+ | | +---------+ |
| +---------+ | | +---------+ |
| | VRF20 +--------+ VRF20 | |
| | RD 0:20 | | | | RD 0:20 | |
| +---------+ | | +---------+ |
+-------------+ +-------------+
In this situation, the VPN routes from R1's VRF10 should be imported to
R2's VRF10 and the VPN routes from R2's VRF10 should be imported to R2's
VRF20. However, the current implementation of ACCEPT_OWN will always
reject routes if the RD of VPN routes are matched with the RD of VRF.
Similar issues will happen in local VRF2VRF route leaks. In such cases,
the route reaked from VRF10 should be imported to VRF20. However, the
current implementation of ACCEPT_OWN will not permit them.
+- R1 ---------------------+
| +------------+ |
| +----v----+ +----v----+ |
| | VRF10 | | VRF20 | |
| | RD 0:10 | | RD 0:10 | |
| +---------+ +---------+ |
+--------------------------+
So, this commit add additional condition in RD match. If the route
doesn't have ACCEPT_OWN extended community, source VRF check will be
skipped.
[RFC7611]: https://datatracker.ietf.org/doc/html/rfc7611
Signed-off-by: Ryoga Saito <ryoga.saito@linecorp.com>
|
||
|---|---|---|
| .github | ||
| alpine | ||
| babeld | ||
| bfdd | ||
| bgpd | ||
| debian | ||
| doc | ||
| docker | ||
| eigrpd | ||
| fpm | ||
| gdb | ||
| grpc | ||
| include | ||
| isisd | ||
| ldpd | ||
| lib | ||
| m4 | ||
| 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 | ||
| .dir-locals.el | ||
| .dockerignore | ||
| .git-blame-ignore-revs | ||
| .gitignore | ||
| .pylintrc | ||
| .travis.yml | ||
| bootstrap.sh | ||
| buildtest.sh | ||
| config.version.in | ||
| configure.ac | ||
| COPYING | ||
| COPYING-LGPLv2.1 | ||
| 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