<div dir="ltr">Hi Philippe,<div><br></div><div>No, I don't quite get this. </div><div><br></div><div>For route leaking between two different VRFs on the local system (one of which could be the default), the proposal put forward by Daniel, Donald and I was that it would be based on route-targets (and import/export route-maps for additional control, when they are added). This means the routes go through BGP to get from one VRF to another - which in turn means BGP needs the corresponding VRF instances. The primary reasons were the ability to preserve and check on BGP path attributes (if the route source is BGP, which we expect to be common), provide control through RTs and import/export route-maps which are well understood and to have a mechanism that is also aligned for BGP-MPLS L3VPNs. My understanding is that Lou and Paul Z. were comfortable and in agreement on this approach.</div><div><br></div><div>Coming to L3VPNs, the flow for handling a received VPN-IPv4 route would be as follows:</div><div><br></div><div>VPN-IPv4 route -> L3VPN (1/128) routing table in default BGP VRF -> import into 1 or more BGP VRFs into the IPv4-unicast (1/1) routing table based on RTs -> install into corresponding zebra VRF routing table</div><div><br></div><div>Route reflection would happen from the L3VPN table in default BGP VRF; advertisement to CE neighbors in the VRF would happen from the BGP VRF (IPv4-unicast routing table).</div><div>bgp_process_main() -> bgp_zebra_announce() flow would be pretty much unchanged and would run in each VRF where route is imported</div><div><br></div><div>The flow for advertising a VRF route as VPN-IPv4 to PE neighbors would be as follows:</div><div><br></div><div>BGP VRFs's IPv4-unicast (1/1) routing table -> export to L3VPN (1/128) routing table in default VRF based on export RT configuration -> advertise as VPN-IPv4 route</div><div><br></div><div><br></div><div>This is what we put forth and it is well aligned with how the route-leaking flow is.</div><div><br></div><div>The above does not mean the CLI has to be only a particular way. That is still a TBD. However, it does mean that VRF route leaking goes through BGP VRFs and if L3VPN routes need to be installed in a VRF forwarding table - kernel, FPM, remote-forwarder or whatever - they also go through BGP VRFs and then ZAPI to the next component (zebra, usually).</div><div><br></div><div>Leaving aside the CLI, you are saying that you have use cases which won't fit into the flow described here?</div><div><br></div><div>Thanks,</div><div>Vivek</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 6, 2018 at 2:20 PM, Philippe Guibert <span dir="ltr"><<a href="mailto:philippe.guibert@6wind.com" target="_blank">philippe.guibert@6wind.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Vivek,<br>
<br>
sorry for delay,<br>
<br>
On Sat, Jan 27, 2018 at 7:03 AM, Vivek Venkatraman<br>
<<a href="mailto:vivek@cumulusnetworks.com">vivek@cumulusnetworks.com</a>> wrote:<br>
> Philippe, when you say leak between default VRF and some other named VRF,<br>
> are you thinking of some direct leaking in zebra?<br>
<br>
At the end, my use case is I want to inject a router in a VRF. So yes,<br>
it is direct leaking in zebra.<br>
<br>
>Otherwise, won't there<br>
> anyway exist a BGP instance for the named VRF as well as the default VRF?<br>
<br>
I only need a BGP core instance ( no BGP VRF instance).<br>
But BGP only receives an ERT, so I need to have local vrf-policies (<br>
with RD and IRT) to find the matching vrf-id.<br>
<br>
><br>
> We are interested in this use case too, in addition to leaking between named<br>
> VRFs. While the UI is clearly still under discussion, I thought that in the<br>
> last meeting, we (the attendees) had converged on performing the route<br>
> leaking via BGP using RTs. Do you have a concern on this approach?<br>
<br>
on [0], using vpn-policy with single core instance could help. do you<br>
see below configuration example ?<br>
I expect a match between bgpd configuration ( vpn-policy cust1) and<br>
zebra configuration ( vrf cust1).<br>
If I receive a BGP update with redirect to VRF matching ERT=52:100,<br>
then BGP will understand that the incoming BGP update must be<br>
redirected to VRF cust1.<br>
<br>
<br>
=== bgpd.conf<br>
router bgp 5226<br>
bgp router-id 1.1.1.1<br>
bgp cluster-id 1.1.1.1<br>
neighbor 2.2.2.2 remote-as 5226<br>
neighbor 2.2.2.2 update-source 1.1.1.1<br>
address-family ipv4 unicast<br>
no neighbor 2.2.2.2 activate<br>
exit-address-family<br>
vpn-policy cust1 both<br>
label 101<br>
rd 10:1<br>
rt both 52:100<br>
!nexthop 192.168.1.1<br>
exit-vpn-policy<br>
=== zebra.conf<br>
vrf cust1<br>
exit-vrf<br>
interface eth1 vrf cust1<br>
ip address <a href="http://3.3.3.3/24" rel="noreferrer" target="_blank">3.3.3.3/24</a><br>
exit<br>
interface eth2<br>
ip address <a href="http://3.3.3.3/24" rel="noreferrer" target="_blank">3.3.3.3/24</a><br>
exit<br>
<br>
Are we aligned on that configuration use case ?<br>
<br>
<br>
[0] <a href="https://docs.google.com/document/d/1w_ie2tNXCgn0N3ZNFGYTK6lJkwMmk_XN5yz33MMNNqM/edit#" rel="noreferrer" target="_blank">https://docs.google.com/<wbr>document/d/1w_<wbr>ie2tNXCgn0N3ZNFGYTK6lJkwMmk_<wbr>XN5yz33MMNNqM/edit#</a><br>
<br>
Regards,<br>
<br>
Philippe<br>
<br>
><br>
> BTW, I am discussing various UI options with my colleagues and I believe<br>
> Donald will call the next meeting as soon as we've completed that.<br>
><br>
> On Fri, Jan 26, 2018 at 6:53 AM, Philippe Guibert<br>
> <<a href="mailto:philippe.guibert@6wind.com">philippe.guibert@6wind.com</a>> wrote:<br>
>><br>
>> Lou, Donald,<br>
>><br>
>> I only need to do kind of vrf route leak from default VRF to a named VRF.<br>
>><br>
>> From BGP perspective, will it not be possible to avoid configuring BGP VRF<br>
>> instance ?<br>
>> I find vpn-policy or vrf-policy very useful.<br>
>><br>
>> Philippe<br>
>><br>
>><br>
>> On Thu, Jan 25, 2018 at 12:17 PM, Lou Berger <<a href="mailto:lberger@labn.net">lberger@labn.net</a>> wrote:<br>
>>><br>
>>> Hi Philippe,<br>
>>><br>
>>> Based on the discussion, I believe vpn-policy is going to move under the<br>
>>> bgp vrf instance config in the final syntax - we're just need to finalize<br>
>>> syntax once vivek has his proposal ready.<br>
>>><br>
>>> the bgp vrf instance Is already automatically associated with the<br>
>>> zebra/kernel vrf via name matching.<br>
>>><br>
>>> Lou<br>
>>><br>
>>> On January 25, 2018 4:32:23 AM Philippe Guibert<br>
>>> <<a href="mailto:philippe.guibert@6wind.com">philippe.guibert@6wind.com</a>> wrote:<br>
>>>><br>
>>>> Hi Lou, Donald,<br>
>>>><br>
>>>> At first glance, the syntax proposed in [1] looks good.<br>
>>>> Does that mean that VRF configured under BGP node ( vpn-policy or<br>
>>>> vrf-policy) will be automatically "connected" to ZEBRA VRF ?<br>
>>>> Maybe an explicit additional command would make that relationship<br>
>>>> possible?<br>
>>>><br>
>>>><br>
>>>> Le 23 janv. 2018 7:40 PM, "Lou Berger" <<a href="mailto:lberger@labn.net">lberger@labn.net</a>> a écrit :<br>
>>>><br>
>>>> Hi<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On 1/23/2018 12:09 PM, Philippe Guibert wrote:<br>
>>>>><br>
>>>>> Hi Donald, Lou,<br>
>>>>><br>
>>>>> I could not attend the meeting.<br>
>>>>> Are there any notes, or presentation that could explain what will be<br>
>>>>> the strategy with BGP ?<br>
>>>>><br>
>>>> We're headed towards supporting VRF-lite route leaking and L3VPN over<br>
>>>> MPLS, with both using common RT and BGP VPN constructs. Donald taking the<br>
>>>> lead on the zebra additions and Paul Z doing the bgp code changes. Vivek is<br>
>>>> also looking at cli and will propose a revised syntax. The syntax Paul is<br>
>>>> currently looking towards can be found at the top of [1], but again this is<br>
>>>> not finalized.<br>
>>>><br>
>>>> [1]<br>
>>>> <a href="https://docs.google.com/document/d/1w_ie2tNXCgn0N3ZNFGYTK6lJkwMmk_XN5yz33MMNNqM/edit#" rel="noreferrer" target="_blank">https://docs.google.com/<wbr>document/d/1w_<wbr>ie2tNXCgn0N3ZNFGYTK6lJkwMmk_<wbr>XN5yz33MMNNqM/edit#</a><br>
>>>><br>
>>>><br>
>>>>> On a separate work, I came to face the issue where I need to redirect<br>
>>>>> flow to a specific VRF, based on route target input.<br>
>>>>> I was wondering if that work was crossing or not.<br>
>>>>><br>
>>>> I suspect yes. How is the flow encapsulated over the core?<br>
>>>><br>
>>>><br>
>>>> I am in progress of having FlowSpec Client into FRR. More information<br>
>>>> Flowspec basically applies some kind of policy ( some rules describe<br>
>>>> which traffic, and what to do with) based on BGP Flowspec infomation.<br>
>>>><br>
>>>> My setup is not finalised yet, I have the main traffic that is not<br>
>>>> encapsulated.<br>
>>>> For security reasons, BGP receives a BGP Flowspec message, including an<br>
>>>> extended community that asks to redirect that traffic to a VRF.<br>
>>>><br>
>>>> I expect that BGP identifies the ZEBRA VRF, based on the incoming<br>
>>>> extended community ( made with Route Target).<br>
>>>> I also expect that the RD and RT concepts do not cross BGP/ZEBRA<br>
>>>> borderline. I expect that the matchine VRF_ID will be contained in the ZAPI<br>
>>>> message.<br>
>>>><br>
>>>> Philippe<br>
>>>><br>
>>>><br>
>>>> Lou<br>
>>>><br>
>>>>> Thanks,<br>
>>>>><br>
>>>>> Philippe<br>
>>>>><br>
>>>>><br>
>>>>> On Tue, Jan 16, 2018 at 4:08 PM, Donald Sharp<br>
>>>>> <<a href="mailto:sharpd@cumulusnetworks.com">sharpd@cumulusnetworks.com</a> <mailto:<a href="mailto:sharpd@cumulusnetworks.com">sharpd@<wbr>cumulusnetworks.com</a>>> wrote:<br>
>>>>><br>
>>>>> All -<br>
>>>>><br>
>>>>> During discussions this morning w/ Lou we discovered that we are<br>
>>>>> both<br>
>>>>> working towards a BGP solution for Route Leaking. We have enough<br>
>>>>> differences between our approaches that we need to spend some time<br>
>>>>> consolidating our approach. The current plan is to have the<br>
>>>>> meeting<br>
>>>>> at 3:30 EDT this Friday Jan 19. If you would like to attend please<br>
>>>>> let me know and I will put you on the invite for it.<br>
>>>>><br>
>>>>> donald<br>
>>>>><br>
>>>>> ______________________________<wbr>_________________<br>
>>>>> dev mailing list<br>
>>>>> <a href="mailto:dev@lists.frrouting.org">dev@lists.frrouting.org</a> <mailto:<a href="mailto:dev@lists.frrouting.org">dev@lists.frrouting.<wbr>org</a>><br>
>>>>> <a href="https://lists.frrouting.org/listinfo/dev" rel="noreferrer" target="_blank">https://lists.frrouting.org/<wbr>listinfo/dev</a><br>
>>>>> <<a href="https://lists.frrouting.org/listinfo/dev" rel="noreferrer" target="_blank">https://lists.frrouting.org/<wbr>listinfo/dev</a>><br>
>>>>><br>
>>>>><br>
>>>><br>
>>>><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> dev mailing list<br>
>> <a href="mailto:dev@lists.frrouting.org">dev@lists.frrouting.org</a><br>
>> <a href="https://lists.frrouting.org/listinfo/dev" rel="noreferrer" target="_blank">https://lists.frrouting.org/<wbr>listinfo/dev</a><br>
>><br>
><br>
</blockquote></div><br></div>