[frr] [PATCH 01/11] bgpd: BGP VRF processing handling
Jeff Tantsura
jefftant at gmail.com
Mon Feb 6 14:27:48 EST 2017
Hi,
RD is usually configured in context of VRF, not per prefix. What would be the use case?
The best way to address prefixes is to do so indirectly, thru route-map/prefix-list/your preferred-feature-name
prefix/label/rd combination makes little sense to me, label per prefix is not really good thing unless there’s a need (we could go in details when), default mode - label per NH, perhaps with knobs per VRF (would require additional lookup if there are more than 1 NH’s), per-prefix, RD per prefix - see comment above
How would additional ext-comm added, think of RO/SOO -> having policies within import/export stanzas my be desirable
Type 5 - I like Junos’s keyword - "ip-prefix-routes” with associated attributes
my 0.2c
Cheers,
Jeff
> On Feb 6, 2017, at 01:45, Philippe Guibert <philippe.guibert at 6wind.com> wrote:
>
> Hello Lou, all,
>
> On Fri, Feb 3, 2017 at 12:16 PM, Lou Berger <lberger at labn.net> wrote:
>>>>> 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!
>
> I mean, I need to be able to configure prefixes before suppressing the
> command :-).
>
>
>
>>> 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] ...
>
> This solution fits with one BGP instance per VRF.
> I agree for that.
>
> But the solution is not enough.
> It does not fit with one BGP instance for multiple VRF handling.
>
> Is there any group consensus about supporting the following:
> specific routes to be added in the context of a VRF-policy by using
> following configuration method:
>
> router bgp <ID>
> vrf-policy <vrf-policy-name>
> rd <>
> label <>
> rt import <>
> rt export <>
> prefix <prefix> [label <value>] [nexthop <value>]
> exit-vrf-policy
>
> Adding to the review, 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 ?
> In the EVPN Route type 5 method, the same
>
> config term
> router bgp ....
> vrf-policy <vrf-name>
> transport vpn | evpn | encap
>
>
>>>>> 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?
>>>
>
> See https://github.com/freerangerouting/frr/pull/168
>
>
>>
>>>>>> - Notification of adds/withdrawals (both models)
>>>
>> 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.
>>
> I will check. Thanks.
>
>>>>>> o Support for load sharing, dynamic moves, redundant NVAs & NVEs
>>>>>
>>>>> 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
>>>>>
>
>> The rfapi does order the prefixes on query call back based on preference,
>
> By using preference on BGP, the entries will not be considered as ECMP.
>
>> 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.
>
> 1) If I understand correctly, if it is up to the call back code, then
> I understand following scenario should be implemented:
>
> On my case, the call back should instantiate a VRF RIB table.
> When ECMP entries are detected, an algorithm in the callback should be
> triggered to know which ECMP entry is valid.
> If there is a preference set that is greater in one of the ECMP
> entries, then it will be selected.
> If there is no preference difference, the difference will be based on
> the underlay nexthop attribute.
>
> Reversely, if a route is withdrawn, notitication call back would be
> called. an algorithm in the callback should be triggered too to know
> if there are still ECMP entries or not.
> If the entry with the best preference disappears, then the entry with
> the least preference would be selected.
>
>
> 2) I would prefer having an internal implementation of BGP best
> selection algorithm, and configure then notifications so as to inform
> only the selected entries.
> It would avoid having a second VRF RIB instance implemented in a second place.
> If I have a preference set for one route more than one other route,
> then only the preferred entry would be sent to the notification.
>
> For 2), I would need :
> - a vrt command to configure multipath per vrf-policy
> config term
> router bgp ....
> vrf-policy <vrf-name>
> transport vpn | evpn | encap
> - a vty command to change the notification procedure.
> config term
> router bgp ....
> ## callbacks would be advertised
> ## new entries that are set as selected ( ECMP or best prefrence for example)
> ## removed entries that are set as unselected ( entries that are no
> more unselected because of a new selected entry with best preference)
> vnc notification only-selected
> ## show vnc registration would show only the selected one
> vnc display only-selected
>
> Waiting for suggestions,
>
>
>
>
>>
>> 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.
>>
>
> Best Regards,
>
> Philippe
>
> _______________________________________________
> frr mailing list
> frr at lists.nox.tf
> https://lists.nox.tf/listinfo/frr
More information about the dev
mailing list