Routing

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

Hello,

---

@Purplezorz wrote:

Hey Guys,

 

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.

It's the other way around:

- if the path is not AS-looped but has other issues such as cluster-id loop, don't keep it.

- if the path is AS-looped then except it, and keep it.

---

@Purplezorz wrote:

 

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?

Negative. Nothing is sent/signaled to peers as a result of "clear bgp neigh BLAH soft". The local peer just reapplies import policies to RIB-IN.

---

@Purplezorz wrote:

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?

 

Route Refresh becomes more understandable if You read it as "Please Refresh ME" - a polite ask from local peer to its remote peer(s) to send the most recent copies of the NLRIs to the local peer. Route Refresh is not a conversation: there is no Refresh request and no Refresh reply, just an "ask".

HTH

Thx

Alex

Thanks Alex,

Conscice and informative as always 🙂 

Makes sense now.

Cheers,

Purplezorz