When you apply policy changes, they are only applied on routes that are learned after the policy changes have been enacted. This is because BGP is most frequently implemented on links that connect to other ASes – and you can’t just force an ISP or another organization to resend their BGP routing table to you. You can force this by running “clear ip bgp *” (every BGP neighbor) or “clear ip bgp A.B.C.D” – but these clear commands actually tear down connections between neighbors and cause communication to cease until the neighbor relations are rebuilt. In the real world where BGP is run – this is a bad thing.
When you perform the “neighbor A.B.C.D soft-reconfiguration inbound” router command – it shuts down the connection (just like a hard reset). When the neighbor resends you it’s routing table, BGP stores a copy of the received routing table in memory. This 2nd copy takes up memory, but it serves a useful purpose. Now, when you apply policy changes to a neighbor or out a particular interface, you can configure “clear ip bgp * (or A.B.C.D) soft in” and run the saved copy of the neighbor’s routes through your new bgp policy filters. You can make policy changes all you want and your neighbor never has to resend you its routing table, and you never have to tear down the connection between you and disrupt network communication.
EIGRP, OSPF, RIP, IGRP – If you apply a policy change (ACL, Distribute List, Route Map, whatever) – that change takes place instantly (instantly + the time to propogate the change and implement the policy). BGP acts differently – it waits until it receives new routes through its new filters. That’s why the “soft-reconfiguration inbound” command was created.
R6#sh ip bgp nei 220.127.116.11 received-routes % Inbound soft reconfiguration not enabled on 18.104.22.168