[dev] BGP Route Leaking for VRF-Lite and VPN's

Philippe Guibert philippe.guibert at 6wind.com
Fri Jan 26 09:53:53 EST 2018


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 at 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 at 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 at 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 at cumulusnetworks.com <mailto:sharpd at 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 at lists.frrouting.org <mailto:dev at lists.frrouting.org>
>>>     https://lists.frrouting.org/listinfo/dev
>>>     <https://lists.frrouting.org/listinfo/dev>
>>>
>>>
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20180126/4d9cd543/attachment.html>


More information about the dev mailing list