In the customer topology:

R1 (default RI) <<<eBGP>>> R2 (default RI) <<<eBGP>>> R2 (PROD VRF) <<<iBGP>>> Other Vendor Router

The customer uses eBGP to inject a default route from R1 into R2's default RI. This route is then redistributed into the PROD VRF on R2 and advertised to the Cisco router via iBGP.

By default, when a route is received via eBGP, the receiving router appends its local-AS to the AS path. Therefore, when R2 receives the default route from R1, it adds its local-AS to the AS path. This AS path is then visible to the other vendor router, which is not the desired behavior.

The customer’s requirement is to suppress the addition of R2’s local-AS in the AS path seen by the other vendor router, while still using iBGP to advertise the default route into the PROD VRF.

• Other vendor router receives a default route with an unexpected AS path.
• The AS path includes the local-AS of R2, which the customer wants to avoid.
• Default route is injected into the PROD VRF via eBGP from the default routing instance (RI).
• iBGP peering exists between R2 (PROD VRF) and the other vendor router.

To meet the requirement and avoid the local-AS being added to the AS path:

1. Use iBGP within R2 to inject the default route from the default RI into the PROD VRF.
2. Configure the iBGP neighbor in the PROD VRF as a Route Reflector (RR). To configure an iBGP router as a route reflector (RR) and use a cluster ID, you need to configure the RR with the cluster-id command.

This approach ensures:

• The default route is propagated within the same AS using iBGP.
• The AS path does not include R2’s local-AS, as the route is not received via eBGP in the PROD VRF.
• The other vendor router receives the default route with the desired AS path.

This configuration leverages the fact that iBGP does not modify the AS path, and using a Route Reflector allows iBGP-to-iBGP route advertisement, which is otherwise restricted.