You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With #12364, route leaking between VNIs in an EVPN-VXLAN setup becomes much more flexible.
For example, to allow one L3 VNI 20 to reach another L3 VNI 10, you can simply configure a route reflector to add a route target for VNI 20 on all routes with a route target for VNI 10.
Overall this works fine - see the FRR configuration below.
However, it a host has a VRF for both VNI 20 and VNI 10, then the local routes to VNI 10 will not be leaked to VNI 20 on that host. The reason is that when the host receives an updated route from the route reflector, it will just discard it since the host created that route originally.
FRR does support accept-own, but as far as I can see only for the ipv4 vpn address family. So it would be great if accept-own was also supported for the l2vpn evpn address family to allow the described use case.
I understand that the route leak could be configured locally on the host. However, it would be nice if only the route reflector had to be touched when route leaking changes.
To illustrate the example, here is an FRR configuration of the route reflector:
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
With #12364, route leaking between VNIs in an EVPN-VXLAN setup becomes much more flexible.
For example, to allow one L3 VNI 20 to reach another L3 VNI 10, you can simply configure a route reflector to add a route target for VNI 20 on all routes with a route target for VNI 10.
Overall this works fine - see the FRR configuration below.
However, it a host has a VRF for both VNI 20 and VNI 10, then the local routes to VNI 10 will not be leaked to VNI 20 on that host. The reason is that when the host receives an updated route from the route reflector, it will just discard it since the host created that route originally.
I believe the way to fix this is to use the accept-own mechanism described in https://datatracker.ietf.org/doc/rfc7611/
FRR does support accept-own, but as far as I can see only for the ipv4 vpn address family. So it would be great if accept-own was also supported for the l2vpn evpn address family to allow the described use case.
I understand that the route leak could be configured locally on the host. However, it would be nice if only the route reflector had to be touched when route leaking changes.
To illustrate the example, here is an FRR configuration of the route reflector:
And here is a configuration of a host:
Beta Was this translation helpful? Give feedback.
All reactions