[frr] [PATCH 01/11] bgpd: BGP VRF processing handling
Lou Berger
lberger at labn.net
Fri Feb 3 06:16:27 EST 2017
Philippe
On January 31, 2017 10:10:34 AM 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.
>
Thanks!
>> 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 )?
>
As I understood the group consensus on the call, specific routes would be
learned/configured in the context of a vrf (under bgp <as> vrf <vrf>) and
specific RDs and the typical attributes could be set using typical route
map operations. -- here's the related portion for the Google doc:
router bgp XXX vrf <vrf-name>
! (address-family ipv4)
network 1.2.3.0/24 route-map foo
neighbor ... ! CE session (or alternately, VRF-lite session)
!make vrf redistribution (import/export)the default
redistribute static|ospf|vrf [route map] ...! CE setup for OSPF
no redistribute vrf
no export vrf
export vrf [route map] ...
>>> 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.
>
Thank you!
>>>> - 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.
>
I did find on issue related to mpls call backs in reviewing / retesting the
code and this has been pushed. Other tunnel types should have worked.
>>> 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
The rfapi does order the prefixes on query call back based on preference,
but it up to the call back code to decide if only the best route is used.
This was explicitly done to support multi/and backup path forwarding.
Again the output you were expecting is here:
> 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 ?
>
No they are ordered and available for downstream processing / selection by
the rfp code.
>>> [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.
>
Well both show in the show vrf command too - this command is there to show
all state.
>
>>>>> 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
>
>
Great.
>
>>> 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.
>
I still don't follow - sorry.
>> 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.
>
Interesting. I'll go lookup what we're seeing...
> 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.
>
Look forward to hearing the results.
Lou
>>
>> Lou
>
More information about the dev
mailing list