Philippe, when you say leak between default VRF and some other named VRF, are you thinking of some direct leaking in zebra? Otherwise, won't there anyway exist a BGP instance for the named VRF as well as the default VRF? We are interested in this use case too, in addition to leaking between named VRFs. While the UI is clearly still under discussion, I thought that in the last meeting, we (the attendees) had converged on performing the route leaking via BGP using RTs. Do you have a concern on this approach? BTW, I am discussing various UI options with my colleagues and I believe Donald will call the next meeting as soon as we've completed that. On Fri, Jan 26, 2018 at 6:53 AM, Philippe Guibert < philippe.guibert@6wind.com> wrote:
Lou, Donald,
I only need to do kind of vrf route leak from default VRF to a named VRF.
From BGP perspective, will it not be possible to avoid configuring BGP VRF instance ? I find vpn-policy or vrf-policy very useful.
Philippe
On Thu, Jan 25, 2018 at 12:17 PM, Lou Berger <lberger@labn.net> wrote:
Hi Philippe,
Based on the discussion, I believe vpn-policy is going to move under the bgp vrf instance config in the final syntax - we're just need to finalize syntax once vivek has his proposal ready.
the bgp vrf instance Is already automatically associated with the zebra/kernel vrf via name matching.
Lou
On January 25, 2018 4:32:23 AM Philippe Guibert < philippe.guibert@6wind.com> wrote:
Hi Lou, Donald,
At first glance, the syntax proposed in [1] looks good. Does that mean that VRF configured under BGP node ( vpn-policy or vrf-policy) will be automatically "connected" to ZEBRA VRF ? Maybe an explicit additional command would make that relationship possible?
Le 23 janv. 2018 7:40 PM, "Lou Berger" <lberger@labn.net> a écrit :
Hi
On 1/23/2018 12:09 PM, Philippe Guibert wrote:
Hi Donald, Lou,
I could not attend the meeting. Are there any notes, or presentation that could explain what will be the strategy with BGP ?
We're headed towards supporting VRF-lite route leaking and L3VPN over MPLS, with both using common RT and BGP VPN constructs. Donald taking the lead on the zebra additions and Paul Z doing the bgp code changes. Vivek is also looking at cli and will propose a revised syntax. The syntax Paul is currently looking towards can be found at the top of [1], but again this is not finalized.
[1] https://docs.google.com/document/d/1w_ie2tNXCgn0N3ZNFGYTK6lJ kwMmk_XN5yz33MMNNqM/edit#
On a separate work, I came to face the issue where I need to redirect
flow to a specific VRF, based on route target input. I was wondering if that work was crossing or not.
I suspect yes. How is the flow encapsulated over the core?
I am in progress of having FlowSpec Client into FRR. More information Flowspec basically applies some kind of policy ( some rules describe which traffic, and what to do with) based on BGP Flowspec infomation.
My setup is not finalised yet, I have the main traffic that is not encapsulated. For security reasons, BGP receives a BGP Flowspec message, including an extended community that asks to redirect that traffic to a VRF.
I expect that BGP identifies the ZEBRA VRF, based on the incoming extended community ( made with Route Target). I also expect that the RD and RT concepts do not cross BGP/ZEBRA borderline. I expect that the matchine VRF_ID will be contained in the ZAPI message.
Philippe
Lou
Thanks,
Philippe
On Tue, Jan 16, 2018 at 4:08 PM, Donald Sharp < sharpd@cumulusnetworks.com <mailto:sharpd@cumulusnetworks.com>> wrote:
All -
During discussions this morning w/ Lou we discovered that we are both working towards a BGP solution for Route Leaking. We have enough differences between our approaches that we need to spend some time consolidating our approach. The current plan is to have the meeting at 3:30 EDT this Friday Jan 19. If you would like to attend please let me know and I will put you on the invite for it.
donald
_______________________________________________ dev mailing list dev@lists.frrouting.org <mailto:dev@lists.frrouting.org> https://lists.frrouting.org/listinfo/dev <https://lists.frrouting.org/listinfo/dev>
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev