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