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

Philippe Guibert philippe.guibert at 6wind.com
Tue Jan 31 10:01:52 EST 2017

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 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) : 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

>> 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
>>         Label: 125                      155  infinite
>>         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
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         0    100      0 i
     EC{64603:1111} label=125 type=bgp, subtype=0
*>i11.11.0.0/16         0    100      0 i
     EC{64603:1111} label=125 type=bgp, subtype=0
*>i22.22.0.0/16         0    100      0 i
     EC{64603:1111} label=125 type=bgp, subtype=0
*>i33.33.0.0/16         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
>>         Label: 125                      155  infinite
>>         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