Master version of basic vrf commands & some other missed fixes

[louberger]

FIX
bgpd: disambiguate different forms of
show bgp ipv4 vpn
address-family ipv4&6 vpn
VRF
bgpd rfapi: add NVE/VRF name to show vnc registrations
bgpd: add vrf-policy config using existing vnc code
add add/clear vrf prefix
+ Modified for FRR master parser
FIX
bgpd rfapi: fix issue where advertised prefixes were not being disambiguated
by RD

[NetDEF-CI]

Continous Integration Result: SUCCESSFUL

Congratulations, this patch passed basic tests

Tested-by: NetDEF / OpenSourceRouting.org CI System

CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-103/

This is a comment from an EXPERIMENTAL automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

[pguibert6WIND]

I have a constraint that prevents me to ack this commit.
It is not with VNC feature.
It is about vrf-policy feature, more specifically thr vrf <> / rd <> command.

BGP needs to know configured vrf-policies so that incoming BGP messages are filtered out according to RD name.
For instance, if I have RD 22:10 configured, and I receive a message with RD 22:11, this message is ignored.
This behaviour could be like described, if at least one vrf-policy is configured.
If no vrf-policy is configured, then all RDs are accessible ( for instance, we work with bgp vrf context)

I would like two lists to handle:

• one sub vrf list in BGP, including RD
• ons sub vrf list in VNC, including RD , RT, etc...

[louberger]

umm... RTs are used for filtering not RDs. RDs are only used to disambiguate routes between different namespaces as well as to support redundancy/alt-paths within a namespace.

[pguibert6WIND]

I agree that RTs are used for filtering.
but before filtering applies, the incoming BGP message is received by BGP. no ?
and the global RIB will append the message to its table, whatever the RT set . no ?

In fact, I think there should be a 1st filtering on incoming BGP messages.

[NetDEF-CI]

Continous Integration Result: SUCCESSFUL

Congratulations, this patch passed basic tests

Tested-by: NetDEF / OpenSourceRouting.org CI System

CI System Testrun URL: https://ci1.netdef.org/browse/FRR-FRRPULLREQ-108/

This is a comment from an EXPERIMENTAL automated CI system.
For questions and feedback in regards to this CI system, please feel free to email
Martin Winter - mwinter (at) opensourcerouting.org.

[pguibert6WIND]

==================================== Problem Description :
I have a use case where the BGPd has no VRF configured ( or few).
The BGPd interops with DC-GW.
The BGP daemon takes place inside a data center.

The fact is that DC-GW speaks with various BGP speakers including this BGP daemon.
DC-GW can then exchange a lot of routes with other BGP speakers.
The problem is the BGP daemon is only interested in learning routes from a sub-set of DC-GW.
In the VPNvx case, only a sub-set of VRFs is of interest for BGPd, that is to say only VRFs configured on Data center side, and not VRFs configured on WAN side of DC-GW.
If the DC-GW has 11000 VRFs configured, and only 1000 configured on DC side, those are only the 1000 that are of interest for BGP daemon.

Currently, the BGPd takes all RDs in memory, even if it is of no use.

I see two problems:

• the operator problem : how can we filter/ignore some VRFs for a BGP daemon
• the security problem : receiving all incoming RDs , including the one that are of no interest, may consume the memory up to a non supportable limit. This may cause memory exhaustion.

==================================== Description of Expectation :
I think of a kind of filtering solution:

currently:

• all incoming VPNvx are entered in global BGP RIB.
• if RT set is set for the received RD, then incoming VPNvx is duplicated in matching BGP VRF RIB

if I receive A.B.C.D/24 RD <20:11> with RT <10:11>, I will have
vty>show ip bgp ipv4 vpn
rd 20:11
A.B.C.D/24
vty>show ip bgp vrf 10:11
rd 10:11
A.B.C.D/24
expected:
because I expect information from a confiugred VRF that does not match the RT set, I expect no entry is duplicated
vty>show ip bgp ipv4 vpn
vty>show ip bgp vrf 10:11

==================================== Solution Proposal:
I would like to be able to know if the RT set that is received matches one VRF.
If it does not match, then there will not be anything in global RIB.
I would like this behaviour to happen if at least one vrf-policy is configured.
If no vrf-policy is configured, the behaviour will be as the currently.

The problem I face is incoming VPNvx systematically are entered in global BGP VRF RIB table, then processed for import processing.

I tend to think that I would like also to create new VRFs matching the incoming RD.

Your suggestions are welcome.

[louberger]

Per the RFCs, RTs are used for filtering, not RDs and this is what the code already does. I think the desired filtering is supported, just based on RT import values, not RDs. (per the RFCs: RT identifies/controls VRFs and VRF topology, RD separates address spaces for route distribution logic.)

[donaldsharp]

Lot's of discussion still surrounding this. We will finalize first before committing

[donaldsharp]

@pguibert6WIND RFC 4684 appears to be written to address the concerns you have. Have you considered it?

[pguibert6WIND]

hello all,
The problem i was referring is out of scope of this issue.
hello @donaldsharp , you are right. rfc4684 could solve my issue.
the problem i face is more related to default behaviour with qbgp.
I created a specific issue : #115

I agree to go ahead with this patch.