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

Vivek Venkatraman vivek at cumulusnetworks.com
Mon Feb 12 09:42:36 EST 2018


Hi Philippe,

Thank you for this information, it made it much easier to understand your
use case.

Given that Flowspec identifies the VRF into which traffic should be
redirected using the VRF's route target and this is a BGP attribute, I do
not see a contradiction in having BGP VRFs configured with their route
targets defined. These need not have any neighbors or address-families
activated. The VRF structure is created anyway when the VRF is configured
in the system (the VRF has to be present on the system for the flow rule to
be valid) and the BGP VRF configuration is just a container for holding its
RTs.

Of course, this is just my opinion, but I also have the reason below.

Based on my understanding, rules exchanged in the global instance (AFI=1,
SAFI=133) will only apply to the global instance i.e., if your action is
redirect, you are redirecting from lookup in the default routing table to a
lookup in a specific VRF's routing table. If you want to extend Flowspec to
work in a L3VPN environment (AFI=1, SAFI=134), you'd anyway need the BGP
VRF definitions. The Flowspec NLRI would get imported into specific VRFs
based on RTs and then installed as rules applicable to that VRF.

So, we may anyway end up needing the BGP VRF definitions when we get to
that.

Think over it. I'll also do likewise and ask my colleagues also to do the
same.

Vivek

On Fri, Feb 9, 2018 at 11:59 PM, Philippe Guibert <
philippe.guibert at 6wind.com> wrote:

> Hi Vivek,
>
> My use case is simpler. I know the VPN import processing to import
> from 1/128 to 1/1.
> What I would need, eventually, is 1-1 => 1/128.
> But is it possible to use that without enabling vpnv4 capability with
> other BGP speakers ?
> My setup does not use VPNv4 capability. I would prefer not use VPNv4,
> despite the advantages of keeping the attributes, etc...
> That is why, when you were talking about Zebra, I was thinking we
> would be aligned.
> However, I will look deeper if it is possible
>
> Here is the reason why I need to perform such setup:
>
> As part of a new ticket that I will create, I want to implement
> flowspec RFC5575, client part.
> And I want to implement the redirect capability. Here is an extract.
>
>    Redirect:  The redirect extended community allows the traffic to be
>       redirected to a VRF routing instance that lists the specified
>       route-target in its import policy.  If several local instances
>       match this criteria, the choice between them is a local matter
>       (for example, the instance with the lowest Route Distinguisher
>       value can be elected).  This extended community uses the same
>       encoding as the Route Target extended community [RFC4360].
>
> My main BGP core instance does not perform VPNv4 capability. It
> handles IPv4 unicast and Flowspec. That is all.
> Do you have any suggestions to make me, on how to handle this.
> I already described the setup in my previous mail. So you should be
> able to make me a suggestion that fits our common needs.
>
> Thanks,
>
> Regards,
>
> Philippe
>
> On Sat, Feb 10, 2018 at 6:23 AM, Vivek Venkatraman
> <vivek at cumulusnetworks.com> wrote:
> >
> > On Fri, Feb 9, 2018 at 8:03 AM, Lou Berger <lberger at labn.net> wrote:
> >>
> >> Hi Guys,
> >>
> >>
> >> On 02/09/2018 02:34 AM, Vivek Venkatraman wrote:
> >> > Hi Philippe,
> >> >
> >> > No, I don't quite get this.
> >> >
> >> > 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.
> >>
> >> Yes, this was out plan independently, the only place we didn't fully
> >> agree (at the start) was on config syntax.  Paul has the core code
> >> almost ready to submit as a PR, hopefully today.
> >>
> >> >
> >> > Coming to L3VPNs, the flow for handling a received VPN-IPv4 route
> would
> >> > be as follows:
> >> >
> >> > 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
> >> >
> >> > 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).
> >> > bgp_process_main() -> bgp_zebra_announce() flow would be pretty much
> >> > unchanged and would run in each VRF where route is imported
> >>
> >>
> >> agreed.  Paul may have some additional work on the zebra export part,
> >> but the BGP core code will be in his PR.
> >>
> >> >
> >> > The flow for advertising a VRF route as VPN-IPv4 to PE neighbors would
> >> > be as follows:
> >> >
> >> > 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
> >> >
> >> >
> >> > This is what we put forth and it is well aligned with how the
> >> > route-leaking flow is.
> >> >
> >>
> >> This is also inline with our discussion (and one of the two options in
> >> our original discussion) -- so all good here
> >>
> >>
> >> > 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).
> >>
> >>
> >> Agreed.
> >> >
> >> > Leaving aside the CLI, you are saying that you have use cases which
> >> > won't fit into the flow described here?
> >>
> >> The one additional case that we think is important is the ability to go
> >> from/to VPN SAFI to/from the default zebra instance/VRF.  This was
> >> actually covered in the existing/current code but not testing in a long
> >> time.  Paul also has it on his plate to ensure this works...
> >>
> >
> > Yes, just like leaking routes between the default VRF and another named
> VRF,
> > I can see the case for going between VPN SAFI and the default VRF. So,
> I'm
> > in support of this capability.
> >
> > Philippe, if this is the use case you were referring to, then I
> comprehend
> > and the about the only thing needed would be for you to review the
> > code/control flow described here and come back if there is a concern. If
> you
> > are referring to some other use case, can you first see if the flow
> > described here will also cater to it? If not, please inform again what
> the
> > scenario is. Thanks!
> >
> >
> >> Lou
> >> >
> >> > Thanks,
> >> > Vivek
> >> >
> >> > On Tue, Feb 6, 2018 at 2:20 PM, Philippe Guibert
> >> > <philippe.guibert at 6wind.com <mailto:philippe.guibert at 6wind.com>>
> wrote:
> >> >
> >> >     Hi Vivek,
> >> >
> >> >     sorry for delay,
> >> >
> >> >     On Sat, Jan 27, 2018 at 7:03 AM, Vivek Venkatraman
> >> >     <vivek at cumulusnetworks.com <mailto: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 <http://3.3.3.3/24>
> >> >     exit
> >> >     interface eth2
> >> >      ip address 3.3.3.3/24 <http://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#
> >> >
> >> > <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 <mailto: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
> >> >     <mailto: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 <mailto: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 at labn.net
> >> >     <mailto: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#
> >> >
> >> > <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>
> >> >     <mailto: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
> >
> >> >     <mailto:dev at lists.frrouting.org <mailto:dev at lists.frrouting.org>>
> >> >     >>>>>     https://lists.frrouting.org/listinfo/dev
> >> >     <https://lists.frrouting.org/listinfo/dev>
> >> >     >>>>>     <https://lists.frrouting.org/listinfo/dev
> >> >     <https://lists.frrouting.org/listinfo/dev>>
> >> >     >>>>>
> >> >     >>>>>
> >> >     >>>>
> >> >     >>>>
> >> >     >>
> >> >     >>
> >> >     >> _______________________________________________
> >> >     >> 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/20180212/44b100ae/attachment-0001.html>


More information about the dev mailing list