Cisco Aironet 1400 Series User manual

1
Cisco IOS Release 12.2(8)T
OSPF Sham-Link Support for MPLS VPN
Feature History
This document describes how to configure and use a sham-link to connect Virtual Private Network
(VPN) client sites that run the Open Shortest Path First (OSPF) protocol and share backdoor OSPF links
in a Multiprotocol Label Switching (MPLS) VPN configuration.
This document includes the following sections:
•Feature Overview, page 1
•Supported Platforms, page 8
•Supported Standards, MIBs, and RFCs, page 10
•Prerequisites, page 10
•Configuration Tasks, page 10
•Configuration Examples, page 12
•Command Reference, page 12
•Glossary, page 16
Feature Overview
Using OSPF in PE-CE Router Connections
In an MPLS VPN configuration, the OSPF protocol is one way you can connect customer edge (CE) routers
to service provider edge (PE) routers in the VPN backbone. OSPF is often used by customers that run OSPF
as their intrasite routing protocol, subscribe to a VPN service, and want to exchange routing information
between their sites using OSPF (during migration or on a permanent basis) over an MPLS VPN backbone.
Figure 1 shows an example of how VPN client sites that run OSPF can connect over an MPLS VPN
backbone.
Release Modification
12.2(8)T This feature was introduced.

OSPF Sham-Link Support for MPLS VPN
Feature Overview
2
Cisco IOS Release 12.2(8)T
Figure 1 OSPF Connectivity Between VPN Client Sites and an MPLS VPN Backbone
When OSPF is used to connect PE and CE routers, all routing information learned from a VPN site is placed
in the VPN routing and forwarding (VRF) instance associated with the incoming interface. The PE routers
that attach to the VPN use the Border Gateway Protocol (BGP) to distribute VPN routes to each other. A CE
router can then learn the routes to other sites in the VPN by peering with its attached PE router. The MPLS
VPN superbackbone provides an additional level of routing hierarchy to interconnect the VPN sites running
OSPF.
When OSPF routes are propagated over the MPLS VPN backbone, additional information about the prefix in
the form of BGP extended communities (route type, domain ID extended communities) is appended to the
BGP update. This community information is used by the receiving PE router to decide the type of link-state
advertisement (LSA) to be generated when the BGP route is redistributed to the OSPF PE-CE process. In this
way, internal OSPF routes that belong to the same VPN and are advertised over the VPN backbone are seen
as interarea routes on the remote sites.
For basic information about how to configure an MPLS VPN, refer to:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/vpn.htm
Using a Sham-Link to Correct OSPF Backdoor Routing
Although OSPF PE-CE connections assume that the only path between two client sites is across the MPLS
VPN backbone, backdoor paths between VPN sites (shown in grey in Figure 2) may exist. If these sites
belong to the same OSPF area, the path over a backdoor link will always be selected because OSPF prefers
intraarea paths to interarea paths. (PE routers advertise OSPF routes learned over the VPN backbone as
interarea paths.) For this reason, OSPF backdoor links between VPN sites must be taken into account so that
routing is performed based on policy.
MPLS VPN
Superbackbone
Area 1Area 1
Area 0
Area 3
Area 2
Area 0
70390

OSPF Sham-Link Support for MPLS VPN Feature Overview
3
Cisco IOS Release 12.2(8)T
Figure 2 Backdoor Paths Between OSPF Client Sites
For example, Figure 2 shows three client sites, each with backdoor links. Because each site runs OSPF within
the same Area 1 configuration, all routing between the three sites follows the intraarea path across the
backdoor links, rather than over the MPLS VPN backbone.
The following example shows BGP routing table entries for the prefix 10.3.1.7/32 in the PE-1 router in
Figure 2. This prefix is the loopback interface of the Winchester CE router. As shown in bold in this example,
the loopback interface is learned via BGP from PE-2 and PE-3. It is also generated through redistribution into
BGP on PE-1.
PE-1# show ip bgp vpnv4 all 10.3.1.7
BGP routing table entry for 100:251:10.3.1.7/32, version 58
Paths: (3 available, best #2)
Advertised to non peer-group peers:
10.3.1.2 10.3.1.5
Local
10.3.1.5 (metric 30) from 10.3.1.5 (10.3.1.5)
Origin incomplete, metric 22, localpref 100, valid, internal
Extended Community: RT:1:793 OSPF DOMAIN ID:0.0.0.100 OSPF
RT:1:2:0 OSPF 2
Local
10.2.1.38 from 0.0.0.0 (10.3.1.6)
Origin incomplete, metric 86, localpref 100, weight 32768,
valid, sourced, best
Extended Community: RT:1:793 OSPF DOMAIN ID:0.0.0.100 OSPF
RT:1:2:0 OSPF 2
Local
10.3.1.2 (metric 30) from 10.3.1.2 (10.3.1.2)
Origin incomplete, metric 11, localpref 100, valid, internal
Extended Community: RT:1:793 OSPF DOMAIN ID:0.0.0.100 OSPF
RT:1:2:0 OSPF 2
Within BGP, the locally generated route (10.2.1.38) is considered to be the best route. However, as shown in
bold in the next example, the VRF routing table shows that the selected path is learned via OSPF with a next
hop of 10.2.1.38, which is the Vienna CE router.
MPLS VPN Backbone
Area 1
Winchester
10.3.1.7
Brighton
70391
PE-3
10.3.1.2
PE-2
10.3.1.5
PE-1
10.3.1.6
Area 1
Stockholm
10.3.1.3
Area 1 Vienna
10.3.1.15

OSPF Sham-Link Support for MPLS VPN
Feature Overview
4
Cisco IOS Release 12.2(8)T
PE-1# show ip route vrf ospf 10.3.1.7
Routing entry for 10.3.1.7/32
Known via "ospf 100", distance 110, metric 86, type intra area
Redistributing via bgp 215
Advertised by bgp 215
Last update from 10.2.1.38 on Serial0/0/0, 00:00:17 ago
Routing Descriptor Blocks:
* 10.2.1.38, from 10.3.1.7, 00:00:17 ago, via Serial0/0/0
Route metric is 86, traffic share count is 1
This path is selected because:
•The OSPF intra-area path is preferred over the interarea path (over the MPLS VPN backbone)
generated by the PE-1 router.
•OSPF has a lower administrative distance (AD) than internal BGP (BGP running between routers in
the same autonomous system).
If the backdoor links between sites are used only for backup purposes and do not participate in the VPN
service, then the default route selection shown in the preceding example is not acceptable. To reestablish the
desired path selection over the MPLS VPN backbone, you must create an additional OSPF intra-area (logical)
link between ingress and egress VRFs on the relevant PE routers. This link is called a sham-link.
A sham-link is required between any two VPN sites that belong to the same OSPF area and share an OSPF
backdoor link. If no backdoor link exists between the sites, no sham-link is required.
Figure 3 shows a sample sham-link between PE-1 and PE-2. A cost is configured with each sham-link and is
used to decide whether traffic will be sent over the backdoor path or the sham-link path. When a sham-link
is configured between PE routers, the PEs can populate the VRF routing table with the OSPF routes learned
over the sham-link.

OSPF Sham-Link Support for MPLS VPN Feature Overview
5
Cisco IOS Release 12.2(8)T
Figure 3 Using a Sham-Link Between PE Routers to Connect OSPF Client Sites
Because the sham-link is seen as an intra-area link between PE routers, an OSPF adjacency is created and
database exchange (for the particular OSPF process) occurs across the link. The PE router can then flood
LSAs between sites from across the MPLS VPN backbone. As a result, the desired intra-area connectivity is
created.
The section, “Creating a Sham-Link”, describes how to configure a sham-link between two PE routers.
For more information about how to configure OSPF, refer to:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/np1_c/1cprt1/1cospf.htm
Sham-Link Configuration Example
The example in this section is designed to show how a sham-link is used only to affect the OSPF intra-area
path selection of the PE and CE routers. The PE router also uses the information received from MP-BGP to
set the outgoing label stack of incoming packets, and to decide to which egress PE router to label switch the
packets.
Figure 4showsasampleMPLSVPNtopologyinwhichasham-linkconfigurationisnecessary.AVPNclient
hasthreesites,eachwithabackdoorlink.Two sham-links have been configured, onebetweenPE-1 and PE-2,
and another between PE-2 and PE-3. A sham-link between PE-1 and PE-3 is not necessary in this
configuration because the Vienna and Winchester sites do not share a backdoor link.
MPLS VPN Backbone
Area 1
Winchester
10.3.1.7
Brighton
70392
Net=10.3.1.7
Type-1 LSA
PE-3
10.3.1.2
MP-BGP
Area 1
Stockholm
10.3.1.3
Net=10.3.1.7
Type-1 LSA
Area 1 Vienna
10.3.1.15
Net=10.3.1.7
Type-1 LSA
Net=10.3.1.7
Route-type 1:2:0
Net=10.3.1.7
Route-type 1:2:0
Sham-linkSham-link PE-2
10.3.1.5
PE-1
10.3.1.6

OSPF Sham-Link Support for MPLS VPN
Feature Overview
6
Cisco IOS Release 12.2(8)T
Figure 4 Sham-Link Example
The following example shows the forwarding that occurs between sites from the standpoint of how PE-1
views the 10.3.1.7/32 prefix, the loopback1 interface of the Winchester CE router in Figure 4.
PE-1# show ip bgp vpnv4 all 10.3.1.7
BGP routing table entry for 100:251:10.3.1.7/32, version 124
Paths: (1 available, best #1)
Local
10.3.1.2 (metric 30) from 10.3.1.2 (10.3.1.2)
Origin incomplete, metric 11, localpref 100, valid, internal,
best
Extended Community: RT:1:793 OSPF DOMAIN ID:0.0.0.100 OSPF
RT:1:2:0 OSPF 2
PE-1# show ip route vrf ospf 10.3.1.7
Routing entry for 10.3.1.7/32
Known via "ospf 100", distance 110, metric 13, type intra area
Redistributing via bgp 215
Last update from 10.3.1.2 00:12:59 ago
Routing Descriptor Blocks:
10.3.1.2 (Default-IP-Routing-Table), from 10.3.1.7, 00:12:59 ago
The next example shows forwarding information in which the next hop for the route, 10.3.1.2, is the PE-3
router rather than the PE-2 router (which is the best path according to OSPF). The reason the OSPF route is
not redistributed to BGP on the PE is because the other end of the sham-link already redistributed the route
to BGP and there is no need for duplication. The OSPF sham-link is used only to influence intra-area path
selection. When sending traffic to a particular destination, the PE router uses the MP-BGP forwarding
information.
PE-1# show ip bgp vpnv4 all tag | begin 10.3.1.7
10.3.1.7/32 10.3.1.2 notag/38
PE-1# show tag-switching forwarding 10.3.1.2
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
31 42 10.3.1.2/32 0 PO3/0/0 point2point
MPLS VPN Backbone
Area 1
Winchester
10.3.1.7
Brighton
70393
PE-3
10.3.1.2
PE-2
10.3.1.5
PE-1
10.3.1.6
Sham-link
Sham-link
Area 1
Stockholm
10.3.1.3
Area 1 Vienna
10.3.1.15

OSPF Sham-Link Support for MPLS VPN Feature Overview
7
Cisco IOS Release 12.2(8)T
PE-1# show ip cef vrf ospf 10.3.1.7
10.3.1.7/32, version 73, epoch 0, cached adjacency to POS3/0/0
0 packets, 0 bytes
tag information set
local tag: VPN-route-head
fast tag rewrite with PO3/0/0, point2point, tags imposed: {42 38}
via 10.3.1.2, 0 dependencies, recursive
next hop 10.1.1.17, POS3/0/0 via 10.3.1.2/32
valid cached adjacency
tag rewrite with PO3/0/0, point2point, tags imposed: {42 38}
If a prefix is learned across the sham-link and the path via the sham-link is selected as the best, the PE router
does not generate an MP-BGP update for the prefix. It is not possible to route traffic from one sham-link over
another sham-link.
In the following example, PE-2 shows how an MP-BGP update for the prefix is not generated. Although
10.3.1.7/32 has been learned via OSPF across the sham-link as shown in bold, no local generation of a route
into BGP is performed. The only entry within the BGP table is the MP-BGP update received from PE-3 (the
egress PE router for the 10.3.1.7/32 prefix).
PE-2# show ip route vrf ospf 10.3.1.7
Routing entry for 10.3.1.7/32
Known via "ospf 100", distance 110, metric 12, type intra area
Redistributing via bgp 215
Last update from 10.3.1.2 00:00:10 ago
Routing Descriptor Blocks:
* 10.3.1.2 (Default-IP-Routing-Table), from 10.3.1.7, 00:00:10 ago
Route metric is 12, traffic share count is 1
PE-2# show ip bgp vpnv4 all 10.3.1.7
BGP routing table entry for 100:251:10.3.1.7/32, version 166
Paths: (1 available, best #1)
Not advertised to any peer
Local
10.3.1.2 (metric 30) from 10.3.1.2 (10.3.1.2)
Origin incomplete, metric 11, localpref 100, valid, internal,
best
Extended Community: RT:1:793 OSPF DOMAIN ID:0.0.0.100 OSPF
RT:1:2:0 OSPF 2
The PE router uses the information received from MP-BGP to set the ongoing label stack of incoming
packets, and to decide to which egress PE router to label switch the packets.
Benefits
Client Site Connection Across the MPLS VPN Backbone
A sham-link overcomes the OSPF default behavior for selecting an intra-area backdoor route between VPN
sites instead of an interarea (PE-to-PE) route. A sham-link ensures that OSPF client sites that share a
backdoor link can communicate over the MPLS VPN backbone and participate in VPN services.
Flexible Routing in an MPLS VPN Configuration
In an MPLS VPN configuration, the OSPF cost configured with a sham-link allows you to decide if OSPF
client site traffic will be routed over a backdoor link or through the VPN backbone.

OSPF Sham-Link Support for MPLS VPN
Supported Platforms
8
Cisco IOS Release 12.2(8)T
Restrictions
When OSPF is used as a protocol between PE and CE routers, the OSPF metric is preserved when routes
are advertised over the VPN backbone. The metric is used on the remote PE routers to select the correct
route. For this reason, you should not modify the metric value when OSPF is redistributed to BGP, and
when BGP is redistributed to OSPF. If you modify the metric value, routing loops may occur.
Related Features and Technologies
•MPLS
•OSPF
•BGP
Related Documents
•Cisco IOS Configuration Fundamentals Configuration Guide, Release 12.2
•Cisco IOS Configuration Fundamentals Command Reference, Release 12.2
•Cisco IOS IP Command Reference, Volume 2 of 3: Routing Protocols, Release 12.2
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fiprrp_r/1rfospf.htm
•MPLS Virtual Private Networks
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/vpn.htm
•Configuring OSPF
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcprt2/1cfospf.
htm
•Configuring BGP
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcprt2/1cfbgp.h
tm
•RFC 1163, A Border Gateway Protocol
•RFC 1164, Application of the Border Gateway Protocol in the Internet
•RFC 2283, Multiprotocol Extensions for BGP-4
•RFC 2328, Open Shortest Path First, Version 2
•RFC 2547, BGP/MPLS VPNs
Supported Platforms
•Cisco 1400 series
•Cisco 1600
•Cisco 1600R
•Cisco 1710
•Cisco 1720

OSPF Sham-Link Support for MPLS VPN Supported Platforms
9
Cisco IOS Release 12.2(8)T
•Cisco 1721
•Cisco 1750
•Cisco 1751
•Cisco 2420
•Cisco 2600
•Cisco 2691
•Cisco 3620
•Cisco 3631
•Cisco 3640
•Cisco 3660
•Cico 3725
•Cisco 3745
•Cisco 7100
•Cisco 7200
•Cisco 7500
•Cisco 7700
•URM
•Cisco uBR7200
Determining Platform Support Through Cisco Feature Navigator
Cisco IOS software is packaged in feature sets that support specific platforms. To get updated
information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature
Navigator dynamically updates the list of supported platforms as new platform support is added for the
feature.
Cisco Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS
software images support a specific set of features and which features are supported in a specific
Cisco IOS image. You can search by feature or release. Under the release section, you can compare
releases side by side to display both the features unique to each software release and the features in
common.
To access Cisco Feature Navigator, you must have an account on Cisco.com. If you have forgotten or
lost your account information, send a blank e-mail to [email protected]. An automatic check
will verify that your e-mail address is registered with Cisco.com. If the check is successful, account
details with a new random password will be e-mailed to you. Qualified users can establish an account on
Cisco.com by following the directions at http://www.cisco.com/register.
Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology
releases occur. For the most current information, go to the Cisco Feature Navigator home page at the
following URL:
http://www.cisco.com/go/fn

OSPF Sham-Link Support for MPLS VPN
Supported Standards, MIBs, and RFCs
10
Cisco IOS Release 12.2(8)T
Supported Standards, MIBs, and RFCs
Standards
No new or modified standards are supported by this feature.
MIBs
No new or modified MIBs are supported by this feature.
To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules,
go to the Cisco MIB website on Cisco.com at the following URL:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
RFCs
No new or modified RFCs are supported by this feature.
Prerequisites
Before you can configure a sham-link in an MPLS VPN, you must first enable OSPF as follows:
•Create an OSPF routing process.
•Specify the range of IP addresses to be associated with the routing process.
•Assign area IDs to be associated with the range of IP addresses.
For more information on these OSPF configuration procedures, go to:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fiprrp_r/1rfospf.htm
Configuration Tasks
See the following sections for configuration tasks for the sham-link feature. Each task in the list is
identified as either required or optional.
•Creating a Sham-Link (required)
•Verifying Sham-Link Creation (optional)
Creating a Sham-Link
Before you create a sham-link between PE routers in an MPLS VPN, you must:
•Configure a separate /32 address on the remote PE so that OSPF packets can be sent over the VPN
backbone to the remote end of the sham-link. The /32 address must meet the following criteria:
– Belong to a VRF.
– Not be advertised by OSPF.
– Be advertised by BGP.
You can use the /32 address for other sham-links.
•Associate the sham-link with an existing OSPF area.