![]() MACVLAN devices are typically used for applications such as VRR/VRRP that require a second MAC address (virtual). These devices have a corresponding SVI/VLAN device - root@TORC11:~# ip addr show vlan1002 39: vlan1002@bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9152 qdisc noqueue master vrf1 state UP group default link/ether 00:02:00:00:00:2e brd ff:ff:ff:ff:ff:ff inet6 2001:aa:1::2/64 scope global valid_lft forever preferred_lft forever root@TORC11:~# ip addr show vlan1002-v0 40: vlan1002-v0@vlan1002: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9152 qdisc noqueue master vrf1 state UP group default link/ether 00:00:5e:00:01:01 brd ff:ff:ff:ff:ff:ff inet6 2001:aa:1::a/64 metric 1024 scope global valid_lft forever preferred_lft forever root@TORC11:~# The macvlan device is used primarily for RX (VR-IP/VR-MAC). And TX is via the SVI. To acheive that functionality the macvlan network's metric is set to a higher value. Zebra currently ignores the devaddr metric sent by the kernel and hardcodes it to 0. This commit eliminates that hardcoding. If the devaddr metric is available (METRIC_MAX) it is used for setting up the connected route otherwise we fallback to the dev/interface metric. Setting the macvlan metric to a higher value ensures that zebra will always select the connected route on the SVI (and subsequently use it for next hop resolution etc.) - root@TORC11:~# vtysh -c "show ip route vrf vrf1 2001:aa:1::/64" Routing entry for 2001:aa:1::/64 Known via "connected", distance 0, metric 1024, vrf vrf1 Last update 11:30:56 ago * directly connected, vlan1002-v0 Routing entry for 2001:aa:1::/64 Known via "connected", distance 0, metric 0, vrf vrf1, best Last update 11:30:56 ago * directly connected, vlan1002 root@TORC11:~# Ticket: CM-23511 Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com> |
||
---|---|---|
.github | ||
alpine | ||
babeld | ||
bfdd | ||
bgpd | ||
debianpkg | ||
doc | ||
docker | ||
eigrpd | ||
fpm | ||
gdb | ||
include | ||
isisd | ||
ldpd | ||
lib | ||
m4 | ||
nhrpd | ||
ospf6d | ||
ospfclient | ||
ospfd | ||
pbrd | ||
pimd | ||
pkgsrc | ||
ports | ||
python | ||
qpb | ||
redhat | ||
ripd | ||
ripngd | ||
sharpd | ||
snapcraft | ||
solaris | ||
staticd | ||
tests | ||
tools | ||
vtysh | ||
watchfrr | ||
yang | ||
zebra | ||
.clang-format | ||
.dir-locals.el | ||
.dockerignore | ||
.gitignore | ||
bootstrap.sh | ||
buildtest.sh | ||
config.version.in | ||
configure.ac | ||
COPYING | ||
COPYING-LGPLv2.1 | ||
defaults.h | ||
Makefile.am | ||
README.md | ||
stamp-h.in |
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 as well as Solaris 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
- EIGRP (alpha)
- NHRP (alpha)
Installation & Use
Packages are available for various distributions on our releases page.
Snaps are also available here.
Instructions on building and installing from source for supported platforms may be found here.
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. Please email the mailing list to request an invite as we do not issue automatic invites.
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