Build the EVPN border around export policy, not attachments

The common assumption is that the Layer 2 attachment model at the border determines everything above it, so the design starts with a vPC pair and works upward. It usually ends up with routing decisions made by accident. An EVPN border is a routing boundary first: a tenant routing context meets an external routing domain, and what crosses that line is a policy statement. Choose the routes, the ASN relationship and the failure paths before anyone argues about port-channels. The attachment model then follows from a requirement instead of dictating one.

Start with what crosses the boundary

Write down the routes that should be visible on each side, the direction they travel and who approves a change to that list. A border that accepts everything and announces everything has no policy, only a cable.

Then name the failure you intend to operate: one uplink down, one border leaf down, or the whole external domain unreachable. Each answer changes whether you need two independent neighbors, a shared Layer 2 attachment, or both.

Only after those two lists exist does the attachment question become answerable. Before that, every mechanism looks equally valid. After it, most of them eliminate themselves. That is the whole argument for doing the routing work first.

Fix the ASN and peering boundary

A private-AS fabric commonly peers with the public border domain over eBGP, and the interesting part is the policy on both sides. Decide which prefixes are accepted, which are announced, and what AS path the upstream should receive.

RFC 6996 reserves a private-use ASN range, and those ASNs are not supposed to appear in global advertisements. Apply the platform's supported removal or filtering policy and verify the resulting advertisement rather than assuming the device did it. That step also does not give you authority to announce an arbitrary public prefix, which is a separate conversation with the address owner.

A confederation or a local-AS feature is a design choice for a specific topology. Neither is mandatory just because the fabric and the upstream use different ASN roles, and adopting one without the requirement adds moving parts to every future change.

Layer 3 uplinks do not need multichassis LAG

Independent routed interfaces with their own BGP neighbors give two clear paths and two clear failure domains. vPC or another multichassis LAG serves a Layer 2 attachment requirement, and it is the right tool when that requirement exists.

A blanket rule that every border pair must use vPC, or must avoid it, hides the conditions that actually decide the case. Ask what the attachment has to carry, then pick the mechanism that carries it with the fewest shared failure modes.

The routing policy you wrote first does not change when the attachment mechanism changes, which is a good sign the order was right.

Export only what the tenant needs

A tenant may need a default route, a set of selected external prefixes, or a much larger table. Choose that scope against real forwarding and control-plane capacity, not against an old count of internet routes that nobody has re-measured.

The EVPN IP Prefix route, commonly called Type 5 and defined in RFC 9136, carries prefix information in the overlay. The implementation still needs matching export and import policy plus next-hop resolution, so receiving an external BGP route at the border does not mean every tenant VRF imports it.

Every leaf does not need the complete table merely because the border holds it. Distribute what the tenant's traffic requires, and let the border own the rest.

Verify one prefix end to end

Pick a representative external prefix and follow it through the border's intended VRF, the export policy, the receiving leaf's forwarding context and the return path to a tenant source. A prefix that appears in one place and not the next localises the mistake immediately.

Confirm how the next hop resolves through the overlay, because a route that is present with an unresolved next hop forwards nothing. Then repeat the check after an uplink change, since that is when policy and next-hop resolution most often diverge.

Order of work: list the crossing routes, agree the ASN policy, choose the attachment for its actual job, scope the export per tenant, then verify one prefix and its return path.