From a CE RIP Route to a Remote VRF: Where the Export Happens

A RIPv2 update arrives at the provider edge, lands in a VRF routing table, and stops there unless something explicitly exports it. Three decisions happen in sequence, and each one can refuse the prefix for its own reason. Reading them as a single event is why people chase the wrong box when a remote site cannot reach a network that the CE clearly advertises. Follow the route through the PE and the sequence becomes obvious.

What the PE does with a RIP update

The PE receives the update on the VRF interface, checks that the source is a permitted neighbor, and installs the prefix into the VRF routing table with a hop count derived from the advertisement. That table is a normal routing table with its own administrative distances and its own best-path election. If the CE advertises the same prefix twice with different metrics, only the better one survives into the table. Nothing in this step involves the provider backbone.

The prefix now exists inside one customer's routing context, which is a long way from being reachable anywhere else.

Export is a policy act, not a protocol consequence

To leave the VRF, a route has to be redistributed into the MP-BGP process that carries VPN routes, and it needs a route target extended community that identifies which remote VRFs may import it. The architecture in RFC 4364 keeps those exchanges separate from the CE-to-PE protocol for exactly this reason. Using RIP at the edge says nothing about what should cross the provider network.

Write the export contract down before configuring anything: the customer prefixes that must be reachable remotely, the routes that must stay local, and any defaults, more-specifics or shared-service exceptions. Match that contract against the actual VRF rather than a similarly named one belonging to a different customer.

The import side is a second policy with its own route targets, and a matching export with a non-matching import produces a prefix that exists in the backbone and appears in no remote table.

Redistribution and explicit origination behave differently

Redistribution takes routes that already exist in the VRF table and copies them into BGP, filtered by a route map. The map decides which prefixes are eligible and what attributes they carry, and the metric has to be set explicitly because a RIP hop count has no meaning as a BGP metric. Anything you leave unset is inherited in a way that usually surprises the person who reads the config six months later.

Mutual redistribution is where the quiet damage happens. A prefix exported into BGP can come back through a second redistribution point, and without tags or filters the route oscillates while both tables look plausible at any instant. Filter on tags applied at the edge rather than trusting the topology to prevent the return path.

Explicit origination looks tidier and is not unconditional. A network statement normally needs a matching route in the routing table before the prefix is originated, so the advertisement disappears the moment the CE stops advertising it. That is often the behavior you want, and it is not the same as a static route that stays configured forever. Check the platform's actual rule instead of assuming either behavior.

Either way, the question to ask about each prefix is which active source makes it eligible and what happens when that source disappears.

Verify the chain in four places

Look at the CE advertisement, the VRF routing table, the VPN route table with its route target, and the remote VRF import, in that order. On IOS that means the CE neighbor output, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, and the same command on the far PE. On IOS-XR the equivalent output lives under show bgp vrf CUSTOMER ipv4 unicast. The command names differ, the four checkpoints do not.

Check a prefix that should be rejected as carefully as one that should pass, because a policy that permits everything looks identical to a correct one until the first exception arrives. Then watch a withdrawal: shut the CE interface, and confirm the remote entry disappears within the expected timer rather than lingering.

Record who owns each policy. When the provider runs the CE, the delivered behavior belongs in the service contract, and a different protocol or withdrawal policy on the managed device is a documentation problem before it is a routing problem.