[frr] [PATCH 01/11] bgpd: BGP VRF processing handling
Philippe Guibert
philippe.guibert at 6wind.com
Fri Feb 3 03:33:30 EST 2017
Hello Lou, all,
coming back to you, I need some answers, please.
a) about the "network" configuration command per vrf-policy
Because network command under address-family would be replaced by an
other command under vrf-policy.
- I did not see all options on RD/RT document I would expect.
IMHO, prefix parameter is not an option, and it should be possible to
provision a whole set of prefixes per vrf-policy.
configuration example:
config term
router bgp ....
vrf-policy <vrf-name>
rd <value> [prefix <prefix>|prefixlist <prefixlist>]
label <value> [prefix <prefix>|prefixlist <prefixlist>]
route-target <import|export|both> <value>
!use routemap to change
nexthop <ip-addr|ipv6-addr|self>
prefix <prefix> [label <value>] [rd <value>] [nexthop <value>]
<---- command moved from afi/safi node to vrf-policy
- Per extension, I would also expect a command that mentions the
signalisation transport method ?
If I set a prefix, how can I force the prefix to be advertised by
VPNvx or EVPN ?
I would expect such a command to request the transport method
config term
router bgp ....
vrf-policy <vrf-name>
transport vpn | evpn | encap
b) about the multipath case.
>From the previous mail example, I observe that show vnc registration
takes into account all incoming NLRIs.
How can vrf-policy so as to configure VRF RIB to enable/disable multipath ?
When ECMP NLRIs are encountered, how can the VRF RIB differentiate the
case that I want to do Load Balancing or not ?
I would expect such a command to influence the multipath case
config term
router bgp ....
vrf-policy <vrf-name>
maximum-path <1-64> <--- command added
Best Regards,
Philippe
On Tue, Jan 31, 2017 at 4:01 PM, 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.
>
>> 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) : 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.
>
>>>> - 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
>>> 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
> 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 ?
>
>>> [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.
>
>
>>>>> 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