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

Tue Feb 6 17:20:08 EST 2018

Hi Vivek,

sorry for delay,

On Sat, Jan 27, 2018 at 7:03 AM, Vivek Venkatraman
<vivek at cumulusnetworks.com> wrote:
> Philippe, when you say leak between default VRF and some other named VRF,
> are you thinking of some direct leaking in zebra?

At the end, my use case is I want to inject a router in a VRF. So yes,
it is direct leaking in zebra.

>Otherwise, won't there
> anyway exist a BGP instance for the named VRF as well as the default VRF?

I only need a BGP core instance ( no BGP VRF instance).
But BGP only receives an ERT, so I need to have local vrf-policies (
with RD and IRT) to find the matching vrf-id.

>
> 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?

on [0], using vpn-policy with single core instance could help. do you
see below configuration example ?
I expect a match between bgpd configuration ( vpn-policy cust1) and
zebra configuration ( vrf cust1).
If I receive a BGP update with redirect to VRF matching ERT=52:100,
 then BGP will understand that the incoming BGP update must be
redirected to VRF cust1.

=== bgpd.conf
router bgp 5226
  bgp router-id 1.1.1.1
  bgp cluster-id 1.1.1.1
  neighbor 2.2.2.2 remote-as 5226
  neighbor 2.2.2.2 update-source 1.1.1.1
  address-family ipv4 unicast
    no neighbor 2.2.2.2 activate
  exit-address-family
  vpn-policy cust1 both
     label 101
     rd 10:1
     rt both 52:100
     !nexthop 192.168.1.1
  exit-vpn-policy
=== zebra.conf
vrf cust1
exit-vrf
interface eth1 vrf cust1
 ip address 3.3.3.3/24
exit
interface eth2
 ip address 3.3.3.3/24
exit

Are we aligned on that configuration use case ?

[0] https://docs.google.com/document/d/1w_ie2tNXCgn0N3ZNFGYTK6lJkwMmk_XN5yz33MMNNqM/edit#

Regards,

Philippe

>
> 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 at 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 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_ie2tNXCgn0N3ZNFGYTK6lJkwMmk_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>
>>>>>
>>>>>
>>>>
>>>>
>>
>>
>> _______________________________________________
>> dev mailing list
>> dev at lists.frrouting.org
>> https://lists.frrouting.org/listinfo/dev
>>
>