Hey Guys,
Trying to get some deeper learning going with BGP and have two queries.
The "keep" functionality's default behaviour doesn't make sense to me in how it's been described.
set protocols bgp neighbour 123.123.123.123 keep all
By default (so when you don't configure the "keep" statement at all), it says it keeps most BGP information - but hides information that is rejected by route policy -, except for routes of which have looped paths. Docs here.
Now my understanding of this implies that if you receive a prefix that is part of a looped path, by default, it won't be kept, so you shouldn't see it in hidden. But I know I've seen hidden routes for looped paths before and you can see it in this KB example here when they introduce the loops feature. So it would seem that by default it does keep all BGP routes, even when it comes from a looped path, it's just marked as hidden.
However, when I've been studying BGP, there seems to be a separate RIB-IN, LOC-RIB and RIB-OUT table and it's possible that none of which represent inet.0 (which has all routes - disregarding the concept of routing-instances here). If that's the case, then perhaps the route is stored in inet.0 as hidden, but in the specified BGP tables, the route doesn't exist. Having said that, I thought the "show route receive-protocol bgp" command shows the RIB-IN table and you can clearly see the looped route in the previous KB example so that doesn't seem right.
All of this to say "What's the difference between the default keep behaviour and the "keep all" behaviour seeing as looped routes are advertised regardsless, albeit as hidden"?
The second question is about ROUTE REFRESH.
I understand that soft-inbound clearing will cause the local router to send a ROUTE REFRESH message to its neighbour and then the neighbour will send an UPDATE message with all the prefixes.
But what about the other way, when you just use the "clear bgp neighbor neighbour-ip soft", you don't send a ROUTE REFRESH message so I can only assume that you just straight up send an UPDATE message (which are incremental by nature anyway) to your peer after you re-apply the prefixes configured under the export policies of the neighbour/group? Basically, I can't find anything in the ROUTE REFRESH message that would be able to indiciate whether or not it's an inbound or outbound message, so it must be used for inbound only - does that sound correct?
Cheers,
Purplezorz