[frr] [PATCH 01/11] bgpd: BGP VRF processing handling

[Lou Berger]

Philippe


On February 6, 2017 4:46:14 AM Philippe Guibert 
<philippe.guibert at 6wind.com> wrote:

> Hello Lou, all,
>
> On Fri, Feb 3, 2017 at 12:16 PM, Lou Berger <lberger at labn.net> wrote:
>>>>> a)
>>>>> global config# add [vrf <vrf-name>] prefix <prefix> [rd <value>]
>>>>> [label <value>] [pref (0-255)]
>>>>> b)
>>>>> vpnv4 af # network 77.11.44.0/24 rd 65:1 tag 55
>>>>
>>>> I had forgotten that this command even existed -- it is ancient and IMO
>>>> a historic appendage - deleting or moving to debug is a good idea.
>>>
>>>
>>> I can handle it, I just need to understand the following.
>>>
>>
>> Thanks!
>
> I mean, I need to be able to configure prefixes before suppressing the
> command :-).
>
>
>
>>> If I am referring to RD/RT document, I can see that route-map keyword
>>> has been removed.
>>> I have some remarks:
>>> o still possible to enter following commands. keeping all commands
>>> would suit me:
>>>   a)  rd <value> [prefix <prefix>|prefixlist <prefixlist>]
>>>   b)  label <value> [prefix <prefix>|prefixlist <prefixlist>]
>>>   c) prefix <prefix> [label <value>] [rd <value>]
>>> o route-map seems to have been suppressed, but I think it would be ok
>>> to integrate it with route-map.
>>> o I would propose a 4th command under vrf-policy. Would that be acceptable
>>> ?
>>>   c) prefix <prefix> [label <value>] [rd <value>] [nexthop <value>]
>>> o about next-hop self | A.B.C.D | A::B::C, I am pro keeping this command
>>> o is there a command that permits to consider the newly prefix as a
>>> vpnv4 entry or an encap entry ( or an evpn entry )?
>>>
>>
>> As I understood the group consensus on the call, specific routes would be
>> learned/configured in the context of a vrf (under bgp <as> vrf <vrf>) and
>> specific  RDs and the typical attributes could be set using typical route
>> map operations. -- here's the related portion for the Google doc:
>>
>
>
>> router bgp XXX vrf <vrf-name>
>>    ! (address-family ipv4)
>>    network  1.2.3.0/24 route-map foo
>>    neighbor ... ! CE session (or alternately, VRF-lite session)
>>    !make vrf redistribution (import/export)the default
>>    redistribute static|ospf|vrf [route map] ...! CE setup for OSPF
>>    no redistribute vrf
>>    no export vrf
>>    export vrf [route map] ...
>
> This solution fits with one BGP instance per VRF.
> I agree for that.
>
> But the solution is not enough.
> It does not fit with one BGP instance for multiple VRF handling.
>
> Is there any group consensus about supporting the following:
> specific routes to be added in the context of a VRF-policy by using
> following configuration method:
>
> router bgp <ID>
>  vrf-policy <vrf-policy-name>
>    rd <>
>    label <>
>    rt import <>
>    rt export <>
>   prefix <prefix> [label <value>] [nexthop <value>]
> exit-vrf-policy
>

This should be discussed on a future call IMO.

> Adding to the review, I would also expect a command that mentions the
> signalisation transport method ?
> If I set a prefix, how can I force the prefix to be advertised by
> VPNvx or EVPN ?
> In the EVPN Route type 5 method, the same
>
> config term
> router bgp ....
>  vrf-policy <vrf-name>
>     transport vpn | evpn | encap
>

Vpn and encap are not orthognol.  The code currently supports vpn and 
vpn+encap and more commands are needed for the encap case.

>
>>>>> moved under debug rfapi-dev node ?
>>>>
>>>>
>>>> This predates the rfapi code removing it or making a debug is a good
>>>> idea.  Do you want to do it or should I?
>>>
>
> See https://github.com/freerangerouting/frr/pull/168
>

Umm I thought we were talking making network  rd and tag a debug command - 
not vnc commands.

>
>>
>>>>>>   - Notification of adds/withdrawals (both models)
>>>
>> I did find on issue related to mpls call backs in reviewing / retesting the
>> code and this has been pushed.  Other tunnel types should have worked.
>>
> I will check. Thanks.
>
>>>>>> o Support for load sharing, dynamic moves, redundant NVAs & NVEs
>>>>>
>>>>> I could then test ECMP with VNC.
>>>>> Whatever the selection criterium on global RIB ( multipath enabled or
>>>>> not), the entry is present in vnc registration list.
>>>>> show vnc registration
>>>>>
>>>>> [Remote] Prefix RT={64603:1111} VRF "64603:1111"
>>>>> Prefix               VN Address      UN Address      Cost Lifetime
>>>>> 11.11.0.0/16         Label: 125                      155  infinite
>>>>> 11.11.0.0/16         Label: 125                      155  infinite
>>>>>
>
>> The rfapi does order the prefixes on query call back based on preference,
>
> By using preference on BGP, the entries will not be considered as ECMP.
>

Unless I miss read something these had identical preferences...  the show 
bgp vrf command is probably what you should be looking at here.

>> but it up to the call back code to decide if only the best route is used.
>> This was explicitly done to support multi/and backup path forwarding.
>
> 1) If I understand correctly, if it is up to the call back code, then
> I understand following scenario should be implemented:
>
> On my case, the call back should instantiate a VRF RIB table.

Why?  Certainly there needs to be a fib somewhere - but I'd expect it to be 
on the other end of your rfp.

Also when routes are redistributed into a vrf there will be another rib 
within that bgp instance.

> When ECMP entries are detected, an algorithm in the callback should be
> triggered to know which ECMP entry is valid.

Umm. I'm not following you here.

> If there is a preference set that is greater in one of the ECMP
> entries, then it will be selected.


> If there is no preference difference, the difference will be based on
> the underlay nexthop attribute.
>
> Reversely,  if a route is withdrawn, notitication call back would be
> called. an algorithm in the callback should be triggered too to know
> if there are still ECMP entries or not.

Rfapi can be configured in a bunch of different ways.  See rfapi.h and 
ensure you're using the options that best match your use case.

> If the entry with the best preference disappears, then the entry with
> the least preference would be selected.
>

There are probably multiple ways to make it work - there are intentionally 
multiple ways to use rfapi to support the different types of rf protocols 
out there.

>
> 2) I would prefer having an internal implementation of BGP best
> selection algorithm, and configure then notifications so as to inform
> only the selected entries.
> It would avoid having a second VRF RIB instance implemented in a second place.

Sure this isn't hard to add as a new config paramtere/feature.  In the 
interim there are hacky approaches to do this.

> If I have a preference set for one route more than one other route,
> then only the preferred entry would be sent to the notification.
>
Sure I can se why you might want this in the inbox usage scenaro.  We were 
focused on controller scenarios.


> For 2), I would need :
> - a vrt command to configure multipath per vrf-policy
> config term
> router bgp ....
>  vrf-policy <vrf-name>
>     transport vpn | evpn | encap
> - a vty command to change the notification procedure.

I think the rest are likely code level changes - not config.
> config term
> router bgp ....
>  ## callbacks would be advertised
>  ## new entries that are set as selected ( ECMP or best prefrence for example)
>  ## removed entries that are set as unselected ( entries that are no
> more unselected because of a new selected entry with best preference)
>  vnc notification only-selected


Perhaps as an option...
>  ## show vnc registration would show only the selected one
>   vnc display only-selected
>

Lou

> Waiting for suggestions,
>
>
>
>
>>
>> Again the output you were expecting is here:
>>
>>> Here is the output
>>>
>>> bgpd# show bgp ipv4 vpn
>>> BGP table version is 0, local router ID is 10.125.0.1
>>> Status codes: s suppressed, d damped, h history, * valid, > best, i -
>>> internal
>>> Origin codes: i - IGP, e - EGP, ? - incomplete
>>>    Network          Next Hop            Metric LocPrf Weight Path
>>> Route Distinguisher: 64603:1111
>>> *=i11.11.0.0/16     10.10.10.1         0    100      0 i
>>>      EC{64603:1111} label=125 type=bgp, subtype=0
>>> *>i11.11.0.0/16     40.40.10.1         0    100      0 i
>>>      EC{64603:1111} label=125 type=bgp, subtype=0
>>> *>i22.22.0.0/16     20.20.10.1         0    100      0 i
>>>      EC{64603:1111} label=125 type=bgp, subtype=0
>>> *>i33.33.0.0/16     30.30.10.1         0    100      0 i
>>>      EC{64603:1111} label=125 type=bgp, subtype=0
>>> Displayed 4 routes and 5 total paths
>>>
>>>>
>>>>> Does that mean that all entries are taken into account without any
>>>>>
>>>> This like got cut off.
>>>
>>>
>>> Does that mean that all entries are taken into account without any
>>> best selection algorithm within the VRF ?
>>>
>>
>> No they are ordered and available for downstream processing / selection by
>> the rfp code.
>>
>
> Best Regards,
>
> Philippe
>