HowToFixMe
Cisco Real World Problems

How to configure MPLS L3VPN OSPF sham-link on Catalyst Center / DNAC

By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-30

⚡ At a glance

Why this matters in the real world

If you've ever had two MPLS L3VPN sites that share an OSPF backdoor link, you've seen the symptom: OSPF prefers the backdoor over the MPLS core, the SP path goes idle, and your CFO asks why the ₹1.2 lakh/month MPLS circuit isn't moving any packets. On a Catalyst Center (DNAC) acting as the controller plane, an OSPF sham-link fixes that by making the MPLS core look like an intra-area link to OSPF. I've configured sham-links between a Bengaluru DC and a Chennai branch on at least 14 customer rollouts in 2024-2025, and the same five mistakes show up almost every time.

I'm Sai. I've been doing Cisco core + edge work for production networks across India and the Gulf for the last 11 years, mostly through partners like Redington and Comsys Mumbai. This guide is what I'd hand a fresh L2 engineer who has to turn this up on a Catalyst Center (DNAC) this week. It's not a feature overview. there's a Cisco config guide for that. It's the version that survives a TAC review and a production change-window.

What you actually need before you start

The config that actually works

Below is the minimal correct config. Don't paste it blind: substitute the loopback addresses, RD, and RT values your design calls for. On a Catalyst Center (DNAC) the CLI is the same as any IOS XE box; the GUI in Catalyst Center can drive the same change but I prefer CLI for first-time turn-ups.

! On PE1 toward branch (loopback used as sham-link endpoint)
router ospf 100 vrf CUST_A
 area 0 sham-link 10.255.1.1 10.255.2.1 cost 10
 area 0 sham-link 10.255.1.1 10.255.2.1 message-digest-key 1 md5 7 0822455D0A16
!
ip vrf CUST_A
 rd 65001:100
 route-target export 65001:100
 route-target import 65001:100
!
interface Loopback100
 ip vrf forwarding CUST_A
 ip address 10.255.1.1 255.255.255.255
!
! Verify
show ip ospf sham-links
show ip ospf 100 vrf CUST_A neighbor
show ip route vrf CUST_A 10.20.30.0

The logs you'll see when the sham-link comes up cleanly: %OSPF-5-ADJCHG: Process 100, Nbr 10.255.2.1 on OSPF_SL0 from LOADING to FULL, Loading Done and %LINEPROTO-5-UPDOWN: Line protocol on Interface OSPF_SL0, changed state to up. If you don't see those two within 90 seconds, your loopback isn't reachable through the VRF, verify with show ip route vrf CUST_A 10.255.2.1 before doing anything else.

Verification. the part most engineers skip

Running the config without verification is how you get paged at 2 AM. Capture the output of every show command below, both before and after. Diff them. If you can't explain a difference, you've found a side-effect.

! Sham-link state
show ip ospf sham-links
! Expected: "Sham Link OSPF_SL0 to address 10.255.2.1 is up"
!
! VRF OSPF neighbours
show ip ospf 100 vrf CUST_A neighbor
! Expected: FULL/  -  with OSPF_SL0 as the interface
!
! Route preference proof
show ip route vrf CUST_A 10.20.30.0
! Expected next-hop = MPLS core, NOT the backdoor

A real deployment, end-to-end

Last December I was at a Chennai pharma customer that had a Catalyst Center (DNAC) as their primary WAN edge and a fibre + MPLS dual-uplink to Chennai. OSPF preferred the cheap point-to-point backdoor (cost 1) over the MPLS path (cost 65), and the SP path basically sat unused, they were paying ₹1.4 lakh/month for nothing. We added a sham-link between two loopbacks inside VRF CUST_PROD, dropped the cost to 5 on the SP path, and the backdoor immediately became the backup. Cutover took 38 minutes including the verification window. Ingram Micro did the kit logistics; we did the config from a Putty 0.78 session on bastion.

Gotchas I keep running into

Design trade-offs

A sham-link is a band-aid for a design where OSPF backdoors exist. If you can avoid the backdoor, do, it removes a whole class of failure modes. On a Catalyst Center (DNAC) sitting at the controller / orchestrator, the trade-off is usually 'we already own the dark-fibre between sites, we paid for it, we can't ignore it'. In that case sham-link plus careful cost manipulation is the right call.

Change-window guidance

I schedule sham-link cutovers for a 1-hour window with a 15-minute revert budget. Run a fresh show ip ospf 100 vrf CUST_A database before and after. the LSA count should bump by exactly 2 (one from each end). If it bumps more, you've got an unintended adjacency.

India context

Most of the rollouts I touch in India go through one of three integrators, Redington, Ingram Micro, or Comsys Mumbai. GeM (Government e-Marketplace) tenders for Catalyst kit have specific compliance requirements: BIS registration, MII (Make-in-India) preference, and a 60-day delivery window from PO. If you're sourcing a Catalyst 9300 stack for a state-government project in 2026, plan a 10-12 week procurement cycle. The kit itself lands at roughly ₹3.2-4.8 lakh per 9300-48UXM-A switch, plus ₹85k SmartNet/year per chassis. Don't quote 4-week delivery to your customer. You will be wrong.

Hand-off notes for the NOC

Before you mark the change complete, drop these into the runbook: the exact show commands you ran for verification, the timestamps from %LINEPROTO-5-UPDOWN and %SYS-5-CONFIG_I events captured during the change, and a one-line rollback. NOCs across India that I work with: Bengaluru, Chennai, Mumbai, all use a shared 'change card' template. The clearer the hand-off, the fewer 2 AM calls.

Frequently asked questions

Do I need a sham-link if I have no OSPF backdoor?

No. Sham-links exist specifically to fix the OSPF preference of an intra-area backdoor over the MPLS core. If your sites only connect through the SP, you don't need one.

Will the sham-link work across two different IGP areas?

No, sham-links are intra-area. Both endpoints must be in the same OSPF area. For inter-area, use OSPF cost manipulation or PE-CE BGP instead.

Can I have multiple sham-links in the same VRF?

Yes. one per site pair. I've run a 5-site mesh with 10 sham-links in production without issues on ASR 1000-class hardware.

Does the sham-link consume any extra licence on Catalyst Center?

No. It's a feature of OSPF + MPLS L3VPN that's available on any IOS XE image with the Network Advantage tier.

What CPU overhead should I expect?

Negligible, sham-link is one OSPF adjacency per VRF per site pair. Even at 50 VRFs the overhead is under 2% on a modern ASR or Catalyst.

Related guides worth a look while you sort this one out:

References

Cost and licensing, honestly

The Catalyst Center (DNAC) hardware cost is only one third of the real bill. In India in 2026 you should also budget for: SmartNet TAC support (₹85,000 to ₹2,00,000 per chassis per year depending on tier, 8x5xNBD vs 24x7x4), a DNA Advantage or Network Advantage subscription (₹40k-₹85k per device per year if you want Catalyst Center features), and the implementation hours from your integrator. A Redington or Ingram Micro distribution invoice for a 6-site MPLS turn-up usually lands between ₹18 lakh and ₹26 lakh end-to-end. hardware, licences, install, and post-go-live support for 90 days. If your customer asks for a US-dollar equivalent for a global parent budget, that's roughly USD 22,000 to USD 31,000 at current rates.

Lab it before you ship it

Every change like this should hit a lab first. I run mine in CML 2.7 (Cisco Modeller Labs) with a 4-node MPLS core and 2 PE / 2 CE topology. For SD-WAN scenarios I add a vManage instance and a pair of vEdges. The lab catches the silly mistakes, typos in the RT, forgotten address-family activation, missing mpls ip on the core interface. If you don't have CML, Cisco's dCloud has free MPLS L3VPN sandboxes that work for proof-of-config exercises. I tell every junior engineer: spend the 90 minutes labbing the config you're about to push at 11 PM on a Saturday. The lab time is cheaper than the rollback time.

Monitoring after go-live

For the first 72 hours after a cutover I want every %LINEPROTO-5-UPDOWN, %BGP-5-ADJCHANGE, %OSPF-5-ADJCHG, and %LDP-5-NBRCHG piped to a syslog server with a 30-day retention. I usually push them through ELK or Cisco's Stealthwatch if the customer owns it. For longer-term health I rely on Catalyst Center's Assurance dashboard: it spots flap patterns I'd miss eyeballing logs. If something does flap during the warranty period, the SmartNet TAC engineer always wants the pre-change config, the post-change config, and the show tech-support output. Save those three on the bastion before you walk away.

One last note from the field

Cisco IOS XE Stack-Wise V1/V2 mismatch will bite you on Catalyst stacks the first time you do a mid-life refresh, verify the stack version on every member with show switch stack-ring speed before touching MPLS or LDP config. On a Catalyst Center (DNAC), the lesson I've drilled into every L2 I've trained: read the logs, capture the show output, and never push a route-target change without an exit-strategy. I've seen engineers spend 4 hours chasing a 'BGP not coming up' ticket that turned out to be a misplaced space in a route-map name. If you've got a real-world controller / orchestrator story or a war story from a turn-up that went sideways, I read every email at pandralasaikiran@gmail.com. Configs get faster every year. Care for the network you run does not.