How to configure MPLS L3VPN OSPF sham-link on FTD
By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-30
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 FTD (Firepower Threat Defense) acting as the security 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 FTD (Firepower Threat Defense) 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
- FTD (Firepower Threat Defense) on a tested image: minimum IOS XE 17.6.5 for production, 17.9.4 if you want a current LTS.
- Bastion access with Putty 0.78 or SecureCRT 9.4, TACACS+ logged.
- Cisco DNA Center or Catalyst Center for inventory + topology if you have it; not mandatory.
- Wireshark 4.2 on the engineer laptop for control-plane capture when things misbehave.
- A SmartNet entitlement that covers TAC (₹85,000-2,00,000 annual depending on the SKU and tier).
- Pre-change ticket approved, peer-review done, rollback documented.
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 FTD (Firepower Threat Defense) 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 Mumbai pharma customer that had a FTD (Firepower Threat Defense) as their primary WAN edge and a fibre + MPLS dual-uplink to Mumbai. 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. Comsys Mumbai did the kit logistics; we did the config from a Putty 0.78 session on bastion.
Gotchas I keep running into
- Sham-link endpoints not reachable through VRF. Bind the endpoint loopback to the VRF with
ip vrf forwarding CUST_A. A sham-link only works if both endpoints are routable inside the VRF via MP-BGP. - Backdoor still preferred after sham-link comes up. Sham-link cost is per-area. Raise the cost on the backdoor link or lower the sham-link cost so the SP path wins SPF.
- Adjacency stuck in EXSTART. MTU mismatch on the underlying virtual link or auth-key mismatch. Set
ip ospf mtu-ignorefor proof, then chase the real MTU. - Authentication failures. If you've set message-digest auth on the area, the sham-link inherits it. Verify the key-id matches both ends.
- Sham-link flaps every few minutes. Underlying VPNv4 BGP convergence is slow: usually because route-reflectors are overloaded.
show bgp vpnv4 unicast all summary | inc Estaband check uptime.
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 FTD (Firepower Threat Defense) sitting at the next-gen firewall + IPS, 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 fixes
Related guides worth a look while you sort this one out:
- How to configure MPLS L3VPN OSPF sham-link on AnyConnect Secure Client
- How to configure MPLS L3VPN OSPF sham-link on ASR 1000
- How to configure MPLS L3VPN OSPF sham-link on Catalyst 8300/8500
- How to configure MPLS L3VPN OSPF sham-link on Catalyst 9200
- How to configure MPLS L3VPN OSPF sham-link on Catalyst 9300
- How to configure MPLS L3VPN OSPF sham-link on Catalyst 9400
References
- Cisco IOS XE MPLS L3VPN configuration guide for your release train.
- Product-specific release notes for FTD (Firepower Threat Defense) on Cisco.com.
- RFC 4364 (BGP/MPLS IP VPNs) for the protocol baseline.
- Cisco TAC bulletins via SmartNet portal.
- Local integrator notes: Comsys Mumbai and Redington / Ingram Micro for India-specific kit availability and GeM tender pricing.
Cost and licensing, honestly
The FTD (Firepower Threat Defense) 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 FTD (Firepower Threat Defense), 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 next-gen firewall + IPS 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.