Routing Configuration Guide, Cisco Catalyst SD-WAN Releases 17.x

PDF

Configure route leaking

Updated: February 6, 2026

Overview

Enables route replication between logical segments to support service sharing and network migration. This task guides you through configuring localized policies and attaching VPN templates to ensure that specific routes are correctly leaked and reachable across the overlay.

Use this task to enable route leaking within your Cisco Catalyst SD-WAN. Route leaking allows for service sharing between different VPNs and facilitates network migration by providing direct access between migrated and non-migrated branches.

Before you begin

Before you begin, ensure you understand the concepts of route leaking and have reviewed the associated restrictions. For more information, see Route leaking and Restrictions for route leaking and redistribution.

Follow these steps to configure route leaking:

Procedure

1.

Configure and enable a localized policy, then attach the route policy.

  1. Configure localized route policy. See Configure localized route policy.

  2. Add the route policy. See Add the route policy

  3. Attach the localized policy to the device template. See Attach the localized policy to the device template.
2.

Configure and enable the route leaking feature between global and service VPNs.

  1. Configure and enable route leaking between global and service VPNs using a configuration group. See Configure and enable route leaking between global and service VPNs using a configuration group.

  2. Configure and enable route leaking between global and service VPNs using Cisco SD-WAN Manager. See Configure and enable route leaking between global and service VPNs using Cisco SD-WAN Manager.

  3. Configure and verify route leaking between global VRF and service VPNs using the CLI. See Configure and verify route leaking between global VRF and service VPNs using the CLI.
3.

Configure and enable the route leaking feature between service VPNs.

  1. Configure route leaking between service VPNs using a configuration group. See Configure route leaking between service VPNs using a configuration group.

  2. Configure route leaking between service VPNs using Cisco SD-WAN Manager. See Configure route leaking between service VPNs using Cisco SD-WAN Manager.

  3. Configure route leaking between service VPNs using a CLI template. See Configure route leaking between service VPNs using a CLI template.

  4. Verify route-leaking configurations between service VPNs using the CLI. See Verify route-leaking configurations between service VPNs using the CLI.

  5. Configure VRRP tracker for tracking leaked service VPNs using the CLI. See Configure VRRP tracker for tracking leaked service VPNs using the CLI.

  6. Verify VRRP tracking. See Verify VRRP tracking.
4.

Attach the service side VPN feature template to the device template. See Attach the service side VPN feature template to the device template.

You have successfully configured route leaking in your Cisco Catalyst SD-WAN, enabling service sharing and optimizing routing paths.

What to do next

To view a configuration example for route leaking, see Configuration example for route leaking.

Configure localized route policy

Use this task to create a new localized route policy that defines how routes are handled within your Cisco Catalyst SD-WAN.

.

Before you begin

Follow these steps to configure localized route policy:

Procedure

1.

From the Cisco SD-WAN Manager menu, choose Configuration > Policies.

2.

Select Localized Policy.

3.

From the Custom Options drop-down, under Localized Policy, select Route Policy.

4.

Click Add Route Policy, and select Create New.
5.

Enter a name and description for the route policy.
6.

In the left pane, click Add Sequence Type.
7.

In the right pane, click Add Sequence Rule to create a single sequence in the policy. Match is selected by default.

8.

Select a desired protocol from the Protocol drop-down list. The options are: IPv4, IPv6, or both.

9.

Click a match condition.
10.

On the left, enter the values for the match condition.
11.

On the right enter the action or actions to take if the policy matches.
12.

Click Save Match and Actions to save a sequence rule.
13.

If no packets match any of the route policy sequence rules, the default action is to drop the packets. To change the default action:

  1. Click Default Action in the left pane.

  2. Click the Pencil icon.

  3. Change the default action to Accept.

  4. Click Save Match and Actions.
14.

Click Save Route Policy.

You have successfully created a localized route policy.

What to do next

Add the route policy. See Add the route policy.

Add the route policy

Use this task to import an existing route policy into your localized policy configuration.

Before you begin

Follow these steps to add the route policy:

Procedure

1.

From the Cisco SD-WAN Manager menu, choose Configuration > Policies.
2.

Choose the Localized Policy.
3.

Click Add Policy.
4.

Click Next in the Local Policy Wizard until you arrive at the Configure Route Policy option.
5.

Click Add Route Policy and choose Import Existing.
6.

From the Policy drop-down list, choose the route policy that you created previously.

7.

Click Import.
8.

Click Next.
9.

Enter the Policy Name and Description for this localized policy.
10.

Click Preview to view the policy configurations in CLI format.
11.

Click Save Policy.

You have successfully added the route policy to your localized policy configuration.

What to do next

Attach the localized policy to the device template to apply it to your network devices. For more information, see Attach the localized policy to the device template.

Attach the localized policy to the device template

Use this task to apply a previously configured localized policy to a device template.

Before you begin

Follow these steps to attach the localized policy to the device template:

Procedure

1.

From the Cisco SD-WAN Manager menu, choose Configuration > Templates.
2.

Click Device Templates and select the desired template.
3.

Click …, and click Edit.
4.

Click Additional Templates.
5.

From the Policy drop-down list, choose the Localized Policy that you created.
6.

Click Update.

Note

Once the localized policy has been added to the device template, selecting the Update option immediately pushes a configuration change to all of the devices that are attached to this device template. If more than one device is attached to the device template, you will receive a warning that they are changing multiple devices.
7.

Click Next and then Configure Devices.
8.

Wait for the validation process and push configuration from Cisco SD-WAN Manager to the device.

You have successfully attached the localized policy to the device template, and the configuration has been pushed to the associated devices.

What to do next

Now that the localized policy is applied, you can proceed to configure and enable the route leaking feature between global and service VPNs. For more information, see step 2 in Configure route leaking.

Configure and enable route leaking between global and service VPNs using a configuration group

Use this task to configure route leaking between the global VRF and service VPNs using a configuration group in Cisco SD-WAN Manager. This method allows for centralized management and deployment of route leaking policies across multiple devices.

Before you begin

Follow these steps to configure and enable route leaking between global and service VPNs using a configuration group:

Procedure

1.

From the Cisco SD-WAN Manager menu, choose Configuration > Configuration Groups.

2.

Create and configure a Service VPN feature from a Service profile.

  1. To leak routes from the global VRF:

    1. In the Route Protocol* field, choose a protocol to configure leak routes from the global VPN to the service VPN that you are configuring. Options include static, connected, bgp, or ospf.

    2. In the Select Route Policy field, choose a route policy from the drop-down list.

    3. Under Redistribution (in service VPN), in the Protocol* field, choose a protocol from the available options to redistribute the leaked routes. Options include bgp, ospf(minimum supported release: Cisco Catalyst SD-WAN Manager Release 20.18.1) , or eigrp.

    4. In the Select Route Policy field, choose a route policy from the drop-down list.

  2. To leak routes from the service VPNs to the global VRF:

    1. In the Route Protocol* field, choose a protocol to leak routes from the service VPN that you are configuring to the global VPN. Options include static, connected, bgp, ospf or eigrp.

    2. In the Select Route Policy field, choose a route policy from the drop-down list.

    3. Under Redistribution (in global VPN), in the Protocol* field, choose a protocol from the available options to redistribute the leaked routes. Options include bgp, or ospf.

    4. In the Select Route Policy field, choose a route policy from the drop-down list.\
3.

Click Save.

You have successfully configured route leaking between the global VRF and service VPNs using a configuration group.

What to do next

Deploy the configuration group to apply these settings to your devices. See Deploy a configuration group.

Configure and enable route leaking between global and service VPNs using Cisco SD-WAN Manager

Use this task to configure and enable route leaking between the global VRF and service VPNs using feature templates in Cisco SD-WAN Manager. This method allows you to define route leaking policies and apply them to specific devices.

Before you begin

Note that route leaking can only be configured on service VPNs. The VPN numbers in the Basic Configuration must be within the range 1—511 or 513—65527. VPN 512 is reserved for network management traffic, and VPN 0 is reserved for control traffic.

Procedure

1.

From the Cisco SD-WAN Manager menu, choose Configuration > Templates.
2.

To configure route leaking, click Feature Templates.

3.

Do one of the following:

  1. To create a feature template:

    1. Click Add Template.

    2. Choose a device from the list of devices. The templates available for the selected device display in the right pane.

    3. Choose the Cisco VPN template from the right pane.

    4. Enter Template Name and Description for the feature template.

    5. Click Global Route Leak below the Description field.

    6. To leak routes from the global VRF, click Add New Route Leak from Global VPN to Service VPN.

      1. From the Route Protocol Leak from Global to Service drop-down list, choose Global to choose a protocol. Otherwise, choose Device-Specific to use a device-specific value.

      2. In the Route Policy Leak from Global to Service drop-down list, choose Global, then select one of the available route policies.

      3. For the Redistribute to protocol (in Service VPN) field, click Add Protocol.

      4. In the Protocol drop-down list, choose Global to select a protocol. Otherwise, choose Device-Specific to use a device-specific value.

      5. In the Redistribution Policy drop-down list, choose Global, then select one of the available redistribution policies.

      6. Click Add.

    7. To leak routes from the service VPNs to the global VRF, click Add New Route Leak from Service VPN to Global VPN.

      1. In the Route Protocol Leak from Service to Global drop-down list, choose Global to select a protocol. Otherwise, or choose Device-Specific to use a device-specific value.

      2. In the Route Policy Leak from Service to Global drop-down list, choose Global, then select one of the available route policies.

      3. For the Redistribute to protocol (in Global VPN) field, click Add Protocol.

      4. From the Protocol drop-down list, choose Global to choose a protocol. Otherwise, choose Device-Specific to use a device-specific value.

      5. In the Redistribution Policy drop-down list, choose Global, then select one of the available redistribution policies.

      6. Click Add.

    8. Click Save/Update.

    9. To redistribute the leaked routes using Cisco SD-WAN Manager, use the CLI Add-on Feature templates to enter the configuration applicable to your environment. Here's an example. 

      
Device(config)# router ospf 65535 
Device(config-router)# redistribute vrf 1 ospf 103  


Device(config)# router eigrp vpn 
Device(config-router)# address-family ipv4 vrf 1 autonomous-system 50 
Device(config-router-af)# topology base 
Device(config-router-af-topology)# redistribute vrf global  ospf 65535 
metric  1 2 3 4 5

      After you create the CLI add-on template, you need to attach it to the protocol template to which you are redistributing routes. In this example, you would attach it to the EIGRP template.

  2. To modify an existing feature template:

    1. Choose a feature template you wish to modify.

    2. Click ... next to the row in the table, and click Edit.

    3. Click Global Route Leak.

    4. To edit information, from the table under Add New Route Leak from Global VPN to Service VPN or Add New Route Leak from Service VPN to Global VPN, click Edit.

    5. The update route leak dialog box appears. Perform the necessary modifications.

    6. Click Save Changes.

    7. Click Update.

You have configured route leaking between the global VRF and service VPNs within the feature template.

What to do next

Attach the service side VPN feature template to the device template to apply these configurations to your network devices. For more information, see Attach the service side VPN feature template to the device template.

Configure and verify route leaking between global VRF and service VPNs using the CLI

Use this task to directly configure and verify route leaking between VRFs using the command-line interface (CLI).\

Before you begin

Follow these steps to configure and verify route leaking using the CLI:

Procedure

1.

Configure and verify route leaking between a global VRF and a service VPN.

  • Configure route leaking.

    These examples show how to configure route leaking between a global VRF and a service VPN. In this example, VRF 103 is the service VPN. This example shows that connected routes are leaked into VRF 103 from the global VRF, similarly, the same connected routes are leaked from VRF 103 to the global VRF.

    vrf definition 103
 !
  address-family ipv4
   route-replicate from vrf global unicast connected
!
global-address-family ipv4
  route-replicate from vrf 103 unicast connected
  exit-address-family

  • Verify route leaking

    1. Verify routes leaked from service VRF 103 to the global VRF. Leaked routes are represented by a + sign next to the route. For example, C+ denotes a leaked connected route.

      Device#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
H - NHRP, G - NHRP registered, g - NHRP registration summary
o - ODR, P - periodic downloaded static route, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
& - replicated local route overrides by connected

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 14 subnets, 2 masks
O 10.1.14.0/24 [110/11] via 10.1.15.13, 00:02:22, GigabitEthernet1
C 10.1.15.0/24 is directly connected, GigabitEthernet1
L 10.1.15.15/32 is directly connected, GigabitEthernet1
O 10.1.16.0/24 [110/11] via 10.1.15.13, 00:02:22, GigabitEthernet1
C 10.1.17.0/24 is directly connected, GigabitEthernet2
L 10.1.17.15/32 is directly connected, GigabitEthernet2
172.16.0.0/12 is subnetted, 1 subnets
[170/10880] via 192.168.24.17(103), 01:04:13, GigabitEthernet5.103
192.168.0.0/16 is variably subnetted, 2 subnets, 2 masks
C + 192.0.2.0/24  is directly connected, GigabitEthernet5.103
L & 192.168.24.15/16 is directly connected, GigabitEthernet5.103
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 203.0.113.0/24 is directly connected, GigabitEthernet6
L 203.0.113.15/32 is directly connected, GigabitEthernet6
10.20.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 198.51.100.0/24 is directly connected, GigabitEthernet7
L 198.51.100.15/24 is directly connected, GigabitEthernet7
192.0.2.0/32 is subnetted, 1 subnets
O E2 100.100.100.100 [110/20] via 10.1.15.13, 00:02:22, GigabitEthernet1
172.16.0.0/32 is subnetted, 1 subnets
O E2 172.16.255.14 [110/20] via 10.1.15.13, 00:02:22, GigabitEthernet1

    2. View Routes Leaked From Global VRF to Service VRF Table

      Use the show ip route vrf <vrf id> command to view the routes leaked from the global VRF to the service VRF table.

      Device#show ip route vrf 103 
Routing Table: 103
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
H - NHRP, G - NHRP registered, g - NHRP registration summary
o - ODR, P - periodic downloaded static route, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
& - replicated local route overrides by connected

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 14 subnets, 2 masks
C + 10.0.1.0/24 is directly connected, GigabitEthernet9
L & 10.0.1.15/32 is directly connected, GigabitEthernet9
C + 10.0.20.0/24 is directly connected, GigabitEthernet4
L & 10.0.20.15/32 is directly connected, GigabitEthernet4
C + 10.0.100.0/24 is directly connected, GigabitEthernet8
L & 10.0.100.15/32 is directly connected, GigabitEthernet8
C + 10.1.15.0/24 is directly connected, GigabitEthernet1
L & 10.1.15.15/32 is directly connected, GigabitEthernet1
C + 10.1.17.0/24 is directly connected, GigabitEthernet2
L & 10.1.17.15/32 is directly connected, GigabitEthernet2
172.16.0.0/12 is subnetted, 1 subnets
D EX 172.16.20.20
[170/10880] via 192.168.24.17, 01:04:07, GigabitEthernet5.103
192.168.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 192.0.2.0/24 is directly connected, GigabitEthernet5.103
L 192.168.24.15/16 is directly connected, GigabitEthernet5.103
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C + 203.0.113.0/24 is directly connected, GigabitEthernet6
L & 203.0.113.15/32 is directly connected, GigabitEthernet6
10.20.0.0/8 is variably subnetted, 2 subnets, 2 masks
C + 198.51.100.0/24 is directly connected, GigabitEthernet7
L & 198.51.100.15/24 is directly connected, GigabitEthernet7
192.0.2.0/32 is subnetted, 1 subnets
2.

Configure and verify route filtering before leaking.

To further filter the routes leaked between the global VRF and the service VRF, you can apply a route map as shown in this example.

vrf definition 103
 !
  address-family ipv4
   route-replicate from vrf global unicast connected route-map myRouteMap permit 10
    match ip address prefix-list pList seq 5 permit 10.1.17.0/24
!
3.

Verify route filtering.

Device#show ip route vrf 103

Routing Table: 1
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
H - NHRP, G - NHRP registered, g - NHRP registration summary
o - ODR, P - periodic downloaded static route, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
& - replicated local route overrides by connected

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
C + 10.1.17.0/24 is directly connected, GigabitEthernet2
L & 10.1.17.15/32 is directly connected, GigabitEthernet2
m 10.1.18.0/24 [251/0] via 172.16.255.14, 19:01:28, Sdwan-system-intf
m 10.2.2.0/24 [251/0] via 172.16.255.11, 17:28:44, Sdwan-system-intf
m 10.2.3.0/24 [251/0] via 172.16.255.11, 17:26:50, Sdwan-system-intf
C 10.20.24.0/24 is directly connected, GigabitEthernet5
L 10.20.24.15/32 is directly connected, GigabitEthernet5
m 10.20.25.0/24 [251/0] via 172.16.255.11, 16:14:18, Sdwan-system-intf
172.16.0.0/32 is subnetted, 3 subnets
m 172.16.255.112 [251/0] via 172.16.255.11, 17:28:44, Sdwan-system-intf
O E2 172.16.255.117 [110/20] via 10.20.24.17, 1d11h, GigabitEthernet5
m 172.16.255.118 [251/0] via 172.16.255.11, 16:14:18, Sdwan-system-intf
4.

Monitor leaked routes.

Device#show ip cef 10.1.17.0 internal
10.1.17.0/24, epoch 2, flags [rcv], refcnt 6, per-destination sharing
[connected cover 10.1.17.0/24 replicated from 1]
sources: I/F
feature space:
Broker: linked, distributed at 4th priority
subblocks:
gsb Connected receive chain(0): 0x7F6B4315DB80
Interface source: GigabitEthernet5 flags: none flags3: none
Dependent covered prefix type cover need deagg, cover 10.20.24.0/24
ifnums: (none)
path list 7F6B47831168, 9 locks, per-destination, flags 0x41 [shble, hwcn]
path 7F6B3D9E7B70, share 1/1, type receive, for IPv4
receive for GigabitEthernet5
output chain:
receive

You have configured and verified route leaking and route filtering using the CLI.

Configure route leaking between service VPNs using a configuration group

Use this task to configure route leaking between different service VPNs using a configuration group in Cisco SD-WAN Manager.

Before you begin

Follow these steps to configure route leaking between service VPNs using a configuration group:

Procedure

1.

From the Cisco SD-WAN Manager menu, choose Configuration > Configuration Groups.

2.

Create and configure a Service VPN feature from a Service profile.

  1. To leak routes between services:

    1. In the Source VPN field, enter the value of the source VPN from which routes will be leaked.

    2. In the Route Protocol* field, choose a protocol from the available options to leak routes from the source service VPN to the service VPN that you are configuring. Options include static, connected, bgp, ospf (minimum supported release: Cisco Catalyst SD-WAN Manager Release 20.18.1), or eigrp.

    3. In the Select Route Policy field, choose a route policy from the drop-down list.

    4. Under Redistribution (in Service VPN), in the Protocol* field, choose a protocol from the available options to redistribute the leaked routes. Options include bgp, ospf minimum supported release: Cisco Catalyst SD-WAN Manager Release 20.18.1, or eigrp.

    5. In the Select Route Policy field, choose a route policy from the drop-down list.
3.

Click Save.

You have configured route leaking between service VPNs using a configuration group.

What to do next

Deploy the configuration group to apply these settings to your devices. See Deploy a configuration group.

Configure route leaking between service VPNs using Cisco SD-WAN Manager

Use this task to configure route leaking directly between service VPNs using feature templates in Cisco SD-WAN Manager.

Before you begin

Follow these steps to configure route leaking between service VPNs:

Procedure

1.

From the Cisco SD-WAN Manager menu, choose Configuration > Templates.
2.

Click Feature Templates.
3.

Navigate to the Cisco VPN template for the device.

Note

To create a VPN template, see Create VPN Template

4.

Click Route Leak.
5.

Click Route Leak between Service VPN.
6.

Click Add New Inter Service VPN Route Leak.
7.

From the Source VPN drop-down list, choose Global to configure the service VPN from where you want to leak the routes, or choose Device-Specific to use a device-specific value.

You can configure service VPNs within the range VPNs 1 to 511, and 513 to 65530, for service-side data traffic on Cisco IOS XE Catalyst SD-WAN devices. (VPN 512 is reserved for network management traffic. VPN 0 is reserved for control traffic using the configured WAN transport interfaces.)

8.

From the Route Protocol Leak to Current VPN drop-down list, choose Global to select a route protocol to enable route leaking to the current VPN. Otherwise, choose Device-Specific to use a device-specific value.

You can choose Connected, Static, OSPF, BGP, and EIGRP protocols for route leaking.
9.

From the Route Policy Leak to Current VPN drop-down list, choose Global to select a route policy to enable route leaking to the current VPN. Otherwise, choose Device-Specific to use a device-specific value.

Note

This field is disabled if no route policies are available.
10.

To configure Redistribute to protocol (in Service VPN), click Add Protocol.

  1. From the Protocol drop-down list, choose Global to choose a protocol. Otherwise, choose Device-Specific to use a device-specific value.

    You can choose Connected, Static, OSPF, BGP, and EIGRP protocols for redistribution.

  2. (Optional) From the Redistribution Policy drop-down list, choose Global. Next, choose one of the available redistribution policies from the drop-down list.

    Note

    This field is disabled if no route policies are available.
11.

Click Add.
12.

Click Save.

You have successfully configured route leaking between service VPNs within the feature template.

What to do next

Attach the service side VPN feature template to the device template to apply these configurations to your network devices. For more information, see Attach the service side VPN feature template to the device template.

Configure route leaking between service VPNs using a CLI template

Use this task to configure route leaking between different service VPNs on the same device using a CLI template.

This topic provides sample CLI configurations to configure interservice VPN route leaking on Cisco IOS XE Catalyst SD-WAN devices.

Before you begin

Ensure your Cisco IOS XE Catalyst SD-WAN device is running Cisco IOS XE Catalyst SD-WAN Release 17.9.1a or later.

Follow these steps to configure inter-service VRF route leaking using a CLI template:

Procedure

1.

Replicate routes between interservice VRFs on the same device..


vrf definition vrf-number 
address-family ipv4 
route-replicate from vrf source-vrf-name unicast protocol [route-map map-tag]
2.

Redistribute the routes that are replicated between the service VPNs:

You can configure the subnets only for bgp, nhrp, ospf, ospfv3, and static protocol types.


router ospf process-id vrf vrf-number 
redistribute vrf vrf-name protocol subnets[route-map map-tag]

The following is a complete configuration example for interservice VRF route replication and redistribution:

vrf definition 2
 rd 1:2
 !
 address-family ipv4
  route-replicate from vrf 1 unicast static route-map VRF1_TO_VRF2
 exit-address-family
 !
!
ip prefix-list VRF1_TO_VRF2 seq 5 permit 10.10.10.97/32
!
route-map VRF1_TO_VRF2 permit 1
 match ip address prefix-list VRF1_TO_VRF2
!
router ospf 2 vrf 2
 redistribute vrf 1 static route-map VRF1_TO_VRF2

You have successfully configured inter-service VRF route leaking using a CLI template.

What to do next

Verify the route leaking configurations. See Verify route-leaking configurations between service VPNs using the CLI.

Configure VRRP tracker for tracking leaked service VPNs using the CLI

Use this task to configure a Virtual Router Redundancy Protocol (VRRP) tracker for monitoring the reachability of leaked routes within service VPNs using the CLI.

Before you begin

Follow these steps to configure a VRRP tracker for tracking leaked service VPNs:

Procedure

1.

Configure a track.

  1. Enter global configuration mode, and track the state of an IP route and enter tracking configuration mode.

    Device# config-transaction 
Device(config)# track object-number {ip} route address|prefix-length  { reachability  | metric threshold}

  2. Configure a VPN routing and forwarding (VRF) table.

    Device(config-track)# ip vrf vrf-name

  3. Return to privileged EXEC mode.

    Device(config-track)# end
2.

Configure VRRP version 2 (VRRPv2).

  1. Configure an interface type such as, Gigabit Ethernet.

    Device(config)# interface type number [name-tag]

  2. Associate a VRF instance with the Gigabit Ethernet interface.

    Device(config-if)# vrf forwarding vrf-name

  3. Set a primary IP address for the Gigabit Ethernet interface.

    Device(config-if)# ip address ip-address [mask]

  4. Enable the autonegotiation protocol to configure the speed, duplex mode, and flow control on a Gigabit Ethernet interface.

    Device(config-if)# negotiation auto

  5. Create a VRRP group and enter VRRP configuration mode.

    Device(config-if)# vrrp group address-family ipv4

  6. Enable the support of VRRP version 2 simultaneously with VRRP version 3. 

    Device(config-if-vrrp)# vrrpv2

  7. Configure interface list tracking as a single entity. 

    Device(config-if-vrrp)# track track-list-name [decrement priority]

  8. Configure the preemption delay so that a device with higher priority waits for a minimum period before taking over.

    Device(config-if-vrrp)# preempt delay minimum seconds

  9. Specify a primary IP address for VRRP.

    Device(config-if-vrrp)# address ip-address primary
3.

Configure a VRF.

  1. Configure a VRF routing table instance and enter the VRF configuration mode.

    Device(config)# vrf definition vrf-number

  2. Set an address family IPv4 in vrf configuration mode.

    Device(config-vrf)# address-family ipv4

  3. Exit from address-family configuration mode.

    Device(config-ipv4)# exit-address-family

The following is a sample configuration for configuring the VRRP tracking.

Use the following configuration to add a track to a VRF red. 

config-transaction
track 1 ip route 10.1.15.13 255.255.255.0 reachability
ip vrf red

Use the following configuration to configure interface tracking and decrement the device priority.

interface GigabitEthernet 1.101
vrf forwarding 100
 ip address 10.1.15.13 255.255.255.0
 negotiation auto
 vrrp 2 address-family ipv4
  vrrpv2
  priority 220
  track 1 decrement 25
  preempt delay minimum 30
  address 10.1.15.100 primary
exit

Use the following configuration to configure the VRF routing table instance for the configured VRF.

vrf definition 100
!
 address-family ipv4
 exit-address-family

You have successfully configured a VRRP track object to monitor the reachability of a leaked route within a service VPN, and integrated it with VRRP on a specified interface.

What to do next

Verify the VRRP tracking configuration. See Verify VRRP tracking.

Configuration example for route leaking

Route leaking is typically used in scenarios requiring the use of shared services. Configuring route replication allows mutual redistribution between VRFs or VPNs. Route replication allows shared services because routes are replicated or leaked between the global VRF and service VPNs, enabling clients in one VPN to reach matching prefixes in another VPN.

Sample Topology

In this section, we'll use an example topology to show route-leaking configuration. Here, Edge routers 1 and 2 are located in two different sites in the overlay network and are connected to each other through MPLS. Both the edge routers have route leaking configured to be able to access services in the underlay network. Router 1 sits behind Edge Router 1 in the service side. The local network at this site runs OSPF. Router 2 sites behind the Edge Router 2 on network that has EIGRP in VRF 1. Router 3 also sites behind Edge Router 2 and has OSPF running in VRF 200.

Figure 1. Route Leaking

Edge Router 1 imports the source IP address of Router 1, 192.0.2.0/24 to the global VRF on Edge Router 1. Thus 192.0.2.0/24 is a route leaked into the global VRF. Edge Router 2 imports the source IP address of Router 2, 198.51.100.0/24 and the source IP address of Edge Router 3, 203.0.113.0/24 to the global VRF on Edge Router 2.

Shared services in the underlay MPLS network are accessed through a loopback address of 209.21.25.18/27. The IP address of the shared services is advertised to the global VRF on Edge Routers 1 and 2 through OSPF. This shared service IP address is then leaked to VRF 1 in Edge Router 1 and VRF 1 and VRF 200 in Edge Router 2. In terms of route-leaking, the leaked routes are imported into the service VRFs on both the edge routers.

Note

OMP doesn't advertise any leaked routes from service VPNs into the overlay network to prevent route looping.

Configuration Examples

This example shows the configuration of BGP and OSPF route leaking between the global VRF and VPN 1 on Edge Router 2.

vrf definition 1
 rd 1:1
 !
  address-family ipv4
   route-replicate from vrf global unicast ospf 65535 
 !
global-address-family ipv4
 route-replicate from vrf 1 unicast eigrp 
 exit-address-family

This example shows the configuration of BGP and OSPF route leaking between the global VRF and VPN 200 on Edge Router 2.

vrf definition 200
 rd 1:200
 !
  address-family ipv4
   route-replicate from vrf global unicast ospf 65535
 !
global-address-family ipv4
 route-replicate from vrf 200 unicast eigrp
 exit-address-family