bgpd: Allow views to 'pretend' resolve nexthops

[donaldsharp]

Views are supposed to be independent tables
that have no connection to routing tables.
Since View's are 'independent' there is
no way to do 'real' nexthop resolution since
connected routes and interfaces are associated
with a particular table (or really vrf).
So when we have a bgp instance assume that
nexthops specified are actually valid,
since we are propagating what our neighbors are telling
us.

Signed-off-by: Donald Sharp sharpd@cumulusnetworks.com

[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-184/

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.

[eqvinox]

Seems good for stable; I'd hope we could do something better for master (i.e. using the default VRF for views), but that'd be a large change which is a bit much for stable... and I don't think it's a huge issue if 2.0 just thinks all nexthops are always reachable in non-default views. Might even be a feature? :D

[eqvinox]

So I think we should apply this on both stable and master, and if someone feels they want something better on master they can go do that on top... and if no one feels so, I don't really care either.

[donaldsharp]

I actually started down the path of using default vrf for views but ran into several issues that I felt were going to make it quite challenging:

1. the api for nexthop lookup has no ability to differentiate between different views in the same vrf
2. the code wants to differentiate views into their own tables but there is no good mechanism to map multiple views to 1 table.

[eqvinox]

Applied on stable/2.0.