MPLS Configuration Examples and TechNotes

Printable View

2010-02-11, 10:18 PM
patris1

MPLS Configuration Examples and TechNotes

[LEFT][CODE]http://www.cisco.com/en/US/tech/tk436/tk428/tech_configuration_examples_list.html[/CODE][B][SIZE=3][B]Configuring a Basic MPLS VPN[/B][/SIZE][/B]

[B]Document ID: 13733[/B]

[B]Contents[/B]
[INDENT][B]Introduction
[/B] [B]Prerequisites
Requirements
Components Used
Related Products
Conventions
[/B] [B]Configure
Network Diagram
Configuration Procedures
Configurations
[/B] [B]Verify
[/B] [B]Troubleshoot
[/B] [B]Related Information
[/B][/INDENT][B]Introduction[/B]

This document provides a sample configuration of a Multiprotocol Label Switching (MPLS) VPN when Border Gateway Protocol (BGP) or Routing Information Protocol (RIP) is present on the customer's site.
When used with MPLS, the VPN feature allows several sites to interconnect transparently through a service provider's network. One service provider network can support several different IP VPNs. Each of these appears to its users as a private network, separate from all other networks. Within a VPN, each site can send IP packets to any other site in the same VPN.
Each VPN is associated with one or more VPN routing or forwarding instances (VRFs). A VRF consists of an IP routing table, a derived Cisco express forwarding (CEF) table, and a set of interfaces that use this forwarding table.
The router maintains a separate routing and CEF table for each VRF. This prevents information being sent outside the VPN and allows the same subnet to be used in several VPNs without causing duplicate IP address problems.
The router using Multiprotocol BGP (MP-BGP) distributes the VPN routing information using the MP-BGP extended communities.
For more information about the propagation of updates through a VPN, refer to these documents:

[LIST][*] [URL="http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/VPN.html#wp11136"]VPN Route Target Communities[/URL][*] [URL="http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/VPN.html#wp11140"]BGP Distribution of VPN Routing Information[/URL][*] [URL="http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/VPN.html#wp11145"]MPLS Forwarding[/URL][/LIST]
[B]Prerequisites[/B]

[B]Requirements[/B]

There are no specific requirements for this document.
[B]Components Used[/B]

The information in this document is based on these software and hardware versions:
[B]P and PE Routers[/B]

[LIST][*] Cisco IOS® Software Release 12.2(6h) includes the MPLS VPN feature.[*] Any Cisco router from the 7200 series or higher supports P functionality. The Cisco 2691, as well as any 3640 series or higher router supports PE functionality.[/LIST]
[B]C and CE Routers[/B]

[LIST][*] You can use any router that can exchange routing information with its PE router.[/LIST]
The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.
[B]Related Products[/B]

To implement the MPLS feature, you must have a router from the range of Cisco 2600 or higher. To select the required Cisco IOS with MPLS feature, use the [URL="http://tools.cisco.com/Support/Fusion/FusionHome.do"]Software Advisor[/URL] ([SIZE=-1][URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) . Also check for the additional RAM and Flash memory required to run the MPLS feature in the routers. WIC-1T, WIC-2T, and serial interfaces can be used.
[B]Conventions[/B]

Refer to [URL="http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080121ac5.shtml"]Cisco Technical Tips Conventions[/URL] for more information on document conventions.
The letters below represent the different types of routers and switches used.

[LIST][*] [B]P[/B]—Provider's core router.[*] [B]PE[/B]—Provider's edge router.[*] [B]CE[/B]—Customer's edge router.[*] [B]C[/B]—Customer's router.[/LIST]
This diagram shows a typical configuration illustrating the conventions outlined above.
[IMG]http://www.cisco.com/image/gif/paws/13733/mplsvpn.gif[/IMG]
[B]Configure[/B]

In this section, you are presented with the information to configure the features described in this document.
[B]Note: [/B]Use the [URL="http://tools.cisco.com/Support/CLILookup/cltSearchAction.do"]Command Lookup Tool[/URL] ([SIZE=-1][URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) to find more information on the commands used in this document.
[B]Network Diagram[/B]

This document uses this network setup:
[IMG]http://www.cisco.com/image/gif/paws/13733/new_mpls_vpn_basic1.gif[/IMG]
[B]Configuration Procedures[/B]

Refer to [URL="http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/VPN.html"]MPLS Virtual Private Networks[/URL] for more information.
[B]Enabling ip cef[/B]

Use this procedure in order to enable [B]ip cef[/B]. For improved performance, use [B]ip cef distributed[/B] (where available). Complete these steps on the PEs after MPLS has been set up (configuring [B]tag-switching ip[/B] on the interfaces).

[LIST=1][*] Create one VRF for each VPN connected using the [B]ip vrf [I]<VPN routing/forwarding instance name>[/I][/B] command.
When doing this:
[LIST][*] Specify the correct route distinguisher used for that VPN. This is used to extend the IP address so that you can identify which VPN it belongs to.[INDENT][B]rd [I]<VPN route distinguisher>[/I]
[/B][/INDENT][*] Set up the import and export properties for the MP-BGP extended communities. These are used for filtering the import and export process.[INDENT][B]route-target [I][export|import|both] <target VPN extended community>[/I]
[/B][/INDENT][/LIST]
[*] Configure the forwarding details for the respective interfaces using the [B]ip vrf forwarding [I]<VPN routing/forwarding instance name>[/I][/B] command and remember to set up the IP address after doing this.[*] Depending on the PE-CE routing protocol you are using, you can configure static routes or routing protocols (RIP, Open Shortest Path First [OSPF], or BGP) between PE and CE. Detailed configurations are available on the [URL="http://www.cisco.com/en/US/tech/tk436/tk798/tech_configuration_examples_list.html"]MPLS over ATM Support[/URL] page.[/LIST]
[B]Configuring MP-BGP[/B]

Configure MP-BGP between the PE routers. There are several ways to configure BGP, such as using the route reflector or confederation methods. The method used here—direct neighbor configuration—is the simplest and the least scalable.

[LIST=1][*] Declare the different neighbors.[*] Enter the [B]address-family ipv4 vrf [I]<VPN routing/forwarding instance name>[/I][/B] command for each VPN present at this PE router.
Carry out one or more of the following steps, as necessary:
[LIST][*] Redistribute the static routing, RIP, or OSPF information.[*] Redistribute connected routing information.[*] Activate BGP neighboring with the CE routers.[/LIST]
[*] Enter the [B]address-family vpnv4[/B] mode, and complete the following steps:
[LIST][*] Activate the neighbors.[*] Specify that extended community must be used. This is mandatory.[/LIST]
[/LIST]
[B]Configurations[/B]

This document uses these configurations:

[LIST][*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00800a6c11.shtml#c1"]Pescara[/URL][*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00800a6c11.shtml#c2"]Pesaro[/URL][*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00800a6c11.shtml#c3"]Pomerol[/URL][*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00800a6c11.shtml#c4"]Pulligny[/URL][*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00800a6c11.shtml#c5"]Pauillac[/URL][/LIST]
Pescara
Current configuration:
!
version 12.2
!
hostname Pescara
!
ip cef
!

[I]
[COLOR=#0000ff]!--- Customer A commands.[/COLOR]
[/I]
ip vrf Customer_A
[I]
[COLOR=#0000ff]!--- Enables the VPN routing and forwarding (VRF) routing table.
!--- This command can be used in global or
!--- router configuration mode. [/COLOR]
[/I]
rd 100:110
[I]
[COLOR=#0000ff]!--- Route distinguisher creates routing and forwarding
!--- tables for a VRF.[/COLOR]
[/I]
route-target export 100:1000
[I]
[COLOR=#0000ff]!--- Creates lists of import and export route-target extended
!--- communities for the specified VRF.[/COLOR]
[/I]
route-target import 100:1000
!

[I]
[COLOR=#0000ff]!--- Customer B commands.[/COLOR]
[/I]
ip vrf Customer_B
rd 100:120
route-target export 100:2000
route-target import 100:2000
!
interface Loopback0
ip address 10.10.10.4 255.255.255.255
ip router isis

[I]
[COLOR=#0000ff]!--- Customer A commands.[/COLOR]
[/I]
interface Loopback101
ip vrf forwarding Customer_A
[I]
[COLOR=#0000ff]!--- Associates a VRF instance with an interface or subinterface.[/COLOR]
[/I]
ip address 200.0.4.1 255.255.255.0
[I]
[COLOR=#0000ff]!--- Loopback101 and 102 use the same IP address, 200.0.4.1.
!--- This is allowed because they belong to two
!--- different customers' VRFs. [/COLOR]
[/I]
no ip directed-broadcast
!

[I]
[COLOR=#0000ff]!--- Customer B commands.[/COLOR]
[/I]
interface Loopback102
ip vrf forwarding Customer_B
ip address 200.0.4.1 255.255.255.0
[I]
[COLOR=#0000ff]!--- Loopback101 and 102 use the same IP address, 200.0.4.1.
!--- This is allowed because they belong to two
!--- different customers' VRFs.[/COLOR]
[/I]
no ip directed-broadcast
!
interface Serial2/0
no ip address
no ip directed-broadcast
encapsulation frame-relay
no fair-queue
!
interface Serial2/0.1 point-to-point
description link to Pauillac
bandwidth 512
ip address 10.1.1.14 255.255.255.252
no ip directed-broadcast
ip router isis
tag-switching ip
frame-relay interface-dlci 401
!
router isis
net 49.0001.0000.0000.0004.00
is-type level-1
!
router bgp 100
bgp log-neighbor-changes
[I]
[COLOR=#0000ff]!--- Enables logging of BGP neighbor resets.[/COLOR]
[/I]
neighbor 10.10.10.6 remote-as 100
[I]
[COLOR=#0000ff]!--- Adds an entry to the BGP or multiprotocol BGP neighbor table.[/COLOR]
[/I]
neighbor 10.10.10.6 update-source Loopback0
[I]
[COLOR=#0000ff]!--- Enables BGP sessions to use a specific operational
!--- interface for TCP connections.[/COLOR]
[/I]
!

[I]
[COLOR=#0000ff]!--- Customer A and B commands.[/COLOR]
[/I]
address-family vpnv4
[I]
[COLOR=#0000ff]!--- To enter address family configuration mode
!--- for configuring routing sessions, such as BGP,
!--- that use standard VPN version 4 address prefixes.[/COLOR]
[/I]
neighbor 10.10.10.6 activate
neighbor 10.10.10.6 send-community both
[I]
[COLOR=#0000ff]!--- Sends the community attribute to a BGP neighbor.[/COLOR]
[/I]
exit-address-family
!

[I]
[COLOR=#0000ff]!--- Customer B commands.[/COLOR]
[/I]
address-family ipv4 vrf Customer_B
[I]
[COLOR=#0000ff]!--- To enter address family configuration mode
!--- for configuring routing sessions, such as BGP,
!--- that use standard VPN version 4 address prefixes.[/COLOR]
[/I]
redistribute connected
no auto-summary
no synchronization
exit-address-family
!

[I]
[COLOR=#0000ff]!--- Customer A commands.[/COLOR]
[/I]
address-family ipv4 vrf Customer_A
redistribute connected
no auto-summary
no synchronization
exit-address-family
!
ip classless
!
end
Pesaro
Current configuration:
!
version 12.1
!
hostname Pesaro
!

[I]
[COLOR=#0000ff]!--- Customer A commands.[/COLOR]
[/I]
ip vrf Customer_A
rd 100:110
route-target export 100:1000
route-target import 100:1000
!

[I]
[COLOR=#0000ff]!--- Customer B commands.[/COLOR]
[/I]
ip vrf Customer_B
rd 100:120
route-target export 100:2000
route-target import 100:2000
!
ip cef

!
interface Loopback0
ip address 10.10.10.6 255.255.255.255
ip router isis

[I]
[COLOR=#0000ff]!--- Customer A commands.[/COLOR]
[/I]
interface Loopback101
ip vrf forwarding Customer_A
ip address 200.0.6.1 255.255.255.0
!

[I]
[COLOR=#0000ff]!--- Customer B commands.[/COLOR]
[/I]
interface Loopback102
ip vrf forwarding Customer_B
ip address 200.0.6.1 255.255.255.0
!

[I]
[COLOR=#0000ff]!--- Customer A commands.[/COLOR]
[/I]
interface Loopback111
ip vrf forwarding Customer_A
ip address 200.1.6.1 255.255.255.0
!
interface Serial0/0
no ip address
encapsulation frame-relay
no ip mroute-cache
random-detect
!
interface Serial0/0.1 point-to-point
description link to Pomerol
bandwidth 512
ip address 10.1.1.22 255.255.255.252
ip router isis
tag-switching ip
frame-relay interface-dlci 603
!
router isis
net 49.0001.0000.0000.0006.00
is-type level-1
!
router bgp 100
neighbor 10.10.10.4 remote-as 100
neighbor 10.10.10.4 update-source Loopback0
!

[I]
[COLOR=#0000ff]!--- Customer B commands.[/COLOR]
[/I]
address-family ipv4 vrf Customer_B
redistribute connected
no auto-summary
no synchronization
exit-address-family
!

[I]
[COLOR=#0000ff]!--- Customer A commands.[/COLOR]
[/I]
address-family ipv4 vrf Customer_A
redistribute connected
no auto-summary
no synchronization
exit-address-family
!

[I]
[COLOR=#0000ff]!--- Customer A and B commands.[/COLOR]
[/I]
address-family vpnv4
neighbor 10.10.10.4 activate
neighbor 10.10.10.4 send-community both
exit-address-family
!
ip classless
!
end
Pomerol
Current configuration:
!
version 12.0
!
hostname Pomerol
!
ip cef

!
interface Loopback0
ip address 10.10.10.3 255.255.255.255
ip router isis

!
interface Serial0/1
no ip address
no ip directed-broadcast
encapsulation frame-relay
random-detect
!
interface Serial0/1.1 point-to-point
description link to Pauillac
ip address 10.1.1.6 255.255.255.252
no ip directed-broadcast
ip router isis
tag-switching mtu 1520
tag-switching ip
frame-relay interface-dlci 301
!
interface Serial0/1.2 point-to-point
description link to Pulligny
ip address 10.1.1.9 255.255.255.252
no ip directed-broadcast
ip router isis
tag-switching ip
frame-relay interface-dlci 303
!
interface Serial0/1.3 point-to-point
description link to Pesaro
ip address 10.1.1.21 255.255.255.252
no ip directed-broadcast
ip router isis
tag-switching ip

frame-relay interface-dlci 306
!
router isis
net 49.0001.0000.0000.0003.00
is-type level-1
!
ip classless
!
end
Pulligny
Current configuration:
!
version 12.1
!
hostname Pulligny
!
!
ip cef

!
!
interface Loopback0
ip address 10.10.10.2 255.255.255.255
!
interface Serial0/1
no ip address
encapsulation frame-relay
random-detect
!
interface Serial0/1.1 point-to-point
description link to Pauillac
ip address 10.1.1.2 255.255.255.252
ip router isis
tag-switching ip
frame-relay interface-dlci 201
!
interface Serial0/1.2 point-to-point
description link to Pomerol
ip address 10.1.1.10 255.255.255.252
ip router isis
tag-switching ip
frame-relay interface-dlci 203
!
router isis
passive-interface Loopback0
net 49.0001.0000.0000.0002.00
is-type level-1
!
ip classless
!
end
Pauillac
!
version 12.1
!
hostname pauillac
!
ip cef

!
interface Loopback0
ip address 10.10.10.1 255.255.255.255
ip router isis
!
interface Serial0/0
no ip address
encapsulation frame-relay
no ip mroute-cache
tag-switching ip
no fair-queue
!
interface Serial0/0.1 point-to-point
description link to Pomerol
bandwith 512
ip address 10.1.1.1 255.255.255.252
ip router isis
tag-switching ip
frame-relay interface-dlci 102
!
interface Serial0/0.2 point-to-point
description link to Pulligny ip address 10.1.1.5 255.255.255.252

ip router isis
tag-switching ip
frame-relay interface-dlci 103
!
interface Serial0/0.3 point-to-point
description link to Pescara
bandwidth 512
ip address 10.1.1.13 255.255.255.252
ip router isis
tag-switching ip
frame-relay interface-dlci 104
!
router isis
net 49.0001.0000.0000.0001.00
is-type level-1
!
ip classless
!
end
[B]Verify[/B]

This section provides information you can use to confirm your configuration is working properly.
The [URL="https://www.cisco.com/cgi-bin/Support/OutputInterpreter/home.pl"]Output Interpreter Tool[/URL] ([SIZE=-1][URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) (OIT) supports certain [B]show[/B] commands. Use the OIT to view an analysis of [B]show[/B] command output.

[LIST][*] [B]show ip vrf[/B]—Verifies that the correct VRF exists.[*] [B]show ip vrf interfaces[/B]—Verifies the activated interfaces.[*] [B]show ip route vrf Customer_A[/B]—Verifies the routing information on the PE routers.[*] [B]traceroute vrf Customer_A 200.0.6.1[/B]—Verifies the routing information on the PE routers.[*] [B]show ip bgp vpnv4 tag[/B]—Verifies the BGP.[*] [B]show ip cef vrf Customer_A 200.0.6.1 detail[/B]—Verifies the routing information on the PE routers.[/LIST]
More commands are detailed in the [URL="http://www.cisco.com/en/US/docs/net_mgmt/vpn_solutions_center/1.1/user/guide/VPN_UG7.html"]MPLS VPN Solution Troubleshooting Guide[/URL].
The following is sample command output of the [B]show ip vrf[/B] command.[INDENT]Pescara#[B]show ip vrf [/B]
Name Default RD Interfaces
Customer_A 100:110 Loopback101
Customer_B 100:120 Loopback102[/INDENT]The following is sample command output of the [B]show ip vrf interfaces[/B] command.[INDENT]Pesaro#[B]show ip vrf interfaces[/B]
Interface IP-Address VRF Protocol
Loopback101 200.0.6.1 Customer_A up
Loopback111 200.1.6.1 Customer_A up
Loopback102 200.0.6.1 Customer_B up[/INDENT]The following [B]show ip route vrf[/B] commands show the same prefix 200.0.6.0/24 in both the outputs. This is because the remote PE has the same network for two customers, Customer_A and Customer_B, which is allowed in a typical MPLS VPN solution.[INDENT]Pescara#[B]show ip route vrf Customer_A[/B]
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR

Gateway of last resort is not set

C 200.0.4.0/24 is directly connected, Loopback101
B 200.0.6.0/24 [200/0] via 10.10.10.6, 05:10:11
B 200.1.6.0/24 [200/0] via 10.10.10.6, 04:48:11

Pescara#[B]show ip route vrf Customer_B[/B]
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is not set
C 200.0.4.0/24 is directly connected, Loopback102

B 200.0.6.0/24 [200/0] via 10.10.10.6, 00:03:24[/INDENT]By running a traceroute between two sites of Customer_A, it is possible to see the label stack used by the MPLS network (if it is configured to do so by [B]mpls ip ttl ...[/B]).[INDENT]Pescara#[B]traceroute vrf Customer_A 200.0.6.1[/B]

Type escape sequence to abort.
Tracing the route to 200.0.6.1

1 10.1.1.13 [[B]MPLS: Labels 20/26[/B] Exp 0] 400 msec 276 msec 264 msec
2 10.1.1.6 [[B]MPLS: Labels 18/26[/B] Exp 0] 224 msec 460 msec 344 msec
3 200.0.6.1 108 msec * 100 msec[/INDENT][B]Note: [/B] Exp 0 is an experimental field used for Quality of Service (QoS).
[B]Troubleshoot[/B]

There is currently no specific troubleshooting information available for this configuration.
[B]Related Information[/B]

[LIST][*][B][URL="http://www.cisco.com/en/US/docs/ios/12_1/switch/command/reference/xrdscmd3.html"]MPLS Command Guide[/URL][/B][*][B][URL="http://www.cisco.com/en/US/docs/ios/12_1/switch/configuration/guide/xcdtagc.html"]Configuring MPLS[/URL][/B][*][B][URL="http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfmbgp.html"]Multiprotocol BGP Extensions for IP Multicast Commands[/URL][/B][*][B][URL="http://tools.cisco.com/Support/CLILookup/cltSearchAction.do"]Command Lookup Tool[/URL] ([SIZE=-1][URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE])[/B][*][B][URL="http://www.cisco.com/web/psa/technologies/tsd_technology_support_configure_guide.html?c=268435750"]MPLS Support[/URL][/B][*][B][URL="http://www.cisco.com/cisco/web/support/index.html"]Technical Support & Documentation - Cisco Systems[/URL][/B][/LIST]

Updated: Nov 16, 2007[/LEFT]
2010-02-11, 10:21 PM
patris1

[LEFT][B][SIZE=3][B]Configuring Basic MPLS Using IS-IS[/B][/SIZE][/B]

[B]Document ID: 13735[/B]

[B]Contents[/B]

[INDENT][B]Introduction
[/B] [B]Prerequisites
Requirements
Components Used
Background Theory
Conventions
[/B] [B]Configure
Network Diagram
Configurations
[/B] [B]Verify
Sample Output
[/B] [B]Troubleshoot
[/B] [B]Related Information[/B][/INDENT][B]Introduction[/B]

This sample configuration shows how to set up a Multiprotocol Label Switching (MPLS) network for further tasks such as Virtual Private Network (VPN) or traffic engineering (see more Sample Configurations on the [URL="http://www.cisco.com/web/psa/technologies/tsd_technology_support_configure_guide.html?c=268435750"]MPLS Support Page[/URL]).
[B]Prerequisites[/B]

[B]Requirements[/B]

Before attempting this configuration, please ensure that you meet the following prerequisites:

[LIST][*] To implement MPLS, you need a Cisco 2600 router or later.[*] Select the required Cisco IOS with MPLS using the [URL="http://www.cisco.com/pcgi-bin/Support/CompNav/Index.pl"]Software Advisor[/URL] ([SIZE=-1][URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) .[*] Check for the additional RAM and Flash memory required to run MPLS in the routers. WAN interface cards (WICs), WIC-1T and WIC-2T, can be used.[/LIST]
[B]Components Used[/B]

The information in this document is based on the software and hardware versions below.

[LIST][*] Cisco 3640, Cisco 3660, Cisco 4500, and Cisco 2610 Routers[*] Cisco IOS® version 12.2(6h) is running on all the routers[/LIST]
The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.
[B]Background Theory[/B]

An MPLS network is commonly a backbone network comprised of MPLS-enabled routers called Label Switch Routers (LSR). Generally, the network consists of a core LSR with an edge LSR responsible for applying labels to packets.
The set-up mechanism of an MPLS network is the following.

[LIST][*] Routing tables of the different LSRs are computed using an Interior Gateway Protocol (IGP). A link-state protocol such as Open Shortest Path First (OSPF) or Intermediate System-to-Intermediate System (IS-IS) is required if you're going to deploy MPLS Traffic Engineering.[*] A label distribution protocol (LDP) advertises the bindings between routes and labels. These bindings are checked against the routing table. If the route (prefix/mask and next hop) learned via the LDP matches the route learned via IGP in the routing table, an entry is created in the label forwarding information bases (LFIB) on the LSR.[/LIST]
The LSR uses the following forwarding mechanism.

[LIST][*] Once an edge LSR receives an unlabeled packet, the Cisco express forwarding table is checked and a label is imposed on the packet if needed. This LSR is called the ingress LSR.[*] Upon the arrival of a labelled packet at the incoming interface of a core LSR, the LFIB provides the outgoing interface and the new label that will be associated with the outgoing packet.[*] The router before the last LSR (the penultimate hop) pops the label and transmits the packet without the label. The last hop is called the egress LSR.[/LIST]
The following diagram illustrates this network setup.
[IMG]http://www.cisco.com/image/gif/paws/13735/1b.gif[/IMG]
[B]Conventions[/B]

For more information on document conventions, see the [URL="http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080121ac5.shtml"]Cisco Technical Tips Conventions[/URL].
[B]Configure[/B]

In this section, you are presented with the information to configure the features described in this document.
[B]Note: [/B]To find additional information on the commands used in this document, use the [URL="http://www.cisco.com/pcgi-bin/Support/Cmdlookup/home.pl"]Command Lookup Tool[/URL] ([SIZE=-1][URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) .
[B]Network Diagram[/B]

This document uses this network setup:
[IMG]http://www.cisco.com/image/gif/paws/13735/1a.gif[/IMG]
[B]Configurations[/B]

This document uses these configurations:

[LIST][*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080093fcc.shtml#quick"]Quick Configuration Guide[/URL][*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080093fcc.shtml#pomerol"]Pomerol[/URL][*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080093fcc.shtml#pulligny"]Pulligny[/URL][*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080093fcc.shtml#pauillac"]Pauillac[/URL][/LIST]
[B]Quick Configuration Guide[/B]

Complete these steps to configure MPLS:

[LIST=1][*] Set up your network as usual (MPLS needs a standard IP connection in order to establish forwarding bases).[*] Ensure that the routing protocol (OSPF or IS-IS) is working correctly. These commands are shown in italics in the configurations in this section.[*] Use the [B][URL="http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_tech_note09186a00801e1e46.shtml"]ip cef[/URL][/B] command (for better performances, use the [B]ip cef distributed[/B] command when available) in the general configuration mode (shown in bold in the configurations in this section) to enable.[*] Use the [B]mpls ip[/B] command (or the [B]tag-switching ip[/B] command on older Cisco IOS versions) in the general configuration mode and in each interface (shown in bold in the configurations in this section) to enable.
[B]Note: [/B] The LSRs must have (up) Loopback interfaces with an address mask of 32 bits.[/LIST]
Pomerol
Current configuration:
!
version 12.2
!
hostname Pomerol
!
[B]ip cef[/B]
[I]
[COLOR=#0000ff]!--- Enables Cisco Express Forwarding globally.[/COLOR]
[/I]
!
interface Loopback0
ip address 10.10.10.3 255.255.255.255
[I]ip router isis[/I]
[I]
[COLOR=#0000ff]!--- Assigns an IP address to interface loopback0
!--- and enables IS-IS for IP on the interface.[/COLOR]
[/I]
!
interface Serial0/0
encapsulation frame-relay
!
interface Serial0/0.1 point-to-point
ip address 10.1.1.6 255.255.255.252
[I]ip router isis[/I]
[B]tag-switching ip[/B]
[I]
[COLOR=#0000ff]!--- Enables dynamic Label Switching of
!--- IPv4 packets on an interface.[/COLOR]
[/I]
frame-relay interface-dlci 301
!
interface Serial0/0.2 point-to-point
ip address 10.1.1.9 255.255.255.252
[I]ip router isis[/I]
[B]tag-switching ip[/B]
frame-relay interface-dlci 303
!
interface Serial0/0.3 point-to-point
ip address 10.1.1.21 255.255.255.252
[I]ip router isis[/I]
[B]tag-switching ip[/B]
frame-relay interface-dlci 306
!
[I]router isis
net 49.0001.0000.0000.0003.00
is-type level-1[/I]
!
ip classless
!
end

Pulligny
Current configuration:
!
version 12.1
!
hostname Pulligny
!
[B]ip cef[/B]
!
interface Loopback0
ip address 10.10.10.2 255.255.255.255
!
interface Serial0/1
no ip address
encapsulation frame-relay
!
interface Serial0/0.1 point-to-point
ip address 10.1.1.2 255.255.255.252
[I]ip router isis[/I]
[B]tag-switching ip[/B]
frame-relay interface-dlci 201
!
interface Serial0/0.2 point-to-point
ip address 10.1.1.10 255.255.255.252
[I]ip router isis[/I]
[B]tag-switching ip[/B]
frame-relay interface-dlci 203
!
[I]router isis
redistribute static ip
passive-interface Loopback0
net 49.0001.0000.0000.0002.00
is-type level-1[/I]
[I]
[COLOR=#0000ff]!--- Enables the IS-IS process on the router,
!--- makes loopback interface passive
!--- (does not send IS-IS packets on interface),
!--- and assigns area and system ID to router.[/COLOR]
[/I]
!
ip classless
!
end

Pauillac
Current configuration : 2366 bytes
!
version 12.1
!
hostname pauillac
!
[B]ip cef[/B]
!
interface Loopback0
ip address 10.10.10.1 255.255.255.255
[I]ip router isis[/I]
!
interface Serial0/0
no ip address
encapsulation frame-relay
!
interface Serial0/0.1 point-to-point
ip address 10.1.1.1 255.255.255.252
[I]ip router isis[/I]
[B]tag-switching ip[/B]
frame-relay interface-dlci 102
!
interface Serial0/0.2 point-to-point
ip address 10.1.1.5 255.255.255.252
ip access-group 150 out
[I]ip router isis[/I]
[B]tag-switching ip[/B]
frame-relay interface-dlci 103
!
interface Serial0/0.3 point-to-point
bandwidth 512
ip address 10.1.1.13 255.255.255.252
[I]ip router isis[/I]
[B]tag-switching ip[/B]
frame-relay interface-dlci 104
!
interface Serial0/0.4 point-to-point
ip address 10.1.1.17 255.255.255.252
[I]ip router isis[/I]
[B]tag-switching ip[/B]
frame-relay interface-dlci 105
!
!
[I]router isis
net 49.0001.0000.0000.0001.00
is-type level-1[/I]
!
ip classless
!
end

[B]Verify[/B]

This section provides information you can use to confirm your configuration is working properly.
Certain [B]show[/B] commands are supported by the [URL="https://www.cisco.com/cgi-bin/Support/OutputInterpreter/home.pl"]Output Interpreter Tool[/URL] ([SIZE=-1][URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) , which allows you to view an analysis of [B]show[/B] command output.

[LIST][*] [B]show tag-switching tdp neighbor[/B][*] [B]show tag-switching tdp bindings[/B][*] [B]show tag-switching forwarding-table[/B][*] [B]show tag-switching forwarding-table a.b.c.d detail[/B][*] [B]traceroute a.b.c.d[/B][/LIST]
An exhaustive list of commands is included in the [URL="http://www.cisco.com/en/US/docs/ios/12_1/switch/command/reference/xrdscmd9.html"]MPLS Command Reference[/URL]. Other sample [B]show[/B] commands are described in [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080093f23.shtml"]Configuring Basic MPLS Using OSPF[/URL].
[B]Sample Output[/B]

The following output focuses on the LDP. The LDP currently implemented in IOS is TDP (Tag Distribution Protocol), which contains some Cisco-proprietary extensions, but it be used with LDP, the IETF official protocol for label distribution. TDP will be replaced by LDP in the future.
You can use the [B]show tag-switching tdp *[/B] command to verify the state of TDP. You can see neighbors using the [B]show tag-switching tdp neighbor[/B] command.
[INDENT]Pulligny# [B]show tag-switching tdp discovery[/B]
Local TDP Identifier:
10.10.10.2:0
TDP Discovery Sources:
Interfaces:
Serial0/0.1: xmit/recv
TDP Id: 10.10.10.1:0
Serial0/0.2: xmit/recv
TDP Id: 10.10.10.3:0
[I]
[COLOR=#0000ff]!--- Ensure you are able to ping this IP address
!--- If not, check whether a route exists in the routing table[/COLOR]
[/I][/INDENT][INDENT]Pulligny# [B]show tag-switching tdp neighbor[/B]
Peer TDP Ident: 10.10.10.1:0; Local TDP Ident 10.10.10.2:0
TCP connection: 10.10.10.1.711 - 10.10.10.2.11001
State: Oper; PIEs sent/rcvd: 27907/27925; ; Downstream
Up time: 2w2d
TDP discovery sources:
Serial0/0.1
Addresses bound to peer TDP Ident:
10.1.1.1 10.1.1.13 10.1.1.17 10.10.10.1
10.1.1.5 10.200.28.89
Peer TDP Ident: 10.10.10.3:0; Local TDP Ident 10.10.10.2:0
TCP connection: 10.10.10.3.11001 - 10.10.10.2.711
State: Oper; PIEs sent/rcvd: 22893/22874; ; Downstream
Up time: 1w6d
TDP discovery sources:
Serial0/0.2
Addresses bound to peer TDP Ident:
10.200.28.91 10.1.1.6 10.1.1.9 10.1.1.21
10.10.10.3[/INDENT]You can use the [B]show tag-switching tdp bindings[/B] command to view the established bindings between labels and routes.
[INDENT]Pulligny# [B]show tag-switching tdp bindings[/B]
(...)
tib entry: 10.10.10.4/32, rev 22
local binding: tag: 21
remote binding: tsr: 10.10.10.1:0, tag: 22
remote binding: tsr: 10.10.10.3:0, tag: 25
tib entry: 10.10.10.6/32, rev 51
local binding: tag: 23
remote binding: tsr: 10.10.10.3:0, tag: 18
remote binding: tsr: 10.10.10.1:0, tag: 20
(...)[/INDENT]You can use the [B]show tag-switching forwarding-table[/B] command to see which bindings are used to build the LFIB.
[INDENT]Pulligny# [B]show tag-switching forwarding-table[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 10.1.1.4/30 0 Se0/0.2 point2point
Pop tag 10.1.1.4/30 0 Se0/0.1 point2point
17 Pop tag 10.1.1.20/30 0 Se0/0.2 point2point
18 Pop tag 10.10.10.3/32 0 Se0/0.2 point2point
19 Pop tag 10.10.10.1/32 0 Se0/0.1 point2point
20 Pop tag 10.1.1.12/30 0 Se0/0.1 point2point
21 Pop tag 10.1.1.16/30 0 Se0/0.1 point2point
22 20 10.10.10.5/32 0 Se0/0.1 point2point
23 22 10.10.10.6/32 0 Se0/0.2 point2point
24 22 10.10.10.4/32 0 Se0/0.1 point2point[/INDENT]You can use the [B]show tag-switching forwarding-table 10.10.10.4 detail[/B] command to view the details of a given destination.
[INDENT]Pulligny# [B]show tag-switching forwarding-table 10.10.10.4 detail[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
21 22 10.10.10.4/32 12103 Se0/0.1 point2point
MAC/Encaps=4/8, MTU=1500, Tag Stack{22}
30918847 00016000
Per-packet load-sharing[/INDENT]You can also use the [B]traceroute[/B] command, if the network does IP TTL propagation, to view the hops. Refer to [URL="http://www.cisco.com/en/US/docs/ios/12_1t/12_1t3/feature/guide/rtr_13t.html#xtocid516027"]Multiprotocol Label Switching on Cisco Routers[/URL] for more information on the [B]mpls ip ttl propagate[/B] command.
[INDENT]Pesaro# [B]traceroute 10.10.10.4[/B]

Type escape sequence to abort.
Tracing the route to 10.10.10.4

1 10.1.1.21 [MPLS: Label 25 Exp 0] 296 msec 256 msec 244 msec
2 10.1.1.5 [MPLS: Label 22 Exp 0] 212 msec 392 msec 352 msec
3 10.1.1.14 436 msec * 268 msec[/INDENT][B]Note: [/B]Exp 0 appears in the output if the experimental field is used for Quality of Service (QoS).
[B]Troubleshoot[/B]

There is currently no specific troubleshooting information available for this configuration.
[B]Related Information[/B]

[LIST][*][B][URL="http://www.cisco.com/web/psa/technologies/tsd_technology_support_configure_guide.html?c=268435750"]MPLS Support Page[/URL][/B][*][B][URL="http://www.cisco.com/en/US/docs/ios/12_1/switch/command/reference/xrdscmd9.html"]MPLS Command Reference[/URL][/B][*][B][URL="http://www.cisco.com/en/US/docs/ios/12_1/switch/configuration/guide/xcdtagc.html"]Configuring Multiprotocol Label Switching[/URL][/B][*][B][URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080093f23.shtml"]Configuring Basic MPLS Using OSPF[/URL][/B][*][B][URL="http://www.cisco.com/en/US/support/index.html"]Technical Support - Cisco Systems[/URL][/B][/LIST]

Updated: Nov 16, 2007

[/LEFT]
2010-02-11, 10:23 PM
patris1

[LEFT][B][B][SIZE=3]Configuring Basic MPLS Using OSPF[/SIZE][/B][/B]

[B]Document ID: 13736[/B]

[B]Contents[/B]

[INDENT][B]Introduction
[/B] [B]Prerequisites
Requirements
Components Used
Conventions
[/B] [B]Mechanism
[/B] [B]Configure
Network Diagram
Quick Configuration Guide
Configurations
[/B] [B]Verify
[/B] [B]Troubleshoot
[/B] [B]Related Information[/B][/INDENT][B]Introduction[/B]

This document shows how to configure a basic Multiprotocol Label Switching (MPLS) network. Refer to [URL="http://www.cisco.com/en/US/tech/tk436/tk428/tech_configuration_examples_list.html"]Configuration Examples and TechNotes[/URL] on the MPLS Support Page for more information on how to configure advanced topics such as VPN or Traffic Engineering (TE).
[B]Prerequisites[/B]

[B]Requirements[/B]

Cisco recommends that you are familiar with the basic operation of MPLS. Refer to [URL="http://www.cisco.com/en/US/docs/ios/12_2/switch/configuration/guide/xcftagov_ps1835_TSD_Products_Configuration_Guide_Chapter.html"]Multiprotocol Label Switching Overview[/URL] for an overview of MPLS.
[B]Components Used[/B]

The information in this document is based on these software and hardware versions:

[LIST][*] Cisco IOS® Software Releases 12.2(28)[*] Cisco 3600 routers[/LIST]
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
[B]Conventions[/B]

Refer to [URL="http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080121ac5.shtml"]Cisco Technical Tips Conventions[/URL] for more information on document conventions.
[B]Mechanism[/B]

An MPLS network is commonly a backbone network comprised of MPLS-enabled routers called Label Switch Routers (LSR). Generally, the network consists of a core LSR with an edge LSR that applies labels to packets.
This is the setup mechanism of an MPLS network:

[LIST=1][*] Routing tables of the different LSRs are computed with an Interior Gateway Protocol (IGP). A link-state protocol, such as Open Shortest Path First (OSPF) or Intermediate System-to-Intermediate System (IS-IS), is required if you plan to deploy MPLS TE.[*] A label distribution protocol (LDP) advertises the bindings between routes and labels. These bindings are checked against the routing table. If the route (prefix/mask and next hop) learned from the LDP matches the route learned from IGP in the routing table, an entry is created in the label that forwards information bases (LFIB) on the LSR.[/LIST]
The LSR uses this forwarding mechanism:

[LIST=1][*] Once an edge LSR receives an unlabelled packet, the Cisco Express Forwarding table is checked and a label is imposed on the packet if needed. This LSR is called the ingress LSR.[*] Upon the arrival of a labelled packet at the inbound interface of a core LSR, the LFIB provides the outbound interface and the new label that is associated with the outbound packet.[*] The router before the last LSR (the penultimate hop) pops the label and transmits the packet without the label. The last hop is called the egress LSR.[/LIST]
This diagram illustrates this network setup:
[IMG]http://www.cisco.com/image/gif/paws/13736/1b.gif[/IMG]
[B]Configure[/B]

In this section, you are presented with the information to configure the features described in this document.
[B]Note: [/B]In order fo find additional information on the commands used in this document, use the [URL="http://tools.cisco.com/Support/CLILookup/cltSearchAction.do"]Command Lookup Tool[/URL] ([SIZE=-1][URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) .
[B]Network Diagram[/B]

This document uses this network setup:
[IMG]http://www.cisco.com/image/gif/paws/13736/1a.gif[/IMG]
[B]Quick Configuration Guide[/B]

Use this procedure as a quick configuration guide.

[LIST=1][*] Set up your network as usual. MPLS needs a standard IP connection in order to establish forwarding bases.[*] Ensure that the routing protocol (OSPF or IS-IS) works correctly. These commands are italicized in the configurations in the next section.[*] Enable [B]ip cef[/B], for better performances use [B]ip cef distributed[/B] when available, in the general configuration mode. This is shown in bold in the configurations in the next section.[*] Enable [B]mpls ip[/B], or [B]tag-switching ip[/B] on older Cisco IOS software releases, in the general configuration mode and in each interface, as shown in bold in the configurations in the next section. Even when the [B]mpls ip[/B] command is used, the [B]show running[/B] output can still show the command as [B]tag-switching ip[/B] in some Cisco IOS software releases, as shown in the configurations in the next section.
[B]Note: [/B]The LSRs must have (up) Loopback interfaces with an address mask of 32 bits and these interfaces must be reachable with the global IP routing table.[/LIST]
[B]Configurations[/B]

This document uses these configurations:

[LIST][*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080093f23.shtml#t1"]Pomerol[/URL][*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080093f23.shtml#t2"]Pulligny[/URL][*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080093f23.shtml#t3"]Pauillac[/URL][*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080093f23.shtml#t4"]Pescara[/URL][*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080093f23.shtml#t5"]Pesaro[/URL][*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080093f23.shtml#t6"]Perugia[/URL][/LIST]
Pomerol
!
version 12.2

!
hostname Pomerol
!
ip subnet-zero
!
[B]ip cef[/B]
!
interface Loopback0
ip address 10.10.10.3 255.255.255.255
!
interface Serial2/0
ip address 10.1.1.21 255.255.255.252
[B] tag-switching ip[/B]
!
interface Serial3/0
ip address 10.1.1.6 255.255.255.252
[B] tag-switching ip[/B]
!
interface Serial4/0
ip address 10.1.1.9 255.255.255.252
[B] tag-switching ip[/B]
!
router ospf 10
log-adjacency-changes
network 10.0.0.0 0.255.255.255 area 9
!
ip classless
!
end

Pulligny
!
version 12.2
!
hostname Pulligny
!
!
ip subnet-zero
!
[B]ip cef[/B]
!
interface Loopback0
ip address 10.10.10.2 255.255.255.255
!
interface Serial2/0
ip address 10.1.1.2 255.255.255.252
[B] tag-switching ip[/B]
!
interface Serial3/0
ip address 10.1.1.10 255.255.255.252
[B] tag-switching ip[/B]
!
router ospf 10
log-adjacency-changes
network 10.0.0.0 0.255.255.255 area 9
!
ip classless
!
end

Pauillac
!
version 12.2
!
hostname Pauillac
!
ip subnet-zero
!
[B]ip cef[/B]
!
interface Loopback0
ip address 10.10.10.1 255.255.255.255
!
interface Serial2/0
ip address 10.1.1.13 255.255.255.252
[B] tag-switching ip[/B]
!
interface Serial3/0
ip address 10.1.1.17 255.255.255.252
[B] tag-switching ip[/B]
!
interface Serial4/0
ip address 10.1.1.1 255.255.255.252
[B] tag-switching ip[/B]
!
interface Serial5/0
ip address 10.1.1.5 255.255.255.252
[B] tag-switching ip[/B]
!
router ospf 10
log-adjacency-changes
network 10.0.0.0 0.255.255.255 area 9
!
ip classless
!
end

Pescara
!
version 12.2
!
hostname Pescara
!
ip subnet-zero
!
[B]ip cef[/B]
!
interface Loopback0
ip address 10.10.10.4 255.255.255.255
!
interface Serial2/0
ip address 10.1.1.14 255.255.255.252
[B] tag-switching ip[/B]
!
router ospf 10
log-adjacency-changes
network 10.0.0.0 0.255.255.255 area 9
!
ip classless
!
end
Pesaro
!
version 12.2
!
hostname Pesaro
!
ip subnet-zero
!
[B]ip cef[/B]
!
interface Loopback0
ip address 10.10.10.6 255.255.255.255
!
interface Serial2/0
ip address 10.1.1.22 255.255.255.252
[B] tag-switching ip[/B]
!
router ospf 10
log-adjacency-changes
network 10.0.0.0 0.255.255.255 area 9
!
ip classless
!
end

Perugia
!
version 12.2
!
hostname Perugia
!
ip subnet-zero
!
[B]ip cef[/B]
!
interface Loopback0
ip address 10.10.10.5 255.255.255.255
!
interface Serial2/0
ip address 10.1.1.18 255.255.255.252
[B] tag-switching ip[/B]
!
router ospf 10
log-adjacency-changes
network 10.0.0.0 0.255.255.255 area 9
!
ip classless
!
end
[B]Verify[/B]

This section provides information you can use to confirm your configuration works properly.
Commands used in the [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080093fcc.shtml"]Configuring Basic MPLS Using IS-IS[/URL] sample configuration are also applicable.
In order to illustrate this sample configuration, look at a particular destination, for example [B]10.10.10.4[/B], on the [B]Pomerol[/B] LSR.
Certain [B]show[/B] commands are supported by the [URL="https://www.cisco.com/cgi-bin/Support/OutputInterpreter/home.pl"]Output Interpreter Tool[/URL] ([SIZE=-1][URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) , which allows you to view an analysis of [B]show[/B] command output.

[LIST][*] [B][URL="http://www.cisco.com/en/US/docs/ios/12_3/switch/command/reference/swi_s2.html#wp1057479"]show ip route[/URL][/B] —Used to check the IP route for this destination in the IP routing table:
[INDENT]Pomerol#[B]show ip route 10.10.10.4[/B]
Routing entry for 10.10.10.4/32
Known via "ospf 10", distance 110, metric 129, type intra area
Last update from 10.1.1.5 on Serial3/0, 17:29:23 ago
Routing Descriptor Blocks:
* 10.1.1.5, from 10.10.10.4, 17:29:23 ago, via [B]Serial3/0[/B]
Route metric is 129, traffic share count is 1[/INDENT][*] [B][URL="http://www.cisco.com/en/US/docs/ios/12_3/switch/command/reference/swi_s4.html#wp1069488"]show mpls forwarding-table[/URL][/B] —Used to check the MPLS forwarding table, which is the label switching equivalent of the IP routing table for standard IP routing. It contains inbound and outbound labels and descriptions of the packets.
[INDENT]Pomerol#[B]show mpls forwarding-table [/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 10.1.1.12/30 636 Se3/0 point2point
17 Pop tag 10.10.10.1/32 0 Se3/0 point2point
[B]18 21 10.10.10.4/32 0 Se3/0 point2point[/B]
19 Pop tag 10.1.1.0/30 0 Se4/0 point2point
Pop tag 10.1.1.0/30 0 Se3/0 point2point
20 Pop tag 10.10.10.6/32 612 Se2/0 point2point
21 Pop tag 10.1.1.16/30 0 Se3/0 point2point
22 16 10.10.10.5/32 0 Se3/0 point2point
23 Pop tag 10.10.10.2/32 0 Se4/0 point2point[/INDENT][*] [B][URL="http://www.cisco.com/en/US/docs/ios/12_3/switch/command/reference/swi_s4.html#wp1069488"]show mpls forwarding-table detail[/URL][/B] —Used to see MPLS forwarding table details:
[INDENT]Pomerol#[B]show mpls forwarding-table 10.10.10.4 32 detail[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
[B]18 21 10.10.10.4/32 0 Se3/0 point2point[/B]
MAC/Encaps=4/8, MRU=1500, Tag Stack{21}
0F008847 00015000
No output feature configured
Per-packet load-sharing[/INDENT][*] [B][URL="http://www.cisco.com/en/US/docs/ios/12_3/switch/command/reference/swi_s4.html#wp1066851"]show mpls ldp bindings[/URL][/B] or [B][URL="http://www.cisco.com/en/US/docs/ios/12_3/switch/command/reference/swi_s5.html#wp1048394"]show tag-switching tdp bindings[/URL][/B] (based on which Cisco IOS software release you use) —Used to see the label bindings associated with a particular destination. Both the local as well as the remote bindings can be seen.
[INDENT]Pomerol#[B]show tag-switching tdp bindings 10.10.10.4 32[/B]
tib entry: 10.10.10.4/32, rev 14
local binding: tag: [B]18[/B]
remote binding: tsr: 10.10.10.1:0, tag: [B]21[/B]
remote binding: tsr: 10.10.10.2:0, tag: 23
remote binding: tsr: 10.10.10.6:612, tag: 20
[/INDENT]Note that labels for each forwarding class are established at each LSR, even if they are not on the preferred (shortest) path. In this case, a packet destined to 10.10.10.4/32 can go by 10.10.10.1 (with label 21) or by 10.10.10.2 (with label 23). The LSR chooses the first solution because it is the shortest one. This decision is made with the standard IP routing table, which in this case, is built with OSPF.[*] [B][URL="http://www.cisco.com/en/US/docs/ios/12_3/switch/command/reference/swi_s2.html"]show ip cef detail[/URL][/B] —Used to check that Cisco Express Forwarding works properly and that tags are swapped correctly:
[INDENT]Pomerol#[B]show ip cef 10.10.10.4 detail[/B]
10.10.10.4/32, version 37, cached adjacency to Serial3/0
0 packets, 0 bytes
tag information set
local tag: [B]18[/B]
fast tag rewrite with Se3/0, point2point, tags imposed: [B]{21}[/B]
via 10.1.1.5, Serial3/0, 0 dependencies
next hop 10.1.1.5, Serial3/0
valid cached adjacency
tag rewrite with Se3/0, point2point, tags imposed: [B]{21}[/B][/INDENT][/LIST]
[B]Troubleshoot[/B]

Refer to [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a0080094b4e.shtml"]MPLS Troubleshooting[/URL] for information on how to troubleshoot MPLS.
[B]Related Information[/B]

[LIST][*][B][URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080093fcc.shtml"]Configuring Basic MPLS Using IS-IS[/URL][/B][*][B][URL="http://www.cisco.com/en/US/docs/ios/12_1/switch/configuration/guide/xcdtagc.html"]Configuring Multiprotocol Label Switching[/URL][/B][*][B][URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00800a6c11.shtml"]Configuring a Basic MPLS VPN[/URL][/B][*][B][URL="http://www.cisco.com/en/US/tech/tk436/tk428/tsd_technology_support_protocol_home.html"]MPLS Technology Support Page[/URL][/B][*][B][URL="http://www.cisco.com/en/US/support/index.html"]Technical Support - Cisco Systems[/URL][/B][/LIST]

Updated: Aug 10, 2005

[/LEFT]
2010-02-11, 10:25 PM
patris1

[LEFT][B][B][SIZE=3]Configuring MPLS Basic Traffic Engineering Using IS-IS[/SIZE][/B][/B]

[B]Document ID: 13737[/B]

[B]Contents[/B]

[INDENT][B]Introduction
[/B] [B]Prerequisites
Requirements
Components Used
Conventions
[/B] [B]Functional Components
[/B] [B]Configure
Network Diagram
Configurations
[/B] [B]Verify
show Commands
Sample show Output
[/B] [B]Related Information[/B][/INDENT][B]Introduction[/B]

This sample configuration shows how to implement traffic engineering (TE) on top of an existing Multiprotocol Label Switching (MPLS) network using Frame Relay and Intermediate System-to-Intermediate System (IS-IS). This example implements two dynamic tunnels (automatically set up by the ingress Label Switch Routers [LSR]) and two tunnels that use explicit paths.
TE is a generic name that corresponds to the use of different technologies to optimize the utilization of a given backbone capacity and topology.
MPLS TE provides a way to integrate TE capabilities (such as those used on Layer 2 protocols like ATM) into Layer 3 protocols (IP). MPLS TE uses an extension to existing protocols (Resource Reservation Protocol [RSVP], IS-IS, Open Shortest Path First [OSPF]) to calculate and establish unidirectional tunnels that are set according to the network constraint. Traffic flows are mapped on the different tunnels depending on their destination.
[B]Prerequisites[/B]

[B]Requirements[/B]

There are no specific requirements for this document.
[B]Components Used[/B]

The information in this document is based on these software and hardware versions:

[LIST][*] Cisco IOS® Software Releases 12.0(11)S and 12.1(3a)T[*] Cisco 3600 routers[/LIST]
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
[B]Conventions[/B]

For more information on document conventions, refer to [URL="http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080121ac5.shtml"]Cisco Technical Tips Conventions[/URL].
[B]Functional Components[/B]

Component
Description
IP tunnel interfaces
Layer 2: An MPLS tunnel interface is the head of a Label Switched Path (LSP). It is configured with a set of resource requirements, such as bandwidth and priority.
Layer 3: The LSP tunnel interface is the head-end of a unidirectional virtual link to the tunnel destination.
RSVP with TE extension
RSVP is used to establish and maintain LSP tunnels based on the calculated path using PATH and RESV messages. The RSVP protocol specification has been extended so that the RESV messages also distribute label information.
Link-state IGP (IS-IS or OSPF with TE extension)
Used to flood topology and resource information from the link management module. IS-IS uses new Type-Length-Values (TLVs) and OSPF uses type 10 Link State Advertisements (also called Opaque LSAs).
MPLS TE path calculation module
Operates at the LSP head only and determines a path using information from the link-state database.
MPLS TE link management module
At each LSP hop, this module performs link call admission on the RSVP signaling messages, and bookkeeping of topology and resource information to be flooded by OSPF or IS-IS.
Label switching forwarding
Basic MPLS forwarding mechanism based on labels.

[B]Configure[/B]

[B]Network Diagram[/B]

This document uses the network setup shown in this diagram.
[IMG]http://www.cisco.com/image/gif/paws/13737/mplsteisis1.gif[/IMG]
[B]Configurations[/B]

[B]Quick Configurations Guide[/B]

This procedure can be used to perform a quick configuration. For more detailed information, refer to [URL="http://www.cisco.com/en/US/docs/ios/12_1t/12_1t3/feature/guide/traffeng.html"]MPLS Traffic Engineering and Enhancements[/URL].

[LIST=1][*] Set up your network with the usual configuration (in this case, Frame Relay is used).
[B]Note: [/B]It is mandatory to set up a loopback interface with a IP mask of 32 bits.
This address is used for the set up of the MPLS network and TE by the routing protocol. This loopback address must be reachable via the global routing table.[*] Set up a routing protocol for the MPLS network. It must be a link-state protocol (IS-IS or OSPF). In the routing protocol configuration mode, enter:

[LIST][*] For IS-IS:
[INDENT]metric-style wide (or metric-style both)
mpls traffic-eng router-id LoopbackN
mpls traffic-eng [level-1 | level-2 |][/INDENT][*] For OSPF:
[INDENT]mpls traffic-eng area X
mpls traffic-eng router-id LoopbackN (must have a 255.255.255.255 mask)[/INDENT][/LIST]
[*] Enable MPLS TE. Enter [B]ip cef[/B] (or [B]ip cef distributed[/B] if available in order to enhance performance) in the general configuration mode. Enable MPLS ([B]tag-switching ip[/B]) on each concerned interface. Enter [B]mpls traffic-engineering tunnel[/B] to enable MPLS TE, as well as RSVP for zero-bandwidth TE tunnels.[*] Enable RSVP by entering [B]ip rsvp bandwidth XXX[/B] on each concerned interface for non-zero bandwidth tunnels.[*] Set up tunnels to be used for TE. There are many options that can be configured for MPLS TE tunnel, but the [B]tunnel mode mpls traffic-eng[/B] command is mandatory. The [B]tunnel mpls traffic-eng autoroute announce[/B] command announces the presence of the tunnel by the routing protocol.[/LIST]
[B]Note: [/B]Do not forget to use [B]ip unnumbered loopbackN[/B] for the IP address of the tunnel interfaces.
This sample configuration shows two dynamic tunnels with different bandwidth (and priorities) that go from the Pescara router to the Pesaro router, and two tunnels that use an explicit path that goes from Pesaro to Pescara.
[B]Configuration File[/B]

Only the relevant parts of the configuration files are included. The commands used to enable MPLS are italicized, while the commands specific to TE (including RSVP) are in bold.
Pesaro
Current configuration:
!
version 12.1
!
hostname Pesaro
!
[I]ip cef[/I]
[B]mpls traffic-eng tunnels[/B]
!
interface Loopback0
ip address 10.10.10.6 255.255.255.255
ip router isis
[B]!
interface Tunnel158
ip unnumbered Loopback0
tunnel destination 10.10.10.4
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 2 2
tunnel mpls traffic-eng bandwidth 158
tunnel mpls traffic-eng path-option 1 explicit name low
!
interface Tunnel159
ip unnumbered Loopback0
tunnel destination 10.10.10.4
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 4 4
tunnel mpls traffic-eng bandwidth 159
tunnel mpls traffic-eng path-option 1 explicit name straight
![/B]

interface Serial0/0
no ip address
encapsulation frame-relay
!
interface Serial0/0.1 point-to-point
bandwidth 512
ip address 10.1.1.22 255.255.255.252
ip router isis
[I]tag-switching ip[/I]
[B]mpls traffic-eng tunnels[/B]
frame-relay interface-dlci 603
[B]ip rsvp bandwidth 512 512[/B]
!
router isis
net 49.0001.0000.0000.0006.00
is-type level-1
metric-style wide
mpls traffic-eng router-id Loopback0
mpls traffic-eng level-1
!
!
ip classless
!
[B]ip explicit-path name low enable
next-address 10.1.1.21
next-address 10.1.1.10
next-address 10.1.1.1
next-address 10.1.1.14
!
ip explicit-path name straight enable
next-address 10.1.1.21
next-address 10.1.1.5
next-address 10.1.1.14[/B]
!
end
Pescara
Current configuration:
!
version 12.0
!
hostname Pescara
!

[I]ip cef[/I]
!
[B]mpls traffic-eng tunnels[/B]
!
interface Loopback0
ip address 10.10.10.4 255.255.255.255
ip router isis
!
[B]interface Tunnel1
ip unnumbered Loopback0

tunnel destination 10.10.10.6
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 5 5
tunnel mpls traffic-eng bandwidth 25
tunnel mpls traffic-eng path-option 2 dynamic
!
interface Tunnel3
ip unnumbered Loopback0

tunnel destination 10.10.10.6
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 6 6
tunnel mpls traffic-eng bandwidth 69
tunnel mpls traffic-eng path-option 1 dynamic
![/B]

interface Serial0/1
no ip address
encapsulation frame-relay
!
interface Serial0/1.1 point-to-point
bandwidth 512
ip address 10.1.1.14 255.255.255.252

ip router isis
[B]mpls traffic-eng tunnels[/B]
[I]tag-switching ip[/I]
frame-relay interface-dlci 401
[B]ip rsvp bandwidth 512 512[/B]
!
router isis
net 49.0001.0000.0000.0004.00
is-type level-1
[B]metric-style wide
mpls traffic-eng router-id Loopback0
mpls traffic-eng level-1[/B]
!
end
Pomerol
Current configuration:

version 12.0
!
hostname Pomerol
!
[I]ip cef[/I]
!
[B]mpls traffic-eng tunnels[/B]
!
interface Loopback0
ip address 10.10.10.3 255.255.255.255
ip router isis
!
interface Serial0/1
no ip address
encapsulation frame-relay
!
interface Serial0/1.1 point-to-point
bandwidth 512
ip address 10.1.1.6 255.255.255.252
ip router isis
[B]mpls traffic-eng tunnels[/B]
[I]tag-switching ip[/I]
frame-relay interface-dlci 301
[B]ip rsvp bandwidth 512 512[/B]
!
interface Serial0/1.2 point-to-point
bandwidth 512
ip address 10.1.1.9 255.255.255.252
ip router isis
[B]mpls traffic-eng tunnels[/B]
[I]tag-switching ip[/I]
frame-relay interface-dlci 302
[B]ip rsvp bandwidth 512 512[/B]
!
interface Serial0/1.3 point-to-point
bandwidth 512
ip address 10.1.1.21 255.255.255.252
ip router isis
[B]mpls traffic-eng tunnels[/B]
[I]tag-switching ip[/I]
frame-relay interface-dlci 306
[B]ip rsvp bandwidth 512 512[/B]
!
router isis
net 49.0001.0000.0000.0003.00
is-type level-1
[B]metric-style wide
mpls traffic-eng router-id Loopback0
mpls traffic-eng level-1[/B]
!
ip classless
!
end
Pulligny
Current configuration:
!
version 12.1
!
hostname Pulligny
!
[I]ip cef[/I]
!
[B]mpls traffic-eng tunnels[/B]
!
interface Loopback0
ip address 10.10.10.2 255.255.255.255
!
interface Serial0/1
no ip address
encapsulation frame-relay
!
interface Serial0/1.1 point-to-point
bandwidth 512
ip address 10.1.1.2 255.255.255.252
ip router isis
[B]mpls traffic-eng tunnels[/B]
[I]tag-switching ip[/I]
frame-relay interface-dlci 201
[B]ip rsvp bandwidth 512 512[/B]
!
interface Serial0/1.2 point-to-point
bandwidth 512
ip address 10.1.1.10 255.255.255.252
ip router isis
[B]mpls traffic-eng tunnels[/B]
[I]tag-switching ip[/I]
frame-relay interface-dlci 203
[B]ip rsvp bandwidth 512 512[/B]
!
router isis
passive-interface Loopback0
net 49.0001.0000.0000.0002.00
is-type level-1
[B]metric-style wide
mpls traffic-eng router-id Loopback0
mpls traffic-eng level-1[/B]
!
ip classless
!
end
Pauillac
!
version 12.1
!
hostname pauillac
!
[I]ip cef[/I]
[B]mpls traffic-eng tunnels[/B]
!
interface Loopback0
ip address 10.10.10.1 255.255.255.255
ip router isis
!
interface Serial0/0
no ip address
encapsulation frame-relay
!
interface Serial0/0.1 point-to-point
bandwidth 512
ip address 10.1.1.1 255.255.255.252
ip router isis
[B]mpls traffic-eng tunnels[/B]
[I]tag-switching ip[/I]
frame-relay interface-dlci 102
[B]ip rsvp bandwidth 512 512[/B]
!
interface Serial0/0.2 point-to-point
bandwidth 512
ip address 10.1.1.5 255.255.255.252
ip router isis
[B]mpls traffic-eng tunnels[/B]
[I]tag-switching ip[/I]
frame-relay interface-dlci 103
ip rsvp bandwidth 512 512
!
interface Serial0/0.3 point-to-point
bandwidth 512
ip address 10.1.1.13 255.255.255.252
ip router isis
[B]mpls traffic-eng tunnels[/B]
[I]tag-switching ip[/I]
frame-relay interface-dlci 104
[B]ip rsvp bandwidth 512 512[/B]
!
router isis
net 49.0001.0000.0000.0001.00
is-type level-1
[B]metric-style wide
mpls traffic-eng router-id Loopback0
mpls traffic-eng level-1[/B]
!
ip classless
!
end
[B]Verify[/B]

[B]show Commands[/B]

This section provides information you can use to confirm your configuration is working properly.
The [URL="https://www.cisco.com/cgi-bin/Support/OutputInterpreter/home.pl"]Output Interpreter Tool[/URL] ([SIZE=-1][URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) (OIT) supports certain [B]show[/B] commands. Use the OIT to view an analysis of [B]show[/B] command output.

[LIST][*] [B]show mpls traffic-eng tunnels brief[/B][*] [B]show mpls traffic-eng tunnels name Pesaro_t158[/B][*] [B]show ip rsvp interface[/B][*] [B]show mpls traffic-eng topology path destination 10.10.10.6 bandwidth 75[/B][/LIST]
Other useful commands (not illustrated here) include:

[LIST][*] [B]show isis mpls traffic-eng advertisements[/B][*] [B]show tag-switching forwarding-table[/B][*] [B]show ip cef[/B][*] [B]show mpls traffic-eng tunnels summary[/B][/LIST]
[B]Sample show Output[/B]

On any LSR, you can use [B]show mpls traffic-eng tunnels[/B] to check the existence and state of the tunnels. For example, on Pesaro, you see a total of four tunnels, two that arrive at Pesaro (Pescara_t1 and t3) and two that start from Pesaro (t158 and t159):
[INDENT]Pesaro#[B]show mpls traffic-eng tunnels brief[/B]
Signaling Summary:
LSP Tunnels Process: running
RSVP Process: running
Forwarding: enabled
Periodic reoptimization: every 3600 seconds, next in 606 seconds
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
[B]Pesaro_t158 10.10.10.4 - Se0/0.1 up/up
Pesaro_t159 10.10.10.4 - Se0/0.1 up/up
Pescara_t1 10.10.10.6 Se0/0.1 - up/up
Pescara_t3 10.10.10.6 Se0/0.1 - up/up[/B]
Displayed [B]2 (of 2) heads[/B], 0 (of 0) midpoints,[B]2 (of 2) tails[/B][/INDENT]This is what is seen while on a middle router:
[INDENT]Pulligny#[B]show mpls traffic-eng tunnels brief[/B]
Signaling Summary:
LSP Tunnels Process: running
RSVP Process: running
Forwarding: enabled
Periodic reoptimization: every 3600 seconds, next in 406 seconds
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
[B]Pescara_t3 10.10.10.6 Se0/1.1 Se0/1.2 up/up
Pesaro_t158 10.10.10.4 Se0/1.2 Se0/1.1 up/up[/B]
Displayed 0 (of 0) heads, 2 (of 2) midpoints, 0 (of 0) tails[/INDENT]The detailed configuration of any tunnel can be seen using this:
[INDENT]Pesaro#[B]show mpls traffic-eng tunnels name Pesaro_t158[/B]

Name: [B]Pesaro_t158[/B] (Tunnel158) Destination: 10.10.10.4
Status:
Admin: up Oper: up Path: valid Signaling: connected

path option 1, type explicit low (Basis for Setup, path weight 40)

Config Parameters:
Bandwidth: 158 kbps Priority: 2 2 Affinity: 0x0/0xFFFF
AutoRoute: enabled LockDown: disabled

InLabel : -
OutLabel : Serial0/0.1, 17
RSVP Signaling Info:
Src 10.10.10.6, Dst 10.10.10.4, Tun_Id 158, Tun_Instance 1601
RSVP Path Info:
My Address: 10.10.10.6
Explicit Route: [B]10.1.1.21 10.1.1.10 10.1.1.1 10.1.1.14
10.10.10.4[/B]
Record Route: NONE
Tspec: ave rate=158 kbits, burst=8000 bytes, peak rate=158 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=158 kbits, burst=8000 bytes, peak rate=4294967 kbits
History:
Current LSP:
Uptime: 3 hours, 33 minutes
Selection: reoptimation
Prior LSP:
ID: path option 1 [1600]
Removal Trigger: configuration changed[/INDENT]In this case, the path is explicit and specified in the RSVP message (the field that carries the path is also known as the Explicit Route Object [ERO]). If this path cannot be followed, the MPLS TE engine uses the next path option, which can be another explicit route or a dynamic route.
RSVP specific information is available using standard RSVP commands. In this output, there are two reservations made on Pulligny, one by Pesaro_t158 (158K) and the other by Pescara_t3 (69k).
[INDENT]Pulligny#[B]show ip rsvp interface[/B]
interface allocated i/f max flow max pct UDP IP UDP_IP UDP M/C
Se0/1 0M 0M 0M 0 0 0 0 0
[B]Se0/1.1 158K 512K 512K 30 0 1 0 0
Se0/1.2 69K 512K 512K 13 0 1 0 0[/B][/INDENT]If you want to know which TE path is used for a particular destination (and a particular bandwidth) without creating a tunnel, you can use this command:
[B]Note: [/B]Please note that this command is wrapped to a second line for spatial reasons.
[INDENT]Pescara#[B]show mpls traffic-eng topology path destination
10.10.10.6 bandwidth 75[/B]
Query Parameters:
Destination: 10.10.10.6
Bandwidth: 75
Priorities: 0 (setup), 0 (hold)
Affinity: 0x0 (value), 0xFFFFFFFF (mask)
Query Results:
Min Bandwidth Along Path: 385 (kbps)
Max Bandwidth Along Path: 512 (kbps)
Hop 0: 10.1.1.14 : affinity 00000000, bandwidth 512 (kbps)
Hop 1: 10.1.1.5 : affinity 00000000, bandwidth 385 (kbps)
Hop 2: 10.1.1.21 : affinity 00000000, bandwidth 512 (kbps)
Hop 3: 10.10.10.6[/INDENT]If the network does IP TTL propagation (refer to [URL="http://www.cisco.com/en/US/docs/ios/12_1t/12_1t3/feature/guide/rtr_13t.html#xtocid516027"][B]mpls ip ttl propagate[/B][/URL] ), issue a [B]traceroute[/B] command and see that the path followed is the tunnel and that the tunnel routes according to what is configured:
[INDENT]Pescara#[B]traceroute 10.10.10.6[/B]

Type escape sequence to abort.
Tracing the route to 10.10.10.6

1 10.1.1.13 [MPLS: Label 29 Exp 0] 540 msec 312 msec 448 msec
2 10.1.1.2 [MPLS: Label 27 Exp 0] 260 msec 276 msec 556 msec
3 10.1.1.9 [MPLS: Label 29 Exp 0] 228 msec 244 msec 228 msec
4 10.1.1.22 112 msec * 104 msec[/INDENT][B]Related Information[/B]

[LIST][*][B][URL="http://www.cisco.com/en/US/tech/tk436/tk428/tsd_technology_support_protocol_home.html"]MPLS Support Page[/URL][/B][*][B][URL="http://www.cisco.com/en/US/tech/tk365/tk381/tsd_technology_support_sub-protocol_home.html"]IS-IS Support Page[/URL][/B][*][B][URL="http://www.cisco.com/en/US/support/index.html"]Technical Support & Documentation - Cisco Systems[/URL][/B][/LIST]

Updated: Aug 10, 2005

[/LEFT]
2010-02-11, 10:26 PM
patris1

[LEFT][B][B][SIZE=3]Configuring MPLS Basic VPN with RIP on Customer Side[/SIZE][/B][/B]

[B]Document ID: 13732[/B]

[B]Contents[/B]

[INDENT][B]Introduction
[/B] [B]Prerequisites
Requirements
Components Used
Network Description
Conventions
[/B] [B]Configuration Procedure
Network Diagram
Part I
Part II
Configuration Examples
[/B] [B]debug and show Commands
MPLS Labels
Address Overlapping
[/B] [B]Sample Debug Output
[/B] [B]Troubleshoot
[/B] [B]Related Information[/B][/INDENT][B]Introduction[/B]

This sample configuration shows a Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) when Routing Information Protocol (RIP) is present on the customer's side.
The VPN feature, when used with MPLS, allows several sites to transparently interconnect through a service provider's network. One service provider network can support several different IP VPNs. Each IP VPN appears as a private network, separate from all other networks. Each site in a VPN sends IP packets to other sites in the same VPN.
Each VPN is associated with one or more VPN routing or forwarding instances (VRFs). A VRF consists of an IP routing table, a derived Cisco express forwarding (CEF) table, and a set of interfaces that use the forwarding table.
The router maintains a separate routing and CEF table for each VRF. This prevents information from being sent outside the VPN and allows the same subnet to be used in several VPNs without causing duplicate IP address problems.
The router using Border Gateway Protocol (BGP) distributes the VPN routing information using the BGP extended communities.
For more information regarding the propagation of updates through a VPN see the VPN Route Target Communities, BGP Distribution of VPN Routing Information, and MPLS Forwarding sections in [URL="http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/VPN.html"]MPLS Virtual Private Networks[/URL].
[B]Prerequisites[/B]

[B]Requirements[/B]

There are no specific prerequisites for this document.
[B]Components Used[/B]

We developed and tested this configuration using the software and hardware versions below:

[LIST][*] [B]PE routers[/B]: The MPLS VPN functionality resides in the PE routers. Use [URL="http://www.cisco.com/go/fn"]Feature Navigator II[/URL] ([SIZE=-1][URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) to determine which hardware and software combinations you can use.[*] [B]CE routers[/B]: Use any router able to exchange routing information with its PE router.[*] [B]P routers and switches[/B]: In this document, ATM switches such as the MSR, the BPX and the MGX were used. However, because the document focuses on the MPLS VPN feature we could also have used frame based MPLS in the core with routers, such as the Cisco 12000.[/LIST]
The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.
[B]Network Description[/B]

We set up a standard MPLS ATM backbone using Open Shortest Path First (OSPF) area 0 as the Interior Gateway Protocol (IGP). We configured two different VPNs using this backbone. The first VPN uses RIP as its customer-edge to provider-edge (CE-PE) routing protocol; the other VPN uses BGP as its PE-CE routing protocol. We configured various loopback and static routes on the CE routers to simulate the presence of other routers and networks.
[B]Note: [/B]BGP must be used as the VPN IGP between PE routers, since using BGP extended communities is the only way to transport routing information for the VPN between the PE routers.
[B]Note: [/B]An ATM network was used as the backbone network to make this configuration. This configuration applies to ATM (and other) protocol(s). PE routers must be able to reach each other using the MPLS network for the VPN configuration to work.
[B]Conventions[/B]

The letters below represent the different types of routers and switches used:

[LIST][*] P: Provider's core router[*] PE: Provider's edge router[*] CE: Customer's edge router[*] C: Customer's router[/LIST]
A typical configuration illustrating these conventions is shown in the diagram below:
[IMG]http://www.cisco.com/image/gif/paws/13732/mpls_vpn_rip_mplsvpn.gif[/IMG]
For more information on document conventions, refer to [URL="http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080121ac5.shtml"]Cisco Technical Tips Conventions[/URL].
[B]Configuration Procedure[/B]

In this section, you are presented with the information to configure the features described in this document. The Cisco IOS documentation found in [URL="http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/VPN.html"]MPLS Virtual Private Networks[/URL] also describes this configuration procedure.
[B]Note: [/B]To find additional information on the commands used in this document, use the IOS [URL="http://www.cisco.com/pcgi-bin/Support/Cmdlookup/home.pl"]Command Lookup tool[/URL] ([SIZE=-1][URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE])
[B]Network Diagram[/B]

This document uses the network setup shown in the diagram below.
[IMG]http://www.cisco.com/image/gif/paws/13732/mpls_vpn_rip_mv_rip.gif[/IMG]
[B]Part I[/B]

The steps below will help you configure correctly.
Enable the [B]ip cef[/B] command. If using a Cisco 7500 router, ensure that the [B]ip cef distributed[/B] command is enabled, where available, to enhance performances on the PE, once MPLS is set up.

[LIST=1][*] Create a VRF for each VPN using the [B]ip vrf [[I]VPN routing | forwarding instance name[/I]][/B] command. While creating the VRFs, be sure to:

[LIST][*] Specify the correct route distinguisher used for that VPN using the command below. The distinguisher is used to extend the IP address and allows you to identify to which VPN it belongs.
[INDENT][B]rd [[I]VPN route distinguisher[/I]][/B][/INDENT][*] Set up the import and export properties for the BGP extended communities using the command below. These properties are used for filtering the import and export process.
[INDENT][B]route-target {export | import | both} [[I]target VPN extended community[/I]] [/B][/INDENT][/LIST]
[*] Configure the forwarding details for the respective interfaces using the [B]ip vrf forwarding [[I]table name[/I]][/B]command and remember to set up the IP address afterwards.[*] Depending on the PE-CE routing protocol used, do one or more of the following:

[LIST][*] Configure the static routes as follows:
[INDENT][B]ip route vrf [I]vrf-name prefix mask[/I] [[I]next-hop-address[/I]] [[I]interface[/I] {[I]interface-number[/I]}] [/B][/INDENT][*] Configure the RIP using the following command:
[INDENT][B]address-family ipv4 vrf [[I]VPN routing[/I] | [I]forwarding instance name[/I]] [/B][/INDENT]Once you have completed one or both of the steps above, enter the normal RIP configuration commands.
[B]Note: [/B]These commands apply only to the forwarding interfaces of the current VRF. Redistribute the correct BGP into RIP and remember to specify the metric used.[*] Declare the BGP neighbor information.[*] Configure the OSPF using the new IOS command:
[INDENT][B]router ospf [I]process-id[/I] vrf [[I]VPN routing | forwarding instance name[/I]] [/B][/INDENT][/LIST]
[B]Note: [/B]This command applies only to the forwarding interfaces for the current VRF. Redistribute the correct BGP routing information into OSPF and specify the metric used. Once the OSPF process to a VRF is complete, even if the OSPF process is not specified in the command line, this process ID is always used for this particular VRF.
[/LIST]
[B]Part II[/B]

Configure BGP between the PE routers. There are several ways to configure BGP, such as using the route reflector or confederation methods. The method shown here is direct neighbor configuration. It is the simplest and the least scalable.

[LIST=1][*] Declare the different neighbors.[*] Enter the [B]address-family ipv4 vrf [[I]VPN routing | forwarding instance name[/I]][/B] command for each VPN present at this PE router. Carry out one or more of the following steps, as necessary:

[LIST][*] Redistribute the static routing information.[*] Redistribute the RIP routing information.[*] Redistribute the OSPF routing information.[*] Activate BGP neighboring with the CE routers.[/LIST]
[*] Enter the [B]address-family vpnv4[/B] mode and:

[LIST][*] Activate the neighbors.[*] Specify that extended community must be used. This is mandatory.[/LIST]
[/LIST]
[B]Configuration Examples[/B]

In the Alcalzaba configuration, lines specific to the VPN configuration are shown in [B]bold[/B].
Alcazaba
!
ip vrf vrf101
rd 1:101
route-target export 1:101
route-target import 1:101
!
ip cef
!
interface Loopback0
ip address 223.0.0.3 255.255.255.255
!
[B]interface Ethernet1/1
ip vrf forwarding vrf101
ip address 150.150.0.1 255.255.255.0[/B]
!
interface ATM3/0
no ip address
no ip mroute-cache
no ATM ilmi-keepalive
PVC qsaal 0/5 qsaal
PVC ilmi 0/16 ilmi
!
!
interface ATM3/0.1 tag-switching
ip address 10.0.0.17 255.255.255.252
tag-switching ATM vpi 2-4
tag-switching ip
!
interface ATM4/0
no ip address
no ATM ilmi-keepalive
!
interface ATM4/0.1 tag-switching
ip address 10.0.0.13 255.255.255.252
tag-switching ATM vpi 2-4
tag-switching ip
!
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
network 223.0.0.3 0.0.0.0 area 0
!
router rip
version 2
!
[B]address-family ipv4 vrf vrf101
version 2
redistribute bgp 1 metric 0
network 150.150.0.0
no auto-summary
exit-address-family[/B]
!
router bgp 1
no synchronization
[B] neighbor 125.2.2.2 remote-as 1
neighbor 125.2.2.2 update-source Loopback0
neighbor 223.0.0.21 remote-as 1
neighbor 223.0.0.21 update-source Loopback[/B]0
no auto-summary
!
[B] address-family ipv4 vrf vrf101
redistribute rip
no auto-summary
no synchronization
exit-address-family[/B]
!
address-family vpnv4
[B] neighbor 125.2.2.2 activate
neighbor 125.2.2.2 send-community extended
neighbor 223.0.0.21 activate
neighbor 223.0.0.21 send-community extended[/B]
no auto-summary
exit-address-family
!
Kozel
!
ip vrf vrf101
rd 1:101
route-target export 1:101
route-target import 1:101
!
ip cef
!
interface Loopback0
ip address 223.0.0.21 255.255.255.255
!
interface Ethernet1/1
ip vrf forwarding vrf101
ip address 200.200.0.1 255.255.255.0
!
interface ATM4/0
no ip address
no ATM scrambling cell-payload
no ATM ilmi-keepalive
PVC qsaal 0/5 qsaal
PVC ilmi 0/16 ilmi
!
interface ATM4/0.1 tag-switching
ip address 10.0.0.6 255.255.255.252
tag-switching ATM vpi 2-4
tag-switching ip
!
router ospf 1
log-adjacency-changes
network 10.0.0.0 0.0.0.255 area 0
network 223.0.0.21 0.0.0.0 area 0
!
router rip
version 2
!
address-family ipv4 vrf vrf101
version 2
redistribute bgp 1 metric 1
network 200.200.0.0
no auto-summary
exit-address-family
!
router bgp 1
no synchronization
neighbor 125.2.2.2 remote-as 1
neighbor 125.2.2.2 update-source Loopback0
neighbor 223.0.0.3 remote-as 1
neighbor 223.0.0.3 update-source Loopback0
no auto-summary
!
address-family ipv4 vrf vrf101
redistribute rip
no auto-summary
no synchronization
exit-address-family
!
address-family vpnv4
neighbor 125.2.2.2 activate
neighbor 125.2.2.2 send-community extended
neighbor 223.0.0.3 activate
neighbor 223.0.0.3 send-community extended
no auto-summary
exit-address-family
!
Medina
Current configuration:
!
ip vrf vrf101
rd 1:101
route-target export 1:101
route-target import 1:101
ip cef
!
interface Loopback1
ip vrf forwarding vrf101
ip address 11.2.2.2 255.255.255.252
!
interface ATM2/0
no ip address
no ATM ilmi-keepalive
!
interface ATM2/0.66 tag-switching
ip address 125.1.4.2 255.255.255.252
tag-switching ip
!
interface Ethernet1/1
ip vrf forwarding vrf101
ip address 11.3.3.1 255.255.255.252
!
router ospf 1

network 125.1.4.0 0.0.0.3 area 0
network 125.2.2.2 0.0.0.0 area 0
!
router rip
version 2
network 11.0.0.0
!
address-family ipv4 vrf vrf101
version 2
redistribute bgp 1 metric 1
network 11.0.0.0
no auto-summary
exit-address-family
!
router bgp 1
no synchronization
neighbor 223.0.0.3 remote-as 1
neighbor 223.0.0.3 update-source Loopback0
neighbor 223.0.0.21 remote-as 1
neighbor 223.0.0.21 update-source Loopback0
!
address-family ipv4 vrf vrf101
redistribute connected
redistribute static
redistribute rip
default-information originate
no auto-summary
no synchronization
exit-address-family
!
address-family vpnv4
neighbor 223.0.0.3 activate
neighbor 223.0.0.3 send-community extended
neighbor 223.0.0.21 activate
neighbor 223.0.0.21 send-community extended
exit-address-family
!
Rapid
Current configuration:

!
interface Loopback0
ip address 223.0.0.12 255.255.255.255
!
interface Loopback2
ip address 7.7.7.7 255.255.255.0
!
interface FastEthernet0/1
ip address 150.150.0.2 255.255.255.0
duplex auto
speed auto
!
router rip
version 2
redistribute static
network 7.0.0.0
network 10.0.0.0
network 150.150.0.0
no auto-summary
!
ip route 158.0.0.0 255.0.0.0 Null0
!
Damme
!
interface Loopback1
ip address 6.6.6.6 255.0.0.0
!
interface FastEthernet0/0
ip address 10.200.10.14 255.255.252.0
duplex auto
speed autoa
!
router bgp 158
no synchronization
network 6.0.0.0
network 10.200.0.0 mask 255.255.252.0
neighbor 10.200.10.3 remote-as 1
no auto-summary
!
Pivrnec
Current configuration:
!
interface Loopback0
ip address 223.0.0.22 255.255.255.255
!
interface Loopback1
ip address 6.6.6.6 255.255.255.255
!
interface FastEthernet0/1
ip address 200.200.0.2 255.255.255.0
duplex auto
speed auto
!
router rip
version 2
redistribute static
network 6.0.0.0
network 200.200.0.0
no auto-summary
!
ip route 69.0.0.0 255.0.0.0 Null0
!
Guilder
!
interface Loopback2
ip address 150.150.0.1 255.255.0.0
!
interface Ethernet0/2
ip address 201.201.201.2 255.255.255.252
!
router bgp 69
no synchronization
network 7.7.7.0 mask 255.255.0.0
network 150.150.0.0
network 201.201.201.0 mask 255.255.255.252
redistribute connected
neighbor 201.201.201.1 remote-as 1
no auto-summary
!
Purkmister
Current configuration:
!
interface Loopback0
ip address 11.5.5.5 255.255.255.252
!
interface FastEthernet0/1
ip address 11.3.3.2 255.255.255.252
duplex auto
speed auto
!
router rip
version 2
network 11.0.0.0
!
[B]debug and show Commands[/B]

Before you use [B]debug[/B] commands, refer to [URL="http://www.cisco.com/en/US/tech/tk801/tk379/technologies_tech_note09186a008017874c.shtml"]Important Information on Debug Commands[/URL]. Routing-specific commands are listed here:

[LIST][*] [B]show ip rip database vrf[/B] - Shows information contained in the RIP database for a particular VRF.[*] [B]show ip bgp vpnv4 vrf[/B] - Displays VPN address information from the BGP table.[*] [B]show ip route vrf[/B] - Displays the IP routing table associated with a VRF.[*] [B]show ip route[/B] - Displays all static IP routes, or those installed using the authentication, authorization, and accounting (AAA) route download function.[/LIST]
Certain [B]show[/B] commands are supported by the [URL="https://www.cisco.com/cgi-bin/Support/OutputInterpreter/home.pl"]Output Interpreter tool[/URL] ([SIZE=-1][URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) , which allows you to view an analysis of [B]show[/B] command output.
On a PE router, the PE-CE routing method such as RIP, BGP, or static, and the PE-PE BGP updates indicate the routing table used for a particular VRF. You can display the RIP information for a particular VRF as follows:
[INDENT]Alcazaba# [B]show ip rip database vrf vrf101[/B]
0.0.0.0/0 auto-summary
0.0.0.0/0
[2] via 150.150.0.2, 00:00:12, Ethernet1/1
6.0.0.0/8 auto-summary
6.6.6.6/32 redistributed
[1] via 223.0.0.21,
7.0.0.0/8 auto-summary
7.7.7.0/24
[1] via 150.150.0.2, 00:00:12, Ethernet1/1
10.0.0.0/8 auto-summary
10.0.0.0/8 redistributed
[1] via 125.2.2.2,
10.0.0.0/16
[1] via 150.150.0.2, 00:00:12, Ethernet1/1
10.200.8.0/22
[1] via 150.150.0.2, 00:00:12, Ethernet1/1
11.0.0.0/8 auto-summary
11.0.0.4/30 redistributed
[1] via 125.2.2.2,
11.1.1.0/30 redistributed
[1] via 125.2.2.2,
11.3.3.0/30 redistributed
[1] via 125.2.2.2,
11.5.5.4/30 redistributed
[1] via 125.2.2.2,
69.0.0.0/8 auto-summary
69.0.0.0/8 redistributed
[1] via 223.0.0.21,
150.150.0.0/16 auto-summary
150.150.0.0/24 directly connected, Ethernet1/1
158.0.0.0/8
[1] via 150.150.0.2, 00:00:17, Ethernet1/1
200.200.0.0/24 auto-summary
200.200.0.0/24 redistributed
[1] via 223.0.0.21,[/INDENT]You can display the BGP information for a particular VRF using the [B]show ip bgp vpnv4 vrf[/B] command. The PE-PE results from the internal BGP (iBGP) are indicated by an i in the output below.
[INDENT]Alcazaba# [B]show ip bgp vpnv4 vrf vrf101[/B]
BGP table version is 46, local router ID is 223.0.0.3
Status codes: s suppressed, d damped, h history, * valid, best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:101 (default for vrf vrf101)
*i6.6.6.6/32 223.0.0.21 1 100 0 ?
* 7.7.7.0/24 150.150.0.2 1 32768 ?
* 10.0.0.0/16 150.150.0.2 1 32768 ?
* 10.200.8.0/22 150.150.0.2 1 32768 ?
*i11.2.2.0/30 125.2.2.2 0 100 0 ?
*i11.3.3.0/30 125.2.2.2 0 100 0 ?
*i11.5.5.4/30 125.2.2.2 1 100 0 ?
*i69.0.0.0 223.0.0.21 1 100 0 ?
* 150.150.0.0/24 0.0.0.0 0 32768 ?
* 158.0.0.0/8 150.150.0.2 1 32768 ?
*i200.200.0.0 223.0.0.21 0 100 0 ?[/INDENT]Check the global routing table for a VRF on both the PE and the CE routers. These VRFs should match. For the PE router, you have to specify the VRF using the [B]show ip route vrf[/B] command:
[INDENT]Alcazaba# [B]show ip route vrf vrf101[/B]
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - ISIS, L1 - ISIS level-1, L2 - ISIS level-2, IA - ISIS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
B 69.0.0.0/8 [200/1] via 223.0.0.21, 00:11:03
B 200.200.0.0/24 [200/0] via 223.0.0.21, 00:11:03
6.0.0.0/32 is subnetted, 1 subnets
B 6.6.6.6 [200/1] via 223.0.0.21, 00:11:03
7.0.0.0/24 is subnetted, 1 subnets
R 7.7.7.0 [120/1] via 150.150.0.2, 00:00:05, Ethernet1/1
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
R 10.0.0.0/16 [120/1] via 150.150.0.2, 00:00:05, Ethernet1/1

R 10.200.8.0/22 [120/1] via 150.150.0.2, 00:00:05, Ethernet1/1
11.0.0.0/30 is subnetted, 3 subnets
B 11.3.3.0 [200/0] via 125.2.2.2, 00:07:05
B 11.2.2.0 [200/0] via 125.2.2.2, 00:07:05
B 11.5.5.4 [200/1] via 125.2.2.2, 00:07:05
150.150.0.0/24 is subnetted, 1 subnets
C 150.150.0.0 is directly connected, Ethernet1/1
R 158.0.0.0/8 [120/1] via 150.150.0.2, 00:00:06, Ethernet1/1[/INDENT]The equivalent command on Pivrnec is the [B]show ip route[/B] command, since for every customer (and customer edge) router this is the standard routing table.
[INDENT]Pivrnec# [B]show ip route [/B]
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - ISIS, L1 - ISIS level-1, L2 - ISIS level-2, IA - ISIS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route Gateway of last resort is not
set S 69.0.0.0/8 is directly connected, Null0
223.0.0.0/32 is subnetted, 1 subnets
C 223.0.0.22 is directly connected, Loopback0
C 200.200.0.0/24 is directly connected, FastEthernet0/1
6.0.0.0/32 is subnetted, 1 subnets
C 6.6.6.6 is directly connected, Loopback1
7.0.0.0/24 is subnetted, 1 subnets
R 7.7.7.0 [120/1] via 200.200.0.1, 00:00:23, FastEthernet0/1
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
R 10.0.0.0/16 [120/1] via 200.200.0.1, 00:00:23, FastEthernet0/1
R 10.200.8.0/22 [120/1] via 200.200.0.1, 00:00:24, FastEthernet0/1
11.0.0.0/30 is subnetted, 3 subnets
R 11.3.3.0 [120/1] via 200.200.0.1, 00:00:24, FastEthernet0/1
R 11.2.2.0 [120/1] via 200.200.0.1, 00:00:25, FastEthernet0/1
R 11.5.5.4 [120/1] via 200.200.0.1, 00:00:25, FastEthernet0/1
150.150.0.0/24 is subnetted, 1 subnets
R 150.150.0.0 [120/1] via 200.200.0.1, 00:00:25, FastEthernet0/1
R 158.0.0.0/8 [120/1] via 200.200.0.1, 00:00:25, FastEthernet0/1[/INDENT][B]MPLS Labels[/B]

Check the label stack used for any route as follows:
[INDENT]Alcazaba# [B]show tag-switching forwarding-table vrf vrf101 11.5.5.5 detail[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
None 2/91 11.5.5.4/30 0 AT4/0.1 point2point
MAC/Encaps=4/12, MTU=4466, [B]Tag Stack{2/91(vcd=69) 37}[/B]
00458847 0004500000025000[/INDENT]You can use the normal commands for viewing the tag allocations along with the virtual path identifier and virtual channel identifier (VPI/VCI) relations as shown in [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a0080093fcd.shtml"]How to Troubleshoot the MPLS VPN[/URL] .
[B]Address Overlapping[/B]

You can use the same address in different VPNs without interfering with other VPNs. In this example, the 6.6.6.6 address is connected twice, to Pivrnec in the VPN 101 and to Damme in the VPN 102. We can check this using the [B]ping[/B] command on one site and the [B]debug ip icmp[/B] command on the other site.
[INDENT]Guilder# [B]ping 6.6.6.6[/B]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

Damme# [B]debug ip icmp[/B]
ICMP packet debugging is on
6d22h: ICMP: echo reply sent, src 6.6.6.6, DST 201.201.201.2
6d22h: ICMP: echo reply sent, src 6.6.6.6, DST 201.201.201.2
6d22h: ICMP: echo reply sent, src 6.6.6.6, DST 201.201.201.2
6d22h: ICMP: echo reply sent, src 6.6.6.6, DST 201.201.201.2
6d22h: ICMP: echo reply sent, src 6.6.6.6, DST 201.201.201.2[/INDENT][B]Sample Debug Output[/B]

Refer to [URL="http://www.cisco.com/en/US/tech/tk436/tk798/technologies_tech_note09186a0080093d42.shtml"]Packet Flow in an MPLS VPN Environment[/URL] to see sample output using the same configuration.
[B]Troubleshoot[/B]

There is currently no specific troubleshooting information available for this configuration.
[B]Related Information[/B]

[LIST][*][B][URL="http://www.cisco.com/public/support/tac/tools.shtml"]Technical Support - Tools & Resources[/URL][/B][*][B][URL="http://www.cisco.com/web/psa/technologies/tsd_technology_support_configure_guide.html?c=268435750"]MPLS Support Page[/URL][/B][*][B][URL="http://www.cisco.com/en/US/support/index.html"]Technical Support - Cisco Systems[/URL][/B][/LIST]

Updated: Nov 16, 2007

[/LEFT]
2010-02-11, 10:28 PM
patris1

[LEFT][B][SIZE=2][B]Multiprotocol Label Switching over ATM (MPLS over ATM)[/B][/SIZE][/B]

[B][SIZE=3][B]Configuring VPN MPLS over ATM with Cisco 7500 Routers and LightStream 1010 Switches[/B][/SIZE][/B]

[B]Document ID: 10533[/B]

[B]Contents[/B]

[INDENT][B]Introduction
[/B] [B]Prerequisites
Requirements
Conventions
[/B] [B]Configure
Network Diagram
Network Description
Configurations
[/B] [B]Related Information[/B][/INDENT][B]Introduction[/B]

This document shows how to configure Virtual Private Network (VPN) Multiprotocol Label Switching (MPLS) over ATM with Cisco 7500 routers as Label Edge Routers (LERs) and LightStream 1010 switches as Label Switch Routers (LSRs). Two ethernet-connected routers, each on a remote customer site, are part of a VPN. In this document, we look at the end-to-end device configurations and helpful show commands.
[B]Prerequisites[/B]

[B]Requirements[/B]

There are no specific requirements for this document.
[B]Conventions[/B]

Refer to [URL="http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080121ac5.shtml"]Cisco Technical Tips Conventions[/URL] for more information on document conventions.
[B]Configure[/B]

In this section, you are presented with the information to configure the features described in this document.
[B]Network Diagram[/B]

This document uses this network setup:
[IMG]http://www.cisco.com/image/gif/paws/10533/vpn-mpls-1.gif[/IMG]
[B]Network Description[/B]

The current setup contains these elements in VPN terminology:

[LIST][*] CE = Customer Edge Router[*] PE = Provider Edge Router[*] P=Provider Router[/LIST]
The current setup contains these elements in MPLS terminology:

[LIST][*] LER = Label Edge Router[*] LSR = Label Switch Router[*] TDP/LDP = Tag Distribution Protocol/Label Distribution Protocol[/LIST]
[B]Configurations[/B]

This document uses these configurations:

[LIST][*] PE1 and PE2 are the LERs in our ATM network.[*] P1 and P2 are the LSRs.[*] CE1 and CE2 are Customer Edge Routers that are unaware and do not carry out VPN or MPLS.[*] CE1 and CE2 are Ethernet connected to PE1 and PE2 respectively, and carry out Routing Information Protocol (RIP).[*] PE1, PE2, P1 and P2 do Open Shortest Path First (OSPF) and are all in Area 0. OSPF is the Interior Gateway Protocol (IGP) used in the ATM network. Tag-switching is used on the ATM interfaces on all four ATM devices. Tag Distribution Protocol (TDP) assigns Tags to the OSPF routes.[*] PE1 and PE2 are Multiprotocol-Border Gateway Protocol (MP-BGP) peers.[*] RIP routes are redistributed into MP-BGP. MP-BGP routes redistributed into RIP on PE1 and PE2 routers.[*] The setup maintains separate VRF routing tables in the PE1 and PE2 routers.[*] The name of the VPN used in this example is NEW.[/LIST]
CE1
!
version 12.1
service timestamps debug datetime msec
service timestamps log datetime msec

!
boot system flashow c4500-js-mz.121-5
!

ip subnet-zero

!
interface Loopback0
ip address 10.1.1.1 255.255.255.0
!
interface Loopback1
ip address 10.2.2.2 255.255.255.0
!
interface Loopback2
ip address 10.3.3.3 255.255.255.0
!
interface Ethernet0
ip address 100.1.1.2 255.255.255.0
media-type 10BaseT

!

router rip
version 2
network 10.0.0.0
network 100.0.0.0
no auto-summary
!
ip classless
!

PE1
!
version 12.1

service timestamps debug uptime
service timestamps log uptime

!
boot system flashow slot1:rsp-jsv-mz.121-5a.bin
!

ip subnet-zero

!
ip vrf NEW
rd 200:1
route-target export 200:1
route-target import 200:1
ip cef distributed

!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface ATM2/0/0
mtu 1500
no ip address
!
interface ATM2/0/0.10 tag-switching
ip unnumbered Loopback0
tag-switching ip
!
interface Ethernet2/1/0
ip vrf forwarding NEW
ip address 100.1.1.1 255.255.255.0

!
router ospf 100
no log-adjacency-changes
network 1.0.0.0 0.255.255.255 area 0
network 100.1.1.0 0.0.0.255 area 0
!
router rip
version 2
network 100.0.0.0
no auto-summary
!
address-family ipv4 vrf NEW
version 2
redistribute bgp 200 metric 0
network 100.0.0.0
no auto-summary
exit-address-family
!
router bgp 200
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 200

neighbor 2.2.2.2 update-source Loopback0
no auto-summary
!
address-family ipv4 vrf NEW
redistribute rip
no auto-summary
no synchronization
exit-address-family
!
address-family vpnv4
neighbor 2.2.2.2 activate
neighbor 2.2.2.2 send-community extended
no auto-summary
exit-address-family
!
ip classless
!

P1
!

service timestamps debug uptime
service timestamps log uptime
!

ip subnet-zero
!

interface Loopback0
ip address 4.4.4.4 255.255.255.255
no ip directed-broadcast
!
interface ATM12/0/0
ip unnumbered Loopback0
no ip directed-broadcast

tag-switching ip
!
interface ATM12/0/1
ip unnumbered Loopback0
no ip directed-broadcast

tag-switching ip

!
router ospf 100
network 4.0.0.0 0.255.255.255 area 0
!
ip classless
!

P2
!
service timestamps debug uptime
service timestamps log uptime

!
ip subnet-zero

!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
no ip directed-broadcast
!
interface ATM0/1/1
ip unnumbered Loopback0
no ip directed-broadcast

tag-switching ip
!
interface ATM0/1/3
ip unnumbered Loopback0
no ip directed-broadcast

tag-switching ip

!
router ospf 100
network 3.0.0.0 0.255.255.255 area 0
!
ip classless
!

PE2
!
version 12.1
service timestamps debug datetime msec
service timestamps log datetime msec

!
boot system flashow slot0:rsp-jsv-mz.121-5a
!

ip subnet-zero

!
ip vrf NEW
rd 200:1
route-target export 200:1
route-target import 200:1
ip cef distributed

!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!

interface FastEthernet3/0/0
ip vrf forwarding NEW
ip address 110.1.1.1 255.255.255.0

half-duplex
!

interface ATM3/1/0.1 tag-switching
ip unnumbered Loopback0
tag-switching ip
!
router ospf 100
log-adjacency-changes
network 2.0.0.0 0.255.255.255 area 0

!
router rip
version 2
network 110.0.0.0
no auto-summary
!
address-family ipv4 vrf NEW
version 2
redistribute bgp 200 metric 0
network 110.0.0.0
no auto-summary
exit-address-family
!
router bgp 200
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 200

neighbor 1.1.1.1 update-source Loopback0

no auto-summary
!
address-family ipv4 vrf NEW
redistribute rip
no auto-summary
no synchronization
exit-address-family
!
address-family vpnv4
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 send-community extended
no auto-summary
exit-address-family
!
ip classless
!

CE2
!
version 12.1

service timestamps debug uptime
service timestamps log uptime

!

boot system disk0:c7100-jo3s56i-mz.121-5.T.bin

!
ip subnet-zero

!
interface Loopback0
ip address 30.1.1.1 255.255.255.0
!
interface Loopback1
ip address 30.2.2.2 255.255.255.0
!
interface Loopback2
ip address 30.3.3.3 255.255.255.0
!
interface FastEthernet0/0
ip address 110.1.1.2 255.255.255.0

!
router rip
version 2
network 30.0.0.0
network 110.0.0.0
no auto-summary
!

[B]show Commands[/B]
Use these commands to test that your network operates properly:

[LIST][*] [B]show ip route[/B] - Displays IP routing table entries.[*] [B]show ip rip database vrf[/B] - Shows information contained in the RIP database for a particular VRF.[*] [B]show ip bgp vpnv4 vrf[/B] - Displays VPN address information from the BGP table.[*] [B]show tag-switching interfaces detail[/B] - Displays information about one or more interfaces that have the MPLS feature enabled.[*] [B]show tag-switching tdp bindings[/B] - Displays the requested entries from the ATM LDP label binding database.[*] [B]show tag-switching forwarding-table vrf[/B] - Checks the label stack used for a particular route.[/LIST]
The output shown below is a result of these entered commands on the devices shown in the network diagram. This output shows that the network operates properly.
[B]CE1[/B]
[INDENT]Cisco4500#[B]show ip route[/B]
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is not set

100.0.0.0/24 is subnetted, 1 subnets
C 100.1.1.0 is directly connected, Ethernet0
110.0.0.0/24 is subnetted, 1 subnets
R 110.1.1.0 [120/1] via 100.1.1.1, 00:00:14, Ethernet0
10.0.0.0/24 is subnetted, 3 subnets
C 10.3.3.0 is directly connected, Loopback2
C 10.2.2.0 is directly connected, Loopback1
C 10.1.1.0 is directly connected, Loopback0
30.0.0.0/24 is subnetted, 3 subnets
R 30.3.3.0 [120/1] via 100.1.1.1, 00:00:14, Ethernet0
R 30.2.2.0 [120/1] via 100.1.1.1, 00:00:15, Ethernet0
R 30.1.1.0 [120/1] via 100.1.1.1, 00:00:15, Ethernet0 [/INDENT][B]PE1[/B]
[INDENT]Cisco7500a#[B]show ip route [/B]
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/4] via 4.4.4.4, 18:17:37, ATM2/0/0.10
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/3] via 4.4.4.4, 18:17:37, ATM2/0/0.10
4.0.0.0/32 is subnetted, 1 subnets
O 4.4.4.4 [110/2] via 4.4.4.4, 18:17:37, ATM2/0/0.10

Cisco7500a#[B]show ip route vrf NEW[/B]
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is not set

100.0.0.0/24 is subnetted, 1 subnets
C 100.1.1.0 is directly connected, Ethernet2/1/0
110.0.0.0/24 is subnetted, 1 subnets
B 110.1.1.0 [200/0] via 2.2.2.2, 00:26:11
10.0.0.0/24 is subnetted, 3 subnets
R 10.3.3.0 [120/1] via 100.1.1.2, 00:00:11, Ethernet2/1/0
R 10.2.2.0 [120/1] via 100.1.1.2, 00:00:11, Ethernet2/1/0
R 10.1.1.0 [120/1] via 100.1.1.2, 00:00:11, Ethernet2/1/0
30.0.0.0/24 is subnetted, 3 subnets
B 30.3.3.0 [200/1] via 2.2.2.2, 00:26:12
B 30.2.2.0 [200/1] via 2.2.2.2, 00:26:12
B 30.1.1.0 [200/1] via 2.2.2.2, 00:26:12

Cisco7500a#[B]show ip rip database vrf NEW [/B]
10.0.0.0/8 auto-summary
10.1.1.0/24
[1] via 100.1.1.2, 00:00:18, Ethernet2/1/0
10.2.2.0/24
[1] via 100.1.1.2, 00:00:18, Ethernet2/1/0
10.3.3.0/24
[1] via 100.1.1.2, 00:00:18, Ethernet2/1/0
30.0.0.0/8 auto-summary
30.1.1.0/24 redistributed
[1] via 2.2.2.2,
30.2.2.0/24 redistributed
[1] via 2.2.2.2,
30.3.3.0/24 redistributed
[1] via 2.2.2.2,
100.0.0.0/8 auto-summary
100.1.1.0/24 directly connected, Ethernet2/1/0
110.0.0.0/8 auto-summary
110.1.1.0/24 redistributed
[1] via 2.2.2.2,

Cisco7500a#[B]show ip bgp vpnv4 vrf NEW[/B]
BGP table version is 17, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 200:1 (default for vrf NEW)
*> 10.1.1.0/24 100.1.1.2 1 32768 ?
*> 10.2.2.0/24 100.1.1.2 1 32768 ?
*> 10.3.3.0/24 100.1.1.2 1 32768 ?
*>i30.1.1.0/24 2.2.2.2 1 100 0 ?
*>i30.2.2.0/24 2.2.2.2 1 100 0 ?
*>i30.3.3.0/24 2.2.2.2 1 100 0 ?
*> 100.1.1.0/24 0.0.0.0 0 32768 ?
*>i110.1.1.0/24 2.2.2.2 0 100 0 ?

Cisco7500a#[B]show tag-switching interfaces [/B]
Interface IP Tunnel Operational
ATM2/0/0.10 Yes No Yes (ATM tagging)

Cisco7500a#[B]show tag-switching interfaces detail[/B]
Interface ATM2/0/0.10:
IP tagging enabled
TSP Tunnel tagging not enabled
Tagging operational
Tagswitching turbo vector
MTU = 4470
ATM tagging:
Tag VPI = 1
Tag VCI range = 33 - 65535
Control VC = 0/32

Cisco7500a#[B]show tag-switching ? [/B]
atm-tdp ATM Tagging Protocol information
cos-map Show Tag CoS ATM Multi-VC CoS Map
forwarding-table Show the Tag Forwarding Information Base (TFIB)
interfaces Show per-interface tag switching
prefix-map Show Tag CoS Prefix Map
tdp Tag Distribution Protocol information

Cisco7500a#[B]show tag-switching tdp bindings [/B]
tib entry: 1.1.1.1/32, rev 2
local binding: tag: imp-null
tib entry: 2.2.2.2/32, rev 23
local binding: tag: 27
tib entry: 3.3.3.3/32, rev 21
local binding: tag: 26
tib entry: 4.4.4.4/32, rev 10
local binding: tag: 28

Cisco7500a#[B]show tag-switching atm-tdp bindings [/B]
Destination: 4.4.4.4/32
Headend Router ATM2/0/0.10 (1 hop) 1/33 Active, VCD=24
Destination: 3.3.3.3/32
Headend Router ATM2/0/0.10 (2 hops) 1/43 Active, VCD=25
Destination: 2.2.2.2/32
Headend Router ATM2/0/0.10 (3 hops) 1/42 Active, VCD=26
Destination: 1.1.1.1/32
Tailend Router ATM2/0/0.10 1/33 Active, VCD=24

Cisco7500a#[B]show tag-switching forwarding-table vrf NEW [/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
29 Aggregate 100.1.1.0/24[V] 2080
30 Untagged 10.3.3.0/24[V] 0 Et2/1/0 100.1.1.2
31 Untagged 10.2.2.0/24[V] 0 Et2/1/0 100.1.1.2
32 Untagged 10.1.1.0/24[V] 0 Et2/1/0 100.1.1.2
[/INDENT][B]P1[/B]
[INDENT]LS1010#[B]show ip route[/B]
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
T - traffic engineered route

Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/2] via 1.1.1.1, 19:00:12, ATM12/0/0
2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/3] via 3.3.3.3, 19:00:12, ATM12/0/1
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/2] via 3.3.3.3, 19:00:12, ATM12/0/1
4.0.0.0/32 is subnetted, 1 subnets
C 4.4.4.4 is directly connected, Loopback0

LS1010#[B]show tag-switching atm-tdp bindings [/B]
Destination: 4.4.4.4/32
Tailend Switch ATM12/0/0 1/33 Active -> Terminating Active
Tailend Switch ATM12/0/1 1/34 Active -> Terminating Active
Destination: 2.2.2.2/32
Transit ATM12/0/0 1/42 Active -> ATM12/0/1 1/35 Active
Destination: 1.1.1.1/32
Transit ATM12/0/1 1/33 Active -> ATM12/0/0 1/33 Active
Destination: 3.3.3.3/32
Transit ATM12/0/0 1/43 Active -> ATM12/0/1 1/34 Active [/INDENT][B]P2[/B]
[INDENT]LS1010#[B]show ip route[/B]
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR

Gateway of last resort is 10.118.1.21 to network 0.0.0.0

1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/3] via 4.4.4.4, 19:46:00, ATM0/1/1
2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/2] via 2.2.2.2, 19:46:00, ATM0/1/3
3.0.0.0/32 is subnetted, 1 subnets
C 3.3.3.3 is directly connected, Loopback0
4.0.0.0/32 is subnetted, 1 subnets
O 4.4.4.4 [110/2] via 4.4.4.4, 19:46:00, ATM0/1/1
10.0.0.0/24 is subnetted, 1 subnets
C 10.118.1.0 is directly connected, Ethernet2/0/0
S* 0.0.0.0/0 [1/0] via 10.118.1.21

LS1010#[B]show tag-switching atm-tdp bindings [/B]
Destination: 1.1.1.1/32
Transit ATM0/1/3 1/33 Active -> ATM0/1/1 1/33 Active
Destination: 3.3.3.3/32
Tailend Switch ATM0/1/3 1/34 Active -> Terminating Active
Tailend Switch ATM0/1/1 1/34 Active -> Terminating Active
Destination: 4.4.4.4/32
Transit ATM0/1/3 1/35 Active -> ATM0/1/1 1/34 Active
Destination: 2.2.2.2/32
Transit ATM0/1/1 1/35 Active -> ATM0/1/3 1/33 Active [/INDENT][B]PE2[/B]
[INDENT]Cisco7500#[B]show ip route[/B]
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/4] via 3.3.3.3, 02:58:46, ATM3/1/0.1
2.0.0.0/32 is subnetted, 1 subnets
C 2.2.2.2 is directly connected, Loopback0
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/2] via 3.3.3.3, 02:58:46, ATM3/1/0.1
4.0.0.0/32 is subnetted, 1 subnets
O 4.4.4.4 [110/3] via 3.3.3.3, 02:58:46, ATM3/1/0.1

Cisco7500#[B]show ip route vrf NEW [/B]
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is not set

100.0.0.0/24 is subnetted, 1 subnets
B 100.1.1.0 [200/0] via 1.1.1.1, 01:16:13
110.0.0.0/24 is subnetted, 1 subnets
C 110.1.1.0 is directly connected, FastEthernet3/0/0
10.0.0.0/24 is subnetted, 3 subnets
B 10.3.3.0 [200/1] via 1.1.1.1, 01:16:13
B 10.2.2.0 [200/1] via 1.1.1.1, 01:16:13
B 10.1.1.0 [200/1] via 1.1.1.1, 01:16:13
30.0.0.0/24 is subnetted, 3 subnets
R 30.3.3.0 [120/1] via 110.1.1.2, 00:00:16, FastEthernet3/0/0
R 30.2.2.0 [120/1] via 110.1.1.2, 00:00:17, FastEthernet3/0/0
R 30.1.1.0 [120/1] via 110.1.1.2, 00:00:17, FastEthernet3/0/0

Cisco7500#[B]show ip rip database vrf NEW [/B]
10.0.0.0/8 auto-summary
10.1.1.0/24 redistributed
[1] via 1.1.1.1,
10.2.2.0/24 redistributed
[1] via 1.1.1.1,
10.3.3.0/24 redistributed
[1] via 1.1.1.1,
30.0.0.0/8 auto-summary
30.1.1.0/24
[1] via 110.1.1.2, 00:00:09, FastEthernet3/0/0
30.2.2.0/24
[1] via 110.1.1.2, 00:00:09, FastEthernet3/0/0
30.3.3.0/24
[1] via 110.1.1.2, 00:00:09, FastEthernet3/0/0
100.0.0.0/8 auto-summary
100.1.1.0/24 redistributed
[1] via 1.1.1.1,
110.0.0.0/8 auto-summary
110.1.1.0/24 directly connected, FastEthernet3/0/0
Cisco7500#[B]show ip bgp vpnv4 vrf NEW [/B]
BGP table version is 17, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 200:1 (default for vrf NEW)
*>i10.1.1.0/24 1.1.1.1 1 100 0 ?
*>i10.2.2.0/24 1.1.1.1 1 100 0 ?
*>i10.3.3.0/24 1.1.1.1 1 100 0 ?
*> 30.1.1.0/24 110.1.1.2 1 32768 ?
*> 30.2.2.0/24 110.1.1.2 1 32768 ?
*> 30.3.3.0/24 110.1.1.2 1 32768 ?
*>i100.1.1.0/24 1.1.1.1 0 100 0 ?
*> 110.1.1.0/24 0.0.0.0 0 32768 ?

Cisco7500#[B]show tag-switching interfaces [/B]
Interface IP Tunnel Operational
ATM3/1/0.1 Yes No Yes (ATM tagging)

Cisco7500#[B]show tag-switching interfaces detail [/B]
Interface ATM3/1/0.1:
IP tagging enabled
TSP Tunnel tagging not enabled
Tagging operational
Tagswitching turbo vector
MTU = 4470
ATM tagging:
Tag VPI = 1
Tag VCI range = 33 - 65535
Control VC = 0/32

Cisco7500#[B]show tag-switching ? [/B]
atm-tdp ATM Tagging Protocol information
cos-map Show Tag CoS ATM Multi-VC CoS Map
forwarding-table Show the Tag Forwarding Information Base (TFIB)
interfaces Show per-interface tag switching
prefix-map Show Tag CoS Prefix Map
tdp Tag Distribution Protocol information

Cisco7500#[B]show tag-switching tdp bindings [/B]
tib entry: 1.1.1.1/32, rev 25
local binding: tag: 26
tib entry: 2.2.2.2/32, rev 2
local binding: tag: imp-null
tib entry: 3.3.3.3/32, rev 27
local binding: tag: 27
tib entry: 4.4.4.4/32, rev 29
local binding: tag: 28

Cisco7500#[B]show tag-switching atm-tdp bindings [/B]
Destination: 1.1.1.1/32
Headend Router ATM3/1/0.1 (3 hops) 1/33 Active, VCD=8
Destination: 3.3.3.3/32
Headend Router ATM3/1/0.1 (1 hop) 1/34 Active, VCD=6
Destination: 4.4.4.4/32
Headend Router ATM3/1/0.1 (2 hops) 1/35 Active, VCD=7
Destination: 2.2.2.2/32
Tailend Router ATM3/1/0.1 1/33 Active, VCD=8

Cisco7500#[B]show tag-switching forwarding-table vrf NEW [/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
33 Aggregate 110.1.1.0/24[V] 0
34 Untagged 30.3.3.0/24[V] 0 Fa3/0/0 110.1.1.2
35 Untagged 30.2.2.0/24[V] 0 Fa3/0/0 110.1.1.2
36 Untagged 30.1.1.0/24[V] 0 Fa3/0/0 110.1.1.2
[/INDENT][B]CE2[/B]
[INDENT]Cisco7100#[B]show ip route [/B]
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is not set

100.0.0.0/24 is subnetted, 1 subnets
R 100.1.1.0 [120/1] via 110.1.1.1, 00:00:19, FastEthernet0/0
110.0.0.0/24 is subnetted, 1 subnets
C 110.1.1.0 is directly connected, FastEthernet0/0
10.0.0.0/24 is subnetted, 3 subnets
R 10.3.3.0 [120/1] via 110.1.1.1, 00:00:19, FastEthernet0/0
R 10.2.2.0 [120/1] via 110.1.1.1, 00:00:19, FastEthernet0/0
R 10.1.1.0 [120/1] via 110.1.1.1, 00:00:19, FastEthernet0/0
30.0.0.0/24 is subnetted, 3 subnets
C 30.3.3.0 is directly connected, Loopback2
C 30.2.2.0 is directly connected, Loopback1
C 30.1.1.0 is directly connected, Loopback0
[/INDENT][B]Related Information[/B]

[LIST][*][B][URL="http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/VPN.html"]MPLS Virtual Private Networks[/URL][/B][*][B][URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00800a6c11.shtml"]Configuring a Basic MPLS VPN[/URL][/B][*][B][URL="http://www.cisco.com/en/US/tech/tk436/tk798/technologies_tech_note09186a0080093d42.shtml"]Packet Flow in an MPLS VPN Environment[/URL][/B][*][B][URL="http://www.cisco.com/en/US/support/index.html"]Technical Support & Documentation - Cisco Systems[/URL][/B][/LIST]

Updated: Jun 05, 2005

[/LEFT]
2010-02-11, 10:29 PM
patris1

[LEFT][B][SIZE=3][B]DiffServ Tunneling Modes for MPLS Networks[/B][/SIZE][/B]

[B]Document ID: 47815[/B]

[B]Contents[/B]

[INDENT] [B] Introduction
[/B] [B] Prerequisites
Requirements
Components Used
Conventions
[/B] [B] Background Information
Default Behavior
Pre Cisco IOS Software 12.2(13)T Command Usage and Behavior
Post Cisco IOS Software 12.2(13)T Command Usage and Behavior
[/B] [B] DiffServ Tunneling Modes
Uniform Mode
Pipe Mode
Short-Pipe Mode
Tunnel Mode Summary
[/B] [B] Cisco Support Community - Featured Conversations
[/B] [B] Related Information
[/B][/INDENT][B] Introduction [/B]

This document describes the implementation of Differentiated Services (DiffServ) Tunneling Modes available for Multiprotocol Label Switching (MPLS) based network environments.
[B] Prerequisites [/B]

[B] Requirements [/B]

Readers of this document should have knowledge of these topics:

[LIST][*] MPLS and MPLS for Virtual Private Networks (VPN)[*] Concepts relating to IP precedence, Type of Service (ToS) and DiffServ[*] Quality of Service (QoS) Packet Marking and Classification using Modular QoS Command Line Interface CLI (MQC)[/LIST]
[B] Components Used [/B]

The information in this document is based on these software and hardware versions:

[LIST][*] Cisco IOS Software® Release 12.2(13)T for new QoS features. Release 12.1(5)T includes original QoS features.[*] Any Cisco router from the 3600 series or later, such as the Cisco 3660 or 7206 that support MPLS provider core (P) router/provider edge (PE) router functionality.[/LIST]
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
[B] Conventions [/B]

For more information on document conventions, refer to the [URL="http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080121ac5.shtml"]Cisco Technical Tips Conventions[/URL].
[B] Background Information [/B]

[B] Default Behavior [/B]

This diagram describes the default behavior of the DiffServ Code Point (DSCP)/MPLS Experimental (EXP) bits as a packet travels from one customer edge (CE) router to another CE router across an MPLS core:
[IMG]http://www.cisco.com/image/gif/paws/47815/diffserv_tunnel_01.jpg[/IMG]
This remainder of this section describes the activity within the Default Behavior diagram.
Imposition of Label (IP –> Label):

[LIST][*] The IP precedence of the incoming IP packet is copied to the MPLS EXP bits of all pushed label(s).[*] The 1st three bits of the DSCP bit is copied to the MPLS EXP bits of all pushed label(s).[*] This technique is also known as ToS Reflection.[/LIST]
MPLS forwarding (Label –> Label):

[LIST][*] The EXP is copied to the new labels that are swapped/pushed during forwarding or imposition.[*] At label imposition, the underlying labels are not modified with the value of the new label being added to the current label stack.[*] At label disposition, the EXP bits are not copied down to the newly exposed label EXP bits.[/LIST]
Disposition of Label (Label –> IP):

[LIST][*] At label disposition the EXP bits are not copied down to the IP precedence/DSCP field of the newly exposed IP packet. [/LIST]
[B] Pre Cisco IOS Software 12.2(13)T Command Usage and Behavior [/B]

Before IOS Release 12.2(13)T, the [URL="http://www.cisco.com/en/US/docs/ios/12_2/switch/command/reference/xrfscmd4.html#1066361"] [B]set mpls experimental[/B] [/URL] command was the only method available to modify the MPLS EXP bits.
[B] Post Cisco IOS Software 12.2(13)T Command Usage and Behavior [/B]

With IOS Release 12.2(13)T and later, the [B]set mpls experimental[/B] command is modified to allow these options:

[LIST][*] [URL="http://www.cisco.com/en/US/docs/ios/12_2t/switch/command/reference/xftscmd4.html#1092959"] [B]set mpls experimental topmost [I]{mpls-exp-value | qos-group [table table-map-name]}[/I] [/B] [/URL] [*] [URL="http://www.cisco.com/en/US/docs/ios/12_2t/switch/command/reference/xftscmd4.html#1092877"] [B]set mpls experimental imposition [I]{mpls-exp-value | qos-group [table table-map-name]}[/I] [/B] [/URL] [/LIST]
[B]Note: [/B]The new [B]set mpls experimental topmost[/B] command is equivalent to the old [B]set mpls imposition[/B] command.
These two commands, in combination with some new command switches, allow better control of MPLS EXP bits manipulation during label push, swap, and pop operations. These two commands allow you to use DiffServ Tunneling Modes.
[B] DiffServ Tunneling Modes [/B]

Diffserv Tunneling Modes introduces a new Per-Hop-Behavior (PHB), which allows differentiated QoS in a providers network. The tunneling mode is defined at the edge of the network, normally in the PE label switch routers (LSRs) (both ingress and egress). You may need to make changes in the P routers; you must also consider what occurs when the topmost label is removed from a packet due to Penultimate-Hop-Popping (PHP). It may be necessary to copy the MPLS EXP value from the top label that is being popped to the newly exposed label; this does not always apply to all tunneling modes.
In some cases (for example, a plain non-VPN MPLS network), the PHP action on the final P router can expose a plain IP packet when a packet with only one label is received. When this IP packet is received by the egress LSR (PE), it is not possible to classify the packet based on the MPLS EXP bits because there is no label now. In these situations, you must configure the egress PE router to advertise an [B]explicit-null[/B] label. When the PHP action is performed on the P router, a label with a value of zero is sent, and with this special label you can mark the EXP bits as normally labeled packets, allowing the correct classification on the egress PE router.
The MPLS network support of Diffserv specification defines these tunneling modes:

[LIST][*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a008022ad7e.shtml#uniform"]Uniform[/URL] [*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a008022ad7e.shtml#pipe"]Pipe[/URL] [*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a008022ad7e.shtml#shortpipe"]Short-Pipe[/URL] [/LIST]
The next sections examine each tunneling mode separately, and provide examples to show how each tunneling mode can be configured. The examples include a full mapping of IP Precedence to MPLS EXP bits. It is possible to have a number of different QoS parameters and tunneling modes for each customer.
[B]Note: [/B]The configuration examples are not specific for MPLS VPN, and are applicable for plain MPLS networks and Carrier supported Carrier (CsC) networks. It is also possible that your network can vary from another network—many different QoS parameters and tunneling modes can be used.
[B] Uniform Mode [/B]

DiffServ Tunneling Uniform Mode has only one layer of QoS, which reaches end-to-end. The ingress PE router (PE1) copies the DSCP from the incoming IP packet into the MPLS EXP bits of the imposed labels. As the EXP bits travel through the core, they may or may not be modified by intermediate P routers. In this example, P router P1 modifies the EXP bits of the top label. At the egress P router (P2) we copy the EXP bits to the EXP bits of the newly exposed label after the PHP (Penultimate-Hop-Pop). Finally at the egress PE router (PE2) we then copy the EXP bits to the DSCP bits of the newly exposed IP packet.
[IMG]http://www.cisco.com/image/gif/paws/47815/diffserv_tunnel_02.jpg[/IMG]
Uniform mode configurations:
PE1
[I]
[COLOR=#0000ff]!--- This configuration maps the IP Precedence
!--- of the incoming IP packets to the MPLS EXP bits.[/COLOR]
[/I]
class-map match-all IP-AF11
match ip precedence 0
class-map match-all IP-AF12
match ip precedence 1
class-map match-all IP-AF21
match ip precedence 2
class-map match-all IP-AF22
match ip precedence 3
class-map match-all IP-AF31
match ip precedence 4
class-map match-all IP-AF32
match ip precedence 5

class-map match-all MPLS-AF11
match mpls experimental topmost 0
class-map match-all MPLS-AF12
match mpls experimental topmost 1
class-map match-all MPLS-AF21
match mpls experimental topmost 2
class-map match-all MPLS-AF22
match mpls experimental topmost 3
class-map match-all MPLS-AF31
match mpls experimental topmost 4
class-map match-all MPLS-AF32
match mpls experimental topmost 5

[B]policy-map set-MPLS-PHB[/B]
class IP-AF11
police 8000 conform-action set-mpls-exp-imposition-transmit
0 exceed-action drop
class IP-AF12
police 10000 conform-action set-mpls-exp-imposition-transmit
1 exceed-action set-mpls-exp-imposition-transmit 0
class IP-AF21
police 12000 conform-action set-mpls-exp-imposition-transmit
2 exceed-action set-mpls-exp-imposition-transmit 1
class IP-AF22
police 12000 conform-action set-mpls-exp-imposition-transmit
3 exceed-action set-mpls-exp-imposition-transmit 2
class IP-AF31
police 12000 conform-action set-mpls-exp-imposition-transmit
4 exceed-action set-mpls-exp-imposition-transmit 3
class IP-AF32
police 12000 conform-action set-mpls-exp-imposition-transmit
5 exceed-action set-mpls-exp-imposition-transmit 4

[B]policy-map output-qos[/B]
class MPLS-AF11
bandwidth percent 5
random-detect
class MPLS-AF12
bandwidth percent 10
random-detect
class MPLS-AF21
bandwidth percent 10
random-detect
class MPLS-AF22
bandwidth percent 15
random-detect
class MPLS-AF31
bandwidth percent 20
random-detect
class MPLS-AF32
bandwidth percent 30
random-detect

interface Ethernet0/0
ip address 192.168.0.1 255.255.255.0
max-reserved-bandwidth 90
[B]service-policy output output-qos[/B]
tag-switching ip
!
interface Ethernet1/0
ip vrf forwarding v1
ip address 10.0.0.2 255.255.255.0
[B]service-policy input set-MPLS-PHB[/B]
!
P1
[I]
[COLOR=#0000ff]!--- This configuration swaps the top label from 3 to 2,
!--- which does not need to occur to follow the previous configuration.[/COLOR]
[/I]
class-map match-all mpls-in
match mpls experimental topmost 3
!
[B]policy-map mpls-in[/B]
class mpls-in
set mpls experimental topmost 2
!
interface Ethernet0/0
ip address 192.168.1.1 255.255.255.0
tag-switching ip
!
interface Ethernet1/0
ip address 192.168.0.2 255.255.255.0
[B]service-policy input mpls-in[/B]
tag-switching ip
!
P2
[I]
[COLOR=#0000ff]!--- Remember to copy down the MPLS EXP value
!--- from the newly exposed label after the PHP.[/COLOR]
[/I]
class-map match-all MPLS-AF11
match mpls experimental topmost 0
class-map match-all MPLS-AF12
match mpls experimental topmost 1
class-map match-all MPLS-AF21
match mpls experimental topmost 2
class-map match-all MPLS-AF22
match mpls experimental topmost 3
class-map match-all MPLS-AF31
match mpls experimental topmost 4
class-map match-all MPLS-AF32
match mpls experimental topmost 5
!
class-map match-all qos-group-AF11
match qos-group 0
class-map match-all qos-group-AF12
match qos-group 1
class-map match-all qos-group-AF21
match qos-group 2
class-map match-all qos-group-AF22
match qos-group 3
class-map match-all qos-group-AF31
match qos-group 4
class-map match-all qos-group-AF32
match qos-group 5
!
[B]policy-map qos-group-in[/B]
class MPLS-AF11
set qos-group mpls experimental topmost
class MPLS-AF12
set qos-group mpls experimental topmost
class MPLS-AF21
set qos-group mpls experimental topmost
class MPLS-AF22
set qos-group mpls experimental topmost
class MPLS-AF31
set qos-group mpls experimental topmost
class MPLS-AF32
set qos-group mpls experimental topmost
!
[B]policy-map qos-group-out[/B]
class qos-group-AF11
bandwidth percent 5
random-detect
set mpls experimental topmost qos-group
class qos-group-AF12
bandwidth percent 10
random-detect
set mpls experimental topmost qos-group
class qos-group-AF21
bandwidth percent 10
random-detect
set mpls experimental topmost qos-group
class qos-group-AF22
bandwidth percent 15
random-detect
set mpls experimental topmost qos-group
class qos-group-AF31
bandwidth percent 20
random-detect
set mpls experimental topmost qos-group
class qos-group-AF32
bandwidth percent 30
random-detect
set mpls experimental topmost qos-group
!
interface Ethernet0/0
ip address 192.168.2.1 255.255.255.0
max-reserved-bandwidth 90
[B]service-policy output qos-group-out[/B]
tag-switching ip
!
interface Ethernet1/0
ip address 192.168.1.2 255.255.255.0
[B]service-policy input qos-group-in[/B]
tag-switching ip
!
PE2
[I]
[COLOR=#0000ff]!--- Remember to copy down the MPLS EXP bits to the IP Precedence
!--- of the newly exposed IP packet.[/COLOR]
[/I]
class-map match-all MPLS-AF11
match mpls experimental topmost 0
class-map match-all MPLS-AF12
match mpls experimental topmost 1
class-map match-all MPLS-AF21
match mpls experimental topmost 2
class-map match-all MPLS-AF22
match mpls experimental topmost 3
class-map match-all MPLS-AF31
match mpls experimental topmost 4
class-map match-all MPLS-AF32
match mpls experimental topmost 5
!
class-map match-all qos-group-AF11
match qos-group 0
class-map match-all qos-group-AF12
match qos-group 1
class-map match-all qos-group-AF21
match qos-group 2
class-map match-all qos-group-AF22
match qos-group 3
class-map match-all qos-group-AF31
match qos-group 4
class-map match-all qos-group-AF32
match qos-group 5
!
[B]policy-map qos-group-in[/B]
class MPLS-AF11
set qos-group mpls experimental topmost
class MPLS-AF12
set qos-group mpls experimental topmost
class MPLS-AF21
set qos-group mpls experimental topmost
class MPLS-AF22
set qos-group mpls experimental topmost
class MPLS-AF31
set qos-group mpls experimental topmost
class MPLS-AF32
set qos-group mpls experimental topmost
!
[B]policy-map qos-group-out[/B]
class qos-group-AF11
bandwidth percent 5
random-detect
set precedence qos-group
class qos-group-AF12
bandwidth percent 10
random-detect
set precedence qos-group
class qos-group-AF21
bandwidth percent 10
random-detect
set precedence qos-group
class qos-group-AF22
bandwidth percent 15
random-detect
set precedence qos-group
class qos-group-AF31
bandwidth percent 20
random-detect
set precedence qos-group
class qos-group-AF32
bandwidth percent 30
random-detect
set precedence qos-group
!
interface Ethernet0/0
ip vrf forwarding v1
ip address 10.0.1.1 255.255.255.0
max-reserved-bandwidth 90
[B]service-policy output qos-group-out[/B]
!
interface Ethernet1/0
ip address 192.168.2.2 255.255.255.0
[B]service-policy input qos-group-in[/B]
tag-switching ip
!
[B] Pipe Mode [/B]

Diffserv Tunneling Pipe Mode uses two layers of QoS:

[LIST=1][*] An underlying QoS for the data, which remains unchanged when traversing the core.[*] A per-core QoS, which is separate from that of the underlying IP packets. This per-core QoS PHB remains transparent to end users.[/LIST]
When a packet reaches the edge of the MPLS core, the egress PE router (PE2) classifies the newly exposed IP packets for outbound queuing based on the MPLS PHB from the EXP bits of the recently removed label.
[IMG]http://www.cisco.com/image/gif/paws/47815/diffserv_tunnel_03.jpg[/IMG]
Pipe mode configurations:
PE1
[I]
[COLOR=#0000ff]!--- On input, the IP Precedence is copied to the MPLS EXP
!--- on label imposition and when leaving the router, the
!--- MPLS EXP bits are used to classify the traffic into three
!--- traffic classes—gold, silver, and bronze (the topmost).[/COLOR]
[/I]
class-map match-all IP-AF22
match ip precedence 0 1
class-map match-all IP-AF31
match ip precedence 2 3
class-map match-all IP-AF32
match ip precedence 4 5
!
class-map match-all bronze
match mpls experimental topmost 2 3
class-map match-all silver
match mpls experimental topmost 4
class-map match-all gold
match mpls experimental topmost 5
!
[B]policy-map set-MPLS-PHB[/B]
class IP-AF22
police 12000 conform-action set-mpls-exp-imposition-transmit
3 exceed-action set-mpls-exp-imposition-transmit 2
class IP-AF31
police 12000 conform-action set-mpls-exp-imposition-transmit
4 exceed-action set-mpls-exp-imposition-transmit 3
class IP-AF32
police 12000 conform-action set-mpls-exp-imposition-transmit
5 exceed-action set-mpls-exp-imposition-transmit 4
!
[B]policy-map output-qos[/B]
class gold
bandwidth 40
random-detect
class silver
bandwidth 30
random-detect
class bronze
bandwidth 20
random-detect
!
interface Ethernet0/0
ip address 192.168.0.1 255.255.255.0
max-reserved-bandwidth 90
[B]service-policy output output-qos[/B]
tag-switching ip
!
interface Ethernet1/0
ip vrf forwarding v1
ip address 10.0.0.2 255.255.255.0
[B]service-policy input set-MPLS-PHB[/B]
!
P1
[I]
[COLOR=#0000ff]!--- This configuration swaps the top label from 4 to 5,
!--- which does not need to occur to follow the previous configuration.[/COLOR]
[/I]
class-map match-all mpls-in
match mpls experimental topmost 4
!
[B]policy-map mpls-in[/B]
class mpls-in
set mpls experimental topmost 5
!
interface Ethernet0/0
ip address 192.168.1.1 255.255.255.0
tag-switching ip
!
interface Ethernet1/0
ip address 192.168.0.2 255.255.255.0
[B]service-policy input mpls-in[/B]
tag-switching ip
!
P2
[I]
[COLOR=#0000ff]!--- Remember to copy down the MPLS EXP value from
!--- the newly exposed label after the PHP.[/COLOR]
[/I]
class-map match-all MPLS-AF11
match mpls experimental topmost 0
class-map match-all MPLS-AF12
match mpls experimental topmost 1
class-map match-all MPLS-AF21
match mpls experimental topmost 2
class-map match-all MPLS-AF22
match mpls experimental topmost 3
class-map match-all MPLS-AF31
match mpls experimental topmost 4
class-map match-all MPLS-AF32
match mpls experimental topmost 5
!
class-map match-all gold
match qos-group 5
class-map match-all silver
match qos-group 4
class-map match-all bronze
match qos-group 3
match qos-group 2
!
[B]policy-map qos-group-in[/B]
class MPLS-AF11
set qos-group mpls experimental topmost
class MPLS-AF12
set qos-group mpls experimental topmost
class MPLS-AF21
set qos-group mpls experimental topmost
class MPLS-AF22
set qos-group mpls experimental topmost
class MPLS-AF31
set qos-group mpls experimental topmost
class MPLS-AF32
set qos-group mpls experimental topmost
!
[B]policy-map qos-group-out[/B]
class gold
bandwidth 40
random-detect
set mpls experimental topmost qos-group
class silver
bandwidth 30
random-detect
set mpls experimental topmost qos-group
class bronze
bandwidth 20
random-detect
set mpls experimental topmost qos-group
!
interface Ethernet0/0
ip address 192.168.2.1 255.255.255.0
max-reserved-bandwidth 90
[B]service-policy output qos-group-out[/B]
tag-switching ip
!
interface Ethernet1/0
ip address 192.168.1.2 255.255.255.0
[B]service-policy input qos-group-in[/B]
tag-switching ip
!
PE2
[I]
[COLOR=#0000ff]!--- Remember to queue the newly exposed IP packet based in
!--- the MPLS EXP bits of the label we just removed. Use
!--- [B]qos-groups[/B] to keep track of this value.[/COLOR]
[/I]
class-map match-all MPLS-AF11
match mpls experimental topmost 0
class-map match-all MPLS-AF12
match mpls experimental topmost 1
class-map match-all MPLS-AF21
match mpls experimental topmost 2
class-map match-all MPLS-AF22
match mpls experimental topmost 3
class-map match-all MPLS-AF31
match mpls experimental topmost 4
class-map match-all MPLS-AF32
match mpls experimental topmost 5
!
class-map match-all gold
match qos-group 5
class-map match-all silver
match qos-group 4
class-map match-all bronze
match qos-group 3
match qos-group 2
!
[B]policy-map qos-group-in[/B]
class MPLS-AF11
set qos-group mpls experimental topmost
set discard-class 0
class MPLS-AF12
set qos-group mpls experimental topmost
set discard-class 1
class MPLS-AF21
set qos-group mpls experimental topmost
set discard-class 2
class MPLS-AF22
set qos-group mpls experimental topmost
set discard-class 3
class MPLS-AF31
set qos-group mpls experimental topmost
set discard-class 4
class MPLS-AF32
set qos-group mpls experimental topmost
set discard-class 5
!
[B]policy-map qos-group-out[/B]
class gold
bandwidth 40
random-detect discard-class-based
class silver
bandwidth 30
random-detect discard-class-based
class bronze
bandwidth 20
random-detect discard-class-based
!
interface Ethernet0/0
ip vrf forwarding v1
ip address 10.0.1.1 255.255.255.0
max-reserved-bandwidth 90
[B]service-policy output qos-group-out[/B]
!
interface Ethernet1/0
ip address 192.168.2.2 255.255.255.0
[B]service-policy input qos-group-in[/B]
tag-switching ip
!
[B] Short-Pipe Mode [/B]

Diffserv Tunneling Short-pipe Mode uses the same rules and techniques across the core. The difference is at the egress PE router (PE2)—you classify the newly exposed IP packets for outbound queuing based on the IP PHB from the DSCP value of this IP packet.
[IMG]http://www.cisco.com/image/gif/paws/47815/diffserv_tunnel_04.jpg[/IMG]
Short-pipe mode configurations:
PE1
[I]
[COLOR=#0000ff]!--- On input, the IP Precedent is copied to the MPLS EXP
!--- on label imposition. When leaving the router, the
!--- MPLS EXP bits are used to classify the traffic into three
!--- traffic classes—gold, silver and bronze (the topmost).
[/COLOR]
[/I]
class-map match-all IP-AF22
match ip precedence 0 1
class-map match-all IP-AF31
match ip precedence 2 3
class-map match-all IP-AF32
match ip precedence 4 5
!
class-map match-all bronze
match mpls experimental topmost 2 3
class-map match-all silver
match mpls experimental topmost 4
class-map match-all gold
match mpls experimental topmost 5
!
[B]policy-map set-MPLS-PHB[/B]
class IP-AF22
police 12000 conform-action set-mpls-exp-imposition-transmit
3 exceed-action set-mpls-exp-imposition-transmit 2
class IP-AF31
police 12000 conform-action set-mpls-exp-imposition-transmit
4 exceed-action set-mpls-exp-imposition-transmit 3
class IP-AF32
police 12000 conform-action set-mpls-exp-imposition-transmit
5 exceed-action set-mpls-exp-imposition-transmit 4
!
[B]policy-map output-qos[/B]
class gold
bandwidth 40
random-detect
class silver
bandwidth 30
random-detect
class bronze
bandwidth 20
random-detect
!
interface Ethernet0/0
ip address 192.168.0.1 255.255.255.0
max-reserved-bandwidth 90
[B]service-policy output output-qos[/B]
tag-switching ip
!
interface Ethernet1/0
ip vrf forwarding v1
ip address 10.0.0.2 255.255.255.0
[B]service-policy input set-MPLS-PHB[/B]
!
P1
[I]
[COLOR=#0000ff]!--- This configuration swaps the top label from 4 to 5,
!--- which does not need to occur to follow the previous configuration.[/COLOR]
[/I]
class-map match-all mpls-in
match mpls experimental topmost 4
!
[B]policy-map mpls-in[/B]
class mpls-in
set mpls experimental topmost 5
!
interface Ethernet0/0
ip address 192.168.1.1 255.255.255.0
tag-switching ip
!
interface Ethernet1/0
ip address 192.168.0.2 255.255.255.0
[B]service-policy input mpls-in[/B]
tag-switching ip
!
P2
[I]
[COLOR=#0000ff]!--- Remember to copy down the MPLS EXP value from
!--- the newly exposed label after the PHP.[/COLOR]
[/I]
class-map match-all MPLS-AF11
match mpls experimental topmost 0
class-map match-all MPLS-AF12
match mpls experimental topmost 1
class-map match-all MPLS-AF21
match mpls experimental topmost 2
class-map match-all MPLS-AF22
match mpls experimental topmost 3
class-map match-all MPLS-AF31
match mpls experimental topmost 4
class-map match-all MPLS-AF32
match mpls experimental topmost 5
!
class-map match-all gold
match qos-group 5
class-map match-all silver
match qos-group 4
class-map match-all bronze
match qos-group 3
match qos-group 2
!
[B]policy-map qos-group-in[/B]
class MPLS-AF11
set qos-group mpls experimental topmost
class MPLS-AF12
set qos-group mpls experimental topmost
class MPLS-AF21
set qos-group mpls experimental topmost
class MPLS-AF22
set qos-group mpls experimental topmost
class MPLS-AF31
set qos-group mpls experimental topmost
class MPLS-AF32
set qos-group mpls experimental topmost
!
[B]policy-map qos-group-out[/B]
class gold
bandwidth 40
random-detect
set mpls experimental topmost qos-group
class silver
bandwidth 30
random-detect
set mpls experimental topmost qos-group
class bronze
bandwidth 20
random-detect
set mpls experimental topmost qos-group
!
interface Ethernet0/0
ip address 192.168.2.1 255.255.255.0
max-reserved-bandwidth 90
[B]service-policy output qos-group-out[/B]
tag-switching ip
!
interface Ethernet1/0
ip address 192.168.1.2 255.255.255.0
[B]service-policy input qos-group-in[/B]
tag-switching ip
!
PE2
[I]
[COLOR=#0000ff]!--- Remember to queue the newly exposed IP packet
!--- based on the value of the IP Precedent.[/COLOR]
[/I]
class-map match-all gold
match precedence 4 5
class-map match-all silver
match precedence 2 3
class-map match-all bronze
match precedence 0 1
!
[B]policy-map qos-group-out[/B]
class gold
bandwidth 40
random-detect prec-based
class silver
bandwidth 30
random-detect prec-based
class bronze
bandwidth 20
random-detect prec-based
!
interface Ethernet0/0
ip vrf forwarding v1
ip address 10.0.1.1 255.255.255.0
max-reserved-bandwidth 90
[B]service-policy output qos-group-out[/B]
!
interface Ethernet1/0
ip address 192.168.2.2 255.255.255.0
tag-switching ip
!
[B] Tunnel Mode Summary [/B]

This table summarizes the various actions that applied to IP or labeled packets at various stages in the network:
Tunneling Mode
IP –> Label
Label –> Label
Label –> IP
Uniform
Copy IP Prec/DiffServ into MPLS EXP (may be changed by the SP also)
MPLS EXP may be changed by SP
MPLS EXP copied to IP Prec/DiffServ
Pipe
MPLS EXP set by the SP QoS policy
Original IP Prec/Diffserv preserved (egress queuing based on MPLS EXP)
Short-Pipe
Original IP Prec/Diffserv preserved (egress queuing based in IP Prec/DiffServ)

[B] Cisco Support Community - Featured Conversations [/B]

[URL="https://supportforums.cisco.com/index.jspa"]Cisco Support Community[/URL] is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers. Below are just some of the most recent and relevant conversations happening right now.
Want to see more? Join us by clicking [URL="https://supportforums.cisco.com/login.jspa"]here[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/thread/250127"]How to deploy MPLS Diff-serv in network?[/URL][URL="https://supportforums.cisco.com/people/shan-cao"]shan-cao[/URL]1 Reply24.03.2005 06:33 Hi,I have trouble with how to deploy MPLS Diff-serv in ISP network. Who can give me a example or a design? thanks Sincerely[URL="https://supportforums.cisco.com/community/feeds/messages?thread=250127"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/250127"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/975197#975197"]Re: How to deploy MPLS Diff-serv in...[/URL][URL="https://supportforums.cisco.com/people/maher%40pd.jaring.my"]maher@pd.jaring.my[/URL]24.03.2005 06:33 Hi, This link might help you. [url=http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a008022ad7e.shtml]DiffServ Tunneling Modes for MPLS Networks [MPLS] - Cisco Systems[/url][URL="https://supportforums.cisco.com/message/975197#975197"]Reply[/URL]

[/LIST][*] [URL="https://supportforums.cisco.com/thread/75429"]MPLS/DiffServ WAN design[/URL][URL="https://supportforums.cisco.com/people/notuteye"]notuteye[/URL]1 Reply04.06.2001 12:03 I'm working on the conceptual design for an IP overlay onto a wireless WAN. We have a setup with SPIKE point-to-multipoint CPE links (layer 2 switching over a wireless interface) connecting into an SDH microwave ring. It's easy enough to run MPLS on cisco 3662s for the backbone nodes, but what does one do onto the CPE? for cost reasons the CPE router has to be a low-end model, preferably 1700 or something even cheaper. Unfortunately the SPIKE unit presents an ethernet interface to the router...how do I implement end-to-end bandwidth management? I can envisage diffserv applying to the CPE -- Edge router, but how does that effectively map onto an MPLS backbone? and with an ethernet interface, I can't throttle the user's output at his own router, but run the risk of him bursting up to 10mbps transmission before being throttled from the remote end...does anybody understand what I'm getting at, or am I talking drivel here?[URL="https://supportforums.cisco.com/community/feeds/messages?thread=75429"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/75429"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/264186#264186"]Re: MPLS/DiffServ WAN design[/URL][URL="https://supportforums.cisco.com/people/mmellet"]mmellet[/URL]04.06.2001 12:03 I’d suggest getting your Cisco design team involved in this complex installation. This is too hard to plan in this forum.[URL="https://supportforums.cisco.com/message/264186#264186"]Reply[/URL]

[/LIST][*] [URL="https://supportforums.cisco.com/thread/250348"]DiffServ & TE paths are required to...[/URL][URL="https://supportforums.cisco.com/people/mpugliese%40diveo.net.br"]mpugliese@diveo.net.br[/URL]2 Replies15.08.2005 06:46 Dear members. There's something I'd like to know from those that truly and successfully implement commercial VoIP over a MPLS infrastructure. Supporting IP QoS (DiffServ) across the core backbone and/or MPLS traffic- engineered paths is really required ? Consider a whole backbone built with high speed throughput connections, plenty of bandwidth availability and no periods of congestion! I do believe TE tunnels (paths) are necessary for quick recovery when a node or link fails, but rather them assuming something I haven't experienced yet I'd like to listen from those who really have already successfully deployed commercial VoIP. Best regards. Murilo Pugliese.[URL="https://supportforums.cisco.com/community/feeds/messages?thread=250348"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/250348"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/976111#976111"]Re: DiffServ & TE paths are required to...[/URL][URL="https://supportforums.cisco.com/people/thomas.chen"]thomas.chen[/URL]12.08.2005 14:12With increasing adoption of voice over IP (VoIP), the landscape for deployment is rapidly changing. Service providers are often driven by the need to provide customers a high grade of service to carry voice traffic across a network. However, today's multiservice packet networks rely on IP-based packet switching. In addition, IP by itself is simply best-effort service that is not sufficient to provide the strict delay, jitter, and bandwidth...[URL="https://supportforums.cisco.com/message/976111#976111"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/976112#976112"]Re: DiffServ & TE paths are required to...[/URL][URL="https://supportforums.cisco.com/people/mpugliese%40diveo.net.br"]mpugliese@diveo.net.br[/URL]15.08.2005 06:46 I'm sorry buddy but I was expecting to receive a strict more detailed technical information. Regarding the statement you sent, I already read something like it few times, it looks more like marketing as far it's not focused in in deep details of this issue. [URL="https://supportforums.cisco.com/message/976112#976112"]Reply[/URL]

[/LIST][/LIST][*] [URL="https://supportforums.cisco.com/thread/249560"]MPLS QoS: RDM - DS-TE[/URL][URL="https://supportforums.cisco.com/people/abayo"]abayo[/URL]1 Reply05.08.2009 15:55 On a RDM with DS-TE do I need to configure a tunnel per every class-type, as I saw on some examples?.[URL="https://supportforums.cisco.com/community/feeds/messages?thread=249560"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/249560"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/972790#972790"]Re: MPLS QoS: RDM - DS-TE[/URL][URL="https://supportforums.cisco.com/people/ANONYMOUS"]ANONYMOUS[/URL]05.08.2009 15:55 You need to configure tunnel for every class-type. MPLS DiffServ Tunneling Modes has the following benefits: â€¢Tunneling modes provide added QoS functionality by the creative manipulation of the MPLS EXP field during label imposition, forwarding, and label disposition. â€¢Tunneling modes provide a common set of PHBs to different service provider customers. [URL="https://supportforums.cisco.com/message/972790#972790"]Reply[/URL]

[/LIST][*] [URL="https://supportforums.cisco.com/thread/7395"]DiffServ[/URL][URL="https://supportforums.cisco.com/people/sschingel"]sschingel[/URL]1 Reply19.07.2004 14:19 Can anyone point me to a good tutorial on diffserv? We have a telephone company that wants me to implement diffserv so they can connect PBX's over the WAN. But I am a newbie at this, and they can't provide any sample router configs.[URL="https://supportforums.cisco.com/community/feeds/messages?thread=7395"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/7395"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/23801#23801"]Re: DiffServ[/URL][URL="https://supportforums.cisco.com/people/rais"]rais[/URL]19.07.2004 14:19 Here is one of the links: [url]http://www.cisco.com/en/US/products/sw/iosswrel/ps1834/products_feature_guide09186a0080080466.html[/url] Look for DiffServ/QoS for the platform you are using. Search for terms like dscp, expedited forwardig etc. HTH [URL="https://supportforums.cisco.com/message/23801#23801"]Reply[/URL]

[/LIST][*] [URL="https://supportforums.cisco.com/thread/80751"]Cisco support for diff-serv[/URL][URL="https://supportforums.cisco.com/people/rtshimizu"]rtshimizu[/URL]0 Replies22.10.2001 17:58 While Cisco claims support for Diff-serv via IPV6 implementation. I have seen very little from Cisco of actual product implementation. Most Cisco SE's and employees either have little knowledge of diff-serv. I was wondering if anyone knows of any sites or discussion groups that talk extensively about Cisco's diff-serv product support???[URL="https://supportforums.cisco.com/community/feeds/messages?thread=80751"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/80751"]Reply[/URL]

[*] [URL="https://supportforums.cisco.com/thread/82388"]Hardware transcoder and DiffServ[/URL][URL="https://supportforums.cisco.com/people/mdeloach"]mdeloach[/URL]3 Replies25.03.2004 13:29 We've noticed that the router-based hardware transcoder/conference bridge platform does not support DiffServ. More specifically the SCCP code on the router only has options for IP Precedence. Our entire network is setup to use DiffServ, and our carrier only supports Diffserv. What options do we have to replace the ToS tagging with DiffServ? Place the transcoder behind an intelligent switch that can rewrite the tagging, or should we use Service Policies on the egress to rewrite the tagging?[URL="https://supportforums.cisco.com/community/feeds/messages?thread=82388"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/82388"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/285213#285213"]Re: Hardware transcoder and DiffServ[/URL][URL="https://supportforums.cisco.com/people/pbarman"]pbarman[/URL]25.03.2004 12:03 Like you said, I see only two options. Placing a transcoder behind a switch will require you to redesign a part of the network. Easy one would be to classify the precedence set by sccp, and mark it to dscp using a policy-map, and apply the service-policy to the egress interface. You need to enable "ip cef" to set the dscp in policy-map.[URL="https://supportforums.cisco.com/message/285213#285213"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/285214#285214"]Re: Hardware transcoder and DiffServ[/URL][URL="https://supportforums.cisco.com/people/mdeloach"]mdeloach[/URL]25.03.2004 12:11We have most of the configuraton in place to use policy-map and service-policy, so this seems the only workable solution. The last remaining issue with it is that a rule to match IP precedence 5 also matches DSCP EF and if the service-policy is set to rewrite the tagging we will be modifying packets that were already correctly tagged. I doubt we will see any performance impact, as the router is only lightly loaded, but it does...[URL="https://supportforums.cisco.com/message/285214#285214"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/285215#285215"]Re: Hardware transcoder and DiffServ[/URL][URL="https://supportforums.cisco.com/people/pbarman"]pbarman[/URL]25.03.2004 13:29 There is just a little difference between the precedence and dsscp mapping. IP Precedence 5 -- 101000 (decimal 40) DSCP EF -- 101110 (decimal 46) Cisco recommends to use dscp value EF for voice bearer and AF31 for voice control traffic. So, if you follow these guidelines, you will find a difference. And this will for sure use some resources, but that won't make much difference. Thanks, Partha[URL="https://supportforums.cisco.com/message/285215#285215"]Reply[/URL]

[/LIST][/LIST][/LIST][*] [URL="https://supportforums.cisco.com/thread/136443"]ASK THE EXPERT - QoS FOR IP/MPLS...[/URL][URL="https://supportforums.cisco.com/people/ciscomoderator"]ciscomoderator[/URL]42 Replies25.08.2006 11:32 Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to discuss with Cisco expert Santiago Alvarez the implementation of QoS in IP/MPLS networks using Cisco IOS and Cisco IOS XR Software. Santiago, (CCIE # 3621), is the manager of the technical marketing engineering group for service providers in the Network Software and Systems technology group. Since 2000, his main areas of focus have been MPLS and QoS technologies. Remember to use the rating system to let Santiago know if you have received an adequate response. Santiago might not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through August 25, 2006. Visit this forum often to view responses to your questions and the questions of other community members.[URL="https://supportforums.cisco.com/community/feeds/messages?thread=136443"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/136443"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/489718#489718"]Re: ASK THE EXPERT - QoS FOR IP/MPLS...[/URL][URL="https://supportforums.cisco.com/people/samuel0901"]samuel0901[/URL]12.08.2006 20:47 Hi, May I ask a "vtp password" question? My question is, There are 10 switches which has same VTP domain, but without configure "VTP password". If I need to configure "VTP password" to each switch. How can I SAFTY to perform it? It will not affect users which are connected. Regards, Samuel[URL="https://supportforums.cisco.com/message/489718#489718"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/489719#489719"]Re: ASK THE EXPERT - QoS FOR IP/MPLS...[/URL][URL="https://supportforums.cisco.com/people/aamercado"]aamercado[/URL]13.08.2006 22:18ON our CE routers from HQ(T3) to multiple remotes(T1, Frame and ATM), AT&T has GSR as their PE with a fully-meshed MPLS VPN that is QoS provision to: 40% Voip Real Time (RT) for dscp 40 and 46 On the 60% for data, ATT is giving Burst High B(H%)=48 for (dscp 24/cs3, 25, 26/af31 and 28/af32) Burst Low (BL)%=6 for (dscp 18/af21 and 20/af22) Best Effort (BE)%=6 for (dscp 0, cs1/cs2/AF1x, and AF4x) Base on the...[URL="https://supportforums.cisco.com/message/489719#489719"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/489720#489720"]Re: ASK THE EXPERT - QoS FOR IP/MPLS...[/URL][URL="https://supportforums.cisco.com/people/mheusinger"]mheusinger[/URL]14.08.2006 07:36Hello Anthony, besides your questions addressed at the moderator, there is one thing I (and Cisco afaik) would not recommend: a priority queue for call signaling traffic. The priority queue comes with a policer, i.e. in an overload situation excess traffic will be dropped and NOT queued. While this is OK for real time traffic, signaling essentially is data transfer, i.e. queueing and not dropping will be preferable. I rather have a...[URL="https://supportforums.cisco.com/message/489720#489720"]Reply[/URL]

[*] [URL="https://supportforums.cisco.com/message/489724#489724"]Re: ASK THE EXPERT - QoS FOR IP/MPLS...[/URL][URL="https://supportforums.cisco.com/people/saalvare"]saalvare[/URL]15.08.2006 09:58 Regarding item #1, enabling WRED would help high-throughput TCP traffic. You need to identify how much of that type of traffic you have in that class (vs UDP, interactive TCP, others). Regarding item #2, you'd only need to ask them to increase the allocation if you know that the amount of best effort traffic will typically exceed the current bandwidth allocation on their side. Cheers.[URL="https://supportforums.cisco.com/message/489724#489724"]Reply[/URL]

[/LIST][*] [URL="https://supportforums.cisco.com/message/489721#489721"]Re: ASK THE EXPERT - QoS FOR IP/MPLS...[/URL][URL="https://supportforums.cisco.com/people/saalvare"]saalvare[/URL]14.08.2006 18:41 Sorry, really off-topic. I'd suggest you search Cisco.com or use a more appropriate NetPro forum for the question.[URL="https://supportforums.cisco.com/message/489721#489721"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/489722#489722"]Re: ASK THE EXPERT - QoS FOR IP/MPLS...[/URL][URL="https://supportforums.cisco.com/people/aamercado"]aamercado[/URL]14.08.2006 22:21 My question deals with QoS on my MPLS cloud. Why is this off-topic?[URL="https://supportforums.cisco.com/message/489722#489722"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/489725#489725"]Re: ASK THE EXPERT - QoS FOR IP/MPLS...[/URL][URL="https://supportforums.cisco.com/people/saalvare"]saalvare[/URL]15.08.2006 10:00 I was replying to samuel0901 regarding his VTP question. Apologies if my reply got mixed with your question. I've answered your question in a separate posting. Cheers. SA --[URL="https://supportforums.cisco.com/message/489725#489725"]Reply[/URL]

[/LIST][/LIST][*] [URL="https://supportforums.cisco.com/message/489726#489726"]Re: ASK THE EXPERT - QoS FOR IP/MPLS...[/URL][URL="https://supportforums.cisco.com/people/saalvare"]saalvare[/URL]15.08.2006 10:01 Sorry, really off-topic. I'd suggest you search Cisco.com or use a more appropriate NetPro forum for the question. Cheers. SA --[URL="https://supportforums.cisco.com/message/489726#489726"]Reply[/URL]

[/LIST][*] [URL="https://supportforums.cisco.com/message/489723#489723"]Re: ASK THE EXPERT - QoS FOR IP/MPLS...[/URL][URL="https://supportforums.cisco.com/people/bbaley"]bbaley[/URL]15.08.2006 09:14 Hi Santiago, Can you please outline the main QoS differences and similarities between an IP and an MPLS network? Thanks - Bill[URL="https://supportforums.cisco.com/message/489723#489723"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/489727#489727"]Re: ASK THE EXPERT - QoS FOR IP/MPLS...[/URL][URL="https://supportforums.cisco.com/people/saalvare"]saalvare[/URL]15.08.2006 10:13Good question! If you're building your own MPLS network, there is a lot in common between both technologies. Both rely heavily on the DiffServ architecture to provide QoS. They have the same concept of aggregating traffic into a small number of classes that are identified by a packet marking. Based on the marking, the nodes in the network will offer a different service (behavior) to each packet. There are two areas...[URL="https://supportforums.cisco.com/message/489727#489727"]Reply[/URL]

[/LIST][*][URL="https://supportforums.cisco.com/message/136443#136443"]More Replies[/URL][/LIST][*] [URL="https://supportforums.cisco.com/thread/194957"]Is WFQ considered DiffServ?[/URL][URL="https://supportforums.cisco.com/people/news2010a"]news2010a[/URL]1 Reply05.03.2007 17:47 If I understand correclty, WFQ considered DiffServ, right? My understanding is that WFW does not rely on predefined classes. Instead it relies on ToS field in the IP header. Am I right that applications will have that ToS value already defined? From there I just enable #fair-queue and the ToS is already defined and therefore I do not need to configure anything else. [URL="https://supportforums.cisco.com/community/feeds/messages?thread=194957"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/194957"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/750381#750381"]Re: Is WFQ considered DiffServ?[/URL][URL="https://supportforums.cisco.com/people/dgahm"]dgahm[/URL]05.03.2007 17:47Marion, Most applications do not set TOS values, and best practice is to overwrite any TOS values, except from explicitly trusted sources like IP phones or IP telephony servers. You do not want a clever programmer dictating the QOS service levels in your network. WFQ does not depend on TOS values to function correctly (though the TOS value will influence it). You can have all TOS bytes set to 0X00 and WFQ will still protect small...[URL="https://supportforums.cisco.com/message/750381#750381"]Reply[/URL]

[/LIST][*] [URL="https://supportforums.cisco.com/thread/249977"]How are the exp bits used in a 6500[/URL][URL="https://supportforums.cisco.com/people/midoherty"]midoherty[/URL]9 Replies23.02.2005 09:42 I am marking packets with dscp on the edge of the network but after the packets have been through the mpls core (6500's with sup720's) only the equivalent ToS value is in the header. Anyone know of a way to preserve the full DSCP value?[URL="https://supportforums.cisco.com/community/feeds/messages?thread=249977"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/249977"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974604#974604"]Re: How are the exp bits used in a 6500[/URL][URL="https://supportforums.cisco.com/people/hritter"]hritter[/URL]20.12.2004 11:18 The MPLS core might be using the uniform mode, therefore changing the value of your original DSCP. For more information on the different modes defined by MPLS DiffServ Tunneling Modes, refer to the following URL: [url=http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t13/ftdtmode.htm]Redirect: Internal Technical Support ITS[/url] Hope this helps, [URL="https://supportforums.cisco.com/message/974604#974604"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974605#974605"]Re: How are the exp bits used in a 6500[/URL][URL="https://supportforums.cisco.com/people/midoherty"]midoherty[/URL]20.12.2004 18:06Thanks for that reference it is a very useful document, however I think I may be restricted by this bug. 'With a PFC2 or a PFC3, you can either set DSCP in a packet or apply an MPLS tag to the packet, but cannot do both. You cannot set DSCP in a packet and then apply an MPLS tag to that packet. (CSCef19599)' For more info refer to [url=http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/122sx/ol_4164.htm]Redirect: Internal Technical Support ITS[/url] My problem is...[URL="https://supportforums.cisco.com/message/974605#974605"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974606#974606"]Re: How are the exp bits used in a 6500[/URL][URL="https://supportforums.cisco.com/people/hritter"]hritter[/URL]21.12.2004 21:15 This DDTS refers the following workaround: A workaround would be to configure a policy-route and set the values in the route-map. I think it would be worth trying. [URL="https://supportforums.cisco.com/message/974606#974606"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974607#974607"]Re: How are the exp bits used in a 6500[/URL][URL="https://supportforums.cisco.com/people/fcotichelli"]fcotichelli[/URL]04.01.2005 08:27 Hi, a simple question: does the bug CSCef19599 means that a 7600 (with Sup7203BXL-IOS 12.2(18)SXD or SXD3) cannot be an Ingress E-LSR marking incoming IP packets' DSCP Field ? And also, did anyone successfully tested the workaround Harold suggested (the policy-route marking the entire dscp field) - with no performance degradation I hope) ? Thanx in advance Francesco[URL="https://supportforums.cisco.com/message/974607#974607"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974608#974608"]Re: How are the exp bits used in a 6500[/URL][URL="https://supportforums.cisco.com/people/midoherty"]midoherty[/URL]08.02.2005 21:27 Francesco, I am running 12.2(17d)SXB1 so I don't know about that later version. I haven't had a chance to test the policy-route work around as I don't have a spare 6500 with Sup720 to try it on. Michael[URL="https://supportforums.cisco.com/message/974608#974608"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974609#974609"]Re: How are the exp bits used in a 6500[/URL][URL="https://supportforums.cisco.com/people/fcotichelli"]fcotichelli[/URL]09.02.2005 15:39Michael, I hope to test that workaround (and possibly its impact ) in thr next future. Anyway with 720-3bxl and 12.2(18)sdx (no osm) a policy map (matching any and marking ip-dscp to, say, cs1) desn't work if traffic enters the 7600 as IP and leaves as mpls (regardless of the tag stack depth)! When I opened a case on that I've been suggested to put a 2950 before entering the 7600 to do the marking action.... I'll let you know the...[URL="https://supportforums.cisco.com/message/974609#974609"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974610#974610"]Re: How are the exp bits used in a 6500[/URL][URL="https://supportforums.cisco.com/people/fcotichelli"]fcotichelli[/URL]21.02.2005 12:41Hi, i could test the proposed workaround (Cisco7609, IOS version is 12.2(18)SXD3, Sup720-3BXL, NO OSM): *********************************** ip access-list extended test permit tcp any any Route-map test permit 10 Match ip address test set ip precedence critical interface fast 3/24 ip vrf forwarding Test-Vrf ip address x.x.x.x y.y.y.y ip policy route-map test *************************************...[URL="https://supportforums.cisco.com/message/974610#974610"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974611#974611"]Re: How are the exp bits used in a 6500[/URL][URL="https://supportforums.cisco.com/people/midoherty"]midoherty[/URL]23.02.2005 00:38Francesco, I have a 6500 with Sup720-3B in the lab for a few days. I have been able to confirm your results. I also tried using a policy map to set the mpls exp bits, but this appears to not work either. In trying to validate my results I found that the mpls accounting experimental does not work on the 6500 but it does work on other routers I am testing with. If dscp is set prior to entering the 6500 this is...[URL="https://supportforums.cisco.com/message/974611#974611"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974612#974612"]Re: How are the exp bits used in a 6500[/URL][URL="https://supportforums.cisco.com/people/fcotichelli"]fcotichelli[/URL]23.02.2005 09:42 Hi thanx for your reports, really interesting ! If I ever could test anything similar I'll let you know for sure! Hope to hear from you soon Cheers Francesco[URL="https://supportforums.cisco.com/message/974612#974612"]Reply[/URL]

[/LIST][/LIST][/LIST][/LIST][/LIST][/LIST][/LIST][/LIST][*][URL="https://supportforums.cisco.com/message/249977#249977"]More Replies[/URL][/LIST][/LIST]
[URL="https://supportforums.cisco.com/community/feeds/search?peopleEnabled=false&dateRange=all&rankBy=29&q=DiffServ%20%7C%7C%20Tunneling%20%7C%7C%20Modes%20%7C%7C%20for%20%7C%7C%20MPLS%20%7C%7C%20Networks"]Subscribe [/URL][URL="https://supportforums.cisco.com/login.jspa?redirectURL=/choose-container%21input.jspa?contentType=1"]Start A New Discussion[/URL]

[B] Related Information [/B]

[LIST][*] [B] [URL="http://www.cisco.com/en/US/products/ps6557/products_ios_technology_home.html"]Cisco IOS Software - MPLS[/URL] [/B][*] [B] [URL="http://www.cisco.com/en/US/tech/tk828/technologies_q_and_a_item09186a00800a43f5.shtml"]Q &A - Quality of Service for Multi-Protocol Label Switching Networks[/URL] [/B][*] [B] [URL="http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fswtch_c/swprt3/index.htm"]Cisco IOS MPLS Configuration Guide, Release 12.2[/URL] [/B][*] [B] [URL="http://www.cisco.com/en/US/docs/ios/12_2/switch/command/reference/fswtch_r.html"]Cisco IOS Switching Services Command Reference, Release 12.2[/URL] [/B][*] [B] [URL="http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/fqos_c.html"]Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.2[/URL] [/B][*] [B] [URL="http://www.cisco.com/en/US/docs/ios/12_2/qos/command/reference/fqos_r.html"]Cisco IOS Quality of Service Solutions Command Reference, Release 12.2[/URL] [/B][*] [B] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/tsd_technology_support_protocol_home.html"]MPLS Support Page[/URL] [/B][*] [B] [URL="http://www.cisco.com/web/psa/technologies/index.html?c=268435881"]QoS Support Page[/URL] [/B][*] [B] [URL="http://www.cisco.com/cisco/web/support/index.html"]Technical Support - Cisco Systems[/URL] [/B][/LIST]

[SIZE=-1] [/SIZE]
Updated: Feb 15, 2008

[/LEFT]
2010-02-11, 10:32 PM
patris1

[LEFT][B][SIZE=3][B]GRE Tunnel with VRF Configuration Example[/B][/SIZE][/B]

[B]Document ID: 46252[/B]

[B]Contents[/B]

[INDENT] [B] Introduction
[/B] [B] Prerequisites
Requirements
Components Used
Conventions
[/B] [B] Configure
Network Diagram
Configurations
[/B] [B] Verify
[/B] [B] Troubleshoot
[/B] [B] Caveats
[/B] [B] Cisco Support Community - Featured Conversations
[/B] [B] Related Information [/B] [/INDENT][B] Introduction [/B]

This document provides a sample configuration for a VPN routing and forwarding (VRF) instance under a generic routing encapsulation (GRE) tunnel interface.
[B] Prerequisites [/B]

[B] Requirements [/B]

Before you attempt this configuration, ensure that you meet these requirements:
Readers of this document should have knowledge of these topics:

[LIST][*] [URL="http://www.cisco.com/en/US/docs/ios/12_1/switch/configuration/guide/xcdtagc.html"]Configuring Multiprotocol Label Switching[/URL] [*] [URL="http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/VPN.html"]MPLS Virtual Private Networks[/URL] [*] [URL="http://www.cisco.com/en/US/docs/ios/12_3t/12_3t2/feature/guide/gtgrevrf.html"]Generic Routing Encapsulation Tunnel IP Source and Destination VRF Membership[/URL] [/LIST]
[B] Components Used [/B]

The information in this document is based on Cisco IOS® Software Release 12.3(4)T1 on 3725 Series routers.
Use [URL="http://tools.cisco.com/ITDIT/CFN/Dispatch?act=featSelect&task=init"]Cisco Feature Navigator II[/URL] ([SIZE=-1] [URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) and search for the [B]GRE Tunnel IP Source and Destination VRF Membership[/B] feature, to obtain additional software and hardware requirements that you need.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
[B] Conventions [/B]

For more information on document conventions, refer to the [URL="http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080121ac5.shtml"]Cisco Technical Tips Conventions[/URL].
[B] Configure [/B]

In this section, you are presented with the information to configure the features described in this document.
The configuration is set up in this way:

[LIST][*] R1-CE and R2-CE are located in VRF BLUE.[*] R1-CE is also located in VRF GREEN through the use of a GRE tunnel to R3-PE.[/LIST]
R1-CE uses a static host route to get to R3-PE (tunnel destination), which ensures that recursive routing does not occur for the GRE tunnel (learning the tunnel destination address through the tunnel).
VRF BLUE and VRF GREEN are owned by two different companies, and no route leaks occur between them. In addition, the access control list (ACL) on the interface between R1-CE and R2-CE can be used to only permit GRE traffic between them.
[B]Note: [/B]To find additional information on the commands used in this document, use the [URL="http://www.cisco.com/pcgi-bin/Support/Cmdlookup/home.pl"]Command Lookup Tool[/URL] ([SIZE=-1] [URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) .
[B] Network Diagram [/B]

This document uses this network setup:
[B]Figure 1 – Physical Topology[/B]
[IMG]http://www.cisco.com/image/gif/paws/46252/grewithvrf_01.gif[/IMG]
[B]Figure 2 – Logical VRF Topology[/B]
[IMG]http://www.cisco.com/image/gif/paws/46252/grewithvrf_02.gif[/IMG]
[B] Configurations [/B]

This document uses these configurations:

[LIST][*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00801e1294.shtml#r3pe"]R3-PE[/URL] [*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00801e1294.shtml#r4pe"]R4-PE[/URL] [*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00801e1294.shtml#r1ce"]R1-CE[/URL] [*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00801e1294.shtml#r2ce"]R2-CE[/URL] [*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00801e1294.shtml#r5ce"]R5-CE[/URL] [*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00801e1294.shtml#r6ce"]R6-CE[/URL] [/LIST]
R3-PE (Tunnel Endpoint)
R3-PE# [B]show running-config[/B]

Building configuration...
.
!
no ip domain lookup
!
ip vrf blue
rd 1:1
route-target export 311:311
route-target import 411:411
!
ip vrf green
rd 2:2
route-target export 322:322
route-target import 422:422
!
ip cef
!
interface Tunnel0
ip vrf forwarding green
ip address 200.200.200.3 255.255.255.0
tunnel source Ethernet0/0
tunnel destination 10.10.10.1
[B]tunnel vrf blue[/B]
[I]
[COLOR=#0000ff]!--- Tunnel 0 is part of VRF GREEN; but it uses the tunnel
!--- destination and source addresses from the routing
!--- table of VRF BLUE, because of this [B]tunnel vrf blue[/B]
!--- command.[/COLOR]
[/I]
!
interface Ethernet0/0
ip vrf forwarding blue
ip address 20.20.20.3 255.255.255.0
[I]
[COLOR=#0000ff]!--- Connection to the VRF BLUE network and the VRF GREEN
!--- network using the GRE tunnel.[/COLOR]
[/I]
!
interface Ethernet1/0
ip address 30.30.30.3 255.255.255.0
tag-switching ip
!
router bgp 1
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 30.30.30.4 remote-as 1
!
address-family vpnv4
neighbor 30.30.30.4 activate
neighbor 30.30.30.4 send-community extended
exit-address-family
!
address-family ipv4 vrf green
redistribute connected
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf blue
redistribute connected
no auto-summary
no synchronization
exit-address-family
!
ip classless
ip route vrf blue 10.10.10.1 255.255.255.255 20.20.20.2
[I]
[COLOR=#0000ff]!--- Static Host route to ensure that recursive routing
!--- does not occur.[/COLOR]
[/I]
no ip http server
!
.
end
R4-PE
R4-PE# [B]show running-config[/B]

Building configuration...
.
.
.
no ip domain lookup
!
ip vrf blue
rd 1:1
route-target export 411:411
route-target import 311:311
!
ip vrf green
rd 2:2
route-target export 422:422
route-target import 322:322
!
ip cef
!
interface Ethernet0/0
ip address 30.30.30.4 255.255.255.0
tag-switching ip
!
interface Ethernet1/0
ip vrf forwarding green
ip address 100.100.100.4 255.255.255.0
!
interface Ethernet2/0
ip vrf forwarding blue
ip address 40.40.40.4 255.255.255.0
!
router bgp 1
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 30.30.30.3 remote-as 1
!
address-family vpnv4
neighbor 30.30.30.3 activate
neighbor 30.30.30.3 send-community extended
exit-address-family
!
address-family ipv4 vrf green
redistribute connected
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf blue
redistribute connected
no auto-summary
no synchronization
exit-address-family
!
ip classless
.
.
end
R1-CE (Tunnel Endpoint)
R1-CE# [B]show running-config[/B]
Building configuration...
.
.
no ip domain lookup

!
ip cef
!
interface Tunnel0
ip address 200.200.200.1 255.255.255.0
tunnel source Ethernet0/0
tunnel destination 20.20.20.3
[I]
[COLOR=#0000ff]!--- Both the tunnel source and destination address are in
!--- the VRF BLUE, to provide transport for the VRF GREEN
!--- network.[/COLOR]
[/I]
!
interface Ethernet0/0
description Connection to R2-CE router
ip address 10.10.10.1 255.255.255.0
ip access-group 100 in
ip access-group 100 out
[I]
[COLOR=#0000ff]!--- Access-group to allow only GRE packets through the
!--- R2-CE network. However, R1-CE networks data is in the
!--- GRE packet.[/COLOR]
[/I]
!
!
ip classless
ip route 0.0.0.0 0.0.0.0 Tunnel0
ip route 20.20.20.3 255.255.255.255 10.10.10.2
[I]
[COLOR=#0000ff]!--- Static Host route to ensure that recursive routing
!--- does not occur.[/COLOR]
[/I]
no ip http server
!
access-list 100 permit gre host 10.10.10.1 host 20.20.20.3
access-list 100 permit gre host 20.20.20.3 host 10.10.10.1
[I]
[COLOR=#0000ff]!--- Permits only GRE packets between the endpoints.[/COLOR]
[/I]
!
.
.
end
R2-CE
R2-CE# [B]show running-config[/B]

Building configuration...
.
.
no ip domain lookup

!
ip cef
!
interface Ethernet0/0
description Connection to R1-CE router
ip address 10.10.10.2 255.255.255.0
ip access-group 100 in
ip access-group 100 out
!
interface Ethernet1/0
ip address 20.20.20.2 255.255.255.0
!
ip classless
ip route 0.0.0.0 0.0.0.0 20.20.20.3
no ip http server
!
access-list 100 permit gre host 10.10.10.1 host 20.20.20.3
access-list 100 permit gre host 20.20.20.3 host 10.10.10.1
[I]
[COLOR=#0000ff]!--- Permits only GRE packets between the endpoints.[/COLOR]
[/I]
.
!
end
R5-CE
R5-CE# [B]show running-config[/B]

Building configuration...
.
.
no ip domain lookup

!
interface Ethernet0/0
ip address 100.100.100.5 255.255.255.0
!
!
ip classless
ip route 0.0.0.0 0.0.0.0 100.100.100.4
no ip http server
!
.
end
R6-CE
R6-CE# [B]show running-config[/B]

Building configuration...
.
.
no ip domain lookup

!
interface Ethernet0/0
ip address 40.40.40.6 255.255.255.0
!
!
ip classless
ip route 0.0.0.0 0.0.0.0 40.40.40.4
no ip http server
!
.
end
[B] Verify [/B]

This section provides information you can use to confirm your configuration is working properly.
Certain [B]show[/B] commands are supported by the [URL="https://www.cisco.com/cgi-bin/Support/OutputInterpreter/home.pl"]Output Interpreter Tool[/URL] ([SIZE=-1] [URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) , which allows you to view an analysis of [B]show[/B] command output.

[LIST][*] [URL="http://www.cisco.com/en/US/docs/ios/12_3/iproute/command/reference/ip2_s3g.html#wp1039689"] [B]show ip route[/B] [/URL] , [URL="http://www.cisco.com/en/US/docs/ios/12_3/switch/command/reference/swi_s2.html#wp1057479"] [B]show ip route vrf[/B] [/URL]—Issue these commands on the tunnel end points to ensure that the tunnel destination is reachable. This ensures that the tunnel interface will come up.[*] [URL="http://www.cisco.com/en/US/docs/ios/12_3/configfun/command/reference/cfr_1g06.html#wp1075989"] [B]ping[/B] [/URL]—Issue this command from the other end of the CE to ensure that the tunnels are reachable from the CE.[*] [URL="http://www.cisco.com/en/US/docs/ios/12_3/switch/command/reference/swi_s1.html#wp1037841"] [B]show ip bgp vpnv4 all labels[/B] [/URL]—Issue this command on the PE devices to view the VPN labels distributed for each prefix via Border Gateway Protocol (BGP) to other PE devices.[/LIST]
[INDENT] R3-PE# [B]show ip route vrf blue 10.10.10.1[/B]

Routing entry for 10.10.10.1/32
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 20.20.20.2
Route metric is 0, traffic share count is 1

R3-PE# [B]show ip route vrf green[/B]

Routing Table: green
Codes: 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
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
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C 200.200.200.0/24 is directly connected, Tunnel0
100.0.0.0/24 is subnetted, 1 subnets
B 100.100.100.0 [200/0] via 30.30.30.4, 01:11:45

R3-PE# [B]show interfaces tunnel 0[/B]

[B]Tunnel0 is up, line protocol is up[/B]
Hardware is Tunnel
Internet address is 200.200.200.3/24
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
[B]Tunnel source 20.20.20.3 (Ethernet0/0), destination 10.10.10.1[/B]
Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
Tunnel TTL 255
Checksumming of packets disabled, fast tunneling enabled
Last input 00:44:05, output 00:26:16, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
105 packets input, 11964 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
83 packets output, 10292 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out

R3-PE# [B]show ip bgp vpnv4 all labels[/B]

Network Next Hop In label/Out label
Route Distinguisher: 1:1 (blue)
[B]20.20.20.0/24 0.0.0.0 16/aggregate(blue)[/B]
Route Distinguisher: 2:2 (green)
100.100.100.0/24 30.30.30.4 nolabel/16
[B]200.200.200.0 0.0.0.0 17/aggregate(green)[/B]

R4-PE# [B]show ip route vrf blue[/B]

Routing Table: blue
Codes: 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
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
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

20.0.0.0/24 is subnetted, 1 subnets
B 20.20.20.0 [200/0] via 30.30.30.3, 01:14:05

R4-PE# [B]show ip route vrf green[/B]

Routing Table: green
Codes: 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
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
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

B 200.200.200.0/24 [200/0] via 30.30.30.3, 01:14:10
100.0.0.0/24 is subnetted, 1 subnets
C 100.100.100.0 is directly connected, Ethernet1/0

R1-CE# [B]show ip route 20.20.20.3[/B]

Routing entry for 20.20.20.3/32
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 10.10.10.2
Route metric is 0, traffic share count is 1

R1-CE# [B]show interfaces tunnel 0[/B]

[B]Tunnel0 is up, line protocol is up[/B]
Hardware is Tunnel
Internet address is 200.200.200.1/24
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
[B]Tunnel source 10.10.10.1 (Ethernet0/0), destination 20.20.20.3[/B]
Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
Tunnel TTL 255
Checksumming of packets disabled, fast tunneling enabled
Last input 00:26:57, output 00:26:57, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
83 packets input, 10292 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
106 packets output, 12088 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out

R5-CE# [B]ping 200.200.200.1[/B]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.200.200.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/54/80 ms

R5-CE# [B]ping 200.200.200.3[/B]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.200.200.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/36/72 ms[/INDENT][B] Troubleshoot [/B]

There is currently no specific troubleshooting information available for this configuration.
[B] Caveats [/B]

These known caveats are identified for the configuration of this feature. You can use the [URL="http://tools.cisco.com/Support/BugToolKit/action.do?hdnAction=searchBugs"]Bug Toolkit[/URL] ([SIZE=-1] [URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) to search for bugs.

[LIST][*] [URL="http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCea81266"]CSCea81266[/URL] ([SIZE=-1] [URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) —[I]Resolved (R)[/I] GRE: Traffic stops flowing after [B]clear ip route *[/B].[*] [URL="http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCdx74855"]CSCdx74855[/URL] ([SIZE=-1] [URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) —[I]Resolved (R)[/I] Can not ping IP address of local GRE tunnel interface.[*] [URL="http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCdx57718"]CSCdx57718[/URL] ([SIZE=-1] [URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) —[I]Resolved (R)[/I] IP packet loss in GRE tunnel when Cisco Express Forwarding (CEF) disabled on outgoing interface.[/LIST]
[B] Cisco Support Community - Featured Conversations [/B]

[URL="https://supportforums.cisco.com/index.jspa"]Cisco Support Community[/URL] is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers. Below are just some of the most recent and relevant conversations happening right now.
Want to see more? Join us by clicking [URL="https://supportforums.cisco.com/login.jspa"]here[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/thread/1001950"]Unusual GRE connectivity issues[/URL][URL="https://supportforums.cisco.com/people/vanderwaalr"]vanderwaalr[/URL]4 Replies23.12.2009 01:43 Hi, I have a problem relating to GRE connectivity that I just can't pinpoint the cause of. I have a customer with 3 sites that currently connect in a hub-and-spoke fashion. Site 'H' is the hub site with sites 'A' and 'G' connecting to 'H' via 9.6kbps serial links. The network connections are only used for control systems and therefor high bandwidth is not essential. See diagram 'design1.jpg' below: 'Router-H' is a Cisco 2811 router, while 'Router-G' and 'Router-A' are both Cisco 1841 routers. 'Router-H' is running Advanced IP Services 12.4(22)YB4 and 'Router-G' and 'Router-A' are both running IP Base 12.4(22)YB4. This version of IOS is currently used because it is a requirement to support the HWIC-3G-GSM cards installed in all 3 routers, which will be used as part of a later project. The network is being migrated away from the serial links to a managed WAN with copper ethernet handoff. The managed WAN is run by a different business unit and does not route RFC1918 addressing through the WAN. As such, we are configuring a set of GRE tunnels in a hub-and-spoke fashion (basically providing the same connectivity the legacy serial links do) between the 3 sites. Again, 'Router-H' is the hub router with 2 GRE tunnels configured to both 'Router-G' and 'Router-A'. See diagram 'design2.jpg' below: When the GRE tunnels were first configured, they all came up and had IP connectivity running across both tunnels. The problem was experienced a few hours after the tunnels were configured, where they just dropped off and went into a 'down' state for no known reason (we have keepalives configured across both GRE tunnels). For some reason, the tunnels would not re-establish connectivity and return to an 'up' state. In an attempt to re-establish tunnel connectivity, we issued a 'shut' and 'no shut' on the tunnel interfaces at both ends of the tunnels, but with no success. After some fiddling around, we found the only way to restore tunnel connectivity was to basically erase the tunnel configuration at both ends ('no int tunnel 1', 'no int tunnel 2') and then re-apply the configuration. After re-applying the configuration from scratch the tunnels all re-established. However, again, after a few hours the tunnels dropped for no apparent reason and the only way to get them to re-establish was to repeat the process of erasing the tunnel configurations and re-applying. This is continually happening so we have been forced to restore the legacy serial links until we can resolve the GRE connectivity issues. The GRE configuration is pretty straight forward: 'Router-H' configuration: interface Loopback0 ip address 134.xxx.zzz.131 255.255.255.255 no ip redirects no ip unreachables no ip proxy-arp ! interface Tunnel1 description Tunnel to Router-A ip address 10.10.10.1 255.255.255.240 ip mtu 1500 keepalive 10 3 tunnel source Loopback0 tunnel destination 134.xxx.zzz.130 ! interface Tunnel2 description Tunnel to Router-G ip address 10.10.20.1 255.255.255.240 ip mtu 1500 keepalive 10 3 tunnel source Loopback0 tunnel destination 134.xxx.zzz.129 ! interface FastEthernet0/1 ip address 134.xxx.yy.90 255.255.255.252 duplex auto speed auto ! 'Router-G' configuration: interface Loopback0 ip address 134.xxx.zzz.129 255.255.255.255 no ip redirects no ip unreachables no ip proxy-arp ! interface Tunnel1 description Tunnel to Hastings ip address 10.10.20.2 255.255.255.240 ip mtu 1500 keepalive 10 3 tunnel source Loopback0 tunnel destination 134.xxx.zzz.131 ! interface FastEthernet0/1 ip address 134.xxx.yy.86 255.255.255.252 duplex auto speed auto ! 'Router-A' configuration: interface Loopback0 ip address 134.xxx.zzz.130 255.255.255.255 no ip redirects no ip unreachables no ip proxy-arp ! interface Tunnel1 description Tunnel to Hastings ip address 10.10.10.2 255.255.255.240 ip mtu 1500 keepalive 10 3 tunnel source Loopback0 tunnel destination 134.xxx.zzz.131 ! interface FastEthernet0/1 ip address 134.xxx.yy.82 255.255.255.252 duplex auto speed auto ! At one point we thought it was a connectivity issue with the managed WAN but the fact that the GRE tunnels do establish when you first apply the configuration has led us away from this thinking at this stage. Another train of thought is that it is a bug of some sort, but we have tested running GRE tunnels over the serial links on the same hardware and this works fine, so we are not focusing our attention on this train of thought. Unfortunately we do not have configuration access to the managed WAN but do have access to an Engineer who supports the managed WAN. Has anyone out there experienced issues like this, or can anyone offer any suggestions/thoughts on where we should look..? All reports from the managed WAN engineer are that there is no access-list filtering in the WAN blocking GRE connectivity. ICMP ping connectivity is also not blocked. Thanks in advance.[B]Attachments:[/B]

[LIST][*][URL="https://supportforums.cisco.com/message/2008293#2008293"]design2.jpg[/URL][*][URL="https://supportforums.cisco.com/message/2008293#2008293"]design1.jpg[/URL][/LIST]
[URL="https://supportforums.cisco.com/community/feeds/messages?thread=1001950"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/1001950"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/2008359#2008359"]Re: Unusual GRE connectivity issues[/URL][URL="https://supportforums.cisco.com/people/marwanshawi"]marwanshawi[/URL]22.12.2009 01:38 two thing to check first make sure the loopack address ( used as a tunnels rources and destinations ) reachable via your IGP ( you have to have in the routing table first) this is to make sure no recursive routing happing next decrease mtu in the tunnel interface last thing why you are using keep alive here are tracking this interface or what ? also why you dont use fa0/1 as the tunnel source ? good luck[URL="https://supportforums.cisco.com/message/2008359#2008359"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/2008793#2008793"]Re: Unusual GRE connectivity issues[/URL][URL="https://supportforums.cisco.com/people/vanderwaalr"]vanderwaalr[/URL]22.12.2009 14:48Thanks for your response. I should have mentioned this in my first post, but the Loopback addresses are all reachable within the managed WAN. This was the first thing I tested. 'Router-H' can ping the loopback addresses of both 'Router-G' and 'Router-A', and vice-versa. We have also tried reducing the MTU size down to 1476 but this did not seem to fix the issues, the tunnels still dropped after an hour or so. One comment worth...[URL="https://supportforums.cisco.com/message/2008793#2008793"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/2008922#2008922"]Re: Unusual GRE connectivity issues[/URL][URL="https://supportforums.cisco.com/people/marwanshawi"]marwanshawi[/URL]22.12.2009 23:38 can just try to keep tunnel from the hub to one of the spokes and see if its drop or not only one trunnl i am just thinkingmay be the hub droping this tunnel if htis is the case you may try mGRE[URL="https://supportforums.cisco.com/message/2008922#2008922"]Reply[/URL]

[*] [URL="https://supportforums.cisco.com/message/2008950#2008950"]Re: Unusual GRE connectivity issues[/URL][URL="https://supportforums.cisco.com/people/paluchpeter"]paluchpeter[/URL]23.12.2009 01:43Hello, Just a single suggestion: is it acceptable for you to deactivate the keepalives for, say, a day long, and have a continuous conectivity test such a ping running on PCs on your locations across the WAN to see if the tunnels stay up and active? I would like to see if the problem with the tunnel stability can be tracked down to the keepalive mechanism or if there is some more profound cause that prevents your tunnels from exchanging...[URL="https://supportforums.cisco.com/message/2008950#2008950"]Reply[/URL]

[/LIST][/LIST][/LIST][*] [URL="https://supportforums.cisco.com/thread/249035"]Gre tunnel in a vrf[/URL][URL="https://supportforums.cisco.com/people/mathieu.ploton"]mathieu.ploton[/URL]5 Replies31.07.2008 19:47 Hello, I'm trying to setup a gre tunnel over my mpls network in a VRF called Intra. Here is my conf. It's weird because the tunnel protocol is up on one side, down on the other side. I can ping the destination ip address on each side. interface Loopback30 ip vrf forwarding Intra ip address 192.168.252.80 255.255.255.255 interface Tunnel1 ip vrf forwarding Intra ip unnumbered Loopback30 keepalive 3 3 tunnel source Loopback30 tunnel destination 10.10.40.1 sh int tunnel 1 Tunnel1 is up, line protocol is down Hardware is Tunnel Interface is unnumbered. Using address of Loopback30 (192.168.252.80) MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive set (3 sec), retries 3 Tunnel source 192.168.252.80 (Loopback30), destination 10.10.40.1, fastswitch TTL 255 Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled Tunnel TTL 255 Checksumming of packets disabled, fast tunneling enabled Last input 00:00:00, output never, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 421 Queueing strategy: fifo Output queue: 0/0 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec L2 Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast L3 out Switched: ucast: 0 pkt, 0 bytes mcast: 0 pkt, 0 bytes 443 packets input, 21700 bytes, 0 no buffer Received 0 broadcasts (0 IP multicast) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 packets output, 0 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out ------------------- interface Tunnel1 ip vrf forwarding Intra ip unnumbered FastEthernet0/1 keepalive 3 3 tunnel source FastEthernet0/1 tunnel destination 192.168.252.80 tunnel vrf Intra interface FastEthernet0/1 ip vrf forwarding Intra ip address 10.10.40.1 255.255.255.0 duplex full speed 100 sh int tunnel 1 Tunnel1 is up, line protocol is up Hardware is Tunnel Interface is unnumbered. Using address of FastEthernet0/1 (10.10.40.1) MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive set (3 sec), retries 3 Tunnel source 10.10.40.1 (FastEthernet0/1), destination 192.168.252.80 Tunnel protocol/transport GRE/IP Key disabled, sequencing disabled Checksumming of packets disabled Tunnel TTL 255 Fast tunneling enabled Tunnel transmit bandwidth 8000 (kbps) Tunnel receive bandwidth 8000 (kbps) Last input never, output 00:00:00, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 7 Queueing strategy: fifo Output queue: 0/0 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 0 packets input, 0 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 556 packets output, 31180 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 unknown protocol drops 0 output buffer failures, 0 output buffers swapped out [URL="https://supportforums.cisco.com/community/feeds/messages?thread=249035"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/249035"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/970132#970132"]Re: Gre tunnel in a vrf[/URL][URL="https://supportforums.cisco.com/people/a.alekseev"]a.alekseev[/URL]07.07.2008 15:32 one command is missing "tunnel vrf Intra" on the first device. [URL="https://supportforums.cisco.com/message/970132#970132"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/970133#970133"]Re: Gre tunnel in a vrf[/URL][URL="https://supportforums.cisco.com/people/mathieu.ploton"]mathieu.ploton[/URL]07.07.2008 23:37 The command does not exist on that one (6500 12.2)[URL="https://supportforums.cisco.com/message/970133#970133"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/970134#970134"]Re: Gre tunnel in a vrf[/URL][URL="https://supportforums.cisco.com/people/a.alekseev"]a.alekseev[/URL]08.07.2008 01:48 You should upgrade IOS on the 6500 I have such command with 12.2(33)SXH2[URL="https://supportforums.cisco.com/message/970134#970134"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/970135#970135"]Re: Gre tunnel in a vrf[/URL][URL="https://supportforums.cisco.com/people/mathieu.ploton"]mathieu.ploton[/URL]08.07.2008 01:51 Ok thank you, i'm in 12.2(18), that should be the problem ![URL="https://supportforums.cisco.com/message/970135#970135"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/970136#970136"]Re: Gre tunnel in a vrf[/URL][URL="https://supportforums.cisco.com/people/rkhalil"]rkhalil[/URL]31.07.2008 19:47 If you can't put "tunnel vrf" command in router A tunnel , that's not works , "tunnel vrf" command for it uses the tunnel destination and source addresses from the routing table of VRF is not set the tunnel destination is unreachable, tunnel use backbplane routing table.. [URL="https://supportforums.cisco.com/message/970136#970136"]Reply[/URL]

[/LIST][/LIST][/LIST][/LIST][/LIST][*] [URL="https://supportforums.cisco.com/thread/343733"]Is it possible ot send VRF traffic over...[/URL][URL="https://supportforums.cisco.com/people/keeleym%40o2.ie"]keeleym@o2.ie[/URL]11 Replies26.11.2009 10:04 Hi All Could you please look at the attached diagram and see if what I am attempting to do is possible and if so could you provide some pointers please. In the diagram I have two routers connected over the corporate WAN/Internet, each router in a different geographical location. On each router I have 2 VRF's configured SI and EDU. The IP addresses assigned to the interfaces to which these VRF's are bound are in the same subnet. What I would like to be able to do next is to configure a GRE tunnel for each VRF so that if I connect the PC on the left to the SI VRF and the PC on the right to the SI VRF traffic between these two nodes will go over the GRE tunnel. The reason that both VRF's have IP addresses in the same subnet is because the IP addresses on the test nodes (represented by the PC's in the diagram) are not easily changed and may be booked for use by different units in my organization and these units can not share networks. What I have done so far is as follows (using Dynamips), Configured 3 routers, JAKARTA, HALIMANTAN and Internet Configured WAN IP connectivity as per the diagram, where by from JAKARTA I can ping the F0/0 interface on KALIMANTAN and visa versa. Configured the VRF's on each router as follows JAKARTA (config)ip vrf SI (config-vrf)rd 100:1 (config-vrf)exit (config)int f2/0 (config-if)ip vrf forwarding SI (config-if)ip add 159.xxx.10.1 255.255.255.0 (config-if)no shut (config-if)exit (config) I have entered a similar configuration for the EDU VRF, changing the VRF name, RD value (200:1) interface & IP assigned to the interface KALIMANTAN (config)ip vrf SI (config-vrf)rd 100:1 (config-vrf)exit (config)int f2/0 (config-if)ip vrf forwarding SI (config-if) ip add 159.xxx.100.1 255.255.255.0 (config-if)no shut (config-if)exit (config) Again I have entered a similar configuration for the EDU VRF, changing the VRF name, RD value (200:1), interface & IP assigned to the interface. I then attempted to set up the GRE Tunnel for the SI VRF as follows JAKARTA (config)int tun0 (config-if)ip add 10.0.0.1 255.255.255.0 (config-if)tunnel source 159.xxx.10.1 (config-if)tunnel dest 159.xxx.100.1 (config-if)exit (config) KALIMANTAN (config)int tun0 (config-if)ip add 10.0.0.2 255.255.255.0 (config-if)tunnel source 159.xxx.100.1 (config-if)tunnel dest 159.xxx.10.1 (config-if)exit (config) I then tried to ping 10.0.0.2 from JAKARTA but the pings failed. Likewise pings to 10.0.0.1 from KALIMANTAN also failed. The routing tables on the routers are shown below (there is no mention of the 159.xxx subnet's in the routing table of either router) JAKARTA's routing table Gateway of last resort is 192.168.50.2 to network 0.0.0.0 10.0.0.0/24 is subnetted, 1 subnets C 10.0.0.0 is directly connected, Tunnel0 C 192.168.50.0/24 is directly connected, FastEthernet0/0 S* 0.0.0.0/0 [1/0] via 192.168.50.2 KALIMANTAN's routing table Gateway of last resort is 192.168.80.2 to network 0.0.0.0 C 192.168.80.0/24 is directly connected, FastEthernet0/0 10.0.0.0/24 is subnetted, 1 subnets C 10.0.0.0 is directly connected, Tunnel0 S* 0.0.0.0/0 [1/0] via 192.168.80.2 There are no vrf routes configured on either router. If anybody could either tell me this is not possible or give me some pointers to what I am doing wrong I would much appreciate it. I should also mention I have never worked with VRFs' before and have oly a little knowledge of GRE tunnels. Best Regards, Michael[B]Attachments:[/B]

[LIST][*][URL="https://supportforums.cisco.com/message/1321342#1321342"]Cisco GRE Tunnel.vsd.zip[/URL][*][URL="https://supportforums.cisco.com/message/1321342#1321342"]Cisco GRE Tunnel.jpg[/URL][/LIST]
[URL="https://supportforums.cisco.com/community/feeds/messages?thread=343733"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/343733"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/1321357#1321357"]Re: Is it possible ot send VRF traffic...[/URL][URL="https://supportforums.cisco.com/people/giuslar"]giuslar[/URL]24.11.2009 05:43Hello Michael, to build VRF communication you need to put the GRE tunnel in the VRF interface tunnel0 ip vrf forwarding XX on both devices, this creates a point-to-point link in VRF between the two sites also you need a GRE tunnel for each VRF that needs to be interconnected as you noted Notice that this works for sure on software based routers but be aware that some multilayer switches like some C4507 allows...[URL="https://supportforums.cisco.com/message/1321357#1321357"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/1321406#1321406"]Re: Is it possible ot send VRF traffic...[/URL][URL="https://supportforums.cisco.com/people/keeleym%40o2.ie"]keeleym@o2.ie[/URL]24.11.2009 07:18Hi Giuseppe Thanks for the reply. I have tried this and it's sill not working. What I have done is Removed the "ip vrf forwarding SI/EDU" commands from F2/0 7 F2/1 from both routers This removed the IP addresses on these interfaces automatically I then shut down both F2/0 7 F2/1 on both routers Next I configured the Tun0 interfaces as follows I added the "ip vrf forwarding SI/EDU" command to the tun0...[B]Attachments:[/B]

[LIST][*][URL="https://supportforums.cisco.com/message/1321406#1321406"]JAKARTA-Conf.txt.zip[/URL][*][URL="https://supportforums.cisco.com/message/1321406#1321406"]KALIMANTAN-conf.txt.zip[/URL][/LIST]
[URL="https://supportforums.cisco.com/message/1321406#1321406"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/1321472#1321472"]Re: Is it possible ot send VRF traffic...[/URL][URL="https://supportforums.cisco.com/people/giuslar"]giuslar[/URL]24.11.2009 08:21 Hello Michael, each VRF has its own routing table so: to see VRF SI routing table you need to use sh ip route vrf SI to ping an host in VRF you need to use ping VRF SI x.x.x.x and so on each command requires to add VRF vrf-name you cannot see routing entries for a VRF in the global routing table that you see with conventional sh ip route Hope to help Giuseppe[URL="https://supportforums.cisco.com/message/1321472#1321472"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/1321483#1321483"]Re: Is it possible ot send VRF traffic...[/URL][URL="https://supportforums.cisco.com/people/keeleym%40o2.ie"]keeleym@o2.ie[/URL]24.11.2009 09:24Hi Guiseppe Again many thanks for your reply. Working with VRF's for the first time is kind of confusing So I have reconfigured the routers just for VRF SI initially and now I that I know the correct commands to use, I can see that there is an entry for the SI vrf (see below) JAKARTA# sh ip route vrf SI Gateway of last resort is not set 10.0.0.0/24 is subnetted, 1 subnets...[URL="https://supportforums.cisco.com/message/1321483#1321483"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/1321514#1321514"]Re: Is it possible ot send VRF traffic...[/URL][URL="https://supportforums.cisco.com/people/sharifimr"]sharifimr[/URL]24.11.2009 10:34Hi Michael, In your attached configs, I do not see any routing protocols configured. You will need to deploy OSPF or EIGRP or BGP. Here is a sample config for EIGRP and OSPF router eigrp 100 passive-interface default no passive-interface Tunnel0 no auto-summary ! address-family ipv4 vrf example network xx.xx.xx.0 0.0.0.255 no auto-summary autonomous-system 100 exit-address-family...[URL="https://supportforums.cisco.com/message/1321514#1321514"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/1321724#1321724"]Re: Is it possible ot send VRF traffic...[/URL][URL="https://supportforums.cisco.com/people/keeleym%40o2.ie"]keeleym@o2.ie[/URL]24.11.2009 15:31 Hi Reza Thank you for your response and the example configuration. Is it not possible to send VRF traffic over a GRE tunnel without using a routing protocol. Just using static routes? Best Regards, Michael[URL="https://supportforums.cisco.com/message/1321724#1321724"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/1321760#1321760"]Re: Is it possible ot send VRF traffic...[/URL][URL="https://supportforums.cisco.com/people/sharifimr"]sharifimr[/URL]24.11.2009 16:12 Michael, You can use static routes, but routing protocols can load balance the traffic and resiliency are automatically achieved. Also configuring too many static routes became an administrative burden. Reza [URL="https://supportforums.cisco.com/message/1321760#1321760"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/1321905#1321905"]Re: Is it possible ot send VRF traffic...[/URL][URL="https://supportforums.cisco.com/people/keeleym%40o2.ie"]keeleym@o2.ie[/URL]25.11.2009 02:48Hi All I think I am making slow but steady progress. I have configured two tunnel interfaces Tun0 & Tun1 and these are bound to two different VRF's. Tun0 is bound ot vrf SI and Tun1 is bound ot vrf EDU. However I can only ping the tunnel end point of tun0. I have tried first with both tunnels using the same source port and Dest IP address. Then I tried adding a secondary IP address to my WAN interface of both...[URL="https://supportforums.cisco.com/message/1321905#1321905"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/1322011#1322011"]Re: Is it possible ot send VRF traffic...[/URL][URL="https://supportforums.cisco.com/people/giuslar"]giuslar[/URL]25.11.2009 05:36Hello Michael, the following two tests should work ping vrf SI 10.0.0.2 ping vrf EDU 20.0.0.2 to see actual VRF routing in action you can add one loopback on each router and the related static routes int loop55 ip vrf forwarding SI ip address 10.110.225.1 255.255.255.255 int loop66 ip vrf forwarding EDU ip address 20.220.250.1 255.255.255.255 on the other router ip route vrf...[URL="https://supportforums.cisco.com/message/1322011#1322011"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/1321995#1321995"]Re: Is it possible ot send VRF traffic...[/URL][URL="https://supportforums.cisco.com/people/keeleym%40o2.ie"]keeleym@o2.ie[/URL]25.11.2009 06:52Hi Guiseppe I have not managed to get both GRE tunnels up and working at the same time. What is happening is that I start of with the two routers (Jakarta & Kalimantan) configured with a WAN link. These two routers are connected to a third router acting as the Internet. I can ping the WAN interface on each router from the other. I then configured the 2 VRF's on each router SI , RD 100:1 EDU RD 200: Next I...[URL="https://supportforums.cisco.com/message/1321995#1321995"]Reply[/URL]

[/LIST][/LIST][/LIST][/LIST][/LIST][/LIST][/LIST][/LIST][/LIST][*][URL="https://supportforums.cisco.com/message/343733#343733"]More Replies[/URL][/LIST][*] [URL="https://supportforums.cisco.com/thread/211763"]GRE tunnel configuration help[/URL][URL="https://supportforums.cisco.com/people/branfarm1"]branfarm1[/URL]2 Replies12.09.2009 18:41 Hi there, I have a need to use a GRE tunnel to connect two subnets across my WAN, but I've never created a tunnel before and I'm not quite sure the correct process. In SiteA I have 147.249.26.136/30, and at SiteB I have 147.249.27.176/29. I have a host in SiteB (147.249.27.180) that needs to route to a series of networks that are reachable via the SiteA 147.249.26.136 network. So I know I need to create a tunnel interface at each site, and set destination and source IP's. Does it matter what I use for the tunnel interface IP? Also, the subnets at each site are on Vlan interfaces, so do I use those as the destination and source IP's for the tunnel? Thanks in advance, Brandon [URL="https://supportforums.cisco.com/community/feeds/messages?thread=211763"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/211763"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/831523#831523"]Re: GRE tunnel configuration help[/URL][URL="https://supportforums.cisco.com/people/rburts"]rburts[/URL]11.09.2009 08:43Brandon One of the basic requirements for successful GRE tunnel is that the tunnel destination address must be reachable from the source before the tunnel comes up. Based on this it might be advantageous if you configure the GRE tunnel to have its source and destination addresses as the outward facing interfaces on each router. You can choose a subnet for the GRE tunnel. As long as the subnet is unique (does not overlap with...[URL="https://supportforums.cisco.com/message/831523#831523"]Reply[/URL]

[*] [URL="https://supportforums.cisco.com/message/831524#831524"]Re: GRE tunnel configuration help[/URL][URL="https://supportforums.cisco.com/people/leolaohoo"]leolaohoo[/URL]12.09.2009 18:41I don't know what the network design is going to be like so you'll need to go through these configuration examples/guides and pick which is suitable. IPSec/GRE with NAT on IOS Router Configuration Example [url=http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a0080094bff.shtml]IPSec/GRE with NAT on IOS Router Configuration Example - Cisco Systems[/url] GRE Tunnel with VRF Configuration Example...[URL="https://supportforums.cisco.com/message/831524#831524"]Reply[/URL]

[/LIST][*] [URL="https://supportforums.cisco.com/thread/190413"]GRE Tunnel Configuration ??????[/URL][URL="https://supportforums.cisco.com/people/afzaalq007"]afzaalq007[/URL]5 Replies27.11.2006 22:06 Hi I want to config the GRE Tunnel over my 7206 VXR running BGP on it, I have read the DOC about GRE tunnel Config. on cisco site in tgis DOc the routing protocol is EIGRP ... this is the title of DOc (GRE over IPSec with EIGRP to Route Through a Hub and Multiple Remote Sites Configuration Example ) i want to ask same config will work for BGP or not ?????? Thanks [URL="https://supportforums.cisco.com/community/feeds/messages?thread=190413"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/190413"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/731081#731081"]Re: GRE Tunnel Configuration ??????[/URL][URL="https://supportforums.cisco.com/people/tdrais"]tdrais[/URL]31.05.2006 05:36 Not sure if I found the doc you are talking about. In general BGP is far more forgiving that EIGRP or any IGP for that matter. BGP uses TCP to essablish it neighbors unlike EIGRP that uses multicast. You should have no issues using the tunnel end points as your BGP neighbors. With BGP it is possible with some careful IPSEC configuration to use only IPSEC and avoid the overhead of the GRE tunnel. [URL="https://supportforums.cisco.com/message/731081#731081"]Reply[/URL]

[*] [URL="https://supportforums.cisco.com/message/731082#731082"]Re: GRE Tunnel Configuration ??????[/URL][URL="https://supportforums.cisco.com/people/sean%40managednetworks.com"]sean@managednetworks.com[/URL]31.05.2006 06:59 It should work. I would recommend using loopbacks for your BGP peers and then pointing to the tunnels for each of the neighbor loopbacks. My friends and I did this so we could run BGP with each other from our home connections.[URL="https://supportforums.cisco.com/message/731082#731082"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/731083#731083"]Re: GRE Tunnel Configuration ??????[/URL][URL="https://supportforums.cisco.com/people/afzaalq007"]afzaalq007[/URL]31.05.2006 07:46 Hi Can u provide me sample configuration of tunnel and also sample configuration with GRE over bgp Thanks for the response [URL="https://supportforums.cisco.com/message/731083#731083"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/731084#731084"]Re: GRE Tunnel Configuration ??????[/URL][URL="https://supportforums.cisco.com/people/amohabir1"]amohabir1[/URL]27.11.2006 15:04 [url=http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00800a43f6.shtml]Configuring a GRE Tunnel over IPsec with OSPF - Cisco Systems[/url] That should be a good starting point. It is using OSPF, but if you replace it with BGP you should be able to accomplish what you are trying to do.[URL="https://supportforums.cisco.com/message/731084#731084"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/731085#731085"]Re: GRE Tunnel Configuration ??????[/URL][URL="https://supportforums.cisco.com/people/royalblues"]royalblues[/URL]27.11.2006 22:06Hi friend, Here is a sample config Router 1 interface Tunnel3 ip address 10.10.10.50 255.255.255.252 keepalive 10 3 tunnel source 192.168.172.30 tunnel destination 192.168.172.2 router bgp 64521 no synchronization bgp log-neighbor-changes network 172.16.119.0 mask 255.255.255.0 timers bgp 5 15 neighbor 192.168.172.29 remote-as 9730 neighbor 192.168.172.29 ebgp-multihop 2 no auto-summary Router 2...[URL="https://supportforums.cisco.com/message/731085#731085"]Reply[/URL]

[/LIST][/LIST][/LIST][/LIST][*] [URL="https://supportforums.cisco.com/thread/248030"]GRE Tunnel interfaces in MPLS VRF[/URL][URL="https://supportforums.cisco.com/people/zahid.hassan"]zahid.hassan[/URL]10 Replies22.11.2006 02:35 Dear All, I am having to configure a GRE tunnel between a Cisco 2600 and SUP-720 acting as MPLS PE. GRE CE (2600) <--------> PE (SUP-720) The tunnel interface on the SUP-720 is in a VRF and I can connect to the other interfaces connected locally on the same PE from the CE. However, I am not being able connect to any other interfaces on the same VRF which are configured on any other PE routers. So basically I can only connect to routes which are local to the PE where the GRE tunnel terminates. Here is my config: PE (SUP-720) ! interface Tunnel1 ip vrf forwarding test ip address 192.168.1.1 255.255.255.252 ip mtu 1460 keepalive 10 3 tunnel source 219.168.33.6 tunnel destination 211.151.241.108 tunnel mode ipip end ! CE (2600) ! interface Tunnel1 ip address 192.168.1.2 255.255.255.252 ip mtu 1460 keepalive 10 3 tunnel source 211.151.241.108 tunnel destination 219.168.33.6 tunnel mode ipip end ! Also I am seeing packets hitting the CE from the PE but not getting back to the PE. I am running OSPF over the tunnel and I have all the necessary routes in place. Has anyone experienced anything similar ? Any help or input will be very much appreciated. Regards, Zahid [URL="https://supportforums.cisco.com/community/feeds/messages?thread=248030"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/248030"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/965439#965439"]Re: GRE Tunnel interfaces in MPLS VRF[/URL][URL="https://supportforums.cisco.com/people/pankajkulkarni"]pankajkulkarni[/URL]20.11.2006 18:20Zahid, There are 2 configuration changes you'll have to make to get this working - 1. "Tunnel keepalives" is supported only with GRE encapsulation. This feature isn't available with encapsulation IPIP. Refer to link below for more information on tunnel keepalives - [url=http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1839/products_feature_guide09186a0080087cec.html]Cisco.com Login Page[/url] 2. While configuring tunnels with VRFs use...[URL="https://supportforums.cisco.com/message/965439#965439"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/965440#965440"]Re: GRE Tunnel interfaces in MPLS VRF[/URL][URL="https://supportforums.cisco.com/people/zahid.hassan"]zahid.hassan[/URL]21.11.2006 03:24 Pankaj, Many thanks for the reply. I have added the tunnel vrf command and changed the mode to GRE. Unfortunately, this hasn't made any difference. I am wondering if there is any know issue with tag-switching GRE packets on 6500/SUP-720 running 12.2(18)SXD3. Anything else that you can think of ? Regards, Zahid [URL="https://supportforums.cisco.com/message/965440#965440"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/965441#965441"]Re: GRE Tunnel interfaces in MPLS VRF[/URL][URL="https://supportforums.cisco.com/people/pankajkulkarni"]pankajkulkarni[/URL]21.11.2006 04:03Zahid, Are you trying to configure GRE tunnel between the PE-CE or across the MPLS backbone? Incase you are attempting tunnel between PE-CE the configuration snapshot I provided in my earlier post is adeqaute to establish connectivity, infact it was taken from a working setup. Could you send me the information below which will help me analyze better. 1. Network diagram 2. configuration of all routers. 3. show command...[URL="https://supportforums.cisco.com/message/965441#965441"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/965443#965443"]Re: GRE Tunnel interfaces in MPLS VRF[/URL][URL="https://supportforums.cisco.com/people/zahid.hassan"]zahid.hassan[/URL]21.11.2006 06:03 Pankaj, I tested this same configuration by terminating the tunnel at the PE end on a 7200/NPE-G1 and it works fine. So it looks like there is an issue with tag-switching GRE packets on the SUP-720 (12.2(18)SXD3). Thanks again for all your input on this. Regards, Zahid [URL="https://supportforums.cisco.com/message/965443#965443"]Reply[/URL]

[/LIST][/LIST][/LIST][*] [URL="https://supportforums.cisco.com/message/965442#965442"]Re: GRE Tunnel interfaces in MPLS VRF[/URL][URL="https://supportforums.cisco.com/people/oettls"]oettls[/URL]21.11.2006 05:28 Hi Zahid, check out the global command: 'mls mpls tunnel-recir' It enables packet recirculation to the SUP720 when labels on tunneled packets are imposed if I remember correctly. hope this helps cheers, Stefan[URL="https://supportforums.cisco.com/message/965442#965442"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/965444#965444"]Re: GRE Tunnel interfaces in MPLS VRF[/URL][URL="https://supportforums.cisco.com/people/swaroop.potdar"]swaroop.potdar[/URL]21.11.2006 07:481) Keepalives will help you bring the tunnel status down if its not up end to end. But as pointed it can be done on a GRE encap only. 2) Tunnel VRF command is use for a different purpose (ie: when you want to tunnel one VRF into another) So that wouldnt be of much help. On the contrary if you run the current config on lets say a 2600 PE and a 2600 CE it will definately work. So this is pointing to a problem somewhere else,...[URL="https://supportforums.cisco.com/message/965444#965444"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/965445#965445"]Re: GRE Tunnel interfaces in MPLS VRF[/URL][URL="https://supportforums.cisco.com/people/pankajkulkarni"]pankajkulkarni[/URL]21.11.2006 09:04 Hello Swaroop, I was configuring a GRE tunnel between a PE (7206) and CE (1750). One end of the tunnel belonged to the VRF instance. Without the "tunnel vrf" command the tunnel status was asymmetric. On the CE router the status was UP/UP (status/line protocol) whereas on the PE end it was UP/Down. This state got resolved upon adding the vrf tunnel command. Regards, Pankaj[URL="https://supportforums.cisco.com/message/965445#965445"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/965446#965446"]Re: GRE Tunnel interfaces in MPLS VRF[/URL][URL="https://supportforums.cisco.com/people/swaroop.potdar"]swaroop.potdar[/URL]21.11.2006 10:48Hello Pankaj, COnventionally when we configure a GRE tunnel the source and destination are supposed to be reachable via the Global Routing Table. But by using this feature We can configure a GRE tunnel using the source and destination from a VRF. So essentially when we configure a GRE tunnel, lets say Tu10, then if we pick up the source and destination from a VRF x then we have to specify this using the command VRF x. And...[URL="https://supportforums.cisco.com/message/965446#965446"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/965447#965447"]Re: GRE Tunnel interfaces in MPLS VRF[/URL][URL="https://supportforums.cisco.com/people/pankajkulkarni"]pankajkulkarni[/URL]21.11.2006 23:10Hello Swaroop, I doubt the tunnel would have come UP without the "tunnel vrf" command in place. Unless, the tunnel is UP neither would be OSPF adjacency be formed. Zahid could confirm this for us. I had tried this scenario in the lab and found that the tunnel stays DOWN unless the command is applied. I agree with you and hope Zahid would share more information which should be handy to identify the problem. Regards,...[URL="https://supportforums.cisco.com/message/965447#965447"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/965448#965448"]Re: GRE Tunnel interfaces in MPLS VRF[/URL][URL="https://supportforums.cisco.com/people/zahid.hassan"]zahid.hassan[/URL]22.11.2006 02:35 Hi Pankaj, I configured the tunnel without the "tunnel vrf" command and its works fine. Regards, Zahid [URL="https://supportforums.cisco.com/message/965448#965448"]Reply[/URL]

[/LIST][/LIST][/LIST][/LIST][/LIST][*][URL="https://supportforums.cisco.com/message/248030#248030"]More Replies[/URL][/LIST][*] [URL="https://supportforums.cisco.com/thread/248339"]GRE Tunnel configuration over MPLS[/URL][URL="https://supportforums.cisco.com/people/prasaddesai.in"]prasaddesai.in[/URL]18 Replies29.06.2007 05:37 HI, I am configuring GRE tunnel between two PE's but tunnel is not coming up please advice how to proceed, Configuration of PE1; 3845] interface Tunnel100 ip vrf forwarding DCN-NEC ip address 10.1.1.1 255.255.255.252 tunnel source 192.168.104.250 tunnel destination 199.168.99.253 ip route vrf DCN-NEC 199.168.99.253 255.255.255.255 91.8.4.5 Configuration on PE2: mls mpls tunnel-recir interface Tunnel100 ip vrf forwarding DCN-NEC ip address 10.1.1.2 255.255.255.252 tunnel source 199.168.99.253 tunnel destination 192.168.104.250 ip route vrf DCN-NEC 192.168.104.250 255.255.255.255 91.8.5.129 Regards, Prasad Desai Datacraft India Ltd. [B]Attachments:[/B]

[LIST][*][URL="https://supportforums.cisco.com/message/966904#966904"]Show_Tech.zip[/URL][/LIST]
[URL="https://supportforums.cisco.com/community/feeds/messages?thread=248339"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/248339"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/966905#966905"]Re: GRE Tunnel configuration over MPLS[/URL][URL="https://supportforums.cisco.com/people/mohammedmahmoud"]mohammedmahmoud[/URL]26.06.2007 05:01 Hi, Can you ping the tunnel destination from both sides ? BR, Mohammed Mahmoud.[URL="https://supportforums.cisco.com/message/966905#966905"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/966906#966906"]Re: GRE Tunnel configuration over MPLS[/URL][URL="https://supportforums.cisco.com/people/mheusing"]mheusing[/URL]26.06.2007 05:20 Hi, You might want to follow the config guide found at "GRE Tunnel with VRF Configuration Example" [url=http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00801e1294.shtml]GRE Tunnel with VRF Configuration Example - Cisco Systems[/url] This should work with the proper IOS version installed. Hope this helps! Regards, Martin[URL="https://supportforums.cisco.com/message/966906#966906"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/966907#966907"]Re: GRE Tunnel configuration over MPLS[/URL][URL="https://supportforums.cisco.com/people/swaroop.potdar"]swaroop.potdar[/URL]26.06.2007 06:23Can you run it through these checks. 1) Does your tunnel come up without the "ip vrf forwarding" on the tunnel. 2) Looking closely at your config it seems that you are trying to reach the /32 subnets with the "ip route vrf:" route. But you are using the same subnets are source and destination as well. So to better troubleshoot can you specify your objective behind having a tunnel between 2 PE's. So that...[URL="https://supportforums.cisco.com/message/966907#966907"]Reply[/URL]

[*] [URL="https://supportforums.cisco.com/message/966908#966908"]Re: GRE Tunnel configuration over MPLS[/URL][URL="https://supportforums.cisco.com/people/swaroop.potdar"]swaroop.potdar[/URL]26.06.2007 06:37 Hi Martin, Glad to see you, and welcome back in the new role !!! Cheers, Swaroop[URL="https://supportforums.cisco.com/message/966908#966908"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/966909#966909"]Re: GRE Tunnel configuration over MPLS[/URL][URL="https://supportforums.cisco.com/people/mheusing"]mheusing[/URL]26.06.2007 07:08Hi Swaroop, Thank you, I am also glad to be back in the new role ;-) Regarding the topic here: sorry, I gave the wrong example (GRE to CE and not between two PEs). The tunnel destination in your config is actually in the VRF, but your static route points to the global ip, wich will not be found in the VRF (check with "show ip route vrf DCN-NEC"). In addition you do not have the static in your "show tech" output. and the tunnel...[URL="https://supportforums.cisco.com/message/966909#966909"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/966910#966910"]Re: GRE Tunnel configuration over MPLS[/URL][URL="https://supportforums.cisco.com/people/prasaddesai.in"]prasaddesai.in[/URL]26.06.2007 22:45 Dear Martin i tried ur both option in 1st option i used ip address as source of interface vlan 93 which is i configured for ip vrf forwarding DCN-NEC & destination ip address of vice versa but it is not working. When i tried 2nd option i used loopback ip addresses of routers tunnel comes up. i dont undestand why it is not up when i used ip addresses from ip vrf DCN-NEC.[URL="https://supportforums.cisco.com/message/966910#966910"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/966911#966911"]Re: GRE Tunnel configuration over MPLS[/URL][URL="https://supportforums.cisco.com/people/swaroop.potdar"]swaroop.potdar[/URL]27.06.2007 00:08When you use the source and destination from the DCN VRF it wont come up because the routes are not reachable in the global routing table. To create a tunnel using a VRF source and destination you will have to use this feature. [url]http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_guide09186a00805e1e8e.html[/url] Now when you use a PE loopback as source and destination, they are reachable in the global table,...[URL="https://supportforums.cisco.com/message/966911#966911"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/966912#966912"]Re: GRE Tunnel configuration over MPLS[/URL][URL="https://supportforums.cisco.com/people/prasaddesai.in"]prasaddesai.in[/URL]27.06.2007 06:55Thanks Swaroop for ur help , the page you have send is not available. We are using vrf for DCN NEC . Idea behind configuring the tunnel is to form isis adjaency because DCN NEC have the area01 used in old DCN NEC & in our NEW MPlS network where we are migrating old DCN NEC we are using area01 as backbone & VRF use for that DCN is DCN-NEC. So the idea was as the vrf Come up the tunnel interface will come up & isis...[URL="https://supportforums.cisco.com/message/966912#966912"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/966913#966913"]Re: GRE Tunnel configuration over MPLS[/URL][URL="https://supportforums.cisco.com/people/swaroop.potdar"]swaroop.potdar[/URL]27.06.2007 07:07 Since you are trying to connect two endpoints of a VRF over a tunnel, why dont you create a tunnel directly between the CE. I am still not clear why do you need tunnels formed using the PE's and what will would be achieved. And also you are trying to route OSI CLNS or IP or its both elements for the DCN. A small diagram would be good. HTH-Cheers, Swaroop[URL="https://supportforums.cisco.com/message/966913#966913"]Reply[/URL]

[*] [URL="https://supportforums.cisco.com/message/966914#966914"]Re: GRE Tunnel configuration over MPLS[/URL][URL="https://supportforums.cisco.com/people/mheusing"]mheusing[/URL]27.06.2007 08:15Hi, If I understand correctly you want to migrate an OSPF customer network to a MPLS VPN solution. If this is correct, then you still could use OSPF in the VRF environment. The customer network might or might not use the same area as the ISP in the backbone, because both are well separated. The customer can also have the same area in different locations. Example: CE1(area1)-PE1-P-PE2-CE2(area1) The PE1-P-PE2 IGP is completely invisible...[URL="https://supportforums.cisco.com/message/966914#966914"]Reply[/URL]

[/LIST][/LIST][/LIST][/LIST][/LIST][/LIST][/LIST][*][URL="https://supportforums.cisco.com/message/248339#248339"]More Replies[/URL][/LIST][*] [URL="https://supportforums.cisco.com/thread/200813"]GRE Tunnel configuration[/URL][URL="https://supportforums.cisco.com/people/Lavanholy"]Lavanholy[/URL]6 Replies14.01.2008 07:28 Hi, I have to configure the GRE tunnel between Site A and Site B. 1. Site A route is connected to a Cisco PIX525 and the PIX 525 inturn connected to Internet. 2. This router serial interface is connected to Site B router through a 512 KB leased line. 3.Site B router also connected to Cisco PIX 525 firewall and the firewall is connected to Internet. 4. Both sites users are accessing internet through router and through PIX 525. 5. Both side networks are accessible through the routers using a static route. My requirement is if the leased line between the sites are down,then the traffic between the sites has to be directed through PIX525 through internet as a redundant. My assumption is as follows: 1. I will configure IPsec site to site between Cisco PIX 525 firewall. 2. I will configure another static route with the higher metric than the previous route that is between the serial interfaces of the routers. 3. My firewall is PIX 525 with 6.13 ios version. 4. My router is Cisco 1750 5. Help to configure the GRE tunnel and IP route . Thanks and Regards, [URL="https://supportforums.cisco.com/community/feeds/messages?thread=200813"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/200813"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/777801#777801"]Re: GRE Tunnel configuration[/URL][URL="https://supportforums.cisco.com/people/royalblues"]royalblues[/URL]07.01.2008 14:06 You cannot configure a GRE tunnel on a PIX or ASA. Configure a site-site ipsec tunnel between the pix and allow the subnets in the crypto access-list for communication Have a look at this link [url=http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a0080094761.shtml]PIX 6.x: Simple PIX-to-PIX VPN Tunnel Configuration Example - Cisco Systems[/url] HTH Narayan [URL="https://supportforums.cisco.com/message/777801#777801"]Reply[/URL]

[*] [URL="https://supportforums.cisco.com/message/777802#777802"]Re: GRE Tunnel configuration[/URL][URL="https://supportforums.cisco.com/people/williamsdo%40si.edu"]williamsdo@si.edu[/URL]07.01.2008 14:15 Hi, you will have to configure a VPN tunnel if you require ipsec. GRE tunnel are useful if you require routing through your tunnel because they will transmit multicast packets use to maintain routing tables. Have a look at the document below it contain a configuration for VPN tunnel on pix firewall. HTH [url=http://www.cisco.com/warp/public/110/38.html]CCO Redirect[/url] [URL="https://supportforums.cisco.com/message/777802#777802"]Reply[/URL]

[*] [URL="https://supportforums.cisco.com/message/777803#777803"]Re: GRE Tunnel configuration[/URL][URL="https://supportforums.cisco.com/people/Collin_Clark"]Collin_Clark[/URL]07.01.2008 14:34As others said, the *best* way of doing this is to use VPN between your PIX firewalls. You'll also want to upgrade your firewall OS and upgrade to the 3DES license (free). Also using two static routes will not work. A static route will never disappear from the routing table so the other route will never "take over". You will need to run a routing protocol internally then set your static route for the VPN a little higher than the IGP AD. ...[URL="https://supportforums.cisco.com/message/777803#777803"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/777804#777804"]Re: GRE Tunnel configuration[/URL][URL="https://supportforums.cisco.com/people/Lavanholy"]Lavanholy[/URL]11.01.2008 21:31 Hi Mr.Ceclark, Thanks for the guidance. I will have IP sec VPN tunnel between two sites firewall. My LAN router is connected to other site router by means of a leased line.It has static IP route with lower metric. Now I will have another static route inthe same router with higher metric. Will it work? Please guide me. Thanks and Regards, S.Venkataraman.[URL="https://supportforums.cisco.com/message/777804#777804"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/777806#777806"]Re: GRE Tunnel configuration[/URL][URL="https://supportforums.cisco.com/people/Collin_Clark"]Collin_Clark[/URL]14.01.2008 07:28 It will NOT work. Remember that static routes are always in the routing table. The lower metric route will never disappear and the other route will never be used! [URL="https://supportforums.cisco.com/message/777806#777806"]Reply[/URL]

[/LIST][/LIST][*] [URL="https://supportforums.cisco.com/message/777805#777805"]Re: GRE Tunnel configuration[/URL][URL="https://supportforums.cisco.com/people/medan"]medan[/URL]11.01.2008 22:49 Hi, Site-A Router-A>FW-A>Internet Site-B Router-B>FW-B>Internet Between Site-A and Site-B Router-A|LeasedLine|Router-B Is the internet facing subnet of firewall is bigger? I'm thinking of triangular connection between router, firewall, and provider router. This way, you can run IP GRE over IPSec VPN in the router. Regards, Dandy[URL="https://supportforums.cisco.com/message/777805#777805"]Reply[/URL]

[/LIST][*] [URL="https://supportforums.cisco.com/thread/74785"]Question regarding tunnel configuration...[/URL][URL="https://supportforums.cisco.com/people/toerierz%40telkom.co.za"]toerierz@telkom.co.za[/URL]2 Replies14.11.2002 00:17 Please have a look at this example: [url=http://www.cisco.com/univercd/cc/td/doc/product/core/7100/swcg/6342gre.htm#xtocid50]Redirect: Internal Technical Support ITS[/url] hq-sanjose interface Tunnel0 bandwidth 180 ip address 172.17.3.3 255.255.255.0 no ip directed-broadcast tunnel source 172.17.2.4 tunnel destination 172.24.2.5 crypto map s1first ro-rtp interface Tunnel1 bandwidth 180 ip address 172.24.3.6 255.255.255.0 no ip directed-broadcast tunnel source 172.24.2.5 tunnel destination 172.17.2.4 crypto map s1first Why does the tunnel interfaces have different networks allocated to them 172.24 & 172.17 ? Should they not have just one network like 172.24.3.0 /30 allocated to both sides of the tunnel ? Tried to simulate sometning similair in a lab using the loopback addresse of each router "ip unnumbered Loopback0" on both sides but it does not work. The tunnel interface status is up up but ospf does not 'learn' about the networks of the other router and no traffic is transported through the tunnel. [URL="https://supportforums.cisco.com/community/feeds/messages?thread=74785"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/74785"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/262142#262142"]Re: Question regarding tunnel...[/URL][URL="https://supportforums.cisco.com/people/wkumari"]wkumari[/URL]13.11.2002 11:38Yes, for what you are tying to do, the tunnel interfaces should be in the same network (like 172.24.3.0/30). After doing that try turning off the crypto map stuff and seeing if OSPF will come up (remember to do someting like network 172.24.3.0 0.0.0.3 area 0 in the OSPF config!). If that works, then turn on the crypto map and make sure it continues to work. If the crypto map makes it break, make sure that you are matching ospf packets in the...[URL="https://supportforums.cisco.com/message/262142#262142"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/262143#262143"]Re: Question regarding tunnel...[/URL][URL="https://supportforums.cisco.com/people/toerierz%40telkom.co.za"]toerierz@telkom.co.za[/URL]14.11.2002 00:17Warren, thanks for the advise. I got the tunnel working using a single subnet for both sides of the tunnel, this was on IOS 11.1(24). I could not get the cisco example to work though, I upgraded to IOS 12.0(22) and only then did the cisco example work. So it looks like it is very much dependent on the IOS version. I still dont really understand the example as it does not make sense to me. Next step is to get a CLNS tunnel...[URL="https://supportforums.cisco.com/message/262143#262143"]Reply[/URL]

[/LIST][/LIST][*] [URL="https://supportforums.cisco.com/thread/249501"]GRE tunnel protocol status goes down...[/URL][URL="https://supportforums.cisco.com/people/kaustav.gupta"]kaustav.gupta[/URL]5 Replies01.06.2009 13:38 I have setup of 4 routers R1 - R2 - R3 - R4 . They are connected as shown. I have also setup a GRE tunnel between R1 and R4. The tunnel status is up and protocol is up. I have configured tunnel source and reach ability related configurations in R1,R2,R3 and R4. Now if I put R1/R4 Tunnel Source Loopback Int, Tunnel Interface and Int connecting R2/R3 in vrf A and also modify the static route to reach Tunnel Destination IP in R4 into a vrf static route the tunnel protocol goes down. Can anybody help ? Thanks Kas[URL="https://supportforums.cisco.com/community/feeds/messages?thread=249501"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/249501"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/972496#972496"]Re: GRE tunnel protocol status goes...[/URL][URL="https://supportforums.cisco.com/people/shivlu"]shivlu[/URL]29.05.2009 10:56 Hi Tunnel protocol down means the destination is not reachable in vrf routing table. Please check have you given the reverse route in vrf. regards shivlu jain [URL="https://supportforums.cisco.com/message/972496#972496"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/972498#972498"]Re: GRE tunnel protocol status goes...[/URL][URL="https://supportforums.cisco.com/people/kaustav.gupta"]kaustav.gupta[/URL]29.05.2009 22:02 Hi, I have configured vrf static routes Tunnel source and desitination and tested xtended ping vrf A dest loop source int lo0. I got ICMP type 8 & 0 msgs which is absolutely fine. So source and destination loopbacks are reachable .thats probally not the issue .[URL="https://supportforums.cisco.com/message/972498#972498"]Reply[/URL]

[/LIST][*] [URL="https://supportforums.cisco.com/message/972497#972497"]Re: GRE tunnel protocol status goes...[/URL][URL="https://supportforums.cisco.com/people/hritter"]hritter[/URL]29.05.2009 11:51 Kas, you need to configure "tunnel vrf <vrf-name>" under the tunnel interface configuration to tell the tunnel interface that the tunnel destination is resolvable via the specific VRF. By default, the tunnel destination is resolvable via the global routing table. Regards [URL="https://supportforums.cisco.com/message/972497#972497"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/972499#972499"]Re: GRE tunnel protocol status goes...[/URL][URL="https://supportforums.cisco.com/people/kaustav.gupta"]kaustav.gupta[/URL]29.05.2009 22:05 Hi, But if I have configured a ip vrf forwarding A under the gre tunnel interface will not take care of it. Anyways i am trying out your command[URL="https://supportforums.cisco.com/message/972499#972499"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/972500#972500"]Re: GRE tunnel protocol status goes...[/URL][URL="https://supportforums.cisco.com/people/hritter"]hritter[/URL]01.06.2009 13:38 Kas, The fact of configuring the tunnel itself in a specific VRF, using the "ip vrf forwaring <vrf-name>, doesn't force the IOS to perform the tunnel destination lookup in that VRF. The tunnel destination lookup is still performed against the global routing table by default. Only the "tunnel vrf" command can change the default behavior. Regards [URL="https://supportforums.cisco.com/message/972500#972500"]Reply[/URL]

[/LIST][/LIST][/LIST][/LIST]
[URL="https://supportforums.cisco.com/community/feeds/search?peopleEnabled=false&dateRange=all&rankBy=29&q=GRE%20%7C%7C%20Tunnel%20%7C%7C%20with%20%7C%7C%20VRF%20%7C%7C%20Configuration%20%7C%7C%20Example"]Subscribe [/URL][URL="https://supportforums.cisco.com/login.jspa?redirectURL=/choose-container%21input.jspa?contentType=1"]Start A New Discussion[/URL]

[B] Related Information [/B]

[LIST][*] [B] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/tsd_technology_support_protocol_home.html"]MPLS Technology Support Page[/URL] [/B][*] [B] [URL="http://www.cisco.com/cisco/web/support/index.html"]Technical Support & Documentation - Cisco Systems[/URL] [/B][/LIST]

[SIZE=-1] [/SIZE]
Updated: Jan 16, 2006
[/LEFT]
2010-02-11, 10:34 PM
patris1

[LEFT][B][SIZE=3]Implementing an MPLS VPN over TE Tunnels[/SIZE][/B]

[B]Document ID: 29828[/B]

[B]Contents[/B]

[INDENT] [B] Introduction
[/B] [B] Prerequisites
Requirements
Components Used
Conventions
Background Theory
[/B] [B] Initial VPN Setup Between CE1 and CE2 Without a TE Tunnel
Topology
Configuration
Verification
[/B] [B] Case 1: VPN over a TE Tunnel When the TE Tunnel Is from PE1 to PE2
Topology
Configuration
Verification
[/B] [B] Case 2: VPN over a TE Tunnel When the TE Tunnel Is from PE1 to P2
Topology
Configuration
Verification
Explanation
Solution
[/B] [B] Case 3: VPN Between CE1 and CE2 over a TE Tunnel from P1 to P2 When TDP/LDP Is Not Enabled
Topology
Configuration
Verification
Solution
[/B] [B] Case 4: VPN over a TE Tunnel Between P1 and P2 with LDP Enabled
Topology
Configuration
Verification
[/B] [B] Case 5: MPLS VPN over a Tunnel Between P1 and PE2
Topology
Configuration
Verification
[/B] [B] Known Issues
[/B] [B] Conclusion
[/B] [B] Cisco Support Community - Featured Conversations
[/B] [B] Related Information [/B] [/INDENT][B] Introduction [/B]

This document provides sample configurations for implementing a Multiprotocol Label Switching (MPLS) VPN over traffic engineering (TE) tunnels in an MPLS network. In order to gain the benefits of an MPLS VPN over TE tunnels, both should coexist in the network. This document illustrates various scenarios that explain why packet forwarding within an MPLS VPN over TE tunnels might fail. It also provides a possible solution.
[B] Prerequisites [/B]

[B] Requirements [/B]

Readers of this document should have knowledge of these topics:

[LIST][*] [URL="http://www.cisco.com/en/US/docs/ios/12_1t/12_1t3/feature/guide/traffeng.html"]MPLS Traffic Engineering and Enhancements[/URL] [*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00800a6c11.shtml"]Configuring a Basic MPLS VPN[/URL] [/LIST]
[B] Components Used [/B]

This document is not restricted to specific software and hardware versions.
[B] Conventions [/B]

Refer to [URL="http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080121ac5.shtml"]Cisco Technical Tips Conventions[/URL] for more information on document conventions.
[B] Background Theory [/B]

[IMG]http://www.cisco.com/image/gif/paws/29828/mplsvpnte-1.gif[/IMG]
As shown in this topology, in a simple MPLS VPN configuration, Provider Edge 1 (PE1) learns the VPN label (Label 1 [L1]) for the VPN prefix 172.16.13.0/24 via multiprotocol Border Gateway Protocol (MPBGP) from PE2 directly, with the next hop as the PE2 loopback address. PE1 also learns the label (L2) for the PE2 loopback address via Label Distribution Protocol (LDP) from its next hop P1.
When forwarding data to the VPN prefix 172.16.13.13, PE1 uses a label stack {L2 L1} with L2 as the outer label. L2 gets swapped by the transit label switch router (LSR), P1. P2 pops the outer L2 and forwards the packet to PE2 with only one L1. To better understand why P2 pops L2, refer to section 3.16 about penultimate hop popping (PHP) in [URL="http://www.ietf.org/rfc/rfc3031.txt"]RFC 3031[/URL] [IMG]http://www.cisco.com/images/exit.gif[/IMG]. Thus, packets to the VPN IP version 4 (IPv4) prefix 172.16.13.0/24 are label switched over an MPLS network.
The MPLS VPN forwarding operation fails if any P router receives the packet with L1 (VPN label) as the only outer label instead of the {L2 L1} label stack. This occurs because none of the P routers has L1 in its label forwarding information base (LFIB) to switch the packet.
An MPLS TE uses Resource Reservation Protocol (RSVP) to exchange labels. When a router is configured for both TE and Tag Distribution Protocol (TDP)/LDP, the router receives different labels from both LDP and RSVP for a given prefix. The labels from LDP and RSVP do not need to be the same in all situations. The router installs an LDP label in the forwarding table if the prefix is learned through an LDP interface, and it installs the RSVP label in the forwarding table if the prefix is learned over a TE tunnel interface.
In the case of a plain TE tunnel (without LDP/TDP enabled on the tunnel), the ingress LSR (the LSR on the headend of the TE tunnel) uses the same label as is used for reaching the tailend of the TE tunnel for all the routes that are learned through a TE tunnel.
For example, there is a TE tunnel from PE1 to P2 learning the prefix 10.11.11.11/32 over the tunnel. The tunnel tailend on P2 is 10.5.5.5, and the label to reach 10.5.5.5 in PE1 is L3. PE1 then uses L3 to reach the destination 10.11.11.11/32, learned over the TE tunnel.
In the scenario [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a0080125b01.shtml#topology"]above[/URL], when there is a TE tunnel between PE1 and P2, consider that PE1 forwards data to Customer Edge 2 (CE2). If L4 is the VPN label, PE1 forwards the data with the label stack {L3 L4}. P1 pops L3, and P2 receives the packet with L4. PE2 is the only LSR that can correctly forward the packet with the outer label L4. P2 does not have an MPBGP session with PE2, so it does not receive the L4 from PE2. Therefore, P2 does not have any knowledge of L2, and it drops the packet.
The configurations and [B]show[/B] outputs that follow demonstrate this and illustrate one possible solution to this problem.
[B] Initial VPN Setup Between CE1 and CE2 Without a TE Tunnel [/B]

[B] Topology [/B]

[IMG]http://www.cisco.com/image/gif/paws/29828/mplsvpnte-1.gif[/IMG]
[B] Configuration [/B]

Only the relevant parts of the configuration files are included here:
PE1
hostname PE1
ip cef
!
ip vrf aqua
rd 100:1
route-target export 1:1
route-target import 1:1
!
mpls traffic-eng tunnels
!
interface Loopback0
ip address 10.2.2.2 255.255.255.255
no ip directed-broadcast
!
interface Ethernet2/0/1
ip vrf forwarding aqua
ip address 172.16.1.2 255.255.255.0
!
interface Ethernet2/0/2
ip address 10.7.7.2 255.255.255.0
ip router isis
mpls traffic-eng tunnels
tag-switching ip
!
router isis
passive-interface Loopback0
net 47.1234.2222.2222.2222.00
is-type level-1
metric-style wide
mpls traffic-eng router-id Loopback0
mpls traffic-eng level-1
!
router bgp 1
bgp log-neighbor-changes
neighbor 10.11.11.11 remote-as 1
neighbor 10.11.11.11 update-source Loopback0
!
address-family vpnv4
neighbor 10.11.11.11 activate
neighbor 10.11.11.11 send-community extended
exit-address-family
!
address-family ipv4
neighbor 10.11.11.11 activate
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf aqua
redistribute connected
no auto-summary
no synchronization
exit-address-family
PE2
hostname PE2
!
ip vrf aqua
rd 100:1
route-target export 1:1
route-target import 1:1
!
mpls traffic-eng tunnels
!
interface Loopback0
ip address 10.11.11.11 255.255.255.255
!
interface POS0/1
ip address 10.12.12.10 255.255.255.0
ip router isis
mpls traffic-eng tunnels
tag-switching ip
crc 16
clock source internal
!
interface POS5/1
ip vrf forwarding aqua
ip address 172.16.13.11 255.255.255.0
crc 32
clock source internal
!
router isis
passive-interface Loopback0
mpls traffic-eng router-id Loopback0
mpls traffic-eng level-1
net 47.1234.1010.1010.1010.00
is-type level-1
metric-style wide
!
router bgp 1
bgp log-neighbor-changes
neighbor 10.2.2.2 remote-as 1
neighbor 10.2.2.2 update-source Loopback0
no auto-summary
!
address-family vpnv4
neighbor 10.2.2.2 activate
neighbor 10.2.2.2 send-community extended
exit-address-family
!
address-family ipv4 vrf aqua
redistribute connected
no auto-summary
no synchronization
exit-address-family
!
[B] Verification [/B]

PE2 learns PE1 VPN IPv4 prefix 172.16.1.0/24 over MPBGP peering between PE1 and PE2. This is shown here:
[INDENT] PE2# [B]show ip route vrf aqua[/B]
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR

Gateway of last resort is not set

10.0.0.0/24 is subnetted, 2 subnets
[B]B 172.16.1.0 [200/0] via 10.2.2.2, 16:09:10[/B]
C 172.16.13.0 is directly connected, POS5/1[/INDENT]Similarly, PE1 learns PE2 VPN IPv4 prefix 172.16.13.0/24 over MPBGP peering between PE1 and PE2. This is shown here:
[INDENT] PE1# [B]show ip route vrf aqua[/B]
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR

Gateway of last resort is not set

10.0.0.0/24 is subnetted, 2 subnets
[B]B 172.16.13.0 [200/0] via 10.11.11.11, 16:09:49[/B]
C 172.16.1.0 is directly connected, Ethernet2/0/1

PE1# [B]show ip route vrf aqua 172.16.13.13[/B]
Routing entry for 172.16.13.0/24
Known via "bgp 1", distance 200, metric 0, type internal
Last update from 10.11.11.11 16:13:19 ago
Routing Descriptor Blocks:
* 10.11.11.11 (Default-IP-Routing-Table), from 10.11.11.11, 16:13:19 ago
Route metric is 0, traffic share count is 1
AS Hops 0, BGP network version 0

PE1# [B]show ip cef vrf aqua 172.16.13.13[/B]
172.16.13.0/24, version 11, cached adjacency 10.7.7.7
0 packets, 0 bytes
tag information set
local tag: VPN route head
fast tag rewrite with Et2/0/2, 10.7.7.7, tags imposed {17 12308}
via 10.11.11.11, 0 dependencies, recursive
next hop 10.7.7.7, Ethernet2/0/2 via 10.11.11.11/32
valid cached adjacency
tag rewrite with Et2/0/2, 10.7.7.7, tags imposed [B]{17 12308}[/B]
[I]
[COLOR=#0000ff]!--- The label stack used to reach 172.16.13.13 is
!--- {17 12308}, where 17 is the outer label to reach next hop 10.11.11.11
!--- and 12308 is the VPN IPv4 label for 172.16.13.0/24.[/COLOR]
[/I]

PE1# [B]show ip cef 10.11.11.11[/B]
10.11.11.11/32, version 31, cached adjacency 10.7.7.7
0 packets, 0 bytes
tag information set
local tag: 21
fast tag rewrite with Et2/0/2, 10.7.7.7, tags imposed {17}
via 10.7.7.7, Ethernet2/0/2, 1 dependency
next hop 10.7.7.7, Ethernet2/0/2
valid cached adjacency
tag rewrite with Et2/0/2, 10.7.7.7, tags imposed [B]{17}[/B]
[I]
[COLOR=#0000ff]!--- Outer label 17 is used to reach next hop 10.11.11.11.[/COLOR]
[/I][/INDENT]Thus, CE1 can reach 172.16.13.13 on the CE2 network via the VPN routing and forwarding (VRF) instance "aqua", which is configured on PE1 using the label stack {17 12308}, as shown above.
This [B]ping[/B] output confirms the connectivity:
[INDENT] CE1# [B]ping 172.16.13.13[/B]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.13.13, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms[/INDENT][B] Case 1: VPN over a TE Tunnel When the TE Tunnel Is from PE1 to PE2 [/B]

[B] Topology [/B]

[IMG]http://www.cisco.com/image/gif/paws/29828/mplsvpnte-2.gif[/IMG]
When the TE tunnel is built between the PE routers with autoroute announce used, the egress PE BGP next hop is reachable via the TE tunnel interface. Thus, PE1 uses the TE label to reach PE2.
[B]Note: [/B]MPLS TE is independent of LDP, which means that, if you have a full mesh of tunnels from PE to PE, you can effectively disable LDP in the routers and do not need to run LDP on the TE tunnel interfaces. However, you must build all tunnels to the BGP next hop of the VPN version 4 (VPNv4) routes. In the example in this [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a0080125b01.shtml#config2"]Configuration[/URL], you can see that this BGP next hop is the Loopback0 on PE2, 10.11.11.11. This same loopback is also the tunnel destination for the tunnel from PE1 to PE2. This explains why, in this example, if there is also a tunnel from PE2 to PE1 for the return traffic, you can disable LDP in the core. Then, forwarding from CE to CE works with all VPNv4 traffic carried over the TE tunnels. If the BGP next hop is not the same as the TE tunnel destination, LDP must be run in the core and on the TE tunnel.
[B] Configuration [/B]

The additional configuration on PE1 to establish a PE tunnel is shown here:
PE1
PE1# [B]show run interface tunnel 0[/B]
!
interface Tunnel0
ip unnumbered Loopback0
no ip directed-broadcast
no ip route-cache distributed
tunnel destination 10.11.11.11
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng path-option 10 dynamic
end
[B] Verification [/B]

[INDENT] PE1# [B]show ip cef vrf aqua 172.16.13.13[/B]
172.16.13.0/24, version 11
0 packets, 0 bytes
tag information set
local tag: VPN route head
fast tag rewrite with Tu0, point2point, tags imposed {19 12308}
via [B]10.11.11.11[/B], 0 dependencies, recursive
next hop 10.11.11.11, Tunnel0 via 10.11.11.11/32
valid adjacency
tag rewrite with Tu0, point2point, tags imposed [B]{19 12308}[/B]
[I]
[COLOR=#0000ff]!--- The label stack to reach 172.16.13.13 is {19 12308}.
!--- BGP next hop for the VPNv4 prefix is 10.11.11.11, which is
!--- the same as the TE tunnel destination.[/COLOR]
[/I]

PE1# [B]show ip route 10.11.11.11[/B]
Routing entry for 10.11.11.11/32
Known via "isis", distance 115, metric 40, type level-1
Redistributing via isis
Last update from 10.11.11.11 on Tunnel0, 00:02:09 ago
Routing Descriptor Blocks:
* 10.11.11.11, from 10.11.11.11, [B]via Tunnel0[/B]
[I]
[COLOR=#0000ff]!--- The route is via Tunnel0.[/COLOR]
[/I]
Route metric is 40, traffic share count is 1[/INDENT]Now, confirm the outer label used to reach the next hop 10.11.11.11 via Tunnel0.
[INDENT] PE1# [B]show mpls traffic-eng tunnels tunnel 0[/B]

Name: PE1_t0 (Tunnel0) Destination: 10.11.11.11
Status:
Admin: up Oper: up Path: valid Signalling: connected

path option 10, type dynamic (Basis for Setup, path weight 30)

Config Parameters:
Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: enabled LockDown: disabled Loadshare: 0 bw-based
auto-bw: disabled

InLabel : -
OutLabel : Ethernet2/0/2, [B]19[/B]
[I]
[COLOR=#0000ff]!--- Label 19 from RSVP is used to reach destination 10.11.11.11/32.[/COLOR]
[/I]
RSVP Signalling Info:
Src 10.2.2.2, Dst 10.11.11.11, Tun_Id 0, Tun_Instance 31
RSVP Path Info:
My Address: 10.7.7.2
Explicit Route: 10.7.7.7 10.8.8.7 10.8.8.5 10.12.12.10
10.11.11.11
Record Route: NONE
Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=Inf
Shortest Unconstrained Path Info:
Path Weight: 30 (TE)
Explicit Route: 10.7.7.2 10.7.7.7 10.8.8.7 10.8.8.5
10.12.12.10 10.11.11.11
History:
Tunnel:
Time since created: 17 hours, 17 minutes
Time since path change: 32 minutes, 54 seconds
Current LSP:
Uptime: 32 minutes, 54 seconds
Prior LSP:
ID: path option 10 [14]
Removal Trigger: tunnel shutdown[/INDENT]Another way to view this information quickly is to use the output modifiers in the [B]show[/B] commands, as shown here:
[INDENT] PE1# [B]show mpls traffic-eng tunnels tunnel 0 | include Label[/B]
InLabel : -
OutLabel : Ethernet2/0/2, [B]19[/B]
[I]
[COLOR=#0000ff]!--- This is the label to reach 10.11.11.11.[/COLOR]
[/I][/INDENT]Look at the tag stack. It is 19, which is the TE label, used to forward packets to next hop 10.11.11.0 over Tunnel0.
[INDENT] PE1# [B]show tag forwarding-table 10.11.11.11 detail[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
21 Pop tag 10.11.11.11/32 0 [B]Tu0[/B] point2point
MAC/Encaps=14/18, MTU=1500, Tag Stack[B]{19}[/B], via Et2/0/2
00603E2B02410060835887428847 00013000
No output feature configured
Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
PE1#[/INDENT]Thus, PE1 sends a packet destined to 172.16.13.13 with the label stack {19 12308}. P1 swaps the label 19. The packet reaches P2, which pops that outer label. Then, the packet is forwarded to PE2 with only the label 12308.
On PE2, the packet with the label 12308 is received and switched according to the information in the forwarding table. This is shown here:
[INDENT] PE2# [B]show tag for tags 12308 detail[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
12308 [B]Aggregate[/B] 172.16.13.0/24[V] 12256
MAC/Encaps=0/0, MTU=0, Tag Stack{}
VPN route: aqua
No output feature configured
Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
PE2#[/INDENT] [B]Note: [/B]No Outgoing interface is shown because the outgoing tag is Aggregate. This is because the prefix associated with the label is the directly connected route.
Pings from CE1 to a host on CE2 confirm the VPN connectivity over the TE tunnel:
[INDENT] CE1# [B]ping 172.16.13.13[/B]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.13.13, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/13/36 ms
CE1#[/INDENT][B] Case 2: VPN over a TE Tunnel When the TE Tunnel Is from PE1 to P2 [/B]

[B] Topology [/B]

[IMG]http://www.cisco.com/image/gif/paws/29828/mplsvpnte-3.gif[/IMG]
[B] Configuration [/B]

The additional TE configuration over the basic configuration on PE1 is shown here:
PE1
PE1# [B]show run interface tunnel 0[/B]
!
interface Tunnel0
ip unnumbered Loopback0
no ip directed-broadcast
no ip route-cache distributed
tunnel destination 10.5.5.5
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng path-option 10 dynamic
end
!
[B] Verification [/B]

Check the route to prefix 172.16.13.13 on PE1 VRF aqua. It points to the next hop 10.11.11.11/32 (over Tunnel0) using label stack {19 12308}.
[INDENT] PE1# [B]show ip cef vrf aqua 172.16.13.13[/B]
172.16.13.0/24, version 11
0 packets, 0 bytes
tag information set
local tag: VPN route head
fast tag rewrite with Tu0, point2point, tags imposed {19 12308}
via 10.11.11.11, 0 dependencies, recursive
next hop 10.5.5.5, Tunnel0 via 10.11.11.11/32
valid adjacency
tag rewrite with Tu0, point2point, tags imposed {19 12308}
PE1#[/INDENT]Label 19, the outer label, is used to reach next hop 10.11.11.11/32, as shown here:
[INDENT] PE1# [B]show ip cef 10.11.11.11[/B]
10.11.11.11/32, version 37
0 packets, 0 bytes
tag information set
local tag: 21
fast tag rewrite with Tu0, point2point, tags imposed [B]{19}[/B]
via 10.5.5.5, Tunnel0, 1 dependency
next hop 10.5.5.5, Tunnel0
valid adjacency
tag rewrite with Tu0, point2point, tags imposed {19}

PE1# [B]show mpls traffic-eng tunnels tunnel 0[/B]

Name: PE1_t0 (Tunnel0) Destination: 10.5.5.5
Status:
Admin: up Oper: up Path: valid Signalling: connected

path option 10, type dynamic (Basis for Setup, path weight 20)

Config Parameters:
Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: enabled LockDown: disabled Loadshare: 0 bw-based
auto-bw: disabled

InLabel : -
[B]OutLabel : Ethernet2/0/2, 19[/B]
RSVP Signalling Info:
Src 10.2.2.2, Dst 10.5.5.5, Tun_Id 0, Tun_Instance 33
RSVP Path Info:
My Address: 10.7.7.2
Explicit Route: 10.7.7.7 10.8.8.7 10.8.8.5 10.5.5.5
Record Route: NONE
Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=Inf
Shortest Unconstrained Path Info:
Path Weight: 20 (TE)
Explicit Route: 10.7.7.2 10.7.7.7 10.8.8.7 10.8.8.5
10.5.5.5
History:
Tunnel:
Time since created: 17 hours, 31 minutes
Time since path change: 8 minutes, 49 seconds
Current LSP:
Uptime: 8 minutes, 49 seconds
Selection: reoptimation
Prior LSP:
ID: path option 10 [31]
Removal Trigger: path verification failed
PE1#

PE1# [B]show mpls traffic-eng tunnels tunnel 0 | i Label[/B]
InLabel : -
OutLabel : Ethernet2/0/2, 19
PE1#[/INDENT]The packet from PE1 is sent over the TE tunnel with the label stack {19 12308}. Once P1 receives the packet, it pops (PHP) the tag 19 and sends the packet with label stack {12308}. The [B]show[/B] command confirms this:
[INDENT] P1> [B]show tag for tag 19[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
[B]19 Pop tag[/B] 10.2.2.2 0 [33] 2130 Et2/0 10.8.8.5
P1>

P1> [B]show tag for tag 19 detail[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
[B]19 Pop tag[/B] 10.2.2.2 0 [33] 2257 Et2/0 10.8.8.5
MAC/Encaps=14/14, MTU=1504, Tag Stack{}
006009E08B0300603E2B02408847
No output feature configured
P1>[/INDENT]When P2 receives the packet with the label stack {12308}, it checks its LFIB and drops the packet because no match exists. This is the [B]show[/B] command output on P2:
[INDENT] P2# [B]show tag forwarding-table tags 12308 detail[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
P2#

P2#
7w4d: TAG: Et0/3: recvd: CoS=0, TTL=253, Tag(s)=12308
7w4d: TAG: Et0/3: recvd: CoS=0, TTL=253, Tag(s)=12308
7w4d: TAG: Et0/3: recvd: CoS=0, TTL=253, Tag(s)=12308
7w4d: TAG: Et0/3: recvd: CoS=0, TTL=253, Tag(s)=12308
P2#
P2#[/INDENT][B] Explanation [/B]

The solution to this problem is to enable TDP/LDP on the TE tunnel and to make it a tag-switched interface. In the example shown in the [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a0080125b01.shtml#sol1"]Solution[/URL], TDP is enabled on the Tunnel0 of PE1. P2 is configured for accepting directed hellos and forming directed TDP neighbors. So, PE1 receives the label for 10.11.11.11 from P2 via LDP. Now that Tunnel0 has been made a tag-switched interface and TDP has been enabled for the traffic to 10.11.11.11, PE1 uses both the labels; it uses the RSVP label to reach the TE tailend and the TDP label to reach 10.11.11.11.
In this scenario, PE1 uses the label stack {L2 L3 L1} to forward data to CE2 if these items are true:

[LIST][*] L1 is the VPN label.[*] L2 is the RSVP label to reach the TE tailend.[*] L3 is the TDP label to reach 10.11.11.11 (received from P2).[/LIST]
[B] Solution [/B]

The solution is to enable TDP across the TE tunnel.
[B] Configuration [/B]

Shown here is the TE tunnel configuration on PE1 with TDP enabled on it. The additions are in boldface.
PE1
PE1# [B]show run interface tunnel 0[/B]
!
interface Tunnel0
ip unnumbered Loopback0
no ip directed-broadcast
no ip route-cache distributed
[B]tag-switching ip[/B]
[I]
[COLOR=#0000ff]!--- This enables TDP.[/COLOR]
[/I]
tunnel destination 10.5.5.5
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng path-option 10 dynamic
end
!
This is the additional configuration on the tailend of the TE tunnel to accept directed TDP hellos:
[INDENT] P2# [B]show run | i directed-hello[/B]
tag-switching tdp discovery directed-hello accept
[I]
[COLOR=#0000ff]!--- This configures P2 to accept directed TDP hellos.[/COLOR]
[/I]
P2#[/INDENT][B] Verification [/B]

[INDENT] PE1# [B]show tag tdp neighbor | i Peer[/B]
Peer TDP Ident: 10.7.7.7:0; Local TDP Ident 10.2.2.2:0
Peer TDP Ident: 10.5.5.5:0; Local TDP Ident 10.2.2.2:0

PE1#
PE1# [B]show ip cef vrf aqua 172.16.13.13[/B]
172.16.13.0/24, version 11
0 packets, 0 bytes
tag information set
local tag: VPN route head
fast tag rewrite with Tu0, point2point, tags imposed [B]{19 18 12308}[/B]
via 10.11.11.11, 0 dependencies, recursive
next hop 10.5.5.5, Tunnel0 via 10.11.11.11/32
valid adjacency
tag rewrite with Tu0, point2point, tags imposed [B]{19 18 12308}[/B]
PE1#

PE1# [B]show mpls traffic-eng tunnels tunnel 0 | i Label[/B]
InLabel : -
OutLabel : Ethernet2/0/2, [B]19[/B]
[I]
[COLOR=#0000ff]!--- This is the TE label learned via RSVP.[/COLOR]
[/I]
PE1#
PE1# [B]show tag tdp bind 10.11.11.11 32[/B]
tib entry: 10.11.11.11/32, rev 20
local binding: tag: 21
remote binding: tsr: 10.7.7.7:0, tag: 17
remote binding: tsr: 10.5.5.5:0, tag: [B]18[/B]
[I]
[COLOR=#0000ff]!--- This is the TDP label from P2.[/COLOR]
[/I][/INDENT]When P1 receives the packet with the label stack {19 18 12308}, it pops the tag 19 and sends the packet with the label stack {18 12308} to P2. P2 checks its LFIB for label 18, then pops the tag and sends it over the outgoing interface PO2/0/0 toward PE1. PE1 receives the packet with label 12308 and switches it successfully to CE2.
[INDENT] P2# [B]show tag for tag 18[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
[B]18 Pop tag[/B] 10.11.11.11/32 117496 POS2/0/0 point2point

P2# [B]show tag tdp discovery[/B]
Local TDP Identifier:
10.5.5.5:0
Discovery Sources:
Interfaces:
Ethernet0/3 (tdp): xmit/recv
TDP Id: 10.7.7.7:0
POS2/0/0 (tdp): xmit/recv
TDP Id: 10.11.11.11:0
Directed Hellos:
10.5.5.5 -> 10.2.2.2 (tdp): passive, xmit/recv
TDP Id: 10.2.2.2:0

P2# [B]show tag tdp neighbor 10.2.2.2[/B]
Peer TDP Ident: 10.2.2.2:0; Local TDP Ident 10.5.5.5:0
TCP connection: 10.2.2.2.711 - 10.5.5.5.11690
State: Oper; PIEs sent/rcvd: 469/465; Downstream
Up time: 01:41:08
TDP discovery sources:
[B]Directed Hello 10.5.5.5 -> 10.2.2.2, passive[/B]
Addresses bound to peer TDP Ident:
10.7.7.2 172.16.47.166 10.2.2.2

PE1# [B]show tag tdp neighbor 10.5.5.5[/B]
Peer TDP Ident: 10.5.5.5:0; Local TDP Ident 10.2.2.2:0
TCP connection: 10.5.5.5.11690 - 10.2.2.2.711
State: Oper; PIEs sent/rcvd: 438/441; Downstream
Up time: 01:35:08
TDP discovery sources:
[B]Directed Hello 10.2.2.2 -> 10.5.5.5, active[/B]
[I]
[COLOR=#0000ff]!--- This indicates the directed neighbor.[/COLOR]
[/I]
Addresses bound to peer TDP Ident:
10.5.5.5 10.12.12.5 10.8.8.5

PE1# [B]show ip route 10.11.11.11[/B]
Routing entry for 10.11.11.11/32
Known via "isis", distance 115, metric 40, type level-1
Redistributing via isis
B Last update from 10.5.5.5 on Tunnel0, 01:52:21 ago
Routing Descriptor Blocks:
* 10.5.5.5, from 10.11.11.11, via Tunnel0
Route metric is 40, traffic share count is 1[/INDENT]A [B]ping[/B] command from CE1 to a host on CE2 confirms the solution.
[INDENT] CE1# [B]ping 172.16.13.13[/B]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.13.13, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
CE1#[/INDENT][B] Case 3: VPN Between CE1 and CE2 over a TE Tunnel from P1 to P2 When TDP/LDP Is Not Enabled [/B]

[B] Topology [/B]

[IMG]http://www.cisco.com/image/gif/paws/29828/mplsvpnte-4.gif[/IMG]
[B] Configuration [/B]

The tunnel configuration on PE1 is shown here:
PE1
P1# [B]show run interface tunnel 0[/B]
Building configuration...

Current configuration : 255 bytes
!
interface Tunnel0
ip unnumbered Loopback0
no ip directed-broadcast
ip route-cache distributed
tunnel destination 10.5.5.5
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng path-option 10 dynamic
end
[B] Verification [/B]

Verify how packets destined to CE2 172.16.13.13 get switched here. The [B]show ip cef[/B] command output shows that packets to destination 172.16.13.13 are switched with the label stack {17 12308}:
[INDENT] PE1# [B]show ip cef vrf aqua 172.16.13.13[/B]
172.16.13.0/24, version 18, cached adjacency 10.7.7.7
0 packets, 0 bytes
tag information set
local tag: VPN route head
fast tag rewrite with Et2/0/2, 10.7.7.7, tags imposed {17 12308}
via [B]10.11.11.11[/B], 0 dependencies, recursive
next hop 10.7.7.7, Ethernet2/0/2 via 10.11.11.11/32
valid cached adjacency
tag rewrite with Et2/0/2, 10.7.7.7, tags imposed [B]{17 12308}[/B][/INDENT]When P1 receives this packet, it removes the outer label 17 and switches the packet after looking in the IP routing table to Tunnel0. Notice the implicit-null OutLabel in this output; it means that the outgoing interface is not label switched.
[INDENT] P1# [B]show ip cef 10.11.11.11 detail[/B]
10.11.11.11/32, version 52
0 packets, 0 bytes
tag information set
local tag: 17
fast tag rewrite with Tu0, point2point, tags imposed {}
via 10.5.5.5, Tunnel0, 0 dependencies
next hop 10.5.5.5, Tunnel0
valid adjacency
tag rewrite with Tu0, point2point, tags imposed {}

P1# [B]show mpls traffic-eng tunnel tunnel 0 | i Label[/B]
InLabel : -
OutLabel : Ethernet2/0, implicit-null
P1# [B]show tag for 10.11.11.11 detail[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
17 Untagged 10.11.11.11/32 882 Tu0 point2point
MAC/Encaps=14/14, MTU=1500, Tag Stack{}, via Et2/0
006009E08B0300603E2B02408847
No output feature configured
Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
P1# [B]show ip route 10.11.11.11[/B]
Routing entry for 10.11.11.11/32
Known via "isis", distance 115, metric 30, type level-1
Redistributing via isis
Last update from 10.5.5.5 on Tunnel0, 00:03:20 ago
Routing Descriptor Blocks:
* 10.5.5.5, from 10.11.11.11, via Tunnel0
Route metric is 30, traffic share count is 1[/INDENT]Once P2 receives the packet with label 12308, it looks at its forwarding table. Because there is no way P2 can be aware of the VPN tag 12308 from CE2, it drops the packet.
[INDENT] P2# [B]show tag for tag 12308 detail[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface[/INDENT]This breaks the path of VPN packets destined to CE2. It is confirmed by the [B]ping[/B] to CE2 172.16.13.13/32.
[INDENT] PE1#
CE1# [B]ping 172.16.13.13[/B]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.13.13, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
CE1#[/INDENT][B] Solution [/B]

The solution is to enable LDP/TDP over the tunnel. The next section discusses this solution.
[B] Case 4: VPN over a TE Tunnel Between P1 and P2 with LDP Enabled [/B]

[B] Topology [/B]

[IMG]http://www.cisco.com/image/gif/paws/29828/mplsvpnte-4.gif[/IMG]
[B] Configuration [/B]

With LDP enabled on the tunnel, the configurations on P1 appear as shown here. Additions are in boldface.
PE1
P1# [B]show run interface tunnel 0[/B]
Building configuration...

Current configuration : 273 bytes
!
interface Tunnel0
ip unnumbered Loopback0
no ip directed-broadcast
ip route-cache distributed
mpls label protocol ldp
tunnel destination 10.5.5.5
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng path-option 10 dynamic
end
!
[B] Verification [/B]

PE1 sends packets to prefix 172.16.13.13/32 with the label stack {17 12308}.
[INDENT] PE1#
PE1# [B]show tag for 10.11.11.11 detail[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
[B]21 17[/B] 10.11.11.11/32 0 Et2/0/2 10.7.7.7
MAC/Encaps=14/18, MTU=1500, Tag Stack{17}
00603E2B02410060835887428847 00011000
No output feature configured
Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

PE1#
PE1# [B]show ip cef 10.11.11.11 detail[/B]
10.11.11.11/32, version 60, cached adjacency 10.7.7.7
0 packets, 0 bytes
tag information set
[B]local tag: 21[/B]
fast tag rewrite with Et2/0/2, 10.7.7.7, tags imposed {17}
via 10.7.7.7, Ethernet2/0/2, 1 dependency
next hop 10.7.7.7, Ethernet2/0/2
valid cached adjacency
tag rewrite with Et2/0/2, 10.7.7.7, tags imposed [B]{17}[/B]

PE1# [B]show ip cef vrf aqua 172.16.13.13[/B]
172.16.13.0/24, version 18, cached adjacency 10.7.7.7
0 packets, 0 bytes
tag information set
local tag: VPN route head
fast tag rewrite with Et2/0/2, 10.7.7.7, tags imposed {17 12308}
via 10.11.11.11, 0 dependencies, recursive
next hop 10.7.7.7, Ethernet2/0/2 via 10.11.11.11/32
valid cached adjacency
tag rewrite with Et2/0/2, 10.7.7.7, tags imposed [B]{17 12308}[/B][/INDENT]P1 receives the packet with label stack {17 12308} and looks at its LFIB for label 17.
[INDENT] P1# [B]show tag for tag 17 detail[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
17 18 10.11.11.11/32 1158 Tu0 point2point
MAC/Encaps=14/18, MTU=1496, Tag Stack{18}, via Et2/0
006009E08B0300603E2B02408847 00012000
No output feature configured
Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
P1#

P1# [B]show ip cef 10.11.11.11 detail[/B]
10.11.11.11/32, version 52
0 packets, 0 bytes
tag information set
local tag: 17
fast tag rewrite with Tu0, point2point, tags imposed {18}
via 10.5.5.5, Tunnel0, 0 dependencies
next hop 10.5.5.5, Tunnel0
valid adjacency
tag rewrite with Tu0, point2point, tags imposed {18}[/INDENT]It shows that label 17 should be swapped to label 18. Therefore, that packet is switched over the tunnel interface with the label stack {18 12308}.
P2 receives the packet over its tunnel interface with label stack {18 12308}. It pops the tag 18 (because it is the penultimate hop router) and switches the packet to PE2 with the label 12308.
[INDENT] P2# [B]show tag for tag 18 detail[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
[B]18 Pop tag[/B] 10.11.11.11/32 127645 PO2/0/0 point2point
MAC/Encaps=4/4, MTU=4474, Tag Stack{}
0F008847
No output feature configured
Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
P2#[/INDENT]PE2 receives the packet with label 12308, which switches the packet to CE2 successfully.
[INDENT] PE2# [B]show tag forwarding tags 12308 detail[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
[B]12308 Aggregate[/B] 172.16.13.0/24[V] 12256
MAC/Encaps=0/0, MTU=0, Tag Stack{}
VPN route: aqua
No output feature configured
Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
PE2#

CE1# [B]ping 172.16.13.13[/B]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.13.13, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
CE1#[/INDENT][B] Case 5: MPLS VPN over a Tunnel Between P1 and PE2 [/B]

[B] Topology [/B]

[IMG]http://www.cisco.com/image/gif/paws/29828/mplsvpnte-5.gif[/IMG]
[B] Configuration [/B]

PE1
P1# [B]show run interface tunnel 0[/B]
Building configuration...

Current configuration : 258 bytes
!
interface Tunnel0
ip unnumbered Loopback0
no ip directed-broadcast
ip route-cache distributed
tunnel destination 10.11.11.11
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng path-option 10 dynamic
end
[B] Verification [/B]

PE1 sends a packet destined to 172.16.13.13 to its next hop 10.11.11.11 with the label stack {17 12308}.
[INDENT] PE1# [B]show ip cef vrf aqua 172.16.13.13[/B]
172.16.13.0/24, version 18, cached adjacency 10.7.7.7
0 packets, 0 bytes
tag information set
local tag: VPN route head
fast tag rewrite with Et2/0/2, 10.7.7.7, tags imposed {17 12308}
via [B]10.11.11.11[/B], 0 dependencies, recursive
next hop 10.7.7.7, Ethernet2/0/2 via 10.11.11.11/32
valid cached adjacency
tag rewrite with Et2/0/2, 10.7.7.7, tags imposed [B]{17 12308}[/B][/INDENT]P1 receives the packet with label stack {17 12308}. P1 looks at its LFIB table and checks the tag stack {17} and switches the packet with label {17} toward P2.
[INDENT] P1# [B]show tag for 10.11.11.11 detail[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
[B]17[/B] Untagged 10.11.11.11/32 411 Tu0 point2point
MAC/Encaps=14/18, MTU=1500, [B]Tag Stack{17}[/B], via Et2/0
006009E08B0300603E2B02408847 00011000
No output feature configured
Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

P1# [B]show tag for tag 17 detail[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
[B]17[/B] Untagged 10.11.11.11/32 685 Tu0 point2point
MAC/Encaps=14/18, MTU=1500, [B]Tag Stack{17}[/B], via Et2/0
006009E08B0300603E2B02408847 00011000
No output feature configured
Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
P1#

P1# [B]show ip cef 10.11.11.11[/B]
10.11.11.11/32, version 67
0 packets, 0 bytes
tag information set
[B]local tag: 17[/B]
fast tag rewrite with Tu0, point2point, tags imposed {17}
via 10.11.11.11, Tunnel0, 0 dependencies
next hop 10.11.11.11, Tunnel0
valid adjacency
tag rewrite with Tu0, point2point, [B]tags imposed {17}[/B][/INDENT]P2 receives the packet with label stack {17 12308}. P2, being the penultimate hop router, pops label 17.
[INDENT] P2# [B]show tag for tag 17 detail[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
[B]17 Pop tag[/B] 10.7.7.7 0 [5] 535 PO2/0/0 point2point
MAC/Encaps=4/4, MTU=4474, Tag Stack{}
0F008847
No output feature configured
P2#[/INDENT]PE2 then receives the packet with the label 12308. P2 is aware that the destination for label 12308 is directly connected. Therefore, the [B]ping[/B] from CE1 to CE2 is 10.
[INDENT] PE2# [B]show tag for tag 12308 detail[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
[B]12308 Aggregate[/B] 172.16.13.0/24[V] 12776
MAC/Encaps=0/0, MTU=0, Tag Stack{}
VPN route: aqua
No output feature configured
Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
PE2#[/INDENT] [B]Note: [/B]No Outgoing interface is shown because the outgoing tag is Aggregate. This is because the prefix associated with the label is the directly connected route.
[INDENT] CE1# [B]ping 172.16.13.13[/B]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.13.13, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
CE1#[/INDENT][B] Known Issues [/B]

Refer to [URL="http://www.cisco.com/en/US/ts/fn/100/fn15911.html"]Field Notice: MPLS VPN with TE and MPLS InterAS Advisory on Cisco IOS® Software[/URL] for more details.
[B] Conclusion [/B]

When the TE tunnel is terminated on the egress PE, the MPLS VPN and the TE work together without any additional configuration. When the TE tunnel is terminated on any P routers (before the PE in the core), the MPLS VPN traffic forwarding fails because packets arrive with VPN labels as the outer labels, which are not in the LFIBs of these devices. Therefore, these intermediate routers are not able to forward packets to the final destination, the VPN customer network. In such a case, LDP/TDP should be enabled on the TE tunnel to solve the problem.
[B] Cisco Support Community - Featured Conversations [/B]

[URL="https://supportforums.cisco.com/index.jspa"]Cisco Support Community[/URL] is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers. Below are just some of the most recent and relevant conversations happening right now.
Want to see more? Join us by clicking [URL="https://supportforums.cisco.com/login.jspa"]here[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/thread/248344"]Pseudowire over MPLS-TE Tunnels[/URL][URL="https://supportforums.cisco.com/people/g.rodegari%40lutech.it"]g.rodegari@lutech.it[/URL]21 Replies03.07.2007 05:05 Hi guys, I'm tring to test interoperability between Cisco an Juniper Boxes about pseudowire services. Let assume that I've an MPLS backbone, where the label distribution protocol used is RSVP, then MPLS-TE tunnels, I do not want to enable LDP on my backbone. Well, as far as I know, pseudowires requires LDP as control protocol... then: from Juniper side I've enable a feature that they calling "LDP-Tunneling" in order to connect different LDP "islands" through my RSVP Backbone. Is there a similar feature into IOS? what I've tested is to configure targeted LDP and MPLS-TE tunnels, but seems to do not work fine. What is happening is that Juniper and Cisco established correctly the LDP targeted session, but discarding the FEC into the advertisement... Any ideas? Have anyone already tested it before??? Any suggestions is more than appreciated, Best Regards, G. [URL="https://supportforums.cisco.com/community/feeds/messages?thread=248344"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/248344"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/966952#966952"]Re: Pseudowire over MPLS-TE Tunnels[/URL][URL="https://supportforums.cisco.com/people/hritter"]hritter[/URL]28.06.2007 10:44Graziano, All you need on either side is the targeted LDP session. The JunOS LDP tunneling feature is not needed in this scenario. It is equivalent to enabling LDP on a TE tunnel interface on the IOS side. On the JunOS side, the targeted LDP session is enabled by the following set of commands: protocols { l2circuit { neighbor x.x.x.x {...[URL="https://supportforums.cisco.com/message/966952#966952"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/966953#966953"]Re: Pseudowire over MPLS-TE Tunnels[/URL][URL="https://supportforums.cisco.com/people/g.rodegari%40lutech.it"]g.rodegari@lutech.it[/URL]29.06.2007 00:25Hello, thank you for your suggestion but actually I do not have LDP on my backbone and on the JunOS side I've to enable LDP tunneling, just to transport LDP into the RSVP backbone. Forget for a second the pseudowire stuff... we have just to connect two LDP network through and RSVP backbone The LDP tunneling features allow JunOS box to start targeted LDP session toward other boxes with, as source and transport address of...[URL="https://supportforums.cisco.com/message/966953#966953"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/966954#966954"]Re: Pseudowire over MPLS-TE Tunnels[/URL][URL="https://supportforums.cisco.com/people/hritter"]hritter[/URL]29.06.2007 04:19Graziano, I completely understand the fact that you do not need LDP in the network. LDP is just required between the two PEs in order to succesfully run l2vpn. You absolutely do not need ldp-tunneling for that purpose. The targeted LDP session started by ldp-tunneling on one side and running ldp on the tunnel interface on the other side will not help as l2vpn starts its own targeted LDP session. For the FEC to be...[URL="https://supportforums.cisco.com/message/966954#966954"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/966955#966955"]Re: Pseudowire over MPLS-TE Tunnels[/URL][URL="https://supportforums.cisco.com/people/g.rodegari%40lutech.it"]g.rodegari@lutech.it[/URL]29.06.2007 05:59 Hello Harold, thank you for your suggestions.Sorry, but, probably I didn't explane well myself. Actually L2vpn is just one application, we should have also L3VPN... The more general stuff is that I need to transport LDP information from one island to an other island through RSVP backbone. Thanks G. [URL="https://supportforums.cisco.com/message/966955#966955"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/966956#966956"]Re: Pseudowire over MPLS-TE Tunnels[/URL][URL="https://supportforums.cisco.com/people/hritter"]hritter[/URL]29.06.2007 06:34Graziano, Thanks for the additional info. It shouldn't be a problem to get the JunOS ldp-tunneling to work with the IOS ldp over the TE tunnel interface. As I said, for the FEC received from the targeted LDP session to be used, you need routes to be installed in the FIB with a next hop via the tunnel interface (or the LSP on the JunOS side). Then in your case, you need to make sure the LDP peer id (targeted LDP peer...[URL="https://supportforums.cisco.com/message/966956#966956"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/966957#966957"]Re: Pseudowire over MPLS-TE Tunnels[/URL][URL="https://supportforums.cisco.com/people/g.rodegari%40lutech.it"]g.rodegari@lutech.it[/URL]29.06.2007 07:37 Thank you Harold, I'll verify that. Best Regards, G. [URL="https://supportforums.cisco.com/message/966957#966957"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/966958#966958"]Re: Pseudowire over MPLS-TE Tunnels[/URL][URL="https://supportforums.cisco.com/people/hritter"]hritter[/URL]29.06.2007 21:50 Graziano, By the way, you do not need to configure LDP over the TE tunnel interface in the case of l3vpn either if the LSP goes all the way from the ingress to the egress PE. Just wanted to make sure that I didn't leave you with the wrong impression. Regards,[URL="https://supportforums.cisco.com/message/966958#966958"]Reply[/URL]

[/LIST][/LIST][*] [URL="https://supportforums.cisco.com/message/966959#966959"]Re: Pseudowire over MPLS-TE Tunnels[/URL][URL="https://supportforums.cisco.com/people/jiangu"]jiangu[/URL]30.06.2007 00:54So the question drills down to the following scenario: two routers, Cisco and Juniper, they are on two ends of a RSVP domain, you want to tunnel LDP over this RSVP domain, you have configured "tag switching ip" on Cisco's TE interface and "ldp-tunneling" on Juniper's RSVP-LSP, and targeted LDP session is established between Cisco and Juniper, but LDP is not using prefix-FECs advertised from either side. At this stage, the only reason a...[URL="https://supportforums.cisco.com/message/966959#966959"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/966960#966960"]Re: Pseudowire over MPLS-TE Tunnels[/URL][URL="https://supportforums.cisco.com/people/hritter"]hritter[/URL]30.06.2007 05:07Jian, Depending on the topology, enabling ospf shortcuts might not be sufficient as this will only impact the BGP learnt routes. If IGP routes need to be resolved via the LSP, the mpls traffic-engineering bgp-igp needs to be configured on the JunOS side. At the end of the day, it largely depends on the topology and whether the TE LSPs are end to end between the PEs. If they are then there is no need to use LDP at all (except for...[URL="https://supportforums.cisco.com/message/966960#966960"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/966961#966961"]Re: Pseudowire over MPLS-TE Tunnels[/URL][URL="https://supportforums.cisco.com/people/hritter"]hritter[/URL]30.06.2007 05:26 Forget my comment about the bgp-igp since if the tunnel was between the core routers you wouldn't need to install the route in inet.0 anyway. The only route that would matter in the core would be the one in mpls.0. Regards,[URL="https://supportforums.cisco.com/message/966961#966961"]Reply[/URL]

[/LIST][/LIST][/LIST][/LIST][/LIST][/LIST][*][URL="https://supportforums.cisco.com/message/248344#248344"]More Replies[/URL][/LIST][*] [URL="https://supportforums.cisco.com/thread/1001584"]RSVP TE FRR[/URL][URL="https://supportforums.cisco.com/people/gauravprakash"]gauravprakash[/URL]2 Replies18.12.2009 01:41 Hi, I have a ring of 8 routers in a ring runing OSPF , can detect LOS ,so I want to implement RSVP TE with FRR. For Traffic going from R1 to R4, it will use the Primary Tunnel R1--R2 and then r3, and finally arrive r4. If link between R1--R2 fails, will the traffic quickly move to Backup NNhop tunnel ( as shown in diagram) and hence the user traffic which was sourced behind R1 and wanted to reach destination behind r4 will follow this path r1--r8---r7---r6---r5---r4---r3-----r2-----r3---r4 . As I understand that the Primary FRR & Backup TE Tunnel will have same destination ( its mandatory.. right ?). This creates unwanted traffic on R4--R3--R2 segment...as long as the R1--R2 link is down. Is this the design problem with One hop tunnel.. ? My friend say after link failure on R1--R2, IGP convergence will take place and this unwanted upstream movement of user traffic will stop. He couldn't explain why ? Can somebody explain ... Thx, Gaurav[URL="https://supportforums.cisco.com/community/feeds/messages?thread=1001584"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/1001584"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/2006797#2006797"]Re: RSVP TE FRR[/URL][URL="https://supportforums.cisco.com/people/shivlu"]shivlu[/URL]17.12.2009 23:56 On failure of R1-R2 link, traffic will follow the backup tunnel. There will not be unwanted traffic on R3-R2 because the backup tunnel is from R4 to R1 via R8. So don't worry about that designers have already taken care about that. regards shivlu jain [url=http://shivlu.blogspot.com]MPLSVPN[/url][URL="https://supportforums.cisco.com/message/2006797#2006797"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/2006828#2006828"]Re: RSVP TE FRR[/URL][URL="https://supportforums.cisco.com/people/gauravprakash"]gauravprakash[/URL]18.12.2009 01:41Hi Shivlu, Thx , perhaps I did not get that ....The primary tunnel is one hop tunnel and my backup tunnel is multi hop away ( may be I shud not use NNHOP earlier )..I guess the backup Tunnel shud have the same destination as Primary , so it will traverse all the ring ( other way) and then reach R2 , then move towards R4. So there is extra traffic from R4----R3---R2 while the traffic ( source behind R1 & destination behind R4 )...[URL="https://supportforums.cisco.com/message/2006828#2006828"]Reply[/URL]

[/LIST][/LIST][*] [URL="https://supportforums.cisco.com/thread/250077"]MPLS TE Tunnels[/URL][URL="https://supportforums.cisco.com/people/galo"]galo[/URL]6 Replies26.02.2005 09:04 If I configure a single tunnel from PE-PE with 1500K specified as the bandwidth and I have multiple simple VPNs configured on both ends am I correct in assuming the bandwidth specified on the headend tunnel would dedicate 1500k to each VPN or is the 1500k shared by all the VPNs? I did try assigning a vrf per tunnel interface but failed to pass any VPN traffic from PE to PE. If anyone can point out a link covering all details surrounding MPLS TE that would be great! Thanks in advance![URL="https://supportforums.cisco.com/community/feeds/messages?thread=250077"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/250077"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/975019#975019"]Re: MPLS TE Tunnels[/URL][URL="https://supportforums.cisco.com/people/hritter"]hritter[/URL]22.02.2005 20:58 The bandwidth is actually shared by all traffic traversing. You wouldn't get 1500K per VRF but rather 1500K for all. You could try allocating 1 tunnel per VRF but that could easily become a management nightmare. Hope this helps,[URL="https://supportforums.cisco.com/message/975019#975019"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/975020#975020"]Re: MPLS TE Tunnels[/URL][URL="https://supportforums.cisco.com/people/galo"]galo[/URL]22.02.2005 21:16 Funny I did try assigning vrf forwarding instances to the tunnel interface but failed to pass any traffic. Is there a link? I probably missed a step. Thanks In Advance![URL="https://supportforums.cisco.com/message/975020#975020"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/975021#975021"]Re: MPLS TE Tunnels[/URL][URL="https://supportforums.cisco.com/people/hritter"]hritter[/URL]22.02.2005 21:35 You can't assign a VRF to the tunnel interface. You would need to the following: Advertise BGP updates for each VRF with a different BGP next-hop using the following command: ip vrf xxx bgp next-hop looopback (x) On the other PE, point a static route for each BGP nexthop via a different tunnel. Hope this helps,[URL="https://supportforums.cisco.com/message/975021#975021"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/975022#975022"]Re: MPLS TE Tunnels[/URL][URL="https://supportforums.cisco.com/people/galo"]galo[/URL]24.02.2005 11:22 I tried the above command in my lab. Unfortunately that feature is not available to me. I'm on mainline 12.2.24a. What version have you successfully executed that command with?[URL="https://supportforums.cisco.com/message/975022#975022"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/975023#975023"]Re: MPLS TE Tunnels[/URL][URL="https://supportforums.cisco.com/people/hritter"]hritter[/URL]24.02.2005 18:57 This command is only available in 12.0S. Alternately, you could configure a route-map that matches on the different route targets and set the next-hop accordingly and apply this route-map to the VPNv4 neighbor(s). Hope this helps,[URL="https://supportforums.cisco.com/message/975023#975023"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/975024#975024"]Re: MPLS TE Tunnels[/URL][URL="https://supportforums.cisco.com/people/galo"]galo[/URL]26.02.2005 09:04I finally decided on using the MPLS TE tunnels to guarantee the bandwidth and to rate limit each VRF @ the ingress. This way I keep all clients to a 1.5mb pipe per VPN, allow MPLS to maintain the integrity/security between VPNs, and RSVP the bandwidth across the backbone. As for my original idea: “You could try allocating 1 tunnel per VRF but that could easily become a management nightmare.” You were...[URL="https://supportforums.cisco.com/message/975024#975024"]Reply[/URL]

[/LIST][/LIST][/LIST][/LIST][/LIST][/LIST][*] [URL="https://supportforums.cisco.com/thread/249286"]MPLS TE Tunnels configuration[/URL][URL="https://supportforums.cisco.com/people/p.diaz"]p.diaz[/URL]2 Replies15.01.2009 08:04 Hello. I have the following doubt. What happens if I configure one TE tunnel in both ends. I have read that is enough configure only one side. Thanks[URL="https://supportforums.cisco.com/community/feeds/messages?thread=249286"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/249286"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/971419#971419"]Re: MPLS TE Tunnels configuration[/URL][URL="https://supportforums.cisco.com/people/gauravprakash"]gauravprakash[/URL]15.01.2009 07:40 The LSP starts on PE on which Tunnel was built and ends on some ther PE, and its unidirectional. To have bidirectional you need to make two Tunnels on each end. HTH, Gaurav Prakash[URL="https://supportforums.cisco.com/message/971419#971419"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/971420#971420"]Re: MPLS TE Tunnels configuration[/URL][URL="https://supportforums.cisco.com/people/p.diaz"]p.diaz[/URL]15.01.2009 08:04 Thank you Gaurav.[URL="https://supportforums.cisco.com/message/971420#971420"]Reply[/URL]

[/LIST][/LIST][*] [URL="https://supportforums.cisco.com/thread/249453"]Pseudowire over TE MPLS[/URL][URL="https://supportforums.cisco.com/people/francisco_1"]francisco_1[/URL]2 Replies13.05.2009 01:14 Has anyone used Pseudowire over Traffic Enginnering MPLS? What i would like to do is setup the MPLS TE using OSPF, built layer 3 tunnels between sites and then use Pseudowire to extend vlans over the TE MPLS tunnels and isolate the vlans using VRF-Lite. Advice pls.. Francisco[URL="https://supportforums.cisco.com/community/feeds/messages?thread=249453"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/249453"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/972273#972273"]Re: Pseudowire over TE MPLS[/URL][URL="https://supportforums.cisco.com/people/laaubert"]laaubert[/URL]23.04.2009 10:53 Hi Francisco, You can map a PW to a MPLS-TE tunnel via the PW-class: pseudowire-class TE encapsulation mpls preferred-path interface Tunnel0 ! interface Ethernet0/0 xconnect 1.1.1.1 10 pw-class TE ! HTH Laurent. [URL="https://supportforums.cisco.com/message/972273#972273"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/972274#972274"]Re: Pseudowire over TE MPLS[/URL][URL="https://supportforums.cisco.com/people/francisco_1"]francisco_1[/URL]13.05.2009 01:14 thanks Laurent. I will give it a go... Francisco[URL="https://supportforums.cisco.com/message/972274#972274"]Reply[/URL]

[/LIST][/LIST][*] [URL="https://supportforums.cisco.com/thread/249901"]MPLS TE with MPLS VPN[/URL][URL="https://supportforums.cisco.com/people/maher%40pd.jaring.my"]maher@pd.jaring.my[/URL]4 Replies14.10.2004 18:33 Hi there, I'm looking for some basic configuration to turn on mpls te over existing mpls vpn. Worried to effect mpls vpn customers. Perhaps a link would be great! thanks in advance. maher[URL="https://supportforums.cisco.com/community/feeds/messages?thread=249901"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/249901"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974302#974302"]Re: MPLS TE with MPLS VPN[/URL][URL="https://supportforums.cisco.com/people/hritter"]hritter[/URL]14.10.2004 13:24There is many scenarios involving TE and MPLS VPN. If you have MPLS TE from ingress to egress PE, the lsp used to go from one PE to the other is signalled using RSVP instead of LDP/TDP. If you configure TE between the core routers then you need to runn LDP/TDP on the tunnel interface for LDP to learn labels via that pseudo interface. This second scenario involves that at some point up to 3 labels (TE lsp label, IGP label, service...[URL="https://supportforums.cisco.com/message/974302#974302"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974303#974303"]Re: MPLS TE with MPLS VPN[/URL][URL="https://supportforums.cisco.com/people/maher%40pd.jaring.my"]maher@pd.jaring.my[/URL]14.10.2004 17:11 Hi Hritter, Thanks for the explaination.Would be grateful to find some of the scenarios in the sample config. Which want would be better to go into MPLS TE with MPLS/VPN. Need to understand some of the basic of MPLS TE. thanks. maher[URL="https://supportforums.cisco.com/message/974303#974303"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974304#974304"]Re: MPLS TE with MPLS VPN[/URL][URL="https://supportforums.cisco.com/people/hritter"]hritter[/URL]14.10.2004 17:21 Here's a link to a document that discusses several scenarios: [url]http://www.cisco.com/en/US/partner/tech/tk436/tk428/technologies_tech_note09186a0080125b01.shtml[/url] Hope this helps, [URL="https://supportforums.cisco.com/message/974304#974304"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974305#974305"]Re: MPLS TE with MPLS VPN[/URL][URL="https://supportforums.cisco.com/people/maher%40pd.jaring.my"]maher@pd.jaring.my[/URL]14.10.2004 18:33 hi hritter, thanks for the link. maher[URL="https://supportforums.cisco.com/message/974305#974305"]Reply[/URL]

[/LIST][/LIST][/LIST][/LIST][*] [URL="https://supportforums.cisco.com/thread/250084"]MPLS over GRE Tunnels[/URL][URL="https://supportforums.cisco.com/people/efairbanks"]efairbanks[/URL]4 Replies30.03.2005 23:17 Is there an article anywhere showing a config for MPLS over GRE tunnels? I need to do this with 3725s... Thank you.[URL="https://supportforums.cisco.com/community/feeds/messages?thread=250084"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/250084"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/975053#975053"]Re: MPLS over GRE Tunnels[/URL][URL="https://supportforums.cisco.com/people/hritter"]hritter[/URL]24.02.2005 20:40 You simply need to configure a GRE tunnel and add "mpls ip" on the tunnel. int tunnel 0 ip address 192.168.1.1 tunnel destination 2.2.2.2 tunnel source 1.1.1.1 mpls ip Hope this helps,[URL="https://supportforums.cisco.com/message/975053#975053"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/975054#975054"]Re: MPLS over GRE Tunnels[/URL][URL="https://supportforums.cisco.com/people/efairbanks"]efairbanks[/URL]25.02.2005 07:10 Hritter, Do all routers in the path need to run some kind of IGP to pass label information? I am still having problems with nonadjacent BGP peers not sending MPLS tags. Also, when I type "sho ip bgp label" nothing is returned.[URL="https://supportforums.cisco.com/message/975054#975054"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/975055#975055"]Re: MPLS over GRE Tunnels[/URL][URL="https://supportforums.cisco.com/people/hritter"]hritter[/URL]25.02.2005 07:35 The routers between the tunnel endpoints need to be able to resolv tunnel endpoints only (no ldp required). Try "show ip bgp v a labels" to see the labels for VRF prefixes. Hope this helps, [URL="https://supportforums.cisco.com/message/975055#975055"]Reply[/URL]

[/LIST][/LIST][*] [URL="https://supportforums.cisco.com/message/975056#975056"]Re: MPLS over GRE Tunnels[/URL][URL="https://supportforums.cisco.com/people/q-coelho"]q-coelho[/URL]30.03.2005 23:17 hi, You will need an IGP that knows how to find the remote tunnel end points as well as IGP running over the tunnels to find the BGP neighbours. [URL="https://supportforums.cisco.com/message/975056#975056"]Reply[/URL]

[/LIST][*] [URL="https://supportforums.cisco.com/thread/249821"]MPLS TE tunnels with DS-TE[/URL][URL="https://supportforums.cisco.com/people/scytmax"]scytmax[/URL]1 Reply15.08.2004 21:57 Dear Sir! I'll want to implement such task: I have a few MPLS VPN offices (for example VPN = C1), and I want to make 2 tunnels between any two of this PEs. First of this tunnel Tu10 is for LLQ-traffic (marked for example with ip prec = 5), and second tunnel Tu20 is for all other from this VPN = C1 traffic. I'm imlemented MPLS DS-TE in my core (between P and PE devices) with appropriate CBWFQ on physical ports between P and PE devices. And example of tunnel configuration: interface Tunnel10 description Use it only for LLQ traffic ip unnumbered Loopback0 tunnel destination 3.3.3.3 tunnel mode mpls traffic-eng no tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 0 0 tunnel mpls traffic-eng bandwidth sub-pool 4096 tunnel mpls traffic-eng path-option 10 explicit name <name1> tunnel mpls traffic-eng path-option 20 explicit name <name2> tunnel mpls traffic-eng path-option 30 dynamic ! ! interface Tunnel20 description Use it for all other traffic -except LLQ ip unnumbered Loopback0 load-interval 30 tunnel destination 3.3.3.3 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng path-option 10 explicit name <name3> tunnel mpls traffic-eng path-option 20 explicit name <name4> tunnel mpls traffic-eng path-option 30 dynamic tunnel mpls traffic-eng auto-bw frequency 300 Then, because I'm announce Tu20 in IGP, all traffic use this tunnel. But how can I forward all LLQ traffic down Tu10? 1) I cannot use static routing for it, because it cannot to see packet parameters (ip prec 5)? 2) I cannot use PBR, because it not supported on VRF interfaces (only for classification/marking, but it is not my task case)? 3) I cannot to announce Tu10 to IGP, because some other non-LLQ traffic can use it? How can I to solve the above task? Best regards, Maxim Denisov[URL="https://supportforums.cisco.com/community/feeds/messages?thread=249821"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/249821"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/973957#973957"]Re: MPLS TE tunnels with DS-TE[/URL][URL="https://supportforums.cisco.com/people/rajiva"]rajiva[/URL]15.08.2004 21:57Maxim, One of the ways to solve this problem is to use different BGP next-hops for the prefixes (probably VoIP prefixes) that attract the LLQ-bound traffic . PE1----PE2 Either PE2 would need to change the next-hop from Loo0 to Loo10 (say) and advertise those (VoIP) VPN prefixes (for this VPN) to PE1, or let PE1 change the next-hop for the relevant prefixes via an import-map within that VRF. And then you could use the...[URL="https://supportforums.cisco.com/message/973957#973957"]Reply[/URL]

[/LIST][*] [URL="https://supportforums.cisco.com/thread/247908"]MPLS over a TE tunnel[/URL][URL="https://supportforums.cisco.com/people/thedquoc"]thedquoc[/URL]2 Replies24.08.2006 12:45 Hi , I tried to configure MPLS over a TE tunnel by following this link : [url=http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a0080125b01.shtml#case1]Implementing an MPLS VPN over TE Tunnels [MPLS] - Cisco Systems[/url] . The problem happened in this tunnel interface config : ---- ! interface Tunnel0 ip unnumbered Loopback0 no ip directed−broadcast no ip route−cache distributed tunnel destination 10.5.5.5 tunnel mode mpls traffic−eng tunnel mpls traffic−eng autoroute announce tunnel mpls traffic−eng path−option 10 dynamic end ! ---- The int tunnel 0 is always in "Tunnel0 is up, line protocol is down" state . My PE routers are 7304s(p-mz.122-27.SBC5) Please advice ! Thanks & Regards[URL="https://supportforums.cisco.com/community/feeds/messages?thread=247908"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/247908"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/964743#964743"]Re: MPLS over a TE tunnel[/URL][URL="https://supportforums.cisco.com/people/sean%40managednetworks.com"]sean@managednetworks.com[/URL]24.08.2006 11:56 If you do a "sh mpls traffic-engineering tunnels tunnel 0", was is the info that is displayed? Please let me know. Thanks.[URL="https://supportforums.cisco.com/message/964743#964743"]Reply[/URL]

[*] [URL="https://supportforums.cisco.com/message/964744#964744"]Re: MPLS over a TE tunnel[/URL][URL="https://supportforums.cisco.com/people/hritter"]hritter[/URL]24.08.2006 12:45Did you configure MPLS specific statements under your IGP (either ISIS or OSPF) as follow: OSPF: mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0 ISIS: mpls traffic-eng router-id Loopback0 mpls traffic-eng <level-1|level-2> Also did you configure all interfaces for mpls traffic engineering between the headend and the tailend using the following statements: mpls traffic-eng tunnels ip...[URL="https://supportforums.cisco.com/message/964744#964744"]Reply[/URL]

[/LIST][*] [URL="https://supportforums.cisco.com/thread/30272"]MPLS VPN and MPLS TE[/URL][URL="https://supportforums.cisco.com/people/okopp"]okopp[/URL]1 Reply07.11.2001 13:15 Hi, is it possible in MPLS network combine VPN and TE ? For example explicitly set path for VPN traffic through MPLS-TE tunnel. Could you recommend me any link or article or can you advise me how to do it ? thanks, Olda[URL="https://supportforums.cisco.com/community/feeds/messages?thread=30272"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/30272"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/107422#107422"]Re: MPLS VPN and MPLS TE[/URL][URL="https://supportforums.cisco.com/people/wdrootz"]wdrootz[/URL]07.11.2001 13:15 I’m not sure what platform you’re on but I found this whitepaper on the 7600 [url]http://www.cisco.com/warp/public/cc/pd/rt/7600osr/tech/76mps_wp.htm[/url][URL="https://supportforums.cisco.com/message/107422#107422"]Reply[/URL]

[/LIST][/LIST]
[URL="https://supportforums.cisco.com/community/feeds/search?peopleEnabled=false&dateRange=all&rankBy=29&q=Implementing%20%7C%7C%20an%20%7C%7C%20MPLS%20%7C%7C%20VPN%20%7C%7C%20over%20%7C%7C%20TE%20%7C%7C%20Tunnels"]Subscribe [/URL][URL="https://supportforums.cisco.com/login.jspa?redirectURL=/choose-container%21input.jspa?contentType=1"]Start A New Discussion[/URL]

[B] Related Information [/B]

[LIST][*] [B] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_q_and_a_item09186a00800949e5.shtml"]MPLS FAQ For Beginners[/URL] [/B][*] [B] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a0080093fcd.shtml"]How to Troubleshoot the MPLS VPN[/URL] [/B][*] [B] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080093fd0.shtml"]MPLS Basic Traffic Engineering Using OSPF Configuration Example[/URL] [/B][*] [B] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00800a6c11.shtml"]Configuring a Basic MPLS VPN[/URL] [/B][*] [B] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a0080144ab2.shtml"]Troubleshooting LSP Failure in MPLS VPN[/URL] [/B][*] [B] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/tsd_technology_support_protocol_home.html"]MPLS Support Page[/URL] [/B][*] [B] [URL="http://www.cisco.com/cisco/web/support/index.html"]Technical Support - Cisco Systems[/URL] [/B][/LIST]

[SIZE=-1] [/SIZE]
Updated: Aug 10, 2005

[/LEFT]
2010-02-11, 10:37 PM
patris1

[LEFT][B][B][SIZE=3]Inter-AS MPLS VPN Configuration with VPNv4 eBGP Sessions Between ASBRs[/SIZE][/B][/B]

[B]Document ID: 5811[/B]

[B]Contents[/B]

[INDENT][B]Introduction
[/B] [B]Prerequisites
Requirements
Components Used
Conventions
[/B] [B]Configure
Network Diagram
Configurations
Configuration Notes
[/B] [B]Verifying and Understanding Inter-AS MPLS VPN
PEsaro Router
Pomerol Router
Pulligny Router
[/B] [B]The next-hop-self Command on ASBRs
[/B] [B]Troubleshoot
[/B] [B]Related Information[/B][/INDENT][B]Introduction[/B]

This document shows a configuration example for a basic inter-autonomous system (inter-AS) Multiprotocol Label Switching (MPLS) VPN.
[B]Prerequisites[/B]

[B]Requirements[/B]

This document assumes a working knowledge of MPLS and MPLS VPN. Please see the [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080094472.shtml#related"]Related Information[/URL] section of this document for links to other MPLS VPN documents.
[B]Components Used[/B]

The information in this document is based on the following software versions:

[LIST][*] Cisco IOS® Software Releases 12.2 and 12.2T[/LIST]
[B]Note: [/B]Because this configuration uses a mixture of codes, Tag Distribution Protocol (TDP) is used rather than Label Distribution Protocol (LDP). In a pure LDP setup, Tag Forwarding Information Base (TFIB) would be replaced by Label Forwarding Information Base (LFIB), the [B]show tag forwarding[/B] command would become [B]show mpls forwarding[/B] command, and so forth.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
[B]Conventions[/B]

For more information on document conventions, refer to the [URL="http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080121ac5.shtml"]Cisco Technical Tips Conventions[/URL].
[B]Configure[/B]

In this section, you are presented with the information to configure the features described in this document.
[B]Note: [/B]To find additional information on the commands used in this document, use the [URL="http://www.cisco.com/pcgi-bin/Support/Cmdlookup/home.pl"]Command Lookup Tool[/URL] ([SIZE=-1][URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) .
[B]Network Diagram[/B]

This document uses the network setup shown in the diagram below.
[IMG]http://www.cisco.com/image/gif/paws/5811/interasvpn_01.gif[/IMG]
[B]Configurations[/B]

This document uses the configurations shown below for the routers in the [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080094472.shtml#diag"]network diagram[/URL] above.

[LIST][*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080094472.shtml#Pulligny"]Pulligny[/URL][*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080094472.shtml#PEscara"]PEscara[/URL][*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080094472.shtml#Pauillac"]Pauillac[/URL][*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080094472.shtml#Pomerol"]Pomerol[/URL][*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080094472.shtml#PEsaro"]PEsaro[/URL][/LIST]
Pulligny
version 12.2
!
hostname Pulligny
!
ip cef
[I]
[COLOR=#0000ff]!--- Cisco Express Forwarding (CEF) must be enabled for MPLS.[/COLOR]
[/I]
!
interface Loopback0
ip address 10.10.10.2 255.255.255.255
ip router isis
!
interface Serial0/0
no ip address
encapsulation frame-relay
!
interface Serial0/0.1 point-to-point
description to Paulliac
ip address 10.1.1.2 255.255.255.252
ip router isis
tag-switching ip
[I]
[COLOR=#0000ff]!--- TDP or LDP needs to be enabled inside each AS.[/COLOR]
[/I]
frame-relay interface-dlci 913
!
interface Serial0/0.2 point-to-point
description to Pomerol
ip address 10.1.1.10 255.255.255.252
frame-relay interface-dlci 912
[I]
[COLOR=#0000ff]!--- No TDP, LDP, or routing protocols enabled on the inter-AS link.[/COLOR]
[/I]
!
router isis
redistribute connected metric 20
[I]
[COLOR=#0000ff]!--- To get the host route created by the Border Gateway Protocol (BGP)
!--- into the Interior Gateway Protocol (IGP).[/COLOR]
[/I]
net 47.0000.5555.5555.5555.00
metric-style wide
!
router bgp 1
no bgp default ipv4-unicast
[I]
[COLOR=#0000ff]!--- BGP is not used for IPv4 unicast.[/COLOR]
[/I]
no bgp default route-target filter
[I]
[COLOR=#0000ff]!--- Needed to accept VPNv4 prefixes.[/COLOR]
[/I]
neighbor 10.1.1.9 remote-as 2
[I]
[COLOR=#0000ff]!--- External BGP (eBGP) to Pomerol.[/COLOR]
[/I]
neighbor 10.10.10.4 remote-as 1
neighbor 10.10.10.4 update-source Loopback0
[I]
[COLOR=#0000ff]!--- Internal BGP (iBGP) to PEscara.[/COLOR]
[/I]
!
address-family vpnv4
neighbor 10.1.1.9 activate
neighbor 10.1.1.9 send-community both
neighbor 10.10.10.4 activate
neighbor 10.10.10.4 send-community extended
exit-address-family
[I]
[COLOR=#0000ff]!--- Address family to allow BGP to carry VPN-IPv4 protocols.[/COLOR]
[/I]
!
ip classless
!
end
PEscara
hostname PEscara
!
ip vrf one
rd 1:1
route-target export 1:1
route-target import 1:1
[I]
[COLOR=#0000ff]!--- Create a virtual routing and forwarding (VRF) instance called [B]one [/B]
!--- with a route distinguished value of [B]1:1[/B]. Routes with route target
!--- values of 1:1 will be imported into the VRF and exported out
!--- of the VRF.
[/COLOR]
[/I]ip cef
[I]
[COLOR=#0000ff]!--- CEF must be enabled for MPLS.[/COLOR]
[/I]
!
interface Loopback0
ip address 10.10.10.4 255.255.255.255
ip router isis
!
interface Serial0/1
no ip address
encapsulation frame-relay
frame-relay lmi-type cisco
!
interface Serial0/1.1 point-to-point
description to Pauillac
ip address 10.1.1.14 255.255.255.252
ip router isis
tag-switching ip
frame-relay interface-dlci 973
!
interface Serial0/1.2 point-to-point
description to CEntrum
ip vrf forwarding one
[I]
[COLOR=#0000ff]!--- Associates the interface with VRF one.[/COLOR]
[/I]
ip address 120.0.0.1 255.255.255.0
frame-relay interface-dlci 979
!
router isis
net 47.0000.7777.7777.7777.00
metric-style wide
!
router bgp 1
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 10.10.10.2 remote-as 1
neighbor 10.10.10.2 update-source Loopback0
[I]
[COLOR=#0000ff]!--- iBGP to Pulligny.[/COLOR]
[/I]
!
address-family ipv4 vrf one
redistribute connected
no auto-summary
no synchronization
exit-address-family
[I]
[COLOR=#0000ff]!--- Address family to allow BGP to carry IPv4 protocols for VRF one
!--- (each VRF that injects routes into BGP must be configured under
!--- the BGP process using its own address family).[/COLOR]
[/I]
!
address-family vpnv4
neighbor 10.10.10.2 activate
neighbor 10.10.10.2 send-community both
exit-address-family
[I]
[COLOR=#0000ff]!--- Address family to allow BGP to carry VPN-IPv4 protocols.[/COLOR]
[/I]
!
ip classless
!
end
Pauillac
[I]
[COLOR=#0000ff]!--- The Pauillac router is a Provider router (p) and its configuration
!--- is quite simple. It is configured for Intermediate System-to-
!--- Intermediate System (IS-IS) and MPLS/Tag switching.[/COLOR]
[/I]
!
hostname Pauillac
!
ip cef
!
interface Loopback0
ip address 10.10.10.1 255.255.255.255
ip router isis
!
interface Serial0/0
no ip address
encapsulation frame-relay
!
interface Serial0/0.1 point-to-point
description to Pulligny
ip address 10.1.1.1 255.255.255.252
ip router isis
tag-switching ip
frame-relay interface-dlci 931
!
interface Serial0/0.3 point-to-point
description to PEscara
ip address 10.1.1.13 255.255.255.252
ip router isis
tag-switching ip
frame-relay interface-dlci 937
!
router isis
net 47.0000.3333.3333.3333.00
metric-style wide
!
ip classless
!
end
Pomerol
[I]
[COLOR=#0000ff]!--- The Pomerol router is an autonomous system border router (ASBR)
!--- like Pulligny and its configuration is very similar to Pomerol's. [/COLOR]
[/I]
hostname Pomerol
!
ip cef
!
interface Loopback0
ip address 10.10.10.3 255.255.255.255
ip router isis
!
interface Serial0/0
no ip address
encapsulation frame-relay
!
interface Serial0/0.1 point-to-point
description to Pulligny
ip address 10.1.1.9 255.255.255.252
frame-relay interface-dlci 921
!
interface Serial0/0.3 point-to-point
description to PEsaro
ip address 10.1.1.21 255.255.255.252
ip router isis
tag-switching ip
frame-relay interface-dlci 925
!
router isis
redistribute connected metric 20
net 47.0000.2222.2222.2222.00
metric-style wide
!
router bgp 2
no bgp default ipv4-unicast
no bgp default route-target filter
bgp log-neighbor-changes
neighbor 10.1.1.10 remote-as 1
neighbor 10.10.10.6 remote-as 2
neighbor 10.10.10.6 update-source Loopback0
!
address-family vpnv4
neighbor 10.1.1.10 activate
neighbor 10.1.1.10 send-community both
neighbor 10.10.10.6 activate
neighbor 10.10.10.6 send-community extended
exit-address-family
!
ip classless
!
end
PEsaro
[I]
[COLOR=#0000ff]!--- The PEsaro router is a PE router like the PEscara router, and its
!--- configuration is very similar.[/COLOR]
[/I]
hostname PEsaro
!
ip vrf one
rd 1:1
route-target export 1:1
route-target import 1:1
ip cef
!
interface Loopback0
ip address 10.10.10.6 255.255.255.255
ip router isis
!
interface Serial0/1
no ip address
encapsulation frame-relay
!
interface Serial0/1.1 point-to-point
description to Pomerol
ip address 10.1.1.22 255.255.255.252
ip router isis
tag-switching ip
frame-relay interface-dlci 952
!
interface Serial0/1.2 point-to-point
description to CErvela
ip vrf forwarding one
ip address 220.0.0.1 255.255.255.0
frame-relay interface-dlci 958
!
router isis
net 47.0000.5555.5555.5555.00
metric-style wide
!
router bgp 2
no synchronization
no bgp default ipv4-unicast
bgp log-neighbor-changes
redistribute connected
neighbor 10.10.10.3 remote-as 2
neighbor 10.10.10.3 update-source Loopback0
no auto-summary
!
address-family ipv4 vrf one
redistribute connected
no auto-summary
no synchronization
exit-address-family
!
address-family vpnv4
neighbor 10.10.10.3 activate
neighbor 10.10.10.3 send-community both
no auto-summary
exit-address-family
!
ip classless
!
end
[B]Configuration Notes[/B]

[LIST][*] eBGP between both ASs cannot be multihop.[*] LDP or TDP is not required between both ASs.[*] A common IGP is not required between both ASs. Each AS can use its own distinct IGP.[*] BGP creates a connected host route for the eBGP peer in the remote AS once the session that needs to be injected into the IGP of each AS comes up.[*] Unless the ASBR is a PE for every VRF that you want to exchange, you will need to configure the [B]no bgp default route-target filter[/B] command to make sure that the ASBR accepts the BGP VPNv4 prefixes from the other PE routers inside the AS. The default behavior is to deny incoming VPNv4 prefixes that are not imported into any local VRF.[/LIST]
[B]Verifying and Understanding Inter-AS MPLS VPN[/B]

This section provides information which you can use to confirm that your configuration is working properly.
Certain [B]show[/B] commands are supported by the [URL="https://www.cisco.com/cgi-bin/Support/OutputInterpreter/home.pl"]Output Interpreter Tool[/URL] ([SIZE=-1][URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) , which allows you to view an analysis of [B]show[/B] command output.
For more information on the commands used below, please see [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a0080093fcd.shtml"]How to Troubleshoot the MPLS VPN[/URL].
The following examples show the packet flow from 220.0.0.0/24—which is a connected VRF one prefix on PEsaro—to 120.0.0.0/24—which is a connected VRF one prefix on PEscara.
[B]PEsaro Router[/B]

Below are the routes for VFR one in the PEsaro router.
[INDENT]PEsaro# [B]show ip route vrf one[/B]
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is not set

C 220.0.0.0/24 is directly connected, Serial0/1.2
120.0.0.0/24 is subnetted, 1 subnets
B 120.0.0.0 [200/0] via [B]10.1.1.10[/B], 00:26:49

PEsaro# [B]show ip cef vrf one 120.0.0.1[/B]
120.0.0.0/24, version 10, cached adjacency to Serial0/1.1
0 packets, 0 bytes
tag information set
local tag: [B]VPN-route-head[/B]
fast tag rewrite with Se0/1.1, point2point, tags imposed: {[B]17 22[/B]}
via 10.1.1.10, 0 dependencies, recursive
next hop 10.1.1.21, Serial0/1.1 via [B]10.1.1.10/32[/B]
valid cached adjacency
tag rewrite with Se0/1.1, point2point, tags imposed: {[B]17 22[/B]}[/INDENT]In the above output, you can see that the next hop for 120.0.0.0/24 is 10.1.1.10. You can also see that the tags imposed are 17 and 22. The TFIB and BGP information (below) shows you the source of these tags: the BGP route for 120.0.0.0/24 has an outgoing tag of 22, and the next hop that is associated with 120.0.0.0/24 has an outgoing tag of 17.
[INDENT]PEsaro# [B]show ip bgp vpnv4 vrf one tags[/B]
Network Next Hop In tag/Out tag
Route Distinguisher: 1:1 (one)
120.0.0.0/24 10.1.1.10 [B]notag/22[/B]
[I]
[COLOR=#0000ff]!--- VPN label.[/COLOR]
[/I]
220.0.0.0 0.0.0.0 18/aggregate(one)

PEsaro# [B]show tag forwarding 10.1.1.10[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
17 [B]17[/B] 10.1.1.10/32 0 Se0/1.1 point2point

PEsaro# [B]show ip route 10.1.1.10[/B]
Routing entry for 10.1.1.10/32
Known via "isis", distance 115, metric 30, type level-2
Redistributing via isis
Last update from 10.1.1.21 on Serial0/1.1, 00:30:39 ago
Routing Descriptor Blocks:
* 10.1.1.21, from 10.10.10.3, via Serial0/1.1
Route metric is 30, traffic share count is 1[/INDENT]10.1.1.10 is advertised by Pomerol. It is the BGP-created host route, which is important because it shows up as being the BGP next-hop for the remote VPNv4 prefixes, as shown in the output above. PEsaro sends a packet with two labels to Pomerol; the “inner” or “IGP” label is 17.
[B]Pomerol Router[/B]

[INDENT]Pomerol# [B]show tag forwarding[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 10.10.10.6/32 0 Se0/0.3 point2point
[B]17 Pop tag[/B] 10.1.1.10/32 540 Se0/0.1 point2point
18 18 1:1:220.0.0.0/24 1704 Se0/0.3 point2point

Pomerol# [B]show ip route 10.1.1.10[/B]
Routing entry for 10.1.1.10/32
Known via [B]"connected"[/B], distance 0, metric 0 (connected, via interface)
Redistributing via isis
Advertised by isis metric 20 metric-type internal level-2
Routing Descriptor Blocks:
* directly connected, via Serial0/0.1
Route metric is 0, traffic share count is 1[/INDENT][B]Note: [/B]The /32 route for 10.1.1.10 is created as soon as eBGP comes up.
In the above output, you can see that Pomerol will “pop” the top label if it is 17; the eBGP VPN label will be the only label left on packets sent to Pulligny in AS1.
[B]Pulligny Router[/B]

[INDENT]Pulligny# [B]show tag forwarding[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 10.1.1.9/32 540 Se0/0.2 point2point
17 Pop tag 10.1.1.12/30 0 Se0/0.1 point2point
18 Pop tag 10.10.10.1/32 0 Se0/0.1 point2point
19 16 10.10.10.4/32 0 Se0/0.1 point2point
21 Pop tag 10.1.1.4/30 0 Se0/0.1 point2point
[B]22 16[/B] 1:1:120.0.0.0/24 1080 Se0/0.1 point2point[/INDENT]The output above shows that Pulligny has local and outgoing tags for 120.0.0.0/24; consider, however, the following detailed TFIB entry:
[INDENT]Pulligny# [B]show tag forwarding detail | begin 22[/B]
22 16 1:1:120.0.0.0/24 1080 Se0/0.1 point2point
MAC/Encaps=4/12, MTU=1496, Tag Stack{16 23}
E4118847 0001000000017000
No output feature configured[/INDENT]The output above shows that Pulligny has a VPNv4 entry in its TFIB, which is necessary because there is only one label over the inter-AS link. Since Pomerol popped label 17 from the label stack, Pulligny receives a packet with label 22. It will pop label 22 and push label 23 and label 16. By looking at the TFIB and BGP information (shown below) you can see that 16 is the IGP label to get to PEscara, and 23 is the VPN label that PEscara advertises for 1:1:120.0.0.0/24.
[INDENT]Pulligny# [B]show ip bgp vpnv4 all tagging[/B]
Network Next Hop In tag/Out tag
Route Distinguisher: 1:1
120.0.0.0/24 10.10.10.4 [B]22/23[/B]
220.0.0.0 10.1.1.9 notag/18

Pulligny# [B]show tagging for 10.10.10.4[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
19 [B]16[/B] 10.10.10.4/32 0 Se0/0.1 point2point[/INDENT]Notice that Pulligny changes the VPN label that it gets from PEscara and advertises a different label to Pomerol. In doing so, it adds an entry for 1:1:120.0.0.0/24 to its TFIB. This behavior is the default because the label changes whenever the next-hop changes (such as in eBGP sessions between both ASs); therefore, the ASBR will have a TFIB entry for each VPN prefix inside its local AS. The output below shows that Pauillac has a simple label swap or pop because the PE is the next-hop (Penultimate Hop Popping [PHP]).
[INDENT]Pauillac# [B]show tag forwarding[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
[B]16 Pop tag[/B] 10.10.10.4/32 111049 Se0/0.3 point2point
17 Pop tag 10.10.10.2/32 94769 Se0/0.1 point2point
18 Pop tag 10.1.1.8/30 0 Se0/0.1 point2point
19 16 10.1.1.9/32 560 Se0/0.1 point2point[/INDENT]When PEscara receives label 23, it will recognize it as being part of VRF one and it will perform an IP lookup to forward it to the correct interface (as shown in the output below).
[INDENT]PEscara# [B]show tag forwarding[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 10.1.1.0/30 0 Se0/1.1 point2point
17 Pop tag 10.1.1.4/30 0 Se0/1.1 point2point
18 Pop tag 10.10.10.1/32 0 Se0/1.1 point2point
19 17 10.10.10.2/32 0 Se0/1.1 point2point
21 18 10.1.1.8/30 0 Se0/1.1 point2point
22 19 10.1.1.9/32 0 Se0/1.1 point2point
[B]23 Aggregate 120.0.0.0/24[V][/B] 1040

PEscara# [B]show tag forwarding detail | begin 23[/B]
23 Aggregate 120.0.0.0/24[V] 1040
MAC/Encaps=0/0, MTU=0, Tag Stack{}
[B]VPN route: one[/B]
Feature Quick flag set[/INDENT]The output below is an example of one packet being sent using the packet flow explained above.
[INDENT]Pomerol#
*Mar 1 19:49:59.103: TAG: Se0/0.3: recvd: CoS=0, TTL=255, Tag(s)=17/22
*Mar 1 19:49:59.103: TAG: Se0/0.1: xmit: CoS=0, TTL=254, Tag(s)=22

Pulligny#
*Mar 1 20:21:35: TAG: Se0/0.2: recvd: CoS=0, TTL=254, Tag(s)=22
*Mar 1 20:21:35: TAG: Se0/0.1: xmit: CoS=0, TTL=253, Tag(s)=16/23

Pauillac#
*Mar 1 19:56:39.627: TAG: Se0/0.1: recvd: CoS=0, TTL=253, Tag(s)=16/23
*Mar 1 19:56:39.627: TAG: Se0/0.3: xmit: CoS=0, TTL=252, Tag(s)=23

PEscara#
*Mar 1 19:57:00.463: TAG: Se0/1.1: recvd: CoS=0, TTL=252, Tag(s)=23[/INDENT][B]The next-hop-self Command on ASBRs[/B]

If you choose to configure the [B]next-hop-self[/B] command towards the iBGP peers on the ASBRs, the ASBR advertises a different label (because a new label is advertised when the next-hop changes) to the iBGP peers, adding an entry for the remote AS VPNv4 routes in its TFIB. This creates an additional state in the ASBRs. You do not need to redistribute the BGP-created host route into the IGP. As shown below, the ASBR now has both entries for local and remote VPN prefixes.
[INDENT]Pomerol# [B]show tag forwarding[/B]
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 10.10.10.6/32 0 Se0/0.3 point2point
17 Pop tag 10.1.1.10/32 540 Se0/0.1 point2point
18 18 1:1:220.0.0.0/24 0 Se0/0.3 point2point
[B]19 22 1:1:120.0.0.0/24 0 Se0/0.1 point2point[/B][/INDENT][B]Troubleshoot[/B]

There is currently no specific troubleshooting information available for this configuration.
[B]Related Information[/B]

[LIST][*][B][URL="http://www.cisco.com/en/US/docs/ios/12_1t/12_1t5/feature/guide/InterAS.html"]Inter-Autonomous Systems for MPLS VPNs[/URL][/B][*][B][URL="http://www.cisco.com/en/US/tech/tk436/tk428/tech_tech_notes_list.html"]MPLS Tech Notes[/URL][/B][*][B][URL="http://www.cisco.com/pcgi-bin/Support/browse/psp_view.pl?p=Internetworking:IGRP"]IGRP Technical Support[/URL][/B][*][B][URL="http://www.cisco.com/pcgi-bin/Support/browse/index.pl?i=Technologies&f=771"]IP Switching Technical Support[/URL][/B][*][B][URL="http://www.cisco.com/pcgi-bin/Support/browse/psp_view.pl?p=Internetworking:MPLS"]MPLS Technical Support[/URL][/B][*][B][URL="http://www.cisco.com/en/US/support/index.html"]Technical Support - Cisco Systems[/URL][/B][/LIST]

Updated: Aug 10, 2005
[/LEFT]
2010-02-11, 10:39 PM
patris1

[LEFT][B][B][SIZE=3]Internet Access from an MPLS VPN Using a Global Routing Table[/SIZE][/B][/B]

[B]Document ID: 24508[/B]

[B]Contents[/B]

[INDENT] [B] Introduction
[/B] [B] Prerequisites
Requirements
Components Used
Background Theory
Conventions
[/B] [B] Configure
Network Diagram
Configurations
[/B] [B] Verify
VPN Connectivity Between CE 1 and CE 2
Connectivity to the Internet from CE 1
[/B] [B] Troubleshoot
[/B] [B] Cisco Support Community - Featured Conversations
[/B] [B] Related Information [/B] [/INDENT][B] Introduction [/B]

The purpose of this document is to demonstrate the sample configuration used to access the Internet from a Multiprotocol Label Switching (MPLS)-based VPN using a global routing table.
In certain network scenarios, it is required to access the Internet from an MPLS-based VPN in addition to continuing to maintain the VPN connectivity among corporate sites. This sample configuration focuses on providing Internet access from the VPN routing and forwarding (VRF) that contains the default route to the Internet gateway router (IGW).
[B] Prerequisites [/B]

[B] Requirements [/B]

A basic understanding of [URL="http://www.cisco.com/en/US/docs/ios/12_1/switch/configuration/guide/xcdtagc.html"]MPLS[/URL] forwarding and [URL="http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/VPN.html"]MPLS VPN[/URL] is required to fully understand the contents of this document.
[B] Components Used [/B]

The information in this document is based on the software and hardware versions below.

[LIST][*] Cisco IOS® Software Release 12.1(3)T. Release 12.0(5)T includes the MPLS VPN feature[*] Any Cisco router from the 3600 series or later, such as the Cisco 3660 or 7206[/LIST]
The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.
[B] Background Theory [/B]

In this example configuration, these policies were in place:

[LIST][*] A router with connectivity to the Internet is attached to the MPLS network. It may or may not inject Border Gateway Protocol (BGP) routes into the global routing table.
[B]Note: [/B]PE routers understand BGP. Routers such as the Gigabit Switch Router (GSR) (which performs as a Provider Core router) do not run BGP at all.[*] There is no requirement for a VRF to have a full routing table from the Internet (global BGP table), so a static default route is put in a VRF pointing to the global next hop address of the IGW.[*] A VPN customer uses a registered unique address range that is routable in the global Internet routing table. The method of access discussed in this document is not recommended where customers have only private addresses in their network.[/LIST]
[B] Conventions [/B]

These acronyms are used in this document:

[LIST][*] CE - Customer Edge router[*] PE - Provider Edge router[*] P - Provider core router[/LIST]
For more information on document conventions, refer to [URL="http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080121ac5.shtml"]Cisco Technical Tips Conventions[/URL].
[B] Configure [/B]

[LIST][*] You can refer to the [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00801445fb.shtml#diag"]Network Diagram[/URL] for an illustration of this configuration. In this example, CE 1 and CE 2 are in the same VPN. They are configured under the customer1 VRF, since there is no requirement for a VRF to have a full routing table from the Internet (as per the policies in the [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00801445fb.shtml#background"]Background Theory[/URL] section of this document).[*] A static default route is configured in the customer1 VRF on CE 1 pointing to the IGW. By placing a static default route within the customer1 VRF, packets that do not match any of the routes contained within customer1 VRF will be sent to the IGW.[/LIST]
[B]Note: [/B]Since the Internet gateway next hop 192.168.67.1 is not a part of the customer1 VRF, a default route is configured under the customer1 VRF pointing to the Internet gateway interface s8/0 IP 192.168.67.1. The route to 192.168.67.1 does not lie within customer1 VRF, so you need to have a global keyword within the static default route configured under customer1 VRF. The global keyword specifies that the next hop address of the static route is resolved within the global routing table, not within the the customer1 VRF.
The following is an example of the static route.
[INDENT] [B]ip route[/B] vrf customer1 0.0.0.0 0.0.0.0 192.168.67.1 global[/INDENT]Having a static route with a global keyword in the customer1 VRF ensures that all packets destined to the Internet are routed to the Internet gateway and subsequently to the Internet.
[B]Note: [/B]The default route in PE 1 is configured to point to the serial interface IP address of the Internet gateway (192.168.67.1) and not to the loopback address (10.1.1.6). This avoids blackholing the routes in the event of connectivity failure between the Internet gateway and the Internet (R7). If the default route is pointed to the loopback address of the Internet gateway and the connectivity between the Internet gateway-R7 breaks, all the packets would continue to route to the Internet gateway. This happens because the loopback address remains up (unlike 192.168.67.1 which is withdrawn from the global routing table when interface s8/0 goes down) and the default route continues to exist in the routing table.
The next step is to ensure that packets coming back from the Internet to destination CE 1 network 11.11.11.0/24, are routed from the Internet gateway to PE 1 and to CE 1 through the MPLS core. This is achieved by configuring a static route for the CE 1 network pointing to the Serial 8/0 interface in the global routing table on PE 1. Redistribute it into the Open Shortest Path First (OSPF) so that the Internet gateway has that route in its global routing table. This allows the Internet gateway to route all packets coming from the Internet to PE 1, and to the final destination beyond CE 1.
The following example is the [B]ip route[/B] command used in configuration on PE 1.
[INDENT] [B]ip route[/B] 11.11.11.0 255.255.255.0 Serial8/0 192.168.10.1[/INDENT] [B]Note: [/B]The above static route configured in the global routing table is in addition to the static route configured within the customer1 VRF, which is used for VPN Network Layer Reachability Information (NLRI). On PE 1, it is configured as shown as below.
[INDENT] [B]ip route[/B] vrf customer1 11.11.11.0 255.255.255.0 192.168.10.1[/INDENT] [B]Note: [/B]To find additional information on the commands used in this document, use the [URL="http://www.cisco.com/pcgi-bin/Support/Cmdlookup/home.pl"]Command Lookup Tool[/URL] ([SIZE=-1] [URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) .
[B] Network Diagram [/B]

This document uses the network setup shown in the diagram below.
[IMG]http://www.cisco.com/image/gif/paws/24508/internet_access_mpls_vpn.gif[/IMG]
[B] Configurations [/B]

This document uses the configurations shown below.

[LIST][*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00801445fb.shtml#table1"]CE 1[/URL] [*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00801445fb.shtml#table2"]PE 1[/URL] [*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00801445fb.shtml#table3"]P[/URL] [*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00801445fb.shtml#table4"]IGW[/URL] [*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00801445fb.shtml#table5"]PE 2[/URL] [*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00801445fb.shtml#table6"]CE 2[/URL] [/LIST]
CE 1
version 12.2
!
hostname CE-1
!
ip subnet-zero
!
interface Loopback0
ip address 10.1.1.1 255.255.255.255
!
interface Loopback2
ip address 11.11.11.1 255.255.255.0
!
interface Serial8/0
ip address 192.168.10.1 255.255.255.252
[I]
[COLOR=#0000ff] !--- The interface is connected to PE 1.[/COLOR]
[/I]
!
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.10.2
[I]
[COLOR=#0000ff]!--- This is the default route to route all packets to PE 1.[/COLOR]
[/I]
!
PE 1
version 12.2
!
hostname PE-1
!
ip subnet-zero
!
ip vrf customer1
[I]
[COLOR=#0000ff]!--- This configured VRF customer1.[/COLOR]
[/I]
rd 100:1
[I]
[COLOR=#0000ff]!--- This configured the route distiguisher for VRF.[/COLOR]
[/I]
route-target export 1:1
route-target import 1:1
[I]
[COLOR=#0000ff]!--- This configured the export and import policies into VRF.[/COLOR]
[/I]
!
ip cef
[I]
[COLOR=#0000ff]!--- This enabled Cisco Express Forwarding (CEF) switching.[/COLOR]
[/I]
!
interface Loopback0
ip address 10.1.1.2 255.255.255.255
!
interface Ethernet0/0
[I]
[COLOR=#0000ff]!--- It is connected to P router.[/COLOR]
[/I]
ip address 10.10.23.2 255.255.255.0
tag-switching ip
[I]
[COLOR=#0000ff]!--- MPLS switching is enabled.[/COLOR]
[/I]
!
interface Serial8/0
! Connected to CE-1
ip vrf forwarding customer1
[I]
[COLOR=#0000ff]!--- Route forwarding based on customer1 VRF is enabled.[/COLOR]
[/I]
ip address 192.168.10.2 255.255.255.252
!
router ospf 1
log-adjacency-changes
redistribute static subnets
network 0.0.0.0 255.255.255.255 area 0
!
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 10.1.1.4 remote-as 100
[I]
[COLOR=#0000ff]!--- Neighbor relationship with PE 2 is established.[/COLOR]
[/I]
neighbor 10.1.1.4 update-source Loopback0
neighbor 10.1.1.4 next-hop-self
no auto-summary
!
address-family ipv4 vrf customer1
[I]
[COLOR=#0000ff]!--- The address-family configuration mode specifies IPv4 unicast
!---address prefixes for customer1 VRF.[/COLOR]
[/I]
no auto-summary
no synchronization
network 11.11.11.0 mask 255.255.255.0
[I]
[COLOR=#0000ff]!--- CE 1 network 11.11.11.0/24 to PE 2 is announced.[/COLOR]
[/I]
network 192.168.10.0 mask 255.255.255.252
exit-address-family
!
address-family vpnv4
[I]
[COLOR=#0000ff]!--- This is the address-family VPNV4 configuration mode for
!--- configuring BGP sessions.[/COLOR]
[/I]
neighbor 10.1.1.4 activate
neighbor 10.1.1.4 send-community extended
no auto-summary
exit-address-family
!
ip classless
ip route 11.11.11.0 255.255.255.0 Serial8/0 192.168.10.1
[I]
[COLOR=#0000ff]!--- The static route in the global routing table is pointing to
!--- the interface connected to CE 1.[/COLOR]
[/I]
ip route vrf customer1 0.0.0.0 0.0.0.0 192.168.67.1 global
[I]
[COLOR=#0000ff]!--- The static default route under customer1 VRF, routing packets
!--- outside of VPN to the Internet gateway.[/COLOR]
[/I]
! routes
ip route vrf customer1 11.11.11.0 255.255.255.0 192.168.10.1
[I]
[COLOR=#0000ff]!--- The static route for network 11.11.11.0/24 (CE-1 Network) under
!---customer1 VRF ensures the reachability of CE 1 network from the
!--- other VPN sites.[/COLOR]
[/I]

P
version 12.2
!
hostname P
!
ip subnet-zero
!
ip cef
[I]
[COLOR=#0000ff]!--- CEF switching is enabled.[/COLOR]
[/I]
!
interface Loopback0
ip address 10.1.1.3 255.255.255.255
!
interface Ethernet0/0
[I]
[COLOR=#0000ff]!--- This is connected to PE 1.[/COLOR]
[/I]
ip address 10.10.23.3 255.255.255.0
tag-switching ip
[I]
[COLOR=#0000ff]!--- MPLS switching is enabled.[/COLOR]
[/I]
!
interface Ethernet1/0
[I]
[COLOR=#0000ff]!--- This is connected to PE 2.[/COLOR]
[/I]
ip address 10.10.34.3 255.255.255.0
tag-switching ip
!
interface Ethernet2/0
[I]
[COLOR=#0000ff]!--- This is connected to the Internet gateway.[/COLOR]
[/I]
ip address 10.10.36.3 255.255.255.0
tag-switching ip
!
router ospf 1
log-adjacency-changes
network 0.0.0.0 255.255.255.255 area 0
IGW
version 12.2
!
hostname IGW
!
ip subnet-zero
!
ip cef
[I]
[COLOR=#0000ff]!--- This enabled CEF switching.[/COLOR]
[/I]
!
interface Loopback0
ip address 10.1.1.6 255.255.255.255
!
interface Ethernet2/0
[I]
[COLOR=#0000ff]!--- This is connected to P router.[/COLOR]
[/I]
ip address 10.10.36.6 255.255.255.0
tag-switching ip
!
interface Serial8/0
[I]
[COLOR=#0000ff]!--- This is connected to Internet R7.[/COLOR]
[/I]
ip address 192.168.67.1 255.255.255.252
!
router ospf 1
log-adjacency-changes
network 0.0.0.0 255.255.255.255 area 0
!
router bgp 100
no synchronization
bgp log-neighbor-changes
network 11.11.11.0 mask 255.255.255.0
network 22.22.22.0 mask 255.255.255.0
neighbor 192.168.67.2 remote-as 200
no auto-summary
PE 2
version 12.2
!
hostname PE-2
!
ip subnet-zero
!
ip vrf customer1
[I]
[COLOR=#0000ff]!--- Customer1 VRF is configured.[/COLOR]
[/I]
rd 100:1
[I]
[COLOR=#0000ff]!--- Route Distinguisher for VRF is configured.[/COLOR]
[/I]
route-target export 1:1
route-target import 1:1
[I]
[COLOR=#0000ff]!--- This configured the import and export policies for customer1
!--- VRF.[/COLOR]
[/I]
!
ip cef
[I]
[COLOR=#0000ff]!--- This enabled CEF switching.[/COLOR]
[/I]
!
interface Loopback0
ip address 10.1.1.4 255.255.255.255
interface Ethernet1/0
[I]
[COLOR=#0000ff]!--- Connected to P router.[/COLOR]
[/I]
ip address 10.10.34.4 255.255.255.0
tag-switching ip
[I]
[COLOR=#0000ff]!--- MPLS switching is enabled.[/COLOR]
[/I]
!
interface Serial9/0
[I]
[COLOR=#0000ff]!--- Connected to CE 2 router.[/COLOR]
[/I]
ip vrf forwarding customer1
[I]
[COLOR=#0000ff]!--- This enables VRF forwarding on the interface.[/COLOR]
[/I]
ip address 192.168.20.1 255.255.255.252
!
router ospf 1
log-adjacency-changes
redistribute static subnets
network 0.0.0.0 255.255.255.255 area 0
!
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 10.1.1.2 remote-as 100
neighbor 10.1.1.2 update-source Loopback0
neighbor 10.1.1.2 next-hop-self
no auto-summary
!
address-family ipv4 vrf customer1
[I]
[COLOR=#0000ff]!--- This is the address-family IPv4 configuration of customer1 VRF.[/COLOR]
[/I]
no auto-summary
no synchronization
network 22.22.22.0 mask 255.255.255.0
[I]
[COLOR=#0000ff]!--- This announces the CE 2 network to PE 1.[/COLOR]
[/I]
exit-address-family
!
address-family vpnv4
[I]
[COLOR=#0000ff]!--- This is the address-family VPNV4 configuration for BGP Sessions
!--- with PE 1.[/COLOR]
[/I]
neighbor 10.1.1.2 activate
neighbor 10.1.1.2 send-community extended
no auto-summary
exit-address-family
!
ip classless
ip route 22.22.22.0 255.255.255.0 Serial9/0 192.168.20.2
[I]
[COLOR=#0000ff]!--- This is the static route for network 22.22.22.0/24 in the global
!--- routing table pointing to the interface connected to CE 2.[/COLOR]
[/I]
ip route vrf customer1 0.0.0.0 0.0.0.0 192.168.67.1 global
[I]
[COLOR=#0000ff]!--- This is the static default route for customer VRF
!--- for destinations outside the VPN.[/COLOR]
[/I]
ip route vrf customer1 22.22.22.0 255.255.255.0 192.168.20.2
[I]
[COLOR=#0000ff]!--- This is the static route within customer1 VRF for CE 2
!--- network for VPN connectivity.[/COLOR]
[/I]

CE 2
version 12.2
!
hostname CE-2
!
ip subnet-zero
!
interface Loopback0
ip address 22.22.22.22 255.255.255.0
!
interface Serial9/0
[I]
[COLOR=#0000ff]!--- This is connected to PE 2.[/COLOR]
[/I]
ip address 192.168.20.2 255.255.255.252
!
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.20.1
[I]
[COLOR=#0000ff]!--- This is the default route pointing to PE 2.[/COLOR]
[/I]

[B] Verify [/B]

This section provides information you can use to confirm your configuration is working properly.
[B] VPN Connectivity Between CE 1 and CE 2 [/B]

To verify the VPN connectivity between CE 1 and CE 2, CE 1 should be able to reach CE 2's network 22.22.22.0/24 and the other way around. To check this, verify the route to network 22.22.22.0/24 in the customer1 VRF at PE 1.
Certain [B]show[/B] commands are supported by the [URL="https://www.cisco.com/cgi-bin/Support/OutputInterpreter/home.pl"]Output Interpreter Tool[/URL] ([SIZE=-1] [URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) , which allows you to view an analysis of [B]show[/B] command output.

[LIST=1][*] The [B]show ip route vrf customer1[/B] command confirms the route to network 22.22.22.0/24 learned from 10.1.1.4 (PE 2's loopback address) shown highlighted in the output below.
[INDENT] PE-1# [B]show ip route vrf customer1[/B]
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is 192.168.67.1 to network 0.0.0.0

192.168.10.0/30 is subnetted, 1 subnets
C 192.168.10.0 is directly connected, Serial8/0
22.0.0.0/24 is subnetted, 1 subnets
[B]B 22.22.22.0 [200/0] via 10.1.1.4, 01:00:50[/B]
11.0.0.0/24 is subnetted, 1 subnets
S 11.11.11.0 [1/0] via 192.168.10.1
S* 0.0.0.0/0 [1/0] via 192.168.67.1[/INDENT][*] Similarily, at PE 2, the route to network 11.11.11.0/24 in the customer1 VRF is shown in the example below.
[INDENT] PE-2# [B]show ip route vrf customer1[/B]
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is 192.168.67.1 to network 0.0.0.0

192.168.10.0/30 is subnetted, 1 subnets
B 192.168.10.0 [200/0] via 10.1.1.2, 01:00:09
22.0.0.0/24 is subnetted, 1 subnets
S 22.22.22.0 [1/0] via 192.168.20.2
192.168.20.0/30 is subnetted, 1 subnets
C 192.168.20.0 is directly connected, Serial9/0
11.0.0.0/24 is subnetted, 1 subnets
[B]B 11.11.11.0 [200/0] via 10.1.1.2, 01:00:09[/B]
S* 0.0.0.0/0 [1/0] via 192.168.67.1[/INDENT][*] Now check the connectivity between CE 1 and CE 2 by pinging a host 22.22.22.22 on CE 2 using the source IP address of 11.11.11.1 from CE 1.
[INDENT] CE-1# [B]ping[/B]
Protocol [ip]:
Target IP address: 22.22.22.22
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 11.11.11.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 22.22.22.22, timeout is 2 seconds:
!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 20/20/20 ms[/INDENT][/LIST]
[B] Connectivity to the Internet from CE 1 [/B]

Follow the steps below to verify connectivity to the Internet from CE1.

[LIST=1][*] All packets destined to the Internet or VPN from CE 1 will route using a default route configured in CE 1 pointing to PE 1, as shown below.
[INDENT] CE-1# [B]show ip route 0.0.0.0[/B]
Routing entry for 0.0.0.0/0, supernet
Known via "static", distance 1, metric 0, candidate default path
Routing Descriptor Blocks:
[B]* 192.168.10.2[/B]
Route metric is 0, traffic share count is 1[/INDENT][*] Packets coming into PE 1 interface s8/0 get routed using the customer1 VRF routing table. PE 1 has a default route in the customer1 VRF pointing to the IGW IP address 192.168.67.1, as shown below in the output for the show ip route vrf customer1 on PE 1.
[INDENT] PE-1# [B]show ip route vrf customer1[/B]
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is 192.168.67.1 to network 0.0.0.0

192.168.10.0/30 is subnetted, 1 subnets
C 192.168.10.0 is directly connected, Serial8/0
22.0.0.0/24 is subnetted, 1 subnets
B 22.22.22.0 [200/0] via 10.1.1.4, 01:21:11
11.0.0.0/24 is subnetted, 1 subnets
S 11.11.11.0 [1/0] via 192.168.10.1
[B]S* 0.0.0.0/0 [1/0] via 192.168.67.1[/B][/INDENT][*] Because the default route on PE 1 is configured with a global keyword, it looks for next hop 192.168.67.1 in its global routing table and routes to the IGW, as shown below.
[INDENT] PE-1# [B]show ip route 192.168.67.1[/B]
Routing entry for 192.168.67.0/30
Known via "ospf 1", distance 110, metric 84, type intra area
Last update from 10.10.23.3 on Ethernet0/0, 00:21:54 ago
Routing Descriptor Blocks:
[B]* 10.10.23.3, from 10.1.1.6, 00:21:54 ago, via Ethernet0/0[/B]
Route metric is 84, traffic share count is 1[/INDENT][*] The packets reaching IGW get routed over to the Internet based on the BGP routes it learned from R7. In this case, you can look at the BGP route learned from R7 to demonstrate the connectivity to the Internet. Shown below is the BGP route (network 99.99.99.0/24) learned from R7 in the IGW routing table.
[INDENT] IGW# [B]show ip route 99.99.99.0[/B]
Routing entry for 99.99.99.0/24
Known via "bgp 100", distance 20, metric 0
Tag 200, type external
Last update from 192.168.67.2 01:37:25 ago
Routing Descriptor Blocks:
[B]* 192.168.67.2[/B], from 192.168.67.2, 01:37:25 ago
Route metric is 0, traffic share count is 1
AS Hops 1[/INDENT] The packets that originated from CE-1 get routed to the Internet.[*] For packets coming back from the Internet destined to CE 1 network 11.11.11.0/24, IGW should have a route pointing to PE 1 in its global routing table. A static route in PE 1's global routing table pointing to s8/0 interface on PE 1 connecting to CE 1 and redistributed it into OSPF is configured. This ensures that the IGW has a route in its global routing table pointing to PE 1. The static route on PE 1 and the OSPF learned route on IGW is shown below.
[INDENT] IGW# [B]show ip route 11.11.11.0[/B]
Routing entry for 11.11.11.0/24
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 20
Last update from 10.10.36.3 on Ethernet2/0, 00:34:34 ago
Routing Descriptor Blocks:
* 10.10.36.3, from 10.1.1.2, 00:34:34 ago, via Ethernet2/0
Route metric is 20, traffic share count is 1

PE-1# [B]show ip route 11.11.11.0[/B]
Routing entry for 11.11.11.0/24
Known via "static", distance 1, metric 0
Redistributing via ospf 1
Advertised by ospf 1 subnets
Routing Descriptor Blocks:
[B]* 192.168.10.1, via Serial8/0[/B]
Route metric is 0, traffic share count is 1[/INDENT][*] Now check the connectivity to the Internet from CE 1 by pinging the R7 IP address 99.99.99.1 with the CE 1 source address of 11.11.11.1.
[INDENT] CE-1# [B]ping[/B]
Protocol [ip]:
Target IP address: 99.99.99.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 11.11.11.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 99.99.99.1, timeout is 2 seconds:
!!!!!
[B]Success rate is 100 percent (5/5), round-trip min/avg/max = 20/24/32 ms[/B]
CE-1#[/INDENT][/LIST]
[B] Troubleshoot [/B]

There is currently no specific troubleshooting information available for this configuration.
[B] Cisco Support Community - Featured Conversations [/B]

[URL="https://supportforums.cisco.com/index.jspa"]Cisco Support Community[/URL] is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers. Below are just some of the most recent and relevant conversations happening right now.
Want to see more? Join us by clicking [URL="https://supportforums.cisco.com/login.jspa"]here[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/thread/250076"]Internet Access from an MPLS VPN Using...[/URL][URL="https://supportforums.cisco.com/people/mlj%40sungard.com"]mlj@sungard.com[/URL]4 Replies10.06.2009 22:24 I have configured in the lab the example from "internet access from an MPLS VPN using a global routing table", Cisco document id 24508 which uses the static command: ip route vrf customer1 0.0.0.0 0.0.0.0 192.168.67.1 global I cannot find any method of providing internet access when multi-homed. Previously the Cisco "MPLS and VPN architecture" book specifies the use of the command "ip vrf forwarding CustomerA fallback global" which does not specify the next-hop, this seems to be the answer to the problem but it does not exist in the IOS code. Thanks in advance[URL="https://supportforums.cisco.com/community/feeds/messages?thread=250076"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/250076"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/975014#975014"]Re: Internet Access from an MPLS VPN...[/URL][URL="https://supportforums.cisco.com/people/g.grof"]g.grof[/URL]24.02.2005 08:18 Hi If you use dual-homing with 2 PE and 1 CE and static routing, than you should do the mentioned static route configuration on both PE routers and static routing on CE with different AD. [URL="https://supportforums.cisco.com/message/975014#975014"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/975015#975015"]Re: Internet Access from an MPLS VPN...[/URL][URL="https://supportforums.cisco.com/people/mlj%40sungard.com"]mlj@sungard.com[/URL]14.03.2005 09:32 Thanks for your response. I am interested in the ability to setup redundant routing using different internet service providers for all customers. Any info would be great.[URL="https://supportforums.cisco.com/message/975015#975015"]Reply[/URL]

[/LIST][*] [URL="https://supportforums.cisco.com/message/975016#975016"]Re: Internet Access from an MPLS VPN...[/URL][URL="https://supportforums.cisco.com/people/mike_winslow"]mike_winslow[/URL]10.06.2009 13:40 just a cautionary note that this document has a small omission in the config for the PE2 router.. address-family ipv4 vrf customer1 no synchronization network 22.22.22.0 mask 255.255.255.0 network 192.168.20.0 mask 255.255.255.252 The CE2/PE2 link wasnt advertised. CE1 was able to ping CE2, but not vice-versa. CE2 was able to ping CE1 using the loopback 0 address as the source..[URL="https://supportforums.cisco.com/message/975016#975016"]Reply[/URL]

[*] [URL="https://supportforums.cisco.com/message/975017#975017"]Re: Internet Access from an MPLS VPN...[/URL][URL="https://supportforums.cisco.com/people/shivlu"]shivlu[/URL]10.06.2009 22:24 pleae check what you ae looking for [url=http://shivlu.blogspot.com/2009/03/provisioning-internet-with-internet-vrf.html]Provisioning Internet With INTERNET vrf[/url] regards shivlu jain[URL="https://supportforums.cisco.com/message/975017#975017"]Reply[/URL]

[/LIST][*] [URL="https://supportforums.cisco.com/thread/247514"]Redundant access from MPLS VPN to...[/URL][URL="https://supportforums.cisco.com/people/andris.zarins"]andris.zarins[/URL]15 Replies09.12.2005 02:17 Several our customers have MPLS VPNs deployed over our infrastructure. Part of them requires access to Internet (global routing table in our case). As I'm not aware of any methods how to dynamicaly import/export routes between VRF/Global routing tables, at the moment there are static routes configured - one inside VRF pointing to global next hop, another one in global routing table, pointing to interface inside VRF. Task is to configure redundant access to Internet. By redundancy I mean using several exit points (primary and backup), what physically represents separate boxes. Here comes tricky part - both global static routes (on both boxes, meaning) are valid and reachable in all cases - no matter if specific prefix is reachable in VRF or not. What I'd like to achieve is that specific static route becomes valid only if specific prefix is reachable inside VRF. Yea, sounds like dynamic routing :), I know OK, hope U got the idea. Any solutions/recommendations ? Running all Internet routing inside VRF isn't an option, at least for now :([URL="https://supportforums.cisco.com/community/feeds/messages?thread=247514"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/247514"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/962874#962874"]Re: Redundant access from MPLS VPN to...[/URL][URL="https://supportforums.cisco.com/people/mheusinger"]mheusinger[/URL]30.11.2005 03:51Hello Andris, would it be feasible to separate internet access and VRF access by using f.e. two frame-relay PVCs (or VLANs etc.) on the PE-CE access line? The PE would get two sub-interfaces and one of them is placed in the VRF, the other in the global routing table. This would allow for all internet access options customers could ask for - from static default to full BGP internet table. You can use any available routing protocol on the...[URL="https://supportforums.cisco.com/message/962874#962874"]Reply[/URL]

[*] [URL="https://supportforums.cisco.com/message/962875#962875"]Re: Redundant access from MPLS VPN to...[/URL][URL="https://supportforums.cisco.com/people/mheusinger"]mheusinger[/URL]30.11.2005 04:03 Hello, me again, had a second thought: why not setting up a BGP session between CE and (global) PE utilizing packet leaking? Instead of static routing towards the announced coustomer prefix you only announce BGP neighbor host routes and BGP will exchange the customer prefixes. It will require eBGP multi-hop but should do the trick. Regards Martin[URL="https://supportforums.cisco.com/message/962875#962875"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/962876#962876"]Re: Redundant access from MPLS VPN to...[/URL][URL="https://supportforums.cisco.com/people/andris.zarins"]andris.zarins[/URL]30.11.2005 04:36Question was not about PE-CE communications, everything is fine there. To be more specific - I dont see any bonuses having two routing tables on CE box, meaning - global and VRF. All customer traffic is inside one VRF or all in global table (all respective interfaces on PE are in VRF in that case). Question is about PE configuration - how to configure redundant/resilent VRF/global communications on PE boxes? One option...[URL="https://supportforums.cisco.com/message/962876#962876"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/962877#962877"]Re: Redundant access from MPLS VPN to...[/URL][URL="https://supportforums.cisco.com/people/mheusinger"]mheusinger[/URL]30.11.2005 05:47Hi Andris, I did not mean to have a VRF on the CE. The CE would have both PVCs in the global routing table - his ONLY routing table in fact. One PVC would be used to announce routes into the customer specific VPN (VRF configured on the PE). The other PVC would allow for internet access through the PE (global IP routing table on the PE). dot1q will be ok as well. This way the CE can be a normal BGP peer to the PE, i.e. there is no MPLS...[URL="https://supportforums.cisco.com/message/962877#962877"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/962878#962878"]Re: Redundant access from MPLS VPN to...[/URL][URL="https://supportforums.cisco.com/people/attrgautam"]attrgautam[/URL]01.12.2005 01:10 Wondering if this would help. Importing IPv4 prefixes into VRF. Two things a) only 5 such VRFs supported per Router b) Not how default route would react. [url=http://www.cisco.com/univercd/cc/td/doc/product/software/ios122s/122snwft/release/122s25/fs_bgivt.htm]BGP Support for IP Prefix Import from Global Table into a VRF Table[/url] . [URL="https://supportforums.cisco.com/message/962878#962878"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/962879#962879"]Re: Redundant access from MPLS VPN to...[/URL][URL="https://supportforums.cisco.com/people/andris.zarins"]andris.zarins[/URL]01.12.2005 01:36 This feature sounds good, only thing - it works in only one direction - to import global prefixes into VRF, so that solves only smallest half of problem. Any ideas how to do same thing vice-versa ? Export prefixes from VRF to global ? [URL="https://supportforums.cisco.com/message/962879#962879"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/962880#962880"]Re: Redundant access from MPLS VPN to...[/URL][URL="https://supportforums.cisco.com/people/attrgautam"]attrgautam[/URL]01.12.2005 01:48 I assume you want it for backup floating routes to kick in, in which case you can use object tracking and remove the static routes so that backup routes can kick in and change the global routing table.[URL="https://supportforums.cisco.com/message/962880#962880"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/962881#962881"]Re: Redundant access from MPLS VPN to...[/URL][URL="https://supportforums.cisco.com/people/andris.zarins"]andris.zarins[/URL]01.12.2005 01:58Exactly, you got the idea. About scripts - you mean some non-IOS based stuff? I havent had much experience with object tracking, but as far as I know - tracking itself isnt able to to any actions, just track state of some specified objects and you have to combine it with some kind of process to do some actions based on tracking results. I hope I'm right with that :) It'd be really nice if you give some more specific info (http...[URL="https://supportforums.cisco.com/message/962881#962881"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/962883#962883"]Re: Redundant access from MPLS VPN to...[/URL][URL="https://supportforums.cisco.com/people/attrgautam"]attrgautam[/URL]01.12.2005 03:40 This should get you started off for object tracking. [url=http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123newft/123limit/123x/123xe/dbackupx.htm]Redirect: Internal Technical Support ITS[/url][URL="https://supportforums.cisco.com/message/962883#962883"]Reply[/URL]

[/LIST][*] [URL="https://supportforums.cisco.com/message/962882#962882"]Re: Redundant access from MPLS VPN to...[/URL][URL="https://supportforums.cisco.com/people/andris.zarins"]andris.zarins[/URL]01.12.2005 03:19 I found Cisco document describing that solution. Agree, it's quite intersting and it was something new for me, but it involves quite a lot of pain to implement, and I'm not sure if SAA is compatible with VRF. I think I'll pass this one :( [URL="https://supportforums.cisco.com/message/962882#962882"]Reply[/URL]

[/LIST][/LIST][/LIST][/LIST][/LIST][/LIST][*][URL="https://supportforums.cisco.com/message/247514#247514"]More Replies[/URL][/LIST][*] [URL="https://supportforums.cisco.com/thread/250358"]MPLS and the Global Routing Table...[/URL][URL="https://supportforums.cisco.com/people/efairbanks"]efairbanks[/URL]1 Reply23.08.2005 11:10 I have a router that has two interfaces; one in the global routing table (G0/0) and one in a VRF (G0/1). My network management server sits behind the interface located in the VRF. I can manage all equipment located in the VRF along with all equipment in the global routing table that is NOT located in the same subnet as the global routing interface (G0/0). Is there a way to get around the restriction of having to specify a next hop when exiting a VRF to the global routing table? I need to manage a switch that is located in the same subnet as G0/0. Thanks in advance.[URL="https://supportforums.cisco.com/community/feeds/messages?thread=250358"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/250358"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/976155#976155"]Re: MPLS and the Global Routing Table...[/URL][URL="https://supportforums.cisco.com/people/didyap"]didyap[/URL]23.08.2005 11:10 The following document has a sample configuration used to access the Internet from a Multiprotocol Label Switching (MPLS)-based VPN using a global routing table. [url=http://www.cisco.com/warp/public/105/internet_access_mpls_vpn.html]CCO Redirect[/url][URL="https://supportforums.cisco.com/message/976155#976155"]Reply[/URL]

[/LIST][*] [URL="https://supportforums.cisco.com/thread/249781"]DSL Access to MPLS VPN Global routing...[/URL][URL="https://supportforums.cisco.com/people/paulledwidge"]paulledwidge[/URL]2 Replies15.07.2004 10:10 Is it possible to define a route in the global routing table that points to a virtual-access interface. e.g. A dsl cpe connects to a PE via pppoe and is assigned to a vrf via radius lcp attributes. that cpe then spawns a virtual-access interface from Virtual-template X. show ip vrf cust-a shows that interface virtual-accessx is in the vrf and vrf routing is fine. but if I want to givr that cpe internet access through the global routing table I can't set the global route to the virtual-access interface! Any suggestions.[URL="https://supportforums.cisco.com/community/feeds/messages?thread=249781"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/249781"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/973781#973781"]Re: DSL Access to MPLS VPN Global...[/URL][URL="https://supportforums.cisco.com/people/gmarogi"]gmarogi[/URL]15.07.2004 07:37 I have tried this, though not on a Virtual-access interface. I am wondering if you can still point it to the physical interface through which connectivity is established. You can try this link [url=http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00801445fb.shtml]Internet Access from an MPLS VPN Using a Global Routing Table [MPLS] - Cisco Systems[/url] [URL="https://supportforums.cisco.com/message/973781#973781"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/973782#973782"]Re: DSL Access to MPLS VPN Global...[/URL][URL="https://supportforums.cisco.com/people/paulledwidge"]paulledwidge[/URL]15.07.2004 10:10 I have done some testing and internet access through an "Internet" vrf seems to be the only way. thanks for your input, P[URL="https://supportforums.cisco.com/message/973782#973782"]Reply[/URL]

[/LIST][/LIST][*] [URL="https://supportforums.cisco.com/thread/248459"]Full internet routing in an internet...[/URL][URL="https://supportforums.cisco.com/people/m.amstelveen"]m.amstelveen[/URL]3 Replies06.12.2003 16:49 Is it possible and advisable to run the full internet routing table in a seperate MPLS VRF. A default route is not an option With kind regards, Mike[URL="https://supportforums.cisco.com/community/feeds/messages?thread=248459"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/248459"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/967481#967481"]Re: Full internet routing in an...[/URL][URL="https://supportforums.cisco.com/people/waris"]waris[/URL]03.12.2003 05:21Hi, It is not advisable to have full Internet Routing table in a vrf.It is possible that you may run out of memory since different routers have different vrf routes holding capacity.e.g if you are using 12000 series and you have only one vrf configured then you can hold the entire Internet routing table in one vrf. Which router you have ? Is it 12000 ?How many vrfs you have ? How many routes have you per vrf ? You need to consider the above...[URL="https://supportforums.cisco.com/message/967481#967481"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/967482#967482"]Re: Full internet routing in an...[/URL][URL="https://supportforums.cisco.com/people/m.amstelveen"]m.amstelveen[/URL]03.12.2003 06:02 Hi, The routers we use are the 12000 serie. Is there a list for the different platforms and there routes holding capacity per vrf. Up to 200 VRF but only with a default route, and one VRF with the full internet routes. -Mike[URL="https://supportforums.cisco.com/message/967482#967482"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/967483#967483"]Re: Full internet routing in an...[/URL][URL="https://supportforums.cisco.com/people/waris"]waris[/URL]06.12.2003 16:49 Hi Mike, Its very hard to come up with the list since vrf route capacity has number of variables like number of vrfs,line card engine,presence of other features like ACl etc. Which line card engine you have ? If its engine 2 or 3 then you can use the full internet routing table since you have 200 vrfs but with default route. If its engine 2 and you are not using ACLs then you can disable them to get more vrf routes. -Waris[URL="https://supportforums.cisco.com/message/967483#967483"]Reply[/URL]

[/LIST][/LIST][/LIST][*] [URL="https://supportforums.cisco.com/thread/247691"]Internet routes, Global Routing table...[/URL][URL="https://supportforums.cisco.com/people/peter.danielsen"]peter.danielsen[/URL]1 Reply06.04.2006 05:46 Best practice, Is that you place all internet peering / transit into Global Routing table or into a MPLS VPN.. What is the benefits / disadvantages of both scenarios /Peter[URL="https://supportforums.cisco.com/community/feeds/messages?thread=247691"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/247691"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/963729#963729"]Re: Internet routes, Global Routing...[/URL][URL="https://supportforums.cisco.com/people/mheusinger"]mheusinger[/URL]06.04.2006 05:46Helo Peter, my 0.02$ Internet in Global Routing Pro: - Wellknown configs and behaviour - separate address-family (separate route refresh, etc.) - potentially separate RR for internet - usual memory consumption Con: - larger Global Routing table Internet in VRF Pro: - smaller global routing table - more (useless?) features like as-override Con: - more memory consumption (RD, RTs) - higher operational risk ("route-target import"...[URL="https://supportforums.cisco.com/message/963729#963729"]Reply[/URL]

[/LIST][*] [URL="https://supportforums.cisco.com/thread/250109"]access from the global routing table to...[/URL][URL="https://supportforums.cisco.com/people/ji.xie"]ji.xie[/URL]1 Reply14.03.2005 05:14 Hello I have a case: On one pe router ,there are two loopbacks: loopback11 (11.11.11.11)belongs to the globle routing table, loopback12(12.12.12.12)belongs to vrf test.I want lo11 can access lo12 vice verse. how to configure to achive this goal? Thanks in advance.[URL="https://supportforums.cisco.com/community/feeds/messages?thread=250109"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/250109"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/975122#975122"]Re: access from the global routing...[/URL][URL="https://supportforums.cisco.com/people/olorunloba"]olorunloba[/URL]14.03.2005 05:14 You need to configure vrf route leaking. See [url=http://www.cisco.com/en/US/tech/tk436/tk832/technologies_configuration_example09186a0080231a3e.shtml]Route Leaking in MPLS/VPN Networks [Multiprotocol Label Switching for VPNs (MPLS for VPNs)] - Cisco Systems[/url] [URL="https://supportforums.cisco.com/message/975122#975122"]Reply[/URL]

[/LIST][*] [URL="https://supportforums.cisco.com/thread/249208"]Global table to MPLS VPN problem[/URL][URL="https://supportforums.cisco.com/people/plearmouth"]plearmouth[/URL]12 Replies18.11.2008 05:15 Hi, I have PE-P-PE (no CE's) with various VPNs. From inside a VPN/VRF I have no issues pinging to the remote PE. However, I have a source within the global table that can ping various interfaces within the local VRF but I cannot get it too ping any VPNV4 address learnt from the remote PE. debug shows encapsulation error. Source is 10.10.0.10 (global table) and tries to ping 192.1.1.1 which exists in VRF Untrusted as a learnt VPNV4 prefix. I have a static route in the global table of ip route 192.1.1.1 255.255.255.255 vlan200 (which is an interface in the same VRF) The source can ping another interface within the VRF i.e a local interface but I cannot seem to get to addresses learnt from BGP. In summary, 1. within the VRF everything is okay. 2. from global to local interface within VRF is okay. 3. from global to learnt VPNV4 route I get encapsulation error. I presume I have the static route misdefined ? Many thanks in advance. Paul [URL="https://supportforums.cisco.com/community/feeds/messages?thread=249208"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/249208"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/970964#970964"]Re: Global table to MPLS VPN problem[/URL][URL="https://supportforums.cisco.com/people/giuslar"]giuslar[/URL]05.11.2008 10:29 Hello Paul, look at the following example: [url=http://www.cisco.com/en/US/tech/tk436/tk832/technologies_configuration_example09186a0080231a3e.shtml#global]Route Leaking in MPLS/VPN Networks [Multiprotocol Label Switching for VPNs (MPLS for VPNs)] - Cisco Systems[/url] It looks like you need a pair of static routes one of them in VRF: ip route 10.0.2.0 255.255.255.252 Serial2/0 ip route vrf vpn2 10.1.2.4 255.255.255.252 Serial1/0 Hope to help Giuseppe [URL="https://supportforums.cisco.com/message/970964#970964"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/970965#970965"]Re: Global table to MPLS VPN problem[/URL][URL="https://supportforums.cisco.com/people/plearmouth"]plearmouth[/URL]05.11.2008 11:00 hi Giuseppe Thanks for your reply but I do have both. It works for routes local to the PE but not for routes learnt from BGP. Although within the VRF the routes are okay. Debug shows arp as not getting a response from 192.1.1.1. I think this is the problem because this is not a local address. regards Paul[URL="https://supportforums.cisco.com/message/970965#970965"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/970966#970966"]Re: Global table to MPLS VPN problem[/URL][URL="https://supportforums.cisco.com/people/giuslar"]giuslar[/URL]05.11.2008 11:21 Hello Paul, have you got redistribute static within address-family ipv4 vrf vrf-name ? Hope to help Giuseppe [URL="https://supportforums.cisco.com/message/970966#970966"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/970967#970967"]Re: Global table to MPLS VPN problem[/URL][URL="https://supportforums.cisco.com/people/plearmouth"]plearmouth[/URL]05.11.2008 11:44hi Giuseppe yes I have - hopefully the following may help I have the following static route in the Global table where source resides: ip route 192.1.1.1 255.255.255.255 Vlan200 The global table shows: C 10.10.0.0/24 is directly connected, Vlan201 (source is 10.10.0.10) S 192.1.1.1 is directly connected, Vlan200 (destination 192.1.1.1)...[URL="https://supportforums.cisco.com/message/970967#970967"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/970968#970968"]Re: Global table to MPLS VPN problem[/URL][URL="https://supportforums.cisco.com/people/plearmouth"]plearmouth[/URL]05.11.2008 12:14 All Just realised I gave the cef entry for the static route in the global table rather than the learnt route in the VRF. sho ip cef vrf Untrusted 192.1.1.1 de 192.1.1.1/32, epoch 12, flags rib defined all labels recursive via 10.1.0.5 label 18 nexthop 10.1.0.138 Port-channel2 label 19 regards [URL="https://supportforums.cisco.com/message/970968#970968"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/970969#970969"]Re: Global table to MPLS VPN problem[/URL][URL="https://supportforums.cisco.com/people/giuslar"]giuslar[/URL]05.11.2008 13:42 Hello Paul, verify on the remote PE if the labels are correct. do a sh ip cef vrf on the remote PE Hope to help Giuseppe [URL="https://supportforums.cisco.com/message/970969#970969"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/970970#970970"]Re: Global table to MPLS VPN problem[/URL][URL="https://supportforums.cisco.com/people/plearmouth"]plearmouth[/URL]06.11.2008 08:49Hi Giuseppe I have traced the path end to end and everything seems fine. I am wondering however if it is a valid configuration. I presume it is valid to have say an Internet connection (global table) and have VRF's on a PE with no 'physical' interfaces but learnt VPNV4 prefixes from remote PE's. Only the system doesn't seem to do recursive lookups. The packet hits the VRF interface and then ARP's when it should do another...[URL="https://supportforums.cisco.com/message/970970#970970"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/970971#970971"]Re: Global table to MPLS VPN problem[/URL][URL="https://supportforums.cisco.com/people/giuslar"]giuslar[/URL]13.11.2008 06:01 Hello Paul, >> I presume it is valid to have say an Internet connection (global table) and have VRF's on a PE with no 'physical' interfaces but learnt VPNV4 prefixes from remote PE's. I think you need to have at least a loopbpack interface in the VRF alive to be able to use it Hope to help Giuseppe [URL="https://supportforums.cisco.com/message/970971#970971"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/970972#970972"]Re: Global table to MPLS VPN problem[/URL][URL="https://supportforums.cisco.com/people/plearmouth"]plearmouth[/URL]13.11.2008 06:07 Giuseppe I did have a loopback but it just doesn't work. I guess its just not possible to do it this way. Thanks for all your help Paul [URL="https://supportforums.cisco.com/message/970972#970972"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/970973#970973"]Re: Global table to MPLS VPN problem[/URL][URL="https://supportforums.cisco.com/people/benjaminwang74"]benjaminwang74[/URL]17.11.2008 14:46Paul, I am having the same problem, 3d22h: IP: s=10.15.5.1 (FastEthernet0/0), d=125.70.0.1, len 100, rcvd 2 3d22h: IP: s=10.15.5.1 (FastEthernet0/0), d=125.70.0.1, len 100, stop process pak for forus packet 3d22h: IP: s=125.70.0.1 (local), d=10.15.5.1 (FastEthernet1/0), len 100, sending 3d22h: IP: s=125.70.0.1 (local), d=10.15.5.1 (FastEthernet1/0), len 100, encapsulation failed 3d22h: IP: s=10.15.5.1 (FastEthernet0/0),...[URL="https://supportforums.cisco.com/message/970973#970973"]Reply[/URL]

[/LIST][/LIST][/LIST][/LIST][/LIST][/LIST][/LIST][/LIST][/LIST][*][URL="https://supportforums.cisco.com/message/249208#249208"]More Replies[/URL][/LIST][*] [URL="https://supportforums.cisco.com/thread/248758"]MPLS/VPN internet access[/URL][URL="https://supportforums.cisco.com/people/v.matiakis"]v.matiakis[/URL]3 Replies15.02.2008 17:04 Hi there, i have a rather general question. I was wondering what is the best and safest way in order to provide internet access to vpn customers? Is it using global routing table? If i already have a lot of vpn customers and not starting from scratch? Appropriate links for extra reading would be really usefull!! thanx in advance[URL="https://supportforums.cisco.com/community/feeds/messages?thread=248758"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/248758"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/968848#968848"]Re: MPLS/VPN internet access[/URL][URL="https://supportforums.cisco.com/people/yagnesh_tel"]yagnesh_tel[/URL]14.02.2008 15:21To have internet access in MPLS VPN, a static default route with the 'global' keyword is configured in the customer VRF pointing to the Internet gateway interface. The global keyword specifies that the next hop address of the static route should resolve within the global routing table, not within the customer's VRF. So the packets that do not match any of the routes contained within customer VRF will be sent to internet gateway. This way...[URL="https://supportforums.cisco.com/message/968848#968848"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/968849#968849"]Re: MPLS/VPN internet access[/URL][URL="https://supportforums.cisco.com/people/v.matiakis"]v.matiakis[/URL]15.02.2008 00:36 Hi and thanx for the response! I am wondering. Do i have to perform NAT anywhere? In the example IGW advertises customer networks in BGP. Isn't that a problem? What if i have many customers? [URL="https://supportforums.cisco.com/message/968849#968849"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/968850#968850"]Re: MPLS/VPN internet access[/URL][URL="https://supportforums.cisco.com/people/yagnesh_tel"]yagnesh_tel[/URL]15.02.2008 17:04The given example considers that a VPN customer uses a public address range that is routable in the global Internet routing table. If your customers are using private addresses, then you have to do NAT at your location. Also in given example IGW router advertise customer's network so that packets coming back from the Internet to destination customer network are routed back to IGW router and then CE 1. This is necessary considering that...[URL="https://supportforums.cisco.com/message/968850#968850"]Reply[/URL]

[/LIST][/LIST][/LIST][*] [URL="https://supportforums.cisco.com/thread/248252"]MPLS VPN internet access using L2TP[/URL][URL="https://supportforums.cisco.com/people/ianwarb"]ianwarb[/URL]3 Replies11.11.2003 03:16 I am trying to configure an MPLS VPN for internet access using L2TP and Radius. I have a dial up user account being dynamically assigned to a VRF which works fine and can see the other end of the VPN. I cannot, however, seem to get internet access working by leaking a route to the global internet. I have read the documentation which explains a standard static site VRF with a static route using the 'global' option, but the dial account uses a dynamic Virtual Interface that is different every time the user logs on and is connected to the LNS. Any help would be appreciated. [URL="https://supportforums.cisco.com/community/feeds/messages?thread=248252"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/248252"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/966378#966378"]Re: MPLS VPN internet access using L2TP[/URL][URL="https://supportforums.cisco.com/people/carenas123"]carenas123[/URL]10.11.2003 08:50 Try this site, you might find some useful tip. [url]http://www.cisco.com/en/US/netsol/ns341/ns396/ns172/ns126/networking_solutions_package.html[/url][URL="https://supportforums.cisco.com/message/966378#966378"]Reply[/URL]

[*] [URL="https://supportforums.cisco.com/message/966379#966379"]Re: MPLS VPN internet access using L2TP[/URL][URL="https://supportforums.cisco.com/people/ashraf.ali"]ashraf.ali[/URL]11.11.2003 00:51 You can do "Per-vrf AAA option on RADIUS" to overcome his problem. In this case vrf will be applied dynamically over the virtual-access interfaces using the attributes returned by the RADIUS server.[URL="https://supportforums.cisco.com/message/966379#966379"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/966380#966380"]Re: MPLS VPN internet access using L2TP[/URL][URL="https://supportforums.cisco.com/people/ianwarb"]ianwarb[/URL]11.11.2003 03:16 We are assigning a dynamic VRF on a per customer basis using radius, which works fine with the VPN, but i don't understand how this can be used for global internet access??[URL="https://supportforums.cisco.com/message/966380#966380"]Reply[/URL]

[/LIST][/LIST][/LIST]
[URL="https://supportforums.cisco.com/community/feeds/search?peopleEnabled=false&dateRange=all&rankBy=29&q=Internet%20%7C%7C%20Access%20%7C%7C%20from%20%7C%7C%20an%20%7C%7C%20MPLS%20%7C%7C%20VPN%20%7C%7C%20Using%20%7C%7C%20a%20%7C%7C%20Global%20%7C%7C%20Routing%20%7C%7C%20Table"]Subscribe [/URL][URL="https://supportforums.cisco.com/login.jspa?redirectURL=/choose-container%21input.jspa?contentType=1"]Start A New Discussion[/URL]

[B] Related Information [/B]

[LIST][*] [B] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a00800a6c11.shtml"]Configuring a Basic MPLS VPN[/URL] [/B][*] [B] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080093f23.shtml"]Configuring Basic MPLS Using OSPF[/URL] [/B][*] [B] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a0080093fcd.shtml"]How to Troubleshoot the MPLS VPN[/URL] [/B][*] [B] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a0080094b4e.shtml"]MPLS Troubleshooting[/URL] [/B][*] [B] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_q_and_a_item09186a00800949e5.shtml"]MPLS FAQ For Beginners[/URL] [/B][*] [B] [URL="http://www.cisco.com/en/US/customer/tech/tk436/tk428/tsd_technology_support_protocol_home.html"]MPLS (Multiprotocol Label Switching) Support Page[/URL] [/B][*] [B] [URL="http://www.cisco.com/en/US/customer/tech/tk436/tk428/tsd_technology_support_protocol_home.html"]MPLS for VPNs (Multiprotocol Label Switching for VPNs) Support Page[/URL] [/B][*] [B] [URL="http://www.cisco.com/cisco/web/support/index.html"]Technical Support - Cisco Systems[/URL] [/B][/LIST]

[SIZE=-1] [/SIZE]
Updated: Aug 10, 2005
[/LEFT]
2010-02-11, 10:41 PM
patris1

[LEFT][B][B][SIZE=3]MPLS Basic Traffic Engineering Using OSPF Configuration Example[/SIZE][/B][/B]

[B]Document ID: 13731[/B]

[B]Contents[/B]

[INDENT][B]Introduction
[/B] [B]Prerequisites
Requirements
Components Used
Conventions
[/B] [B]Functional Components
[/B] [B]Configure
Network Diagram
Quick Configuration Guide
Configuration Files
[/B] [B]Verify
Sample show Command Output
[/B] [B]Troubleshoot
[/B] [B]Related Information[/B][/INDENT][B]Introduction[/B]

This document provides a sample configuration for implementing traffic engineering (TE) on top of an existing Multiprotocol Label Switching (MPLS) network using Frame Relay and Open Shortest Path First (OSPF). Our example implements two dynamic tunnels (automatically set up by the ingress Label Switch Routers [LSR]) and two tunnels that use explicit paths.
TE is a generic name corresponding to the use of different technologies to optimize the utilization of a given backbone capacity and topology.
MPLS TE provides a way to integrate TE capabilities (such as those used on Layer 2 protocols like ATM) into Layer 3 protocols (IP). MPLS TE uses an extension to existing protocols (Intermediate System-to-Intermediate System (IS-IS), Resource Reservation Protocol (RSVP), OSPF) to calculate and establish unidirectional tunnels that are set according to the network constraint. Traffic flows are mapped on the different tunnels depending on their destination.
[B]Prerequisites[/B]

[B]Requirements[/B]

There are no specific requirements for this document.
[B]Components Used[/B]

The information in this document is based on the software and hardware versions:

[LIST][*] Cisco IOS® Software Releases 12.0(11)S and 12.1(3a)T[*] Cisco 3600 routers[/LIST]
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
[B]Conventions[/B]

Refer to [URL="http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080121ac5.shtml"]Cisco Technical Tips Conventions[/URL] for more information on document conventions.
[B]Functional Components[/B]

The following table describes the functional components of this configuration example:
Component
Description
IP tunnel interfaces
Layer 2: an MPLS tunnel interface is the head of a Label Switched Path (LSP). It is configured with a set of resource requirements, such as bandwidth and priority. Layer 3: the LSP tunnel interface is the head-end of a unidirectional virtual link to the tunnel destination.
RSVP with TE extension
RSVP is used to establish and maintain LSP tunnels based on the calculated path using PATH and RSVP Reservation (RESV) messages. The RSVP protocol specification has been extended so that the RESV messages also distribute label information.
Link-State Interior Gateway Protocol (IGP) [IS-IS or OSPF with TE extension]
Used to flood topology and resource information from the link management module. IS-IS uses new Type-Length-Values (TLVs); OSPF uses type 10 Link-State Advertisements (also called Opaque LSAs).
MPLS TE path calculation module
Operates at the LSP head only and determines a path using information from the link-state database.
MPLS TE link management module
At each LSP hop, this module performs link call admission on the RSVP signaling messages, and bookkeeping of topology and resource information to be flooded by OSPF or IS-IS.
Label switching forwarding
Basic MPLS forwarding mechanism based on labels.

[B]Configure[/B]

In this section, you are presented with the information to configure the features described in this document.
[B]Note: [/B]Use the [URL="http://www.cisco.com/pcgi-bin/Support/Cmdlookup/home.pl"]Command Lookup Tool[/URL] ([SIZE=-1][URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) to find more information on the commands used in this document.
[B]Network Diagram[/B]

This document uses this network setup:
[IMG]http://www.cisco.com/image/gif/paws/13731/mplsteisis1.gif[/IMG]
[B]Quick Configuration Guide[/B]

You can use the following steps to perform a quick configuration. Refer to [URL="http://www.cisco.com/en/US/docs/ios/12_1t/12_1t3/feature/guide/traffeng.html"]MPLS Traffic Engineering and Enhancements[/URL] for more detailed information.

[LIST=1][*] Set up your network with the usual configuration. (In this case, we used Frame Relay.)
[B]Note: [/B]It is mandatory to set up a loopback interface with an IP mask of 32 bits. This address will be used for the setup of the MPLS network and TE by the routing protocol. This loopback address must be reachable via the global routing table.[*] Set up a routing protocol for the MPLS network. It must be a link-state protocol (IS-IS or OSPF). In the routing protocol configuration mode, enter the following commands:

[LIST][*] For IS-IS:
[INDENT][B]metric-style [wide | both][/B]
[B]mpls traffic-eng router-id LoopbackN[/B]
[B]mpls traffic-eng [level-1 | level-2 |][/B][/INDENT][*] For OSPF:
[INDENT][B]mpls traffic-eng area X[/B]
[B]mpls traffic-eng router-id LoopbackN[/B] (must have a 255.255.255.255 mask)[/INDENT][/LIST]
[*] Enable MPLS TE. Enter [B]ip cef[/B] (or [B]ip cef distributed[/B] if available in order to enhance performance) in the general configuration mode. Enable MPLS ([B]tag-switching ip[/B]) on each concerned interface. Enter [B]mpls traffic-engineering tunnel[/B] to enable MPLS TE, as well as RSVP for zero-bandwidth TE tunnels.[*] Enable RSVP by entering [B]ip rsvp bandwidth XXX[/B] on each concerned interface for non-zero bandwidth tunnels.[*] Set up tunnels to be used for TE. There are many options that can be configured for MPLS TE Tunnel, but the [B]tunnel mode mpls traffic-eng[/B] command is mandatory. The [B]tunnel mpls traffic-eng autoroute announce[/B] command announces the presence of the tunnel by the routing protocol.
[B]Note: [/B]Do not forget to use [B]ip unnumbered loopbackN[/B] for the IP address of the tunnel interfaces.
This configuration shows two dynamic tunnels (Pescara_t1 and Pescara_t3) with different bandwidth (and priorities) going from the Pescara router to the Pesaro router, and two tunnels (Pesaro_t158 and Pesaro_t159) using an explicit path going from Pesaro to Pescara.[/LIST]
[B]Configuration Files[/B]

This document uses the configurations shown below. Only the relevant parts of the configuration files are included. Commands used to enable MPLS are in blue text; commands specific to TE (including RSVP) are in [B]bold[/B] text.
Pesaro
Current configuration:

!

version 12.1

!

hostname Pesaro

!

[I]
[COLOR=#0000ff]ip cef[/COLOR]
[/I]

!

[B]mpls traffic-eng tunnels[/B]

!

interface Loopback0

ip address 10.10.10.6 255.255.255.255

!

[B]interface Tunnel158

ip unnumbered Loopback0

tunnel destination 10.10.10.4

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 2 2

tunnel mpls traffic-eng bandwidth 158

tunnel mpls traffic-eng path-option 1 explicit name low

!

interface Tunnel159

ip unnumbered Loopback0

tunnel destination 10.10.10.4

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 4 4

tunnel mpls traffic-eng bandwidth 159

tunnel mpls traffic-eng path-option 1 explicit name straight[/B]

!

interface Serial0/0

no ip address

encapsulation frame-relay

!

interface Serial0/0.1 point-to-point

bandwidth 512

ip address 10.1.1.22 255.255.255.252

[I]
[COLOR=#0000ff]tag-switching ip[/COLOR]
[/I]

[B]mpls traffic-eng tunnels[/B]

frame-relay interface-dlci 603

[B]ip rsvp bandwidth 512 512[/B]

!

router ospf 9

network 10.1.1.0 0.0.0.255 area 9

network 10.10.10.0 0.0.0.255 area 9

[B]mpls traffic-eng area 9[/B]

[B]mpls traffic-eng router-id Loopback0[/B]

!

ip classless

!

[B]ip explicit-path name low enable

next-address 10.1.1.21

next-address 10.1.1.10

next-address 10.1.1.1

next-address 10.1.1.14

!

ip explicit-path name straight enable

next-address 10.1.1.21

next-address 10.1.1.5

next-address 10.1.1.14[/B]

!

end
Pescara
Current configuration:

!

version 12.0

!

hostname Pescara

!

[I]
[COLOR=#0000ff]ip cef[/COLOR]
[/I]

!

[B]mpls traffic-eng tunnels[/B]

!

interface Loopback0

ip address 10.10.10.4 255.255.255.255

!

[B]interface Tunnel1

ip unnumbered Loopback0

no ip directed-broadcast

tunnel destination 10.10.10.6

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 5 5

tunnel mpls traffic-eng bandwidth 25

tunnel mpls traffic-eng path-option 2 dynamic

!

interface Tunnel3

ip unnumbered Loopback0

no ip directed-broadcast

tunnel destination 10.10.10.6

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 6 6

tunnel mpls traffic-eng bandwidth 69

tunnel mpls traffic-eng path-option 1 dynamic[/B]

!

interface Serial0/1

no ip address

encapsulation frame-relay

!

interface Serial0/1.1 point-to-point

bandwidth 512

ip address 10.1.1.14 255.255.255.252

[B]mpls traffic-eng tunnels[/B]

[I]
[COLOR=#0000ff]tag-switching ip[/COLOR]
[/I]

frame-relay interface-dlci 401

[B]ip rsvp bandwidth 512 512[/B]

!

router ospf 9

network 10.1.1.0 0.0.0.255 area 9

network 10.10.10.0 0.0.0.255 area 9

[B]mpls traffic-eng area 9

mpls traffic-eng router-id Loopback0[/B]

!

end
Pomerol
Current configuration:

version 12.0

!

hostname Pomerol

!

[I]
[COLOR=#0000ff]ip cef[/COLOR]
[/I]

!

[B]mpls traffic-eng tunnels[/B]

!

interface Loopback0

ip address 10.10.10.3 255.255.255.255

!

interface Serial0/1

no ip address

encapsulation frame-relay

!

interface Serial0/1.1 point-to-point

bandwidth 512

ip address 10.1.1.6 255.255.255.252

[B]mpls traffic-eng tunnels[/B]

[I]
[COLOR=#0000ff]tag-switching ip[/COLOR]
[/I]

frame-relay interface-dlci 301

ip rsvp bandwidth 512 512

!

interface Serial0/1.2 point-to-point

bandwidth 512

ip address 10.1.1.9 255.255.255.252

[B]mpls traffic-eng tunnels[/B]

[I]
[COLOR=#0000ff]tag-switching ip[/COLOR]
[/I]

frame-relay interface-dlci 302

[B]ip rsvp bandwidth 512 512[/B]

!

interface Serial0/1.3 point-to-point

bandwidth 512

ip address 10.1.1.21 255.255.255.252

[B]mpls traffic-eng tunnels[/B]

[I]
[COLOR=#0000ff]tag-switching ip[/COLOR]
[/I]

frame-relay interface-dlci 306

[B]ip rsvp bandwidth 512 512[/B]

!

router ospf 9

network 10.1.1.0 0.0.0.255 area 9

network 10.10.10.0 0.0.0.255 area 9

[B]mpls traffic-eng area 9

mpls traffic-eng router-id Loopback0[/B]

!

ip classless

!

end
Pulligny
Current configuration:

!

version 12.1

!

hostname Pulligny

!

[I]
[COLOR=#0000ff]ip cef[/COLOR]
[/I]

!

[B]mpls traffic-eng tunnels[/B]

!

interface Loopback0

ip address 10.10.10.2 255.255.255.255

!

interface Serial0/1

no ip address

encapsulation frame-relay

!

interface Serial0/1.1 point-to-point

bandwidth 512

ip address 10.1.1.2 255.255.255.252

[B]mpls traffic-eng tunnels[/B]

[I]
[COLOR=#0000ff]tag-switching ip[/COLOR]
[/I]

frame-relay interface-dlci 201

[B]ip rsvp bandwidth 512 512[/B]

!

interface Serial0/1.2 point-to-point

bandwidth 512

ip address 10.1.1.10 255.255.255.252

[B]mpls traffic-eng tunnels[/B]

[I]
[COLOR=#0000ff]tag-switching ip[/COLOR]
[/I]

frame-relay interface-dlci 203

[B]ip rsvp bandwidth 512 512[/B]

!

router ospf 9

network 10.1.1.0 0.0.0.255 area 9

network 10.10.10.0 0.0.0.255 area 9

[B]mpls traffic-eng area 9

mpls traffic-eng router-id Loopback0[/B]

!

ip classless

!

end
Pauillac
!

version 12.1

!

hostname pauillac

!

[I]
[COLOR=#0000ff]ip cef[/COLOR]
[/I]

!

[B]mpls traffic-eng tunnels[/B]

!

interface Loopback0

ip address 10.10.10.1 255.255.255.255

!

interface Serial0/0

no ip address

encapsulation frame-relay

!

interface Serial0/0.1 point-to-point

bandwidth 512

ip address 10.1.1.1 255.255.255.252

[B]mpls traffic-eng tunnels[/B]

[I]
[COLOR=#0000ff]tag-switching ip[/COLOR]
[/I]

frame-relay interface-dlci 102

[B]ip rsvp bandwidth 512 512[/B]

!

interface Serial0/0.2 point-to-point

bandwidth 512

ip address 10.1.1.5 255.255.255.252

[B]mpls traffic-eng tunnels[/B]

[I]
[COLOR=#0000ff]tag-switching ip[/COLOR]
[/I]

frame-relay interface-dlci 103

[B]ip rsvp bandwidth 512 512[/B]

!

interface Serial0/0.3 point-to-point

bandwidth 512

ip address 10.1.1.13 255.255.255.252

[B]mpls traffic-eng tunnels[/B]

[I]
[COLOR=#0000ff]tag-switching ip[/COLOR]
[/I]

frame-relay interface-dlci 104

[B]ip rsvp bandwidth 512 512[/B]

!

router ospf 9

network 10.1.1.0 0.0.0.255 area 9

network 10.10.10.0 0.0.0.255 area 9

[B]mpls traffic-eng area 9

mpls traffic-eng router-id Loopback0[/B]

!

ip classless

!

end
[B]Verify[/B]

This section provides information you can use to confirm your configuration is working properly.
General show commands are illustrated in [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080093fcb.shtml"]Configuring MPLS Basic Traffic Engineering Using IS-IS[/URL]. The following commands are specific to MPLS TE with OSPF and are illustrated below:

[LIST][*] [B]show ip ospf mpls traffic-eng link[/B][*] [B]show ip ospf database opaque-area[/B][/LIST]
The [URL="https://www.cisco.com/cgi-bin/Support/OutputInterpreter/home.pl"]Output Interpreter Tool[/URL] ([SIZE=-1][URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) (OIT) supports certain [B]show[/B] commands. Use the OIT to view an analysis of [B]show[/B] command output.
[B]Sample show Command Output[/B]

You can use the [B]show ip ospf mpls traffic-eng link[/B] command to see what will be advertised by OSPF at a given router. The RSVP characteristics are shown in bold below, indicating the bandwidth that can be reserved, which is being advertised and used. You can see the bandwidth used by Pescara_t1 (at Priority 5) and Pescara_t3 (at Priority 6).
[INDENT]Pesaro# [B]show ip ospf mpls traffic-eng link[/B]

OSPF Router with ID (10.10.10.61) (Process ID 9)

Area 9 has 1 MPLS TE links. Area instance is 3.

Links in hash bucket 48.
Link is associated with fragment 0. Link instance is 3
Link connected to Point-to-Point network
Link ID : 10.10.10.3 Pomerol
Interface Address : 10.1.1.22
Neighbor Address : 10.1.1.21
Admin Metric : 195
[B]Maximum bandwidth : 64000
Maximum reservable bandwidth : 64000
Number of Priority : 8
Priority 0 : 64000 Priority 1 : 64000
Priority 2 : 64000 Priority 3 : 64000
Priority 4 : 64000 Priority 5 : 32000
Priority 6 : 24000 Priority 7 : 24000[/B]
Affinity Bit : 0x0[/INDENT]The [B]show ip ospf database[/B] command can be restrained to Type 10 LSAs and shows the database that is used by the MPLS TE process to calculate the best route (for TE) for dynamic tunnels (Pescara_t1 and Pescara_t3 in this example). This can be seen in the following partial output:
[INDENT]Pesaro# [B]show ip ospf database opaque-area[/B]

OSPF Router with ID (10.10.10.61) (Process ID 9)

Type-10 Opaque Link Area Link States (Area 9)

LS age: 397
Options: (No TOS-capability, DC)
LS Type: Opaque Area Link
Link State ID: 1.0.0.0
Opaque Type: 1
Opaque ID: 0
Advertising Router: 10.10.10.1
LS Seq Number: 80000003
Checksum: 0x12C9
Length: 132
Fragment number : 0

MPLS TE router ID : 10.10.10.1 Pauillac

Link connected to Point-to-Point network
Link ID : 10.10.10.3
Interface Address : 10.1.1.5
Neighbor Address : 10.1.1.6
Admin Metric : 195
Maximum bandwidth : 64000
Maximum reservable bandwidth : 48125
Number of Priority : 8
Priority 0 : 48125 Priority 1 : 48125
Priority 2 : 48125 Priority 3 : 48125
Priority 4 : 48125 Priority 5 : 16125
Priority 6 : 8125 Priority 7 : 8125
Affinity Bit : 0x0

Number of Links : 1
LS age: 339
Options: (No TOS-capability, DC)
LS Type: Opaque Area Link
Link State ID: 1.0.0.0
Opaque Type: 1
Opaque ID: 0
Advertising Router: 10.10.10.2
LS Seq Number: 80000001
Checksum: 0x80A7
Length: 132
Fragment number : 0

MPLS TE router ID : 10.10.10.2 Pulligny

Link connected to Point-to-Point network
Link ID : 10.10.10.1
Interface Address : 10.1.1.2
Neighbor Address : 10.1.1.1
Admin Metric : 195
Maximum bandwidth : 64000
Maximum reservable bandwidth : 64000
Number of Priority : 8
Priority 0 : 64000 Priority 1 : 64000
Priority 2 : 64000 Priority 3 : 64000
Priority 4 : 64000 Priority 5 : 64000
Priority 6 : 64000 Priority 7 : 64000
Affinity Bit : 0x0

Number of Links : 1

LS age: 249
Options: (No TOS-capability, DC)
LS Type: Opaque Area Link
Link State ID: 1.0.0.0
Opaque Type: 1
Opaque ID: 0
Advertising Router: 10.10.10.3
LS Seq Number: 80000004
Checksum: 0x3DDC
Length: 132
Fragment number : 0[/INDENT][B]Troubleshoot[/B]

There is currently no specific troubleshooting information available for this configuration.
[B]Related Information[/B]

[LIST][*][B][URL="http://www.cisco.com/en/US/tech/tk436/tk428/tsd_technology_support_protocol_home.html"]MPLS Support Page[/URL][/B][*][B][URL="http://www.cisco.com/en/US/tech/tk365/tk381/tsd_technology_support_sub-protocol_home.html"]IP Routing Support Page[/URL][/B][*][B][URL="http://www.cisco.com/en/US/support/index.html"]Technical Support & Documentation - Cisco Systems[/URL][/B][/LIST]

Updated: Aug 10, 2005

[/LEFT]
2010-02-11, 10:42 PM
patris1

[LEFT][B][B][SIZE=3]Multicast Support for MPLS VPNs Configuration Example[/SIZE][/B][/B]

[B]Document ID: 29220[/B]

[B]Contents[/B]

[INDENT] [B] Introduction
[/B] [B] Prerequisites
Requirements
Components Used
Conventions
[/B] [B] Background Information
[/B] [B] Configure
Network Diagram
Configurations
[/B] [B] Design Tips
[/B] [B] Verify
[/B] [B] Troubleshoot
[/B] [B] Cisco Support Community - Featured Conversations
[/B] [B] Related Information [/B] [/INDENT][B] Introduction [/B]

This document provides a sample configuration and general guidelines to configure multicast support for Multiprotocol Label Switching (MPLS) VPNs. This feature was introduced in Cisco IOS® Software Release 12.0(23)S and 12.2(13)T.
[B] Prerequisites [/B]

[B] Requirements [/B]

Before attempting this configuration, ensure that you meet these requirements:

[LIST][*] Service providers must have a multicast-enabled core in order to use the Cisco Multicast VPN feature.[/LIST]
[B] Components Used [/B]

The information in this document is based on Cisco IOS Software Release 12.2(13)T
[B]Note: [/B]To obtain updated information about platform support for this feature, use the [URL="http://www.cisco.com/pcgi-bin/Support/CompNav/Index.pl"]Software Advisor[/URL] ([SIZE=-1] [URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) . The Software Advisor dynamically updates the list of supported platforms as new platform support is added for the feature.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
[B] Conventions [/B]

For more information on document conventions, refer to [URL="http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080121ac5.shtml"]Cisco Technical Tips Conventions[/URL].
[B] Background Information [/B]

For background information, refer to the Cisco IOS Software Release 12.2(13)T new feature documentation for [URL="http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftmltvpn.html"]IP Multicast Support for MPLS VPNs[/URL].
[B] Configure [/B]

In this section, you are presented with the information to configure the features described in this document.
[B]Note: [/B]To find additional information on the commands used in this document, use the [URL="http://www.cisco.com/pcgi-bin/Support/Cmdlookup/home.pl"]Command Lookup Tool[/URL] ([SIZE=-1] [URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) .
[B] Network Diagram [/B]

This document uses the network setup shown in this diagram.
[IMG]http://www.cisco.com/image/gif/paws/29220/config_mpls_vpn1.gif[/IMG]
[B] Configurations [/B]

The [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080242aa8.shtml#diag"]network diagram[/URL] represents a service provider's backbone. This consists of routers R2, R3, and R4. The backbone is configured to support MPLS VPN. R2 and R4 are Provider Edge (PE) routers while R3 is a Provider (P) router. R1 and R5 represent Customer Edge (CE) routers that belong to the same VPN Routing and Forwarding (VRF) instance, yellow.
In order to provide multicast services, the backbone must be configured to run multicast routing. The multicast protocol selected for this purpose is Protocol Independent Multicast (PIM), and R3 is configured as the Rendezvous Point (RP). R2 and R4 are also configured to run multicast routing into VRF yellow. PIM sparse-dense mode is configured as the multicast routing protocol between the PEs and the CEs. R2 has been configured to be the RP for VRF yellow.
In order to test the multicast connectivity, the s0/0 interface of R5 is configured to join multicast group 224.2.2.2. Pings are sent from R1's loopback address to 224.2.2.2. The Internet Control Message Protocol (ICMP) echo is a multicast packet, while the ICMP reply is a unicast packet since the IP destination address is the R1 loopback address.
The configurations presented in this document include these:

[LIST][*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080242aa8.shtml#r1"]R1-(CE)[/URL] [*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080242aa8.shtml#r2"]R2-(PE)[/URL] [*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080242aa8.shtml#r3"]R3-(P)[/URL] [*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080242aa8.shtml#r4"]R4-(PE)[/URL] [*] [URL="http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080242aa8.shtml#r5"]R5-(CE)[/URL] [/LIST]
R1-(CE)
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
!
clock timezone CET 1
ip subnet-zero
no ip domain lookup
!
ip multicast-routing
[I]
[COLOR=#0000ff]!--- Enable multicast routing.[/COLOR]
[/I]
!
!
interface Loopback0
ip address 100.0.0.1 255.255.255.255
!
interface Serial0/0
ip address 10.1.0.1 255.255.255.0
ip pim sparse-dense-mode
[I]
[COLOR=#0000ff]!--- PIM sparce-dense mode is used between the PE and CE.
!--- PIM sparce-dense mode is the multicast routing protocol.[/COLOR]
[/I]

!
router rip
version 2
network 10.0.0.0
network 100.0.0.0
no auto-summary
!
ip classless
no ip http server
ip pim bidir-enable
!
!
!
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
login
!
end
R2-(PE)
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R2
!
!
clock timezone CET 1
ip subnet-zero
no ip domain lookup
!
ip vrf yellow
rd 2:200
route-target export 2:200
route-target import 2:200
mdt default 239.1.1.1
[I]
[COLOR=#0000ff]!--- Configure the default Multicast Distribution Tree (MDT)
!--- for VRF yellow.[/COLOR]
[/I]
mdt data 239.2.2.0 0.0.0.255 threshold 1
[I]
[COLOR=#0000ff]!--- Configure the range global addresses for
!--- data MDTs and the threshold.[/COLOR]
[/I]
ip multicast-routing
[I]
[COLOR=#0000ff]!--- Enable global multicast routing.[/COLOR]
[/I]
ip multicast-routing vrf yellow
[I]
[COLOR=#0000ff]!--- Enable multicast routing in VRF yellow.[/COLOR]
[/I]
ip cef
mpls label protocol ldp
tag-switching tdp router-id Loopback0
!
!
!
interface Loopback0
ip address 50.0.0.2 255.255.255.255
ip pim sparse-dense-mode

[I]
[COLOR=#0000ff]!--- Multicast needs to be enabled on loopback
!--- interface. This is used as a source
!--- for MPBGP sessions between PE routers that participate in MVPN.[/COLOR]
[/I]

!
interface Loopback100
ip vrf forwarding yellow
ip address 100.0.0.2 255.255.255.255
ip pim sparse-dense-mode
!
[I]
[COLOR=#0000ff]!--- This router needs to be RP for
!--- multicast in VRF yellow. Therefore, multicast
!--- needs to be enabled on the interface which is used as RP.[/COLOR]
[/I]

!
interface Serial1/0
ip vrf forwarding yellow
ip address 10.1.0.2 255.255.255.0
ip pim sparse-dense-mode
[I]
[COLOR=#0000ff]!--- Multicast is enabled on PE-CE interfaces in VRF.[/COLOR]
[/I]

!
interface Serial2/0
ip address 10.2.0.2 255.255.255.0
ip pim sparse-dense-mode
[I]
[COLOR=#0000ff]!--- Service provider core needs to run multicast
!--- to support MVPN services,
!--- so multicast is enabled on PE-P links.[/COLOR]
[/I]

tag-switching ip
!
router ospf 1
router-id 50.0.0.2
log-adjacency-changes
network 10.0.0.0 0.255.255.255 area 0
network 50.0.0.0 0.0.0.255 area 0
!
router rip
version 2
no auto-summary
!
address-family ipv4 vrf yellow
version 2
redistribute bgp 1
network 10.0.0.0
network 100.0.0.0
default-metric 5
no auto-summary
exit-address-family
!
router bgp 1
no synchronization
no bgp default ipv4-unicast
bgp log-neighbor-changes
redistribute rip
neighbor 50.0.0.4 remote-as 1
neighbor 50.0.0.4 update-source Loopback0
neighbor 50.0.0.4 activate
neighbor 50.0.0.6 remote-as 1
neighbor 50.0.0.6 update-source Loopback0
neighbor 50.0.0.6 activate
no auto-summary
!
address-family ipv4 vrf yellow
redistribute connected
redistribute rip
no auto-summary
no synchronization
exit-address-family
!
address-family vpnv4
neighbor 50.0.0.4 activate
neighbor 50.0.0.4 send-community extended
neighbor 50.0.0.6 activate
neighbor 50.0.0.6 send-community extended
no auto-summary
exit-address-family
!
ip classless
no ip http server
ip pim bidir-enable
ip pim vrf yellow send-rp-announce Loopback100 scope 100
ip pim vrf yellow send-rp-discovery Loopback100 scope 100
[I]
[COLOR=#0000ff]!--- Configure auto-RP. The R2's loopback
!--- 100 is the RP in VRF yellow.[/COLOR]
[/I]
!
!
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
login
!
end
R3-(P)
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R3
!
!
clock timezone CET 1
ip subnet-zero
!
ip multicast-routing
[I]
[COLOR=#0000ff]!--- Enable global multicast routing.[/COLOR]
[/I]
ip cef
mpls label protocol ldp
tag-switching tdp router-id Loopback0
!
!
!
interface Loopback0
ip address 50.0.0.3 255.255.255.255
ip pim sparse-dense-mode
!
!
interface Serial1/0
ip address 10.2.0.3 255.255.255.0
ip pim sparse-dense-mode
[I]
[COLOR=#0000ff]!--- Enable multicast on links to PE routers
!--- which have MVPNs configured.[/COLOR]
[/I]

tag-switching ip
!
interface Serial2/0
ip address 10.3.0.3 255.255.255.0
ip pim sparse-dense-mode
tag-switching ip
!
router ospf 1
router-id 50.0.0.3
log-adjacency-changes
network 10.0.0.0 0.255.255.255 area 0
network 50.0.0.0 0.0.0.255 area 0
!
ip classless
no ip http server
ip pim bidir-enable
ip pim send-rp-announce Loopback0 scope 100
ip pim send-rp-discovery Loopback0 scope 100
[I]
[COLOR=#0000ff]!--- R3 is configured to announce itself as
!--- the RP through auto-RP.[/COLOR]
[/I]
!
!
!
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
login
!
end
R4-(PE)
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R4
!
!
clock timezone CET 1
ip subnet-zero
no ip domain lookup
!
ip vrf yellow
rd 2:200
route-target export 2:200
route-target import 2:200
mdt default 239.1.1.1
[I]
[COLOR=#0000ff]!--- Configure the default MDT address.[/COLOR]
[/I]
mdt data 238.2.2.0 0.0.0.255 threshold 1
[I]
[COLOR=#0000ff]!--- Configure the data MDT range and threshold.[/COLOR]
[/I]
!
ip multicast-routing
[I]
[COLOR=#0000ff]!--- Enable global multicast routing.[/COLOR]
[/I]
ip multicast-routing vrf yellow
[I]
[COLOR=#0000ff]!--- Enable multicast routing in VRF yellow.[/COLOR]
[/I]
ip cef
mpls label protocol ldp
tag-switching tdp router-id Loopback0
!
!
!
interface Loopback0
ip address 50.0.0.4 255.255.255.255
ip pim sparse-dense-mode
!
interface Loopback100
ip vrf forwarding yellow
ip address 100.0.0.4 255.255.255.255
ip pim sparse-dense-mode
!
interface Serial1/0
ip address 10.3.0.4 255.255.255.0
ip pim sparse-dense-mode
tag-switching ip
!
interface Serial2/0
ip vrf forwarding yellow
ip address 10.4.0.4 255.255.255.0
ip pim sparse-dense-mode
[I]
[COLOR=#0000ff]!--- Enable the PIM toward the CE.[/COLOR]
[/I]
!
router ospf 1
router-id 50.0.0.4
log-adjacency-changes
network 10.0.0.0 0.255.255.255 area 0
network 50.0.0.0 0.0.0.255 area 0
!
router rip
version 2
no auto-summary
!
address-family ipv4 vrf yellow
version 2
redistribute bgp 1
network 10.0.0.0
network 100.0.0.0
default-metric 5
no auto-summary
exit-address-family
!
router bgp 1
no synchronization
no bgp default ipv4-unicast
bgp log-neighbor-changes
redistribute rip
neighbor 50.0.0.2 remote-as 1
neighbor 50.0.0.2 update-source Loopback0
neighbor 50.0.0.2 activate
no auto-summary
!
address-family ipv4 vrf yellow
redistribute connected
redistribute rip
no auto-summary
no synchronization
exit-address-family
!
address-family vpnv4
neighbor 50.0.0.2 activate
neighbor 50.0.0.2 send-community extended
no auto-summary
exit-address-family
!
ip classless
no ip http server
ip pim bidir-enable
!
!
!
!
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
login
!
end
R5-(CE)
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R5
!
!
clock timezone CET 1
ip subnet-zero
no ip domain lookup
!
ip multicast-routing
[I]
[COLOR=#0000ff]!--- Enable global multicast routing in the CE.[/COLOR]
[/I]
!
!
interface Loopback0
ip address 100.0.0.5 255.255.255.255
!
interface Serial0/0
ip address 10.4.0.5 255.255.255.0
ip pim sparse-dense-mode
ip igmp join-group 224.2.2.2
!
router rip
version 2
network 10.0.0.0
network 100.0.0.0
no auto-summary
!
ip classless
no ip http server
ip pim bidir-enable
!
!
!
!
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
login
!
end
[B] Design Tips [/B]

[LIST][*] Multicast for MPLS VPNs (MVPN) is configured on top of the VPN configuration. The MPLS VPN network needs to be carefully designed, to observe all recommendations for MPLS VPN networks first. [*] The service provider core must be configured for native multicast service. The core must be configured for PIM Sparse mode (PIM-SM), Source specific multicast (PIM-SSM), or Bidirectional PIM (PIM-BIDIR). Dense mode PIM (PIM-DM) is not supported as core protocol in MVPN configurations. It is possible to configure a mix of supported protocols in the provider's core. This can be done when some multicast groups are handled by one PIM mode and some other groups are handled by another supported PIM mode. [*] All multicast protocols are supported within multicast VRF. That is, within multicast VRF you can use MSDP and PIM-DM in addition to PIM-SM, PIM-SSM and PIM-BIDIR [*] The MVPN service can be added separately on a VRF-by-VRF basis. That is, one PE router may have both multicast-enabled VRFs and unicast-only VRFs configured. [*] Not all sites of a single unicast VRF must be configured for multicast. It is possible to have some sites (and even interfaces of MVPN PE router) where multicast is not enabled. You must ensure that routes are never calculated to point to non-multicast enabled interfaces. Otherwise, multicast forwarding will be broken. [*] More than one VRF can belong to the same MVPN multicast domain. IP addressing must be unique within a multicast domain. Leaking of routes and/or packets between multicast domains or into a global multicast routing table is currently not possible. [*] An MDT default configuration is mandatory for MVPN to work. Configuring data MDT is optional. It is highly recommended to set the threshold for data MDT if you choose to configure one. [*] The IP address of the default MDT determines which multicast domain VRF belongs to. Therefore, it is possible to have the same default MDT address for more than one VRF. However, they will share multicast packets between them and must observe other requirements on multicast domains (such as unique IP addressing scheme). [*] Data MDT might or might not be configured with the same range of IP addresses on different PE routers. This depends on which PIM mode is used in a provider's core. If the service provider core is using Sparse mode PIM, then each PE router must use a unique range of IP addresses for Data MDT groups. If the service provider core is using Source-specific multicast, then all PE routers might be configured with the same range of IP addresses for Data MDT of each multicast domain. [/LIST]
[B] Verify [/B]

This section provides information you can use to confirm your configuration is working properly.
Certain [B]show[/B] commands are supported by the [URL="https://www.cisco.com/cgi-bin/Support/OutputInterpreter/home.pl"]Output Interpreter Tool[/URL] ([SIZE=-1] [URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) , which allows you to view an analysis of [B]show[/B] command output.

[LIST][*] [B]show ip igmp groups[/B]—Displays the multicast groups with receivers that are directly connected to the router and that were learned through Internet Group Management Protocol (IGMP).[*] [B]show ip pim mdt bgp[/B]—Displays detailed Border Gateway Protocol (BGP) advertisement of the Route Distinguisher (RD) for the MDT default group.[*] [B]show ip pim vrf [I]<vrf-name>[/I] mdt send[/B]—Displays the data MDT advertisements that the router has made in the specified VRF. [*] [B]show ip pim vrf [I]<vrf-name>[/I] mdt receive[/B]—Displays the data MDT advertisements received by the router in the specified VRF.[*] [B]show ip mroute[/B]—Displays the contents of the IP multicast routing table in the provider's core. [*] [B]show ip mroute vrf [I]<vrf-name>[/I] [/B]—Displays the multicast routing table in the client's VRF. [/LIST]
[U] [COLOR=red] [/COLOR] [/U] Complete these steps to verify that your configuration is working properly.

[LIST=1][*] Check that the PEs have joined the IGMP group for the default MDT tunnel.
If it is configured after the [B]default-mdt[/B] command is issued under the VRF configuration, the PE might fail to join the default MDT group. Once the loopback is configured, remove the [B]mdt[/B] command from the VRF and put it back to solve the problem.

[LIST][*] For PE-R2, issue the [B]show ip igmp groups [/B]command.
[INDENT] IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
224.0.1.40 Serial2/0 02:21:23 stopped 10.2.0.2
239.1.1.1 Loopback0 02:36:59 stopped 0.0.0.0[/INDENT][*] For PE-R4, issue the [B]show ip igmp groups [/B]command.
[INDENT] IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
224.0.1.40 Loopback0 02:51:48 00:02:39 50.0.0.4
239.1.1.2 Loopback0 02:51:45 stopped 0.0.0.0
239.1.1.1 Loopback0 02:51:45 stopped 0.0.0.0
239.2.2.0 Loopback0 01:40:03 stopped 0.0.0.0[/INDENT][/LIST]
[*] Check the BGP advertisement received for each PE.
[B]Note: [/B]For this example, check the MDTs sourced from the peer PEs PE-R2 and PE-R4.

[LIST][*] For PE-R2, issue the [B]show ip pim mdt bgp [/B]command.
[INDENT] MDT-default group 239.1.1.1
rid: 50.0.0.4 next_hop: 50.0.0.4

WAVL tree nodes

MDT-default: 239.1.1.1 Tunnel0 source-interface: Loopback0[/INDENT][*] For PE-R4 issue the [B]show ip pim mdt bgp [/B]command
[INDENT] MDT-default group 239.1.1.1
rid: 50.0.0.2 next_hop: 50.0.0.2

WAVL tree nodes

MDT-default: 239.1.1.1 Tunnel0 source-interface: Loopback0
MDT-data : 239.2.2.0 Tunnel0 source-interface: Loopback0[/INDENT][/LIST]
[*] Check the data MDTs.
[B]Note: [/B]For this example, check the data MDT sourced or joined by PE-R2 and PE-R4.

[LIST][*] For PE-R2, issue the [B]show ip pim vrf yellow mdt send[/B] command.
[INDENT] MDT-data send list for VRF: yellow
(source, group) MDT-data group ref_count
(100.0.0.1, 224.2.2.2) 239.2.2.0 1[/INDENT][*] For PE-R2, issue the[B] show ip pim vrf yellow mdt receive[/B] command.
[INDENT] Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate MSDP Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Joined MDT-data groups for VRF: yellow
group: 239.2.2.0 source: 0.0.0.0 ref_count: 1[/INDENT][*] Check the global multicast routing table for the default MDT.
[B]Note: [/B]Notice this information:

[LIST=1][*] The outgoing interface list is MVRF yellow on the PEs.[*] The P router sees the group as a regular Multicast group.[*] Each PE is a source for the default MDT, and is only in the PE routers.[*] A new flag, Z, indicates this is a multicast tunnel.[/LIST]
[*] For PE-R2, issue the [B]show ip mroute 239.1.1.1[/B] command.
[INDENT] IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate MSDP Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 02:37:16/stopped, RP 50.0.0.3, flags: SJCFZ
Incoming interface: Serial2/0, RPF nbr 10.2.0.3
Outgoing interface list:
MVRF yellow, Forward/Sparse-Dense, 02:21:26/00:00:28

(50.0.0.2, 239.1.1.1), 02:37:12/00:03:29, flags: FTZ
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list:
Serial2/0, Forward/Sparse-Dense, 02:36:09/00:02:33
(
50.0.0.4, 239.1.1.1), 02:36:02/00:02:59, flags: JTZ
Incoming interface: Serial2/0, RPF nbr 10.2.0.3
Outgoing interface list:
MVRF yellow, Forward/Sparse-Dense, 02:21:26/00:00:28[/INDENT][*] For P-R3, issue the [B]show ip mroute 239.1.1.1[/B] command.
[INDENT]
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate MSDP Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 02:50:24/stopped, RP 50.0.0.3, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial1/0, Forward/Sparse-Dense, 02:34:41/00:03:16
Serial2/0, Forward/Sparse-Dense, 02:49:24/00:02:37

(50.0.0.2, 239.1.1.1), 02:49:56/00:03:23, flags: T
Incoming interface: Serial1/0, RPF nbr 10.2.0.2
Outgoing interface list:
Serial2/0, Forward/Sparse-Dense, 02:49:24/00:02:37

(50.0.0.4, 239.1.1.1), 02:49:47/00:03:23, flags: T
Incoming interface: Serial2/0, RPF nbr 10.3.0.4
Outgoing interface list:
Serial1/0, Forward/Sparse-Dense, 02:34:41/00:03:16[/INDENT][*] For PE-R4, issue the [B]show ip mroute 239.1.1.1 [/B]command.
[INDENT] IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate MSDP Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 02:51:06/stopped, RP 50.0.0.3, flags: SJCFZ
Incoming interface: Serial1/0, RPF nbr 10.3.0.3
Outgoing interface list:
MVRF yellow, Forward/Sparse-Dense, 02:51:06/00:00:48

(50.0.0.2, 239.1.1.1), 02:50:06/00:02:58, flags: JTZ
Incoming interface: Serial1/0, RPF nbr 10.3.0.3
Outgoing interface list:
MVRF yellow, Forward/Sparse-Dense, 02:50:06/00:00:48

(50.0.0.4, 239.1.1.1), 02:51:00/00:03:10, flags: FTZ
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list:
Serial1/0, Forward/Sparse-Dense, 02:35:24/00:03:00[/INDENT][/LIST]
[*] Check the global multicast routing table for data MDTs.
[B]Note: [/B]For PE-R2, notice that the outgoing interface is tunnel0.

[LIST][*] For PE-R2, where the source is located (VRF side), issue the [B]show ip mroute vrf yellow 224.2.2.2 [/B]command.
[INDENT] IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate MSDP Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.2.2.2), 2d01h/stopped, RP 100.0.0.2, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Tunnel0, Forward/Sparse-Dense, 2d01h/00:02:34

(100.0.0.1, 224.2.2.2), 00:05:32/00:03:26, flags: Ty
Incoming interface: Serial1/0, RPF nbr 10.1.0.1
Outgoing interface list:
Tunnel0, Forward/Sparse-Dense, 00:05:37/00:02:34[/INDENT][*] For PE-R2, where the source is located (global multicast route), issue the [B]show ip mroute 239.2.2.0 [/B]command.
[INDENT] IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate MSDP Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.2.2.0), 02:13:27/stopped, RP 50.0.0.3, flags: SJPFZ
Incoming interface: Serial2/0, RPF nbr 10.2.0.3
Outgoing interface list: Null

(50.0.0.2, 239.2.2.0), 02:13:27/00:03:22, flags: FTZ
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list:
Serial2/0, Forward/Sparse-Dense, 02:13:27/00:03:26[/INDENT][/LIST]
[B]Note: [/B]Only the PE router with has the multicast source attached to it appears as the source for multicast traffic of data MDT group address.
[/LIST]
[B] Troubleshoot [/B]

[LIST][*] Issue the [B]show ip pim vrf neighbor[/B] command to check that PE routers established a PIM neighbor relationship through the dynamic Tunnel interface. If they did, then Default MDT operates properly. [*] If Default MDT does not function, issue the [B]show ip pim mdt bgp[/B] command to check that loopbacks of remote PE routers participating in MVPN are known by the local router. If they are not, verify that PIM is enabled on loopback interfaces used as a source of MP BGP sessions [*] Check that the SP core is properly configured to deliver multicast between PE routers. For test purposes you might configure [B]ip igmp join-group[/B] on the loopback interface of one PE router and do multicast [B]ping[/B] sourced from the loopback of another PE router.[/LIST]
[B] Cisco Support Community - Featured Conversations [/B]

[URL="https://supportforums.cisco.com/index.jspa"]Cisco Support Community[/URL] is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers. Below are just some of the most recent and relevant conversations happening right now.
Want to see more? Join us by clicking [URL="https://supportforums.cisco.com/login.jspa"]here[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/thread/249990"]Multicast support for MPLS VPNS.[/URL][URL="https://supportforums.cisco.com/people/amms68958%40yahoo.com"]amms68958@yahoo.com[/URL]9 Replies06.04.2005 00:24 Hi , I am having only entry level knowledge in MPLS and Multicasting.. I have read that multicast across VRFS are currently not supported. But in the design tips given in the document "Multicast support for MPLS VPNs configuration examples",it is given as follows. "More than one VRF can belong to the same MVPN multicast domain. IP addressing must be unique within a multicast domain. Leaking of routes and/or packets between multicast domains or into a global multicast routing table is currently not possible." My qusetions are. 1) more tha one vrf belonging to the same MVPN multicast domain is contradicting the observation that multicast across vrfs are not supported..Can anyone pls give an explanation on this.. Thanks in advance, Thomas. [URL="https://supportforums.cisco.com/community/feeds/messages?thread=249990"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/249990"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974681#974681"]Re: Multicast support for MPLS VPNS.[/URL][URL="https://supportforums.cisco.com/people/hritter"]hritter[/URL]03.01.2005 14:55 Multicast is indeed supported in a MPLS VPN environment. The VRF being part of how MPLS VPN is deployed therefore needs to support MCAST. What is it precisely that you need to? For more information about MVPN, please refer to teh following URL: [url=http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/tcast_wp.htm]Cisco�- Multicast Virtual Private Networks Concepts[/url] Hope this helps, [URL="https://supportforums.cisco.com/message/974681#974681"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974684#974684"]Re: Multicast support for MPLS VPNS.[/URL][URL="https://supportforums.cisco.com/people/maher%40pd.jaring.my"]maher@pd.jaring.my[/URL]16.01.2005 18:41 Hi Hritter, Just want to ask basic question, for multicast mpls vpn, what kind of customers and application if they are using multicast mpls vpn? On normal implementation mpls vpn is normal sharing files,application server, but for multicast... thanks in advance, maher p/s:still new in multicast :)[URL="https://supportforums.cisco.com/message/974684#974684"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974685#974685"]Re: Multicast support for MPLS VPNS.[/URL][URL="https://supportforums.cisco.com/people/hritter"]hritter[/URL]17.01.2005 05:57 It can be for many purposes. Financial customers mainly use multicast for trading applications. Presentations, training sessions are other examples. Hope this helps,[URL="https://supportforums.cisco.com/message/974685#974685"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974686#974686"]Re: Multicast support for MPLS VPNS.[/URL][URL="https://supportforums.cisco.com/people/maher%40pd.jaring.my"]maher@pd.jaring.my[/URL]17.01.2005 06:23 Hi Hritter, Thanks for the info. Sorry to "hijeck" the thread. :) regards, maher[URL="https://supportforums.cisco.com/message/974686#974686"]Reply[/URL]

[/LIST][/LIST][/LIST][*] [URL="https://supportforums.cisco.com/message/974682#974682"]Re: Multicast support for MPLS VPNS.[/URL][URL="https://supportforums.cisco.com/people/q-coelho"]q-coelho[/URL]09.01.2005 22:04 Multicasting is support across an MPLS network unless you have a ATM cell based core using BPX/LSC set-up. Regards, Quinton[URL="https://supportforums.cisco.com/message/974682#974682"]Reply[/URL]

[*] [URL="https://supportforums.cisco.com/message/974683#974683"]Re: Multicast support for MPLS VPNS.[/URL][URL="https://supportforums.cisco.com/people/robert.hyde"]robert.hyde[/URL]13.01.2005 10:28Thomas, This is an interesting one. For a better explanation, instead of saying "multicast across vrf's" let's look at "intra-vrf multicast" and "inter-vrf multicast". To define those, take a look at the Network Diagram on the document that you referenced above. Intra-vrf multicast is simply multicast connectivity within the same vrf, between vrf YELLOW on R1 and vrf YELLOW on R5. This works nicely. ...[URL="https://supportforums.cisco.com/message/974683#974683"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974687#974687"]Re: Multicast support for MPLS VPNS.[/URL][URL="https://supportforums.cisco.com/people/amms68958%40yahoo.com"]amms68958@yahoo.com[/URL]17.01.2005 06:31 Hi Harold, Thanks for the url. Hi Robert, Thanks for the detailed explanation.[URL="https://supportforums.cisco.com/message/974687#974687"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974688#974688"]Re: Multicast support for MPLS VPNS.[/URL][URL="https://supportforums.cisco.com/people/sandjose"]sandjose[/URL]05.04.2005 23:52I have a Query in this region ,If someone could reply i would be thankful I am using a 3550cat with 12.1 EA image which is used as the PE router . The scenatio i would like to Implment is I have a vrf on which i place the multicast sources .i have a couple of other VRFs within the same PE where i need to receive the Multicast stream on these VRF from the Multicast VRF .But as per Roberts Comments .This wouldn't work since the MDT...[URL="https://supportforums.cisco.com/message/974688#974688"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974689#974689"]Re: Multicast support for MPLS VPNS.[/URL][URL="https://supportforums.cisco.com/people/barisal"]barisal[/URL]06.04.2005 00:24 Hi; As far as i have known, Multicast support for MPLS VPN is announced with 12.2T and 12.2S releases. Regards,[URL="https://supportforums.cisco.com/message/974689#974689"]Reply[/URL]

[/LIST][/LIST][/LIST][*][URL="https://supportforums.cisco.com/message/249990#249990"]More Replies[/URL][/LIST][*] [URL="https://supportforums.cisco.com/thread/2002914"]EoMPLSoGRE[/URL][URL="https://supportforums.cisco.com/people/madhaquer"]madhaquer[/URL]2 Replies01.02.2010 22:41 I'm moving this [url]https://supportforums.cisco.com/message/2016937#2016937[/url] discussion here because I feel I will get a quicker response. In a nutshell the setup is as below: ASR1004=={ GRE }==C7206 I need to run layer 2 services between the 2 without mpls support from the service provider. Unfortunatelly there is no specific detail on getting EoMPLSoGRE up and running. I have the GRE tunnel working and I have mpls forced to my loopbacks and the xconect configured on the 2 router interfaces. however the mpls forwarding table on the 7206 shows the outgoing interface is 'none' and I cannot pass any traffic across. 7206>sh mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 200 Untagged l2ckt(303) 0 none point2point On the ASR it looks fine: asr>sh mpls forwarding-table labels 201 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or VC or Tunnel Id Switched interface 201 No Label l2ckt(303) 0 Gi0/0/7 point2point Thanks [URL="https://supportforums.cisco.com/community/feeds/messages?thread=2002914"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/2002914"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/3011657#3011657"]Re: EoMPLSoGRE[/URL][URL="https://supportforums.cisco.com/people/giuslar"]giuslar[/URL]01.02.2010 14:05 Hello, have a look at this nice document [url]http://www.cisco.com/en/US/prod/collateral/routers/ps9343/Deploying_and_Configuring_MPLS_Virtual_Private_Networks_In_IP_Tunnel_Environments.pdf[/url] I'm afraid it is not supported on C7200. What IOS image is running on C7200 and what NPE model is present? Hope to help Giuseppe[URL="https://supportforums.cisco.com/message/3011657#3011657"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/3011841#3011841"]Re: EoMPLSoGRE[/URL][URL="https://supportforums.cisco.com/people/madhaquer"]madhaquer[/URL]01.02.2010 22:41 Thanks for the response. I'm running Version 12.4(11)T4 with a NPE-G1 processor. I will try out the example on the case study before i give up.[URL="https://supportforums.cisco.com/message/3011841#3011841"]Reply[/URL]

[/LIST][/LIST][*] [URL="https://supportforums.cisco.com/thread/248187"]Does MPLS VPN Support Multicast NLRI[/URL][URL="https://supportforums.cisco.com/people/darin.pesnell"]darin.pesnell[/URL]2 Replies20.03.2007 11:19 I have been looking into mVPN and have a question that I couldn't find addressed on CCO. Does Cisco's implementation of MPLS (mVPN) allow the CE Router to send Multicast NLRI (through mBGP) to the PE router so to influence ONLY the multicast RPF check? I have tried to configure this in the lab and it doesn't appear as though it is an option (ie: the address-family ipv4 vrf XXX multicast option doesn't exist). Any insight to this question would be great appreciated. Thank you, Darin Pesnell[URL="https://supportforums.cisco.com/community/feeds/messages?thread=248187"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/248187"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/966097#966097"]Re: Does MPLS VPN Support Multicast NLRI[/URL][URL="https://supportforums.cisco.com/people/drolemc"]drolemc[/URL]20.03.2007 11:09 MPLS VPNs supports multicast. Refer these doc for more info: [url=http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080242aa8.shtml]Multicast Support for MPLS VPNs Configuration Example [MPLS] - Cisco Systems[/url] [url=http://www.cisco.com/en/US/tech/tk828/technologies_tech_note09186a0080094821.shtml]Multicast Quick-Start Configuration Guide - Cisco Systems[/url] [URL="https://supportforums.cisco.com/message/966097#966097"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/966098#966098"]Re: Does MPLS VPN Support Multicast NLRI[/URL][URL="https://supportforums.cisco.com/people/darin.pesnell"]darin.pesnell[/URL]20.03.2007 11:19Hi, Thank you for the reply. Yes, I realize that MPLS VPNs support Multicast, but what I have not seen an answer on is whether you can send Multicast-NLRI inside of an MPLS VPN. In other words, can an mVPN be configured such that a dual-homed CE uses Multicast NLRI to only influence the RPF check but leave unicast routing as is? We can do this today with mBGP and Multicast NLRI but I can't seem to get this to...[URL="https://supportforums.cisco.com/message/966098#966098"]Reply[/URL]

[/LIST][/LIST][*] [URL="https://supportforums.cisco.com/thread/247499"]MPLS configuration example[/URL][URL="https://supportforums.cisco.com/people/stephtchoko"]stephtchoko[/URL]10 Replies16.04.2006 22:38 I 'm looking for a simple configuration of MPLS between 3 routers (or 2 routers). Somebody can help me ? Best regards.[URL="https://supportforums.cisco.com/community/feeds/messages?thread=247499"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/247499"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/962811#962811"]Re: MPLS configuration example[/URL][URL="https://supportforums.cisco.com/people/mounir.mohamed"]mounir.mohamed[/URL]27.10.2005 03:58Dear stephtchoko, MPLS is a great technologies it’s easy to take and running script from the internet and post it on your router then everything gone be working but it’s very nice to understand how it’s working because your life gone be under control (I mean you have to understand the technologies how it’s works to troubleshoot your network in any case) Here is a simple configuration to get mpls working with 2 routers...[URL="https://supportforums.cisco.com/message/962811#962811"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/962812#962812"]Re: MPLS configuration example[/URL][URL="https://supportforums.cisco.com/people/jbrunner%40mortgageit.com"]jbrunner@mortgageit.com[/URL]31.10.2005 09:19 i built my test mpls network using this page [url=http://www.informit.com/articles/article.asp?p=391649&seqNum=2&rl=1]InformIT: Troubleshooting Any Transport over MPLS Based VPNs > Configuring MPLS VPNs[/url] and 3 x 2811 routers (2 PE's and 1 P) and 2 x 2621 routers as the "CE" which dont run MPLS themselves...[URL="https://supportforums.cisco.com/message/962812#962812"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/962813#962813"]Re: MPLS configuration example[/URL][URL="https://supportforums.cisco.com/people/mounir.mohamed"]mounir.mohamed[/URL]31.10.2005 11:52 the document is good, but is everything working with you or you facing a problem?[URL="https://supportforums.cisco.com/message/962813#962813"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/962814#962814"]Re: MPLS configuration example[/URL][URL="https://supportforums.cisco.com/people/stephtchoko"]stephtchoko[/URL]02.11.2005 00:38 yes, ThanK.This is my first experience with this protocol (MPLS).Which type of routing protocol ( isis, ospf) do you think, it is more adapatable with mpls in isp network ? Best regards[URL="https://supportforums.cisco.com/message/962814#962814"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/962815#962815"]Re: MPLS configuration example[/URL][URL="https://supportforums.cisco.com/people/mounir.mohamed"]mounir.mohamed[/URL]02.11.2005 11:37 ISIS is recommended in service provider networks and it's more sclabel than OSPF[URL="https://supportforums.cisco.com/message/962815#962815"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/962816#962816"]Re: MPLS configuration example[/URL][URL="https://supportforums.cisco.com/people/stephtchoko"]stephtchoko[/URL]04.11.2005 00:00 please what is main reason isis is more scalable than ospf ? Best regards.[URL="https://supportforums.cisco.com/message/962816#962816"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/962817#962817"]Re: MPLS configuration example[/URL][URL="https://supportforums.cisco.com/people/mounir.mohamed"]mounir.mohamed[/URL]06.11.2005 02:23 Dear Steph, Kindly check the following URL [url=http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080093fcc.shtml]Configuring Basic MPLS Using IS-IS [MPLS] - Cisco Systems[/url] Best Regards, Mounir Mohamed[URL="https://supportforums.cisco.com/message/962817#962817"]Reply[/URL]

[/LIST][/LIST][/LIST][/LIST][/LIST][*] [URL="https://supportforums.cisco.com/message/962820#962820"]Re: MPLS configuration example[/URL][URL="https://supportforums.cisco.com/people/abdul1983"]abdul1983[/URL]16.04.2006 22:38 Hi H r u I am Abdul Khadeer from chennai . i had compeleted the ccna course but not certification .plz if do u have any dumps plz send it to me .so I am planing to give the exam [URL="https://supportforums.cisco.com/message/962820#962820"]Reply[/URL]

[/LIST][*] [URL="https://supportforums.cisco.com/message/962818#962818"]Re: MPLS configuration example[/URL][URL="https://supportforums.cisco.com/people/michaelhawkins"]michaelhawkins[/URL]06.11.2005 06:26 Here's a copy of the configuration that I had on my two lab PE routers that was testing multicast tunneling through mpls. You will need two CE routers for a total of four routers. It's not a perfect config (the traffic engineering is only half begun) but it will get you going. [B]Attachments:[/B]

[LIST][*][URL="https://supportforums.cisco.com/message/962818#962818"]PE1andPE2workingVPNMulticast.doc[/URL][/LIST]
[URL="https://supportforums.cisco.com/message/962818#962818"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/962819#962819"]Re: MPLS configuration example[/URL][URL="https://supportforums.cisco.com/people/jasrine47"]jasrine47[/URL]27.03.2006 00:20 Hi You may find some valuable infos here at [url=http://ciscorouterconfig.blogspot.com/]CISCO ROUTER CONFIGURATIONS[/url] jasrine47 [url=http://ciscorouterconfig.blogspot.com/]CISCO ROUTER CONFIGURATIONS[/url][URL="https://supportforums.cisco.com/message/962819#962819"]Reply[/URL]

[/LIST][*][URL="https://supportforums.cisco.com/message/247499#247499"]More Replies[/URL][/LIST][*] [URL="https://supportforums.cisco.com/thread/249863"]can mpls support multicast?[/URL][URL="https://supportforums.cisco.com/people/rachelhor%40yahoo.com.sg"]rachelhor@yahoo.com.sg[/URL]9 Replies22.09.2004 19:37 Hi, Can mpls support multicast packets? Meaning, can multicast packets be sent to destinations over mpls network? If so, how does it work? I read in this forum somewhere that someone mentioned mpls and multicast can co-eixt. What exactly does it mean? Thanx![URL="https://supportforums.cisco.com/community/feeds/messages?thread=249863"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/249863"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974135#974135"]Re: can mpls support multicast?[/URL][URL="https://supportforums.cisco.com/people/hritter"]hritter[/URL]20.09.2004 04:50 Multicast traffic can not currently be forwarded down an LSP. By co-exist we mean that you can have an SP core network running both MPLS an Multicast but they run independently from each other. Hope this helps, [URL="https://supportforums.cisco.com/message/974135#974135"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974137#974137"]Re: can mpls support multicast?[/URL][URL="https://supportforums.cisco.com/people/rachelhor%40yahoo.com.sg"]rachelhor@yahoo.com.sg[/URL]20.09.2004 20:00hi hritter and romccallum, I'm still confused I read book that says "In LAN environment, labeled packets carrying multicast layer 3 packets use ethertype value 8848 hex. These ethertype values can be used directly on Ethernet media" From the above sentence, does it mean that multicast packets still can be labelled and sent over mpls? Another question, where is this ethertype value contained? Is it contained inside...[URL="https://supportforums.cisco.com/message/974137#974137"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974138#974138"]Re: can mpls support multicast?[/URL][URL="https://supportforums.cisco.com/people/hritter"]hritter[/URL]21.09.2004 05:39 Provisions are there for multicast to be transported by MPLS. Unfortunately it is not supported yet. The ethertype value is part of the L2 header. The shim header is 32 bits long and comprises the following fields: Label value: 20 bits expirimental bits: 3 bits bottom of stack bit: one bit TTL: 8 bits Hope this helps,[URL="https://supportforums.cisco.com/message/974138#974138"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974139#974139"]Re: can mpls support multicast?[/URL][URL="https://supportforums.cisco.com/people/rachelhor%40yahoo.com.sg"]rachelhor@yahoo.com.sg[/URL]21.09.2004 20:00 oh i see! think i am clearer now so all those technical documents/notes about multicast by mpls from ietf and other companies etc found on web-site, are just theory? thanx a lot! :)[URL="https://supportforums.cisco.com/message/974139#974139"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974140#974140"]Re: can mpls support multicast?[/URL][URL="https://supportforums.cisco.com/people/hritter"]hritter[/URL]22.09.2004 05:40 I know thar there is work being done with IOS to support it. I don't know about other vendors implementation. As far as IETF is concerned, there is currently no RFC for mcast over MPLS. The only thing I'm aware of is a the following draft to support mcast over TE tunnels: [url]http://www.simpleweb.org/ietf/internetdrafts/complete/draft-raggarwa-mpls-p2mp-te-02.txt[/url] This draft is currently expired. Hope this helps,[URL="https://supportforums.cisco.com/message/974140#974140"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974141#974141"]Re: can mpls support multicast?[/URL][URL="https://supportforums.cisco.com/people/rachelhor%40yahoo.com.sg"]rachelhor@yahoo.com.sg[/URL]22.09.2004 08:21thank you very much I have one "last" question So, if I have a network of cisco routers with mpls configured (so this means mpls network right?), and my ingress edge LSR receives a multicast IP packet. How does my ingress edge LSR sent this multicast IP packet to its destinations over this network where all the routers have mpls enabled? Am I right to say that - this multicast IP packet will not be tagged - and this...[URL="https://supportforums.cisco.com/message/974141#974141"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974142#974142"]Re: can mpls support multicast?[/URL][URL="https://supportforums.cisco.com/people/hritter"]hritter[/URL]22.09.2004 13:00In the MPLS network you can either use native multicast or you could implement mVPN on the PE routers if you implement MPLS VPN. mVPN uses native multicast in the core to encapsulate the multicast messages coming from a CE router and to forward these messages to PEs containing the same VRF. For more information on mVPN, see the following link: ...[URL="https://supportforums.cisco.com/message/974142#974142"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/974143#974143"]Re: can mpls support multicast?[/URL][URL="https://supportforums.cisco.com/people/rachelhor%40yahoo.com.sg"]rachelhor@yahoo.com.sg[/URL]22.09.2004 19:37 thanx a lot! :-)[URL="https://supportforums.cisco.com/message/974143#974143"]Reply[/URL]

[/LIST][/LIST][/LIST][/LIST][/LIST][/LIST][/LIST][*] [URL="https://supportforums.cisco.com/message/974136#974136"]Re: can mpls support multicast?[/URL][URL="https://supportforums.cisco.com/people/romccallum"]romccallum[/URL]20.09.2004 07:32 In other words Multicast within a VPN works absolutely fine. It just doesnt get label switched across the MPLS network and is just Native IP (multicast). [URL="https://supportforums.cisco.com/message/974136#974136"]Reply[/URL]

[*][URL="https://supportforums.cisco.com/message/249863#249863"]More Replies[/URL][/LIST][*] [URL="https://supportforums.cisco.com/thread/248006"]I want a configuration example for mpls...[/URL][URL="https://supportforums.cisco.com/people/guominquan"]guominquan[/URL]2 Replies01.11.2006 22:15 hello,everyone I am learning mpls vpn ,I am also seeking a new job that is about telecommunication. I want a complete comfiguration example for mpls vpn using about eight routers.The mpls domain may be divided into two AS ,one runs ospf routing protocol that includes three routers and the other runs is-is routing protocol that also includes three routers .BGP run between the AS.the last two routrs are ces that can perform vpn function located in seperate sites. I have no experiment devices,but I want the complete configuration about mpls bgp vpn and the topology.any one can hepl me.thank you. a friend from china. you can send me word doc to my email: my email: [email]gmqit@163.com[/email] BEST WISHES![URL="https://supportforums.cisco.com/community/feeds/messages?thread=248006"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/248006"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/965310#965310"]Re: I want a configuration example for...[/URL][URL="https://supportforums.cisco.com/people/swaroop.potdar"]swaroop.potdar[/URL]01.11.2006 01:05IF you are learning MPLS & VPN's then believe me if anyone sends you a ready config, it wont be of much help. Instead you can spread your learning like below, even though you dont have any devices, 1) Configuring routing using OSPF & ISIS. 2) Enabling MPLS on all PE devices with LDP. 3) COnfiguring MPBGP. 4) COnfiguring VRF's. If you have a good hold on the above topics theoritically,...[URL="https://supportforums.cisco.com/message/965310#965310"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/965311#965311"]Re: I want a configuration example for...[/URL][URL="https://supportforums.cisco.com/people/guominquan"]guominquan[/URL]01.11.2006 22:15 I will follow your instruction to further learn MPLS & VPN. Thank you Swaroop. Minquan[URL="https://supportforums.cisco.com/message/965311#965311"]Reply[/URL]

[/LIST][/LIST][*] [URL="https://supportforums.cisco.com/thread/2001208"]QPPB for MPLS VPNs[/URL][URL="https://supportforums.cisco.com/people/gauravprakash"]gauravprakash[/URL]10 Replies03.02.2010 04:33 Hi, I have a MPLS NNI Type C ( INter AS Option 10C) for my inter-as L3VPNs. Now I want to police traffic per VPN or per customer, so that one VPN does not send too much traffic out of one ISPcloud over the NNI link, affecting other VPN traffic over the NNI link. Can I do this with QPPB ? I think this is possible in IPv4 environment or if the requirement is exp based traffic policing, but now the case above. PLz help Thx, Gaurav Prakash[URL="https://supportforums.cisco.com/community/feeds/messages?thread=2001208"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/2001208"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/3005151#3005151"]Re: QPPB for MPLS VPNs[/URL][URL="https://supportforums.cisco.com/people/jcozzupoli"]jcozzupoli[/URL]20.01.2010 04:01Hi Gaurav, I'd say its possible, look at this config guide: [url=http://www.cisco.com/en/US/docs/ios/iproute/configuration/guide/irp_ip_prot_indep_ps6017_TSD_Products_Configuration_Guide_Chapter.html#wp1059912]Cisco IOS IP Routing Protocols Configuration Guide, Release 12.2SX - Configuring IP Routing Protocol-Independent Features [Cisco IOS Software Releases 12.2 SX] - Cisco Systems[/url] Now to do it in an MPLS VPN environment look at the topology below: CE1----PE1---------PE2----CE2 Now to implement QPPB on traffic between the 2 CEs, the following steps could be done: 1) PE1 is...[URL="https://supportforums.cisco.com/message/3005151#3005151"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/3005599#3005599"]Re: QPPB for MPLS VPNs[/URL][URL="https://supportforums.cisco.com/people/jcozzupoli"]jcozzupoli[/URL]20.01.2010 16:18Hi again, I have tested my theory and it works. The only pre-requisit is that BGP is used as the PE-CE protocol. I have attached the configs from my lab based on the same topology as my previous post. To explain what I did: 1. On PE2 I configured an inbound route-map under the MP-BGP VPNV4 AF to set all prefixes with BGP Community of 250:1 2. On PE2 I then configured a table-map under the ipv4 vrf CUST_A AF to match a...[B]Attachments:[/B]

[LIST][*][URL="https://supportforums.cisco.com/message/3005599#3005599"]PE1.txt.zip[/URL][*][URL="https://supportforums.cisco.com/message/3005599#3005599"]CE1.txt.zip[/URL][*][URL="https://supportforums.cisco.com/message/3005599#3005599"]CE2.txt.zip[/URL][*][URL="https://supportforums.cisco.com/message/3005599#3005599"]PE2.txt.zip[/URL][/LIST]
[URL="https://supportforums.cisco.com/message/3005599#3005599"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/3006349#3006349"]Re: QPPB for MPLS VPNs[/URL][URL="https://supportforums.cisco.com/people/jcozzupoli"]jcozzupoli[/URL]21.01.2010 18:16 Guys. I must correct myself. You can use any IGP as your PE-CE protocol. I have updated my configs to show this. It all works the same. Silly me!! Cheers, Joe.[B]Attachments:[/B]

[LIST][*][URL="https://supportforums.cisco.com/message/3006349#3006349"]CE1.txt.zip[/URL][*][URL="https://supportforums.cisco.com/message/3006349#3006349"]CE2.txt.zip[/URL][*][URL="https://supportforums.cisco.com/message/3006349#3006349"]PE1.txt.zip[/URL][*][URL="https://supportforums.cisco.com/message/3006349#3006349"]PE2.txt.zip[/URL][/LIST]
[URL="https://supportforums.cisco.com/message/3006349#3006349"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/3006665#3006665"]Re: QPPB for MPLS VPNs[/URL][URL="https://supportforums.cisco.com/people/giuslar"]giuslar[/URL]22.01.2010 10:35Hello Joe, good job. Now, Gaurav was asking about an inter-AS VPN scenario and BGP community is not transitive so if BGP community is set on PE and not on CE it should be able to reach other provider in other AS. OP speaks of option C. in AF vpvnv4 I would expect send community both and not only extended Reviewing your configuration everything is done on PE2 itself, this explains why you don't need use send-com both ...[URL="https://supportforums.cisco.com/message/3006665#3006665"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/3006810#3006810"]Re: QPPB for MPLS VPNs[/URL][URL="https://supportforums.cisco.com/people/jcozzupoli"]jcozzupoli[/URL]22.01.2010 16:22Hello Giuseppe, Yeah if you look at my second bunch of configs, I am setting a community value on PE1 too (As I am redistributing OSPF into MP-BGP I have a route-map to set community on the prefixes), so I can be more controlling of what can be done on PE2 as well (i'm now trying to implement CBQoS instead of CTCAR). I did use community "both" as if left with default "extended" the community would not be sent to PE2. I will try...[URL="https://supportforums.cisco.com/message/3006810#3006810"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/3006787#3006787"]Re: QPPB for MPLS VPNs[/URL][URL="https://supportforums.cisco.com/people/jcozzupoli"]jcozzupoli[/URL]22.01.2010 20:11 Hi again, Yes I just ran an Inter-AS solution for QPPB for MPLS VPNs, worked fine. I tested with the Option A & B method (well my PE's are also acting as ASBRs, but I am VPNv4 eBGP peering), theoreticaly the other methods should work too. Anyways. So my final answer on this is yes its possible to implement QPPB for MPLS-VPNs to control the rate of traffic going between different SPs. HTH Regards, Joe.[URL="https://supportforums.cisco.com/message/3006787#3006787"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/3007036#3007036"]Re: QPPB for MPLS VPNs[/URL][URL="https://supportforums.cisco.com/people/giuslar"]giuslar[/URL]23.01.2010 13:51 Hello Joe, very good. I had seen you were to near to test the whole solution so I tried to stimulate this last step. Have a nice weekend Best Regards Giuseppe[URL="https://supportforums.cisco.com/message/3007036#3007036"]Reply[/URL]

[*] [URL="https://supportforums.cisco.com/message/3007382#3007382"]Re: QPPB for MPLS VPNs[/URL][URL="https://supportforums.cisco.com/people/gauravprakash"]gauravprakash[/URL]25.01.2010 03:43 Hi, Thanks for all the effort. So we can do CTQoS & CTCAR over Inter-AS type B ( also A) NNI link for each of the VPN flowing over it separtely by using the RT. I think we cannot do this for Type C , as VPN routes dont stay locally in ASBR where the binding bgp parameter and traffic policing is done.. Thx again, Gaurav Prakash[URL="https://supportforums.cisco.com/message/3007382#3007382"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/3008553#3008553"]Re: QPPB for MPLS VPNs[/URL][URL="https://supportforums.cisco.com/people/jcozzupoli"]jcozzupoli[/URL]26.01.2010 14:48 Hi again, Actually Option C is not a problem either! I can provide the working configurations if you like? Or I can add them to the Documentation section for everyone to access! Regards, Joe Cozzupoli.[URL="https://supportforums.cisco.com/message/3008553#3008553"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/3012649#3012649"]Re: QPPB for MPLS VPNs[/URL][URL="https://supportforums.cisco.com/people/gauravprakash"]gauravprakash[/URL]03.02.2010 04:33 Yes, plz let share it, so that other can know it too Thx very much for all your support.. rgds, Gaurav[URL="https://supportforums.cisco.com/message/3012649#3012649"]Reply[/URL]

[/LIST][/LIST][/LIST][/LIST][/LIST][/LIST][/LIST][/LIST][*][URL="https://supportforums.cisco.com/message/2001208#2001208"]More Replies[/URL][/LIST][*] [URL="https://supportforums.cisco.com/thread/44789"]"NAT Integration with MPLS VPNs"...[/URL][URL="https://supportforums.cisco.com/people/nishiguro"]nishiguro[/URL]3 Replies23.02.2003 19:15 My customer is building the network which consisted of Cisco7200 with NPE-G1. Since the "NAT Integration with MPLS VPNs" function is needed in the network, it is required for there to be support by IOS 12.2T. However, NPE-G1 does not operate in 12.2T. It seems that the function is operating correctly when I verified by NPE-G1+12.2(15)B. Anyone know when "NAT Integration with MPLS VPNs" function will be supported in the IOS release12.2B? Thanks,[URL="https://supportforums.cisco.com/community/feeds/messages?thread=44789"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/44789"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/157698#157698"]Re: "NAT Integration with MPLS VPNs"...[/URL][URL="https://supportforums.cisco.com/people/thisisshanky"]thisisshanky[/URL]18.02.2003 10:12 NPE G1 operates correctly with 12.1(14)E, 12.2(4)BW, 12.2(14)S, 12.2(15)B But the feature you ask for are supported only in the following trains. 12.2(13)ZE 12.2(13)ZD 12.2(13)T 12.2(13)T1 [URL="https://supportforums.cisco.com/message/157698#157698"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/157699#157699"]Re: "NAT Integration with MPLS VPNs"...[/URL][URL="https://supportforums.cisco.com/people/nishiguro"]nishiguro[/URL]18.02.2003 13:08 Thank you for your quick responce! I understand that it is impossible to support this feature by Cisco 7200 w/NPE-G1. I will suggest my customer to use the feature by NPE-400 for their network. Does anyone have an experience using this feature? I am concerned about NPE-400 can have a good performance when this feature is configured on the 7200... Thanks,[URL="https://supportforums.cisco.com/message/157699#157699"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/157700#157700"]Re: "NAT Integration with MPLS VPNs"...[/URL][URL="https://supportforums.cisco.com/people/nishiguro"]nishiguro[/URL]23.02.2003 19:15 Anyone know if/when the "NAT Integration with MPLS VPNs" feature will be supported in the 12.1E, 12.2BW, 12.2S or 12.2B IOS release train? My customer MUST use NPE-G1... :'-( Thanks,[URL="https://supportforums.cisco.com/message/157700#157700"]Reply[/URL]

[/LIST][/LIST][/LIST][*] [URL="https://supportforums.cisco.com/thread/1002463"]ASM SSM multicast in MPLS domain[/URL][URL="https://supportforums.cisco.com/people/gautamanish"]gautamanish[/URL]2 Replies29.12.2009 22:01 in our mpls network we have ssm deployed for multicast, but for some old reason there is a static RP also defined on each box and as per my understanding it is not required incase of SSM. we are planning to remove the RP entry but after removing it from some of the boxes some of the multicast tunnels went down. Can someone provide some info if ASM and SSM both are enabled, is there a preference which would be used or any other problems that are due to arise because of both models deployed.[URL="https://supportforums.cisco.com/community/feeds/messages?thread=1002463"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/1002463"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/2010720#2010720"]Re: ASM SSM multicast in MPLS domain[/URL][URL="https://supportforums.cisco.com/people/giuslar"]giuslar[/URL]29.12.2009 10:10 Hello Gautam, usually SSM is deployed for a subset of multicast address space. you need to verify if there are multicast groups that are out of this SSM subset, for those groups to run in PIM SM an RP is required. Hope to help Giuseppe[URL="https://supportforums.cisco.com/message/2010720#2010720"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/2011040#2011040"]Re: ASM SSM multicast in MPLS domain[/URL][URL="https://supportforums.cisco.com/people/gautamanish"]gautamanish[/URL]29.12.2009 22:01 thanks mate, i understand that SSM is used as subset of multicast addresses but if i have defined a SSM range in my network and also defined a RP for the same range, what is going to be the affect[URL="https://supportforums.cisco.com/message/2011040#2011040"]Reply[/URL]

[/LIST][/LIST][*] [URL="https://supportforums.cisco.com/thread/247890"]multicast over MPLS-core that not...[/URL][URL="https://supportforums.cisco.com/people/tonywen"]tonywen[/URL]2 Replies13.08.2006 16:17 Hi Team I have a question re multicast over MPLS core.The problem is the MPLS core doesn't support multicast but we need to forward multicast anyway. The MPLS core doesn't support multicast.A customer has 15+ sites and wants to use MULTICAST between the sites. I thought about GRE tunnel but it will require full mesh tunnels between all the routers, will it not? so for 15 sites only there will be 14 tunnel config and in total it will be too many. and if they add new site it will be a lot of work. Can we implement hub-and spoke like architecture for multicast and create GRE tunnels from the CPEs to HQ CPE only without going full mesh? is there any limit for the number of GRE tunnels? what impact will it have on the router performance. is PIM capable of working over GRE tunnel? Thank you very much team! Regards Tony [URL="https://supportforums.cisco.com/community/feeds/messages?thread=247890"]Subscribe [/URL][URL="https://supportforums.cisco.com/thread/247890"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/964665#964665"]Re: multicast over MPLS-core that not...[/URL][URL="https://supportforums.cisco.com/people/mheusinger"]mheusinger[/URL]10.08.2006 23:54Hi, Multicast can work over GRE and this seems to be the easiest solution in your case. Make sure your unicast routing is using GRE as well then, otherwise RPF check might fail and no multicast packets will be sent. You can use a hub-and-spoke like topology but because of RPF check you should be aware of the impacts on unicast routing, delay, bandwidth requirements and the like. Another option to look into might be dynamic...[URL="https://supportforums.cisco.com/message/964665#964665"]Reply[/URL]

[LIST][*] [URL="https://supportforums.cisco.com/message/964666#964666"]Re: multicast over MPLS-core that not...[/URL][URL="https://supportforums.cisco.com/people/tonywen"]tonywen[/URL]13.08.2006 16:17 Hi Martin Thank you so much!You rocks! Again much appreciate your help. Tony[URL="https://supportforums.cisco.com/message/964666#964666"]Reply[/URL]

[/LIST][/LIST][/LIST]
[URL="https://supportforums.cisco.com/community/feeds/search?peopleEnabled=false&dateRange=all&rankBy=29&q=Multicast%20%7C%7C%20Support%20%7C%7C%20for%20%7C%7C%20MPLS%20%7C%7C%20VPNs%20%7C%7C%20Configuration%20%7C%7C%20Example"]Subscribe [/URL][URL="https://supportforums.cisco.com/login.jspa?redirectURL=/choose-container%21input.jspa?contentType=1"]Start A New Discussion[/URL]

[B] Related Information [/B]

[LIST][*] [B] [URL="http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftmltvpn.html"]MPLS VPN New Feature Documentation[/URL] [/B][*] [B] [URL="http://www.cisco.com/en/US/customer/tech/tk436/tk428/tsd_technology_support_protocol_home.html"]MPLS Support Page[/URL] [/B][*] [B] [URL="http://www.cisco.com/en/US/customer/tech/tk828/tk363/tsd_technology_support_sub-protocol_home.html"]IP Multicast Support Page[/URL] [/B][*] [B] [URL="http://www.cisco.com/cisco/web/support/index.html"]Technical Support - Cisco Systems[/URL] [/B][/LIST]

[SIZE=-1] [/SIZE]
Updated: Aug 10, 2005
[/LEFT]
2010-02-11, 10:45 PM
patris1

[LEFT][SIZE=3][B]MPLS Command Guide

[/B][/SIZE][CODE]http://www.cisco.com/en/US/docs/ios/12_1/switch/command/reference/xrdscmd9.html[/CODE]
[/LEFT]