Configuring an OSPF Sham Link

This section describes how to configure the routes that traverse the MPLS VPN backbone network to be the routes of the OSPF area. After the configuration, traffic between sites of the same VPN in the same OSPF area need not be forwarded through routes of the OSPF area.

Pre-configuration Tasks

Before configuring an OSPF sham link, complete the following tasks:

Configure basic BGP/MPLS IP VPN functions (OSPF between the PE and CE). For details, see Configuring Basic BGP/MPLS IP VPN Functions.
Configure OSPF in the LANs where the CE devices are located.

Context

OSPF sham links are unnumbered P2P links between two PEs over an BGP/MPLS IP VPN backbone network. Generally, BGP extended community attributes carry routing information over the BGP/MPLS IP VPN backbone between BGP peers. OSPF running on the other PE can use the routing information to generate inter-area routes from PEs to CEs.

If an intra-area OSPF link exists between the network segments of local and remote CEs on the BGP/MPLS IP VPN backbone network. Routes that pass through the intra-area route link and have higher preferences than inter-area routes that pass through the MPLS VPN backbone network. As a result, VPN traffic is always forwarded through the intra-area route instead of the backbone network. To avoid such a problem, an OSPF sham link can be established between PEs so that the routes that pass through the MPLS VPN backbone network also become OSPF intra-area routes and take precedence.

Perform the following steps on the PE devices at both ends of a sham link.

Procedure

Configure an endpoint address for the sham link.

Each VPN instance must have an endpoint address of the sham link. The endpoint address is a loopback interface address with a 32-bit mask in the VPN address space on a PE device. Multiple sham links of the same OSPF process share an endpoint address, but sham links of different OSPF processes cannot have the same endpoint address.
1. Run system-view
  
  The system view is displayed.
2. Run interface loopback interface-number
  
  A loopback interface is created and the loopback interface view is displayed.
3. Run ip binding vpn-instance vpn-instance-name
  
  The loopback interface is bound to a VPN instance.
4. Run ip address ip-address { mask | mask-length }
  
  An IP address is assigned to the loopback interface.
  
  The loopback interface address must have a 32-bit mask, 255.255.255.255.
Advertise routes of the sham link endpoint address.
1. Run system-view
  
  The system view is displayed.
2. Run bgp { as-number-plain | as-number-dot }
  
  The BGP view is displayed.
3. Run ipv4-family vpn-instance vpn-instance-name
  
  The BGP-VPN instance IPv4 address family view is displayed.
4. Run import-route direct
  
  Direct routes are imported to BGP. (The route of the sham link endpoint address is imported to BGP).
  
  BGP advertises the sham link endpoint address as a VPN IPv4 address.
  
  The route of the sham link endpoint address cannot be advertised to the peer PE through an OSPF process bound to a VPN instance.
  
  If the route of the sham link endpoint address is advertised to the peer PE through an OSPF process bound to a VPN instance, the peer PE has two routes to the sham link endpoint address. One route is learned from the OSPF process, and the other is learned from MP-BGP. The OSPF route takes precedence over the BGP route, so the peer PE uses the OSPF route. As a result, the sham link fails to be established.
Create a sham link.
1. Run system-view
  
  The system view is displayed.
2. Run ospf process-id [ router-id router-id ] vpn-instance vpn-instance-name
  
  The OSPF view is displayed.
3. Run area area-id
  
  The OSPF area view is displayed.
4. Run sham-link source-ip-address destination-ip-address [ [ simple [ plain plain-text | [ cipher ] cipher-text ] | { md5 | hmac-md5 | hmac-sha256 } [ key-id { plain plain-text | [ cipher ] cipher-text } ] | authentication-null | keychain keychain-name ] | smart-discover | cost cost | dead dead-interval | hello hello-interval | retransmit retransmit-interval | trans-delay trans-delay-interval ] ^*
  
  A sham link is configured.
  The default settings of the parameters in the command are as follows:
  - cost (sham link interface cost): 1
  - dead-interval (sham link timeout interval): 40 seconds
  - hello-interval (interval for sending Hello packets on the sham link interface): 10 seconds
  - retransmit-interval (LSA packet retransmission interval on the sham link interface): 5 seconds
  - trans-delay-interval (delay in sending LSA packets on the sham link interface): 1 second
  Both ends of the sham link must use the same packet authentication method. If packet authentication is configured, the PE devices accept only the OSPF packets that pass the authentication. If packets fail the authentication, the neighbor relationship cannot be established between the PE devices.
  
  If simple-text authentication (simple) is used, the authentication key type is plain by default. If the MD5 or HMAC-MD5 authentication (md5 | hmac-md5) is used, the authentication key type is cipher by default.
  
  Simple authentication, MD5 authentication and HMAC-MD5 authentication have potential security risks. Therefore, HMAC-SHA256 authentication is recommended.
  
  To forward VPN traffic over the MPLS backbone network, ensure that the cost of the sham link is smaller than the cost of the OSPF route used for forwarding VPN traffic over the customer network. A commonly used method is to set the cost of the forwarding interface on the customer network to be larger than the cost of the sham link.

Verifying the Configuration

After configuring an OSPF sham link, you can check the routing table on a CE, trace the nodes that data packets pass through from local CE to the remote CE, and check whether the sham link is successfully established on the PE.

Run the display ip routing-table vpn-instance vpn-instance-name command on the PE to check the VPN routing table. You can see from the VPN routing table that the route from the PE to the remote CE is an OSPF route that passes through the customer network but not a BGP route that passes through the backbone network.
Run the display ip routing-table and tracert host commands on a CE, and you can find that the VPN traffic from the local CE to the remote CE is forwarded through the backbone network.
Run the display ospf process-id sham-link [ area area-id ] command on the PE to check whether the sham link is established successfully. You can find that the OSPF neighbor relationship between the PE and the remote CE is Full.
Run the display ospf routing on the CE, and you can find that the route to the remote CE is an intra-area route.