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

Philippe Guibert philippe.guibert at 6wind.com
Tue Jan 31 04:43:39 EST 2017

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 ?

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

global config# add [vrf <vrf-name>] prefix <prefix> [rd <value>]
[label <value>] [pref (0-255)]
vpnv4 af # network rd 65:1 tag 55

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 ?

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 ?

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

> 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 ?
I tried to use rfp_methods.response_cb, and fp_methods.local_cb, but
without any success.
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.
I could then test ECMP with VNC.
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         Label: 125                      155  infinite         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
*>         Label: 125                      155  infinite         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
*>         Label: 125                      155  infinite
=>         Label: 125                      155  infinite

Does that mean that all entries are taken into account without any

> 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 ?
I understand that both features are linked : "evpn core" and "evpn
import processing".

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

More information about the dev mailing list