ASR1001-X BGP soft-reconfiguration inbound question

[TelesEC]

Hello everyone,

I have a big doubt and I hope you can help me, thanks in advance.

Question: Why is the memory consumed by adj-rib-in not greater than or equal to the memory consumed by local-rib?

Context:

I was reviewing the configuration of my Internet Edge routers and in the BGP configuration with the ISP we have applied the following command:

neighbor x.x.x.x.x soft-reconfiguration inbound

The ISP sends me the full BGP routing table and I am aware that the command 'soft-reconfiguration inboud' should be deleted.

But I don't understand why the memory used by the Adj-rib-in is not the same as the local-rib?

show ip bgp neighbors x.x.x.x.x
*Output omitted for brevity*
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 7 818518 (Consumes 111316272 bytes)
Prefixes Total: 7 4120075
Implicit Withdraw: 0 3039791
Explicit Withdraw: 0 261766
Used as bestpath: n/a 777318
Used as multipath: n/a 0
Used as secondary: n/a 0
Saved (soft-reconfig): n/a 1 (Consumes 136 bytes)

show ip bgp summary
*Output omitted for brevity*
1 received paths for inbound soft reconfiguration

PID: ASR1001-X Version 16.9.5

show ip bgp neighbors x.x.x.x policy
Neighbor: x.x.x.x, Address-Family: IPv4 Unicast
Locally configured policies:
prefix-list ISPtoME in
prefix-list ANNONCE_ME_ISP out
filter-list 7 out
soft-reconfiguration inbound
remove-private-as

[paul driver]

Hello
But I don't understand why the memory used by the Adj-rib-in is not the same as the local-rib?

Not necessarily the case - in fact BGP does mention its not by protocol design to specifically maintain 3 separate rib tables even those 3 rib tables are stated it could be just the one rib table is used with pointers towards the specific prefixes.

In any case like i suggested initially if your rtrs support route fresh then utilise that feature and remove soft-inbound from the bgp stanzas 

---

[paul driver]

FYI - I managed to find the rfc -

rfc4271 - page 10

[TelesEC]

Thank you for your reply Paul.

Yes, I will delete this functionality. I just wanted to understand why the behavior was not as expected on these routers.

Normally the soft-reconfiguration functionality should keep in memory all the prefixes before applying the policy... The use of this functionality becomes meaningless with the advent of Route refresh.

[Peter Paluch]

Hello Paul, hello Andrés,

Please allow me to join.

Andrés, I think that the behavior you see - having only 1 route in the soft-reconfig database instead of all those 800K routes - could be the result of configuring the soft-reconfig only after the BGP peering already came up. Are you sure it has been always configured for that neighbor, particularly before the peering came up and the neighbor sent us all the routes?

The soft reconfiguration can only store the routes it newly receives from a neighbor, and so if it is activated after the peering has come up and the routes were already advertised, it has nothing to remember. It can only store aside routes that are advertised later.

Could this be the case?

Best regards,
Peter

[TelesEC]

Hello Peter,

Thank you very much for your response.
What you say makes a lot of sense, on the other hand, I have had several problems on this link so the BGP session has been re-established several times with the configuration of the feature (soft-reconfiguration inbound) already applied.

If I have the feature configured and if I lose the BGP session... when it is established again, I should have the 800K in both tables, right?

Thanks,

Andrés