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

Lou Berger lberger at labn.net
Tue Jan 31 08:23:48 EST 2017



On 1/31/2017 4:43 AM, Philippe Guibert wrote:
> Hello Lou,
>
> On Tue, Jan 24, 2017 at 7:37 PM, Lou Berger <lberger at labn.net> wrote:
>
>> I'm not sure what you're asking here, if anything.  Nonetheless I'll add
>> some to details/response below
> Thanks a lot, I need information, I need to dig into the vnc internals :-).
>
>
>> The vrf-policy and add drop functions described
> drop function, you mean clear command ?
yes.
>> 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.

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.*

*

> When I run a), I was expecting to have the prefix imported in the
> 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.

> When I run b), the prefix is imported as local, as expected.
> Assuming b) is a command for troubleshooting, should not that command
> 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?

>> Here's a list of what's covered in the VNC code:
>> o NVO3 NVA (SDN controller)
>> o BGP based distribution of IPv4, IPv6 and L2/MAC VPN information over
>> arbitrary tunnel types
>>   - IPv4 and IPv6 tested extensively, MAC tested, but less extensively
>>   - Arbitrary control topologies (mesh, RR, hybrid, etc.)
>> o Full BGP VRF support (RTs & RDs)
> This is what I am interested in.
> - First, Importing VPNv4 or VPNv6 entries
>
>> o Multiple L2 logical nets (~= EVPN Ethernet Segment Id)
> From what I see, the 10 byte ethernet segment identifier is not carried out yet.
> This matches what you are referring by L2/MAC VPN information over
> arbitrary tunnel types
A 4 byte logical network identifier is carried as an RT unless there is
a configured RT override (for the LNI label tuple under l2-group config).

>> o Parallel L2 forwarders per segment
>> o Remote Forwarder "RF" (NVE) support
>>   - Dynamic RF registration based on configured policy
>>   - Full state maintained per remote forwarder
>>   - Dynamically learned, or configured mappings
>>   - Cache driven (pull) and full table download (push)
>>   - 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...
> 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.
multipath isn't needed - but it also can be used.
> I observe the following:
>
> 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 was expecting something like that:
> [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
>
> If there was a command to enable multipath on the RT, I would have
> expect the following
>
> [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.

> Does that mean that all entries are taken into account without any
>
This like got cut off.

>> o Per VRF import/export via BGP (inside L3VPN)
> I began some testing.
>
>> o IGP import/export to single zebra
>> o API support for custom remote forwarder (NVA/NVE) protocol
>>
>>
>>>     Our plan was to add the vty functions for the VNC code once they were
>>>     agreed to by the community (background in the link provided by
>>>     Philippe).  It sounds to me that we should resume this discussion as
>>>     well as discuss this patch in an upcoming technical meeting.
>>>
>>>
>> again, see pull requests for basic support
>>
>>> From our exchange, I understand that the VNC feature implements the
>>> VRF portion of this patch.
>>> The VNC also implements the NVO3 style forwarder. You are better
>>> placed than me to talk about the VNC feature.
>>>
>>> I don't know if there are plans for supporting the next features I
>>> mention ( EVPN, VPNv6) and when ?.
>>>
>> -L2 is via non-standard BGP encoding, plan to convert to evpn once core
>> code available
>> - Support for  zebra VRFs needs to be done as part of the CLI support
>> mentioned in URL above.
> In fact, VPNv6 should already work, I guess ?
v4 and v6 have equivalent support in our code. (Unless there's a bug.)

> 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,
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?

Lou




More information about the dev mailing list