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

Lou Berger lberger at labn.net
Fri Feb 3 06:19:28 EST 2017


Philippe,

Please see the mail I just sent.  It also sounds like you enough questions 
on the rd/RT config discussed that we should revisit it on a future call.

Lou


On February 3, 2017 3:34:08 AM Philippe Guibert 
<philippe.guibert at 6wind.com> wrote:

> Hello Lou, all,
>
> coming back to you, I need some answers, please.
>
> a) about the "network" configuration command per vrf-policy
> Because network command under address-family would be replaced by an
> other command under vrf-policy.
>
> - I did not see all options on RD/RT document I would expect.
> IMHO, prefix parameter is not an option, and it should be possible to
> provision a whole set of prefixes per vrf-policy.
>
> configuration example:
>
> config term
> router bgp ....
>  vrf-policy <vrf-name>
>     rd <value> [prefix <prefix>|prefixlist <prefixlist>]
>     label <value> [prefix <prefix>|prefixlist <prefixlist>]
>     route-target <import|export|both> <value>
>     !use routemap to change
>     nexthop <ip-addr|ipv6-addr|self>
>     prefix <prefix> [label <value>] [rd <value>] [nexthop <value>]
>            <---- command moved from afi/safi node to vrf-policy
>
> - Per extension, 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 ?
>
> I would expect such a command to request the transport method
>
> config term
> router bgp ....
>  vrf-policy <vrf-name>
>     transport vpn | evpn | encap
>
>
> b) about the multipath case.
> From the previous mail example, I observe that show vnc registration
> takes into account all incoming NLRIs.
> How can vrf-policy so as to configure VRF RIB to enable/disable multipath ?
>
> When ECMP NLRIs are encountered, how can the VRF RIB differentiate the
> case that I want to do Load Balancing or not ?
>
> I would expect such a command to influence the multipath case
> config term
> router bgp ....
>  vrf-policy <vrf-name>
>    maximum-path <1-64>                       <--- command added
>
>
> Best Regards,
>
> Philippe
>
> On Tue, Jan 31, 2017 at 4:01 PM, Philippe Guibert
> <philippe.guibert at 6wind.com> wrote:
>> Hello Lou,
>>
>>
>> On Tue, Jan 31, 2017 at 2:23 PM, Lou Berger <lberger at labn.net> wrote:
>>
>>>>> https://docs.google.com/document/d/1w_ie2tNXCgn0N3ZNFGYTK6lJkwMmk_XN5yz33MMNNqM/
>>>>> are now available via https://github.com/freerangerouting/frr/pulls
>>>> I attended lately at the meeting of 17th of january.
>>>> I had a question about following vty commands:
>>>>
>>>> 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.
>>
>>> in the Jan 17 the form that was agreed to for such was to use route maps
>>> to set RD and to add under vrf-policy
>>> *
>>>
>>>     label <value> [prefix <prefix>|prefixlist <prefixlist>]
>>>
>>> **
>>>
>>> *and we don't have support for this yet.*
>>>
>>> *
>>>
>> Could you give more information, please.
>>
>> 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 )?
>>
>>>> When I run a), I was expecting to have the prefix imported in the
>>
>> My mistake, it was network b) : 77.11.44.0/24 rd 65:1 tag 55
>>
>>>> rf_import_table 65:1.
>>>> Maybe there is a configuration issue, or the behaviour is not what I expect ?
>>> keep in mind RTs determine table while RDs control route
>>> selection/distribution.
>>> The RTs on the add command are determined by the vrf-policy of the
>>> <vrf-name>.  When no vrf is specified the add is to the default
>>> instance's unicast table.  This is really something outside of vrf
>>> support and not something we have (or are planning) to implement.
>>>
>> my config is the following:
>> vrf 65:1
>>  rd 65:1
>>  rt import 65:1
>>  rt export 65:1
>> exit-vrf-policy
>>
>>
>>>> When I run b), the prefix is imported as local, as expected.
>>
>> My mistake, it was network a) : vnc add
>>
>>>> Assuming b) is a command for troubleshooting, should not that command
>>
>> Assuming a) vnc add
>>
>>>> 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?
>>
>> I can handle it.
>>
>>>>>   - Notification of adds/withdrawals (both models)
>>>> Are the notifications you are referring handled by the following
>>>> callback structure:
>>>> file rfapi.h, struct rfapi_rfp_cb_methods ?
>>>>
>>>> Is it possible to get some notifications when a new prefix coming from
>>>> a remote BGP speaker is imported ?
>>> yes
>>>> I tried to use rfp_methods.response_cb, and fp_methods.local_cb, but
>>>> without any success.
>>> you have to set these on rfapi_register and then query for mac|IP, or
>>> set full table download and query for anything...
>>
>> I will have a look, and keep you in touch.
>>
>>>> If you have a pointer to give me, you are very welcome.
>>>>
>>>>> o Support for load sharing, dynamic moves, redundant NVAs & NVEs
>>>> I made a pull request in order to support multipath for vpnvx address families.
>>>> ( https://github.com/freerangerouting/frr/pull/138 )
>>>> I admit that this is not necessary in order to test multipath against RTs.
>>> RDs you mean.  Different RDs allow for route distribution of multiple
>>> instances of the same prefix.
>>>
>>>> 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
>>>>
>>
>>> I think I need to see the output of 'show bgp ipv4 vpn' to comment.
>>> Right now these look like ECMP routes to me.
>>
>> The output in vnc register is the same, whatever if the route is
>> selected or not in show bgp ipv4 vpn entry
>> 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 ?
>>
>>>> [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
>>
>> For instance, if in VRF RT "64603:1111", the number of paths is
>> limited to 1 ( no load balancing for example), then I would expect to
>> see one entry, not two.
>>
>>
>>>>>> mention ( EVPN, VPNv6) and when ?.
>>>>>>
>>>> In fact, VPNv6 should already work, I guess ?
>>> v4 and v6 have equivalent support in our code. (Unless there's a bug.)
>>
>> In fact, I could make VPNv6 work.
>>
>> 1002::/64            Label: 676                      155  infinite
>>
>>
>>
>>>> I understand that both features are linked : "evpn core" and "evpn
>>>> import processing".
>>> evpn core is your (or someone else's) code, I'm not sure what you mean
>>> import processing we already have support for mac addresses in RFAPI,
>>
>> evpn import processing stands for work to be done for VNC to handle
>> VRF import processing for EVPN.
>>
>>> just the BGP encoding isn't according to standard EVPN -- and it's this
>>> encode/decode that will need to be integrated with the EVPN core code
>>> once it's available.
>>>
>>>>>> Also, if VNC is interesting to use, I would like to have some figures
>>>>>> in terms of footprint or performances. What about the following usage:
>>>>>> 10 VRFs, 1000000 prefixes, and 8 peers configured.
>>>>>>
>>>> I could extract some memory figures. 20000 prefixes and 40 VRFs.
>>> great.
>>>> Interesting.
>>>>
>>> How did it look / compare to what you expected?
>>
>> Actually, the VNC implementation is heavier in terms of memory ( for
>> 1M routes, I have had 1,8GB memory consumed versus 1,3GB for the other
>> implementation ofVRF import processing). But I think we have to
>> consider the whole set of other features that VNC brings.
>>
>> I would like to do the performance measurements, but for that, I would
>> like to measure  it with capnproto interface attached to VNC. So more
>> work to do before.
>>
>>>
>>> Lou
>






More information about the dev mailing list