I'm often promoting the idea of separating customer routing from core routing in the design articles I write. The only viable solution (unless you want to implement MPLS VPN and migrate customer routing into VPNv4) is to carry customer routes in BGP, redistributing them into BGP from other routing sources. On the other hand, I’m telling you that you should advertise only static IP prefixes into the public Internet. Obviously there’s a seeming disconnect between the two advices.
However, the dilemma is easily solved with the no-export BGP community that prevents an IP prefix from being advertised over EBGP sessions. Whenever you redistribute customer routes into BGP, you should attach the no-export community to them, ensuring that only the statically advertised IP prefixes will be propagated outside of your AS boundaries.
Important: for this design to work, you have to configure BGP community propagation with the neighbor send-community router configuration command on all IBGP sessions in your network, preferably with a peer template. Otherwise, the BGP communities will be lost on IBGP updates and the IP prefixes will leak to your EBGP neighbors.
For example, if you use static routing with your customers and want to redistribute the static routes into BGP, use the following configuration (I’ve used tag 123 to tag static routes that should get inserted into BGP).
router bgp 65001 redistribute static route-map StaticToBGP ! route-map StaticToBGP permit 10 match tag 123 set community no-export additive
When you configure a static route toward the IP subnet 10.1.2.0/24 …
ip route 10.1.2.0 255.255.255.0 Null0 tag 123
… it’s automatically inserted in the BGP table and marked with the no-export community.