Hi,
I’m doing some testing of an environment using EVPN pure type 5 routes in a VRF, with EVPN-VXLAN, on MX and QFX5120.
I am trying to do some “asymmetric" import+export - to do like we did in L3VPN and build a “hub and spoke” VPN.
Specific use case is a common “services” VRF, which has direct access to various other VRFs - but of course I do not want to give the other VRFs access to one another. I have a few other use cases for this type of topology as well - but focusing on this, for now.
I am finding that EVPN type 5 routes which are imported (with vrf-import) are then exported (with vrf-export). This is different to MPLS L3VPN, where it will never export an L3VPN route that you have imported from another VRF.
I don’t seem to be able to fix this in policy, as I can’t figure what I can match on to reject these (or the inverse).
I suspect I could make this work with some very annoying verbose policy, which would have to know all the prefixes etc. - but that’s obviously not really ideal.
Is there a knob to control this re-export behaviour - or - has anyone got examples of how to get a “hub and spoke” type VPN together with EVPN pure type 5?
For another use case I am trying to set communities based on whether the route is a direct route or not.
I note that in vrf-export policy, all routes appear to be “protocol evpn” - even direct routes.
I believe evpn ip-prefix-routes export policy can see the “real” protocol (direct, etc.) - but setting communities here doesn’t seem to get through. I had a play with route-attributes community export-action allow, but it doesn’t appear to have any effect, and the documentation on the plethora of these knobs is.. limited. These knobs appear to be more for copying attributes from type 2 to type 5 routes, but, that’s not what I’m doing here - these are pure type 5 routes.
Does anyone know how to set communities in EVPN type 5 routes, where we have knowledge of the route’s original protocol?
--
Nathan Ward
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
I’m doing some testing of an environment using EVPN pure type 5 routes in a VRF, with EVPN-VXLAN, on MX and QFX5120.
I am trying to do some “asymmetric" import+export - to do like we did in L3VPN and build a “hub and spoke” VPN.
Specific use case is a common “services” VRF, which has direct access to various other VRFs - but of course I do not want to give the other VRFs access to one another. I have a few other use cases for this type of topology as well - but focusing on this, for now.
I am finding that EVPN type 5 routes which are imported (with vrf-import) are then exported (with vrf-export). This is different to MPLS L3VPN, where it will never export an L3VPN route that you have imported from another VRF.
I don’t seem to be able to fix this in policy, as I can’t figure what I can match on to reject these (or the inverse).
I suspect I could make this work with some very annoying verbose policy, which would have to know all the prefixes etc. - but that’s obviously not really ideal.
Is there a knob to control this re-export behaviour - or - has anyone got examples of how to get a “hub and spoke” type VPN together with EVPN pure type 5?
For another use case I am trying to set communities based on whether the route is a direct route or not.
I note that in vrf-export policy, all routes appear to be “protocol evpn” - even direct routes.
I believe evpn ip-prefix-routes export policy can see the “real” protocol (direct, etc.) - but setting communities here doesn’t seem to get through. I had a play with route-attributes community export-action allow, but it doesn’t appear to have any effect, and the documentation on the plethora of these knobs is.. limited. These knobs appear to be more for copying attributes from type 2 to type 5 routes, but, that’s not what I’m doing here - these are pure type 5 routes.
Does anyone know how to set communities in EVPN type 5 routes, where we have knowledge of the route’s original protocol?
--
Nathan Ward
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp