نمایش نتایج: از شماره 1 تا 14 از مجموع 14

موضوع: MPLS Configuration Examples and TechNotes

  
  1. #1
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272

    MPLS Configuration Examples and TechNotes

    کد:
    http://www.cisco.com/en/US/tech/tk436/tk428/tech_configuration_examples_list.html
    Configuring a Basic MPLS VPN


    Document ID: 13733


    Contents
    Introduction
    Prerequisites
    Requirements
    Components Used
    Related Products
    Conventions
    Configure
    Network Diagram
    Configuration Procedures
    Configurations
    Verify
    Troubleshoot
    Related Information
    Introduction

    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:


    Prerequisites

    Requirements

    There are no specific requirements for this document.
    Components Used

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

    • 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.

    C and CE Routers

    • You can use any router that can exchange routing information with its PE router.

    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.
    Related Products

    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 Software Advisor (registered customers only) . 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.
    Conventions

    Refer to Cisco Technical Tips Conventions for more information on document conventions.
    The letters below represent the different types of routers and switches used.

    • P—Provider's core router.
    • PE—Provider's edge router.
    • CE—Customer's edge router.
    • C—Customer's router.

    This diagram shows a typical configuration illustrating the conventions outlined above.

    Configure

    In this section, you are presented with the information to configure the features described in this document.
    Note: Use the Command Lookup Tool (registered customers only) to find more information on the commands used in this document.
    Network Diagram

    This document uses this network setup:

    Configuration Procedures

    Refer to MPLS Virtual Private Networks for more information.
    Enabling ip cef

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

    1. Create one VRF for each VPN connected using the ip vrf <VPN routing/forwarding instance name> command.
      When doing this:
      • 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.
        rd <VPN route distinguisher>
      • Set up the import and export properties for the MP-BGP extended communities. These are used for filtering the import and export process.
        route-target [export|import|both] <target VPN extended community>

    2. Configure the forwarding details for the respective interfaces using the ip vrf forwarding <VPN routing/forwarding instance name> command and remember to set up the IP address after doing this.
    3. 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 MPLS over ATM Support page.

    Configuring MP-BGP

    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.

    1. Declare the different neighbors.
    2. Enter the address-family ipv4 vrf <VPN routing/forwarding instance name> command for each VPN present at this PE router.
      Carry out one or more of the following steps, as necessary:
      • Redistribute the static routing, RIP, or OSPF information.
      • Redistribute connected routing information.
      • Activate BGP neighboring with the CE routers.

    3. Enter the address-family vpnv4 mode, and complete the following steps:
      • Activate the neighbors.
      • Specify that extended community must be used. This is mandatory.


    Configurations

    This document uses these configurations:


    Pescara
    Current configuration:
    !
    version 12.2
    !
    hostname Pescara
    !
    ip cef
    !


    !--- Customer A commands.

    ip vrf Customer_A

    !--- Enables the VPN routing and forwarding (VRF) routing table.
    !--- This command can be used in global or
    !--- router configuration mode.


    rd 100:110

    !--- Route distinguisher creates routing and forwarding
    !--- tables for a VRF.


    route-target export 100:1000

    !--- Creates lists of import and export route-target extended
    !--- communities for the specified VRF.


    route-target import 100:1000
    !


    !--- Customer B commands.

    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


    !--- Customer A commands.

    interface Loopback101
    ip vrf forwarding Customer_A

    !--- Associates a VRF instance with an interface or subinterface.

    ip address 200.0.4.1 255.255.255.0

    !--- Loopback101 and 102 use the same IP address, 200.0.4.1.
    !--- This is allowed because they belong to two
    !--- different customers' VRFs.


    no ip directed-broadcast
    !


    !--- Customer B commands.

    interface Loopback102
    ip vrf forwarding Customer_B
    ip address 200.0.4.1 255.255.255.0

    !--- Loopback101 and 102 use the same IP address, 200.0.4.1.
    !--- This is allowed because they belong to two
    !--- different customers' VRFs.


    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

    !--- Enables logging of BGP neighbor resets.

    neighbor 10.10.10.6 remote-as 100

    !--- Adds an entry to the BGP or multiprotocol BGP neighbor table.

    neighbor 10.10.10.6 update-source Loopback0

    !--- Enables BGP sessions to use a specific operational
    !--- interface for TCP connections.


    !


    !--- Customer A and B commands.

    address-family vpnv4

    !--- To enter address family configuration mode
    !--- for configuring routing sessions, such as BGP,
    !--- that use standard VPN version 4 address prefixes.


    neighbor 10.10.10.6 activate
    neighbor 10.10.10.6 send-community both

    !--- Sends the community attribute to a BGP neighbor.

    exit-address-family
    !


    !--- Customer B commands.

    address-family ipv4 vrf Customer_B

    !--- To enter address family configuration mode
    !--- for configuring routing sessions, such as BGP,
    !--- that use standard VPN version 4 address prefixes.


    redistribute connected
    no auto-summary
    no synchronization
    exit-address-family
    !


    !--- Customer A commands.

    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
    !


    !--- Customer A commands.

    ip vrf Customer_A
    rd 100:110
    route-target export 100:1000
    route-target import 100:1000
    !


    !--- Customer B commands.

    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


    !--- Customer A commands.

    interface Loopback101
    ip vrf forwarding Customer_A
    ip address 200.0.6.1 255.255.255.0
    !


    !--- Customer B commands.

    interface Loopback102
    ip vrf forwarding Customer_B
    ip address 200.0.6.1 255.255.255.0
    !


    !--- Customer A commands.

    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
    !


    !--- Customer B commands.

    address-family ipv4 vrf Customer_B
    redistribute connected
    no auto-summary
    no synchronization
    exit-address-family
    !


    !--- Customer A commands.

    address-family ipv4 vrf Customer_A
    redistribute connected
    no auto-summary
    no synchronization
    exit-address-family
    !


    !--- Customer A and B commands.

    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
    Verify

    This section provides information you can use to confirm your configuration is working properly.
    The Output Interpreter Tool (registered customers only) (OIT) supports certain show commands. Use the OIT to view an analysis of show command output.

    • show ip vrf—Verifies that the correct VRF exists.
    • show ip vrf interfaces—Verifies the activated interfaces.
    • show ip route vrf Customer_A—Verifies the routing information on the PE routers.
    • traceroute vrf Customer_A 200.0.6.1—Verifies the routing information on the PE routers.
    • show ip bgp vpnv4 tag—Verifies the BGP.
    • show ip cef vrf Customer_A 200.0.6.1 detail—Verifies the routing information on the PE routers.

    More commands are detailed in the MPLS VPN Solution Troubleshooting Guide.
    The following is sample command output of the show ip vrf command.
    Pescara#show ip vrf
    Name Default RD Interfaces
    Customer_A 100:110 Loopback101
    Customer_B 100:120 Loopback102
    The following is sample command output of the show ip vrf interfaces command.
    Pesaro#show ip vrf interfaces
    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
    The following show ip route vrf 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.
    Pescara#show ip route vrf Customer_A
    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#show ip route vrf Customer_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
    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 mpls ip ttl ...).
    Pescara#traceroute vrf Customer_A 200.0.6.1

    Type escape sequence to abort.
    Tracing the route to 200.0.6.1

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

    There is currently no specific troubleshooting information available for this configuration.
    Related Information






    Updated: Nov 16, 2007




    موضوعات مشابه:

  2. #2
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    Configuring Basic MPLS Using IS-IS


    Document ID: 13735


    Contents

    Introduction
    Prerequisites
    Requirements
    Components Used
    Background Theory
    Conventions
    Configure
    Network Diagram
    Configurations
    Verify
    Sample Output
    Troubleshoot
    Related Information
    Introduction

    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 MPLS Support Page).
    Prerequisites

    Requirements

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

    • To implement MPLS, you need a Cisco 2600 router or later.
    • Select the required Cisco IOS with MPLS using the Software Advisor (registered customers only) .
    • 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.

    Components Used

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

    • Cisco 3640, Cisco 3660, Cisco 4500, and Cisco 2610 Routers
    • Cisco IOS® version 12.2(6h) is running on all the routers

    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.
    Background Theory

    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.

    • 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.

    The LSR uses the following forwarding mechanism.

    • 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.

    The following diagram illustrates this network setup.

    Conventions

    For more information on document conventions, see the Cisco Technical Tips Conventions.
    Configure

    In this section, you are presented with the information to configure the features described in this document.
    Note: To find additional information on the commands used in this document, use the Command Lookup Tool (registered customers only) .
    Network Diagram

    This document uses this network setup:

    Configurations

    This document uses these configurations:


    Quick Configuration Guide

    Complete these steps to configure MPLS:

    1. Set up your network as usual (MPLS needs a standard IP connection in order to establish forwarding bases).
    2. Ensure that the routing protocol (OSPF or IS-IS) is working correctly. These commands are shown in italics in the configurations in this section.
    3. Use the ip cef command (for better performances, use the ip cef distributed command when available) in the general configuration mode (shown in bold in the configurations in this section) to enable.
    4. Use the mpls ip command (or the tag-switching ip 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.
      Note: The LSRs must have (up) Loopback interfaces with an address mask of 32 bits.

    Pomerol
    Current configuration:
    !
    version 12.2
    !
    hostname Pomerol
    !
    ip cef

    !--- Enables Cisco Express Forwarding globally.

    !
    interface Loopback0
    ip address 10.10.10.3 255.255.255.255
    ip router isis

    !--- Assigns an IP address to interface loopback0
    !--- and enables IS-IS for IP on the interface.


    !
    interface Serial0/0
    encapsulation frame-relay
    !
    interface Serial0/0.1 point-to-point
    ip address 10.1.1.6 255.255.255.252
    ip router isis
    tag-switching ip

    !--- Enables dynamic Label Switching of
    !--- IPv4 packets on an interface.


    frame-relay interface-dlci 301
    !
    interface Serial0/0.2 point-to-point
    ip address 10.1.1.9 255.255.255.252
    ip router isis
    tag-switching ip
    frame-relay interface-dlci 303
    !
    interface Serial0/0.3 point-to-point
    ip address 10.1.1.21 255.255.255.252
    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
    !
    interface Serial0/0.1 point-to-point
    ip address 10.1.1.2 255.255.255.252
    ip router isis
    tag-switching ip
    frame-relay interface-dlci 201
    !
    interface Serial0/0.2 point-to-point
    ip address 10.1.1.10 255.255.255.252
    ip router isis
    tag-switching ip
    frame-relay interface-dlci 203
    !
    router isis
    redistribute static ip
    passive-interface Loopback0
    net 49.0001.0000.0000.0002.00
    is-type level-1


    !--- 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.


    !
    ip classless
    !
    end

    Pauillac
    Current configuration : 2366 bytes
    !
    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
    !
    interface Serial0/0.1 point-to-point
    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
    ip address 10.1.1.5 255.255.255.252
    ip access-group 150 out
    ip router isis
    tag-switching ip
    frame-relay interface-dlci 103
    !
    interface Serial0/0.3 point-to-point
    bandwidth 512
    ip address 10.1.1.13 255.255.255.252
    ip router isis
    tag-switching ip
    frame-relay interface-dlci 104
    !
    interface Serial0/0.4 point-to-point
    ip address 10.1.1.17 255.255.255.252
    ip router isis
    tag-switching ip
    frame-relay interface-dlci 105
    !
    !
    router isis
    net 49.0001.0000.0000.0001.00
    is-type level-1

    !
    ip classless
    !
    end

    Verify

    This section provides information you can use to confirm your configuration is working properly.
    Certain show commands are supported by the Output Interpreter Tool (registered customers only) , which allows you to view an analysis of show command output.

    • show tag-switching tdp neighbor
    • show tag-switching tdp bindings
    • show tag-switching forwarding-table
    • show tag-switching forwarding-table a.b.c.d detail
    • traceroute a.b.c.d

    An exhaustive list of commands is included in the MPLS Command Reference. Other sample show commands are described in Configuring Basic MPLS Using OSPF.
    Sample Output

    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 show tag-switching tdp * command to verify the state of TDP. You can see neighbors using the show tag-switching tdp neighbor command.
    Pulligny# show tag-switching tdp discovery
    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

    !--- Ensure you are able to ping this IP address
    !--- If not, check whether a route exists in the routing table

    Pulligny# show tag-switching tdp neighbor
    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
    You can use the show tag-switching tdp bindings command to view the established bindings between labels and routes.
    Pulligny# show tag-switching tdp bindings
    (...)
    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
    (...)
    You can use the show tag-switching forwarding-table command to see which bindings are used to build the LFIB.
    Pulligny# show tag-switching forwarding-table
    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
    You can use the show tag-switching forwarding-table 10.10.10.4 detail command to view the details of a given destination.
    Pulligny# show tag-switching forwarding-table 10.10.10.4 detail
    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
    You can also use the traceroute command, if the network does IP TTL propagation, to view the hops. Refer to Multiprotocol Label Switching on Cisco Routers for more information on the mpls ip ttl propagate command.
    Pesaro# traceroute 10.10.10.4

    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
    Note: Exp 0 appears in the output if the experimental field is used for Quality of Service (QoS).
    Troubleshoot

    There is currently no specific troubleshooting information available for this configuration.
    Related Information






    Updated: Nov 16, 2007





  3. #3
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    Configuring Basic MPLS Using OSPF


    Document ID: 13736


    Contents

    Introduction
    Prerequisites
    Requirements
    Components Used
    Conventions
    Mechanism
    Configure
    Network Diagram
    Quick Configuration Guide
    Configurations
    Verify
    Troubleshoot
    Related Information
    Introduction

    This document shows how to configure a basic Multiprotocol Label Switching (MPLS) network. Refer to Configuration Examples and TechNotes on the MPLS Support Page for more information on how to configure advanced topics such as VPN or Traffic Engineering (TE).
    Prerequisites

    Requirements

    Cisco recommends that you are familiar with the basic operation of MPLS. Refer to Multiprotocol Label Switching Overview for an overview of MPLS.
    Components Used

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

    • Cisco IOS® Software Releases 12.2(28)
    • Cisco 3600 routers

    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.
    Conventions

    Refer to Cisco Technical Tips Conventions for more information on document conventions.
    Mechanism

    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:

    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.
    2. 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.

    The LSR uses this forwarding mechanism:

    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.
    2. 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.
    3. 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.

    This diagram illustrates this network setup:

    Configure

    In this section, you are presented with the information to configure the features described in this document.
    Note: In order fo find additional information on the commands used in this document, use the Command Lookup Tool (registered customers only) .
    Network Diagram

    This document uses this network setup:

    Quick Configuration Guide

    Use this procedure as a quick configuration guide.

    1. Set up your network as usual. MPLS needs a standard IP connection in order to establish forwarding bases.
    2. Ensure that the routing protocol (OSPF or IS-IS) works correctly. These commands are italicized in the configurations in the next section.
    3. Enable ip cef, for better performances use ip cef distributed when available, in the general configuration mode. This is shown in bold in the configurations in the next section.
    4. Enable mpls ip, or tag-switching ip 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 mpls ip command is used, the show running output can still show the command as tag-switching ip in some Cisco IOS software releases, as shown in the configurations in the next section.
      Note: 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.

    Configurations

    This document uses these configurations:


    Pomerol
    !
    version 12.2

    !
    hostname Pomerol
    !
    ip subnet-zero
    !
    ip cef
    !
    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
    tag-switching ip
    !
    interface Serial3/0
    ip address 10.1.1.6 255.255.255.252
    tag-switching ip
    !
    interface Serial4/0
    ip address 10.1.1.9 255.255.255.252
    tag-switching ip
    !
    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
    !
    ip cef
    !
    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
    tag-switching ip
    !
    interface Serial3/0
    ip address 10.1.1.10 255.255.255.252
    tag-switching ip
    !
    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
    !
    ip cef
    !
    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
    tag-switching ip
    !
    interface Serial3/0
    ip address 10.1.1.17 255.255.255.252
    tag-switching ip
    !
    interface Serial4/0
    ip address 10.1.1.1 255.255.255.252
    tag-switching ip
    !
    interface Serial5/0
    ip address 10.1.1.5 255.255.255.252
    tag-switching ip
    !
    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
    !
    ip cef
    !
    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
    tag-switching ip
    !
    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
    !
    ip cef
    !
    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
    tag-switching ip
    !
    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
    !
    ip cef
    !
    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
    tag-switching ip
    !
    router ospf 10
    log-adjacency-changes
    network 10.0.0.0 0.255.255.255 area 9
    !
    ip classless
    !
    end
    Verify

    This section provides information you can use to confirm your configuration works properly.
    Commands used in the Configuring Basic MPLS Using IS-IS sample configuration are also applicable.
    In order to illustrate this sample configuration, look at a particular destination, for example 10.10.10.4, on the Pomerol LSR.
    Certain show commands are supported by the Output Interpreter Tool (registered customers only) , which allows you to view an analysis of show command output.

    • show ip route —Used to check the IP route for this destination in the IP routing table:
      Pomerol#show ip route 10.10.10.4
      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 Serial3/0
      Route metric is 129, traffic share count is 1
    • show mpls forwarding-table —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.
      Pomerol#show mpls forwarding-table
      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
      18 21 10.10.10.4/32 0 Se3/0 point2point
      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
    • show mpls forwarding-table detail —Used to see MPLS forwarding table details:
      Pomerol#show mpls forwarding-table 10.10.10.4 32 detail
      Local Outgoing Prefix Bytes tag Outgoing Next Hop
      tag tag or VC or Tunnel Id switched interface
      18 21 10.10.10.4/32 0 Se3/0 point2point
      MAC/Encaps=4/8, MRU=1500, Tag Stack{21}
      0F008847 00015000
      No output feature configured
      Per-packet load-sharing
    • show mpls ldp bindings or show tag-switching tdp bindings (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.
      Pomerol#show tag-switching tdp bindings 10.10.10.4 32
      tib entry: 10.10.10.4/32, rev 14
      local binding: tag: 18
      remote binding: tsr: 10.10.10.1:0, tag: 21
      remote binding: tsr: 10.10.10.2:0, tag: 23
      remote binding: tsr: 10.10.10.6:612, tag: 20
      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.
    • show ip cef detail —Used to check that Cisco Express Forwarding works properly and that tags are swapped correctly:
      Pomerol#show ip cef 10.10.10.4 detail
      10.10.10.4/32, version 37, cached adjacency to Serial3/0
      0 packets, 0 bytes
      tag information set
      local tag: 18
      fast tag rewrite with Se3/0, point2point, tags imposed: {21}
      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: {21}

    Troubleshoot

    Refer to MPLS Troubleshooting for information on how to troubleshoot MPLS.
    Related Information






    Updated: Aug 10, 2005





  4. #4
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    Configuring MPLS Basic Traffic Engineering Using IS-IS


    Document ID: 13737


    Contents

    Introduction
    Prerequisites
    Requirements
    Components Used
    Conventions
    Functional Components
    Configure
    Network Diagram
    Configurations
    Verify
    show Commands
    Sample show Output
    Related Information
    Introduction

    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.
    Prerequisites

    Requirements

    There are no specific requirements for this document.
    Components Used

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

    • Cisco IOS® Software Releases 12.0(11)S and 12.1(3a)T
    • Cisco 3600 routers

    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.
    Conventions

    For more information on document conventions, refer to Cisco Technical Tips Conventions.
    Functional Components

    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.

    Configure

    Network Diagram

    This document uses the network setup shown in this diagram.

    Configurations

    Quick Configurations Guide

    This procedure can be used to perform a quick configuration. For more detailed information, refer to MPLS Traffic Engineering and Enhancements.

    1. Set up your network with the usual configuration (in this case, Frame Relay is used).
      Note: 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.
    2. 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:

      • For IS-IS:
        metric-style wide (or metric-style both)
        mpls traffic-eng router-id LoopbackN
        mpls traffic-eng [level-1 | level-2 |]
      • For OSPF:
        mpls traffic-eng area X
        mpls traffic-eng router-id LoopbackN (must have a 255.255.255.255 mask)

    3. Enable MPLS TE. Enter ip cef (or ip cef distributed if available in order to enhance performance) in the general configuration mode. Enable MPLS (tag-switching ip) on each concerned interface. Enter mpls traffic-engineering tunnel to enable MPLS TE, as well as RSVP for zero-bandwidth TE tunnels.
    4. Enable RSVP by entering ip rsvp bandwidth XXX on each concerned interface for non-zero bandwidth tunnels.
    5. Set up tunnels to be used for TE. There are many options that can be configured for MPLS TE tunnel, but the tunnel mode mpls traffic-eng command is mandatory. The tunnel mpls traffic-eng autoroute announce command announces the presence of the tunnel by the routing protocol.

    Note: Do not forget to use ip unnumbered loopbackN 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.
    Configuration File

    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
    !
    ip cef
    mpls traffic-eng tunnels
    !
    interface Loopback0
    ip address 10.10.10.6 255.255.255.255
    ip router isis
    !
    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
    !


    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
    tag-switching ip
    mpls traffic-eng tunnels
    frame-relay interface-dlci 603
    ip rsvp bandwidth 512 512
    !
    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
    !
    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

    !
    end
    Pescara
    Current configuration:
    !
    version 12.0
    !
    hostname Pescara
    !

    ip cef
    !
    mpls traffic-eng tunnels
    !
    interface Loopback0
    ip address 10.10.10.4 255.255.255.255
    ip router isis
    !
    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
    !


    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
    mpls traffic-eng tunnels
    tag-switching ip
    frame-relay interface-dlci 401
    ip rsvp bandwidth 512 512
    !
    router isis
    net 49.0001.0000.0000.0004.00
    is-type level-1
    metric-style wide
    mpls traffic-eng router-id Loopback0
    mpls traffic-eng level-1

    !
    end
    Pomerol
    Current configuration:

    version 12.0
    !
    hostname Pomerol
    !
    ip cef
    !
    mpls traffic-eng tunnels
    !
    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
    mpls traffic-eng tunnels
    tag-switching ip
    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
    ip router isis
    mpls traffic-eng tunnels
    tag-switching ip
    frame-relay interface-dlci 302
    ip rsvp bandwidth 512 512
    !
    interface Serial0/1.3 point-to-point
    bandwidth 512
    ip address 10.1.1.21 255.255.255.252
    ip router isis
    mpls traffic-eng tunnels
    tag-switching ip
    frame-relay interface-dlci 306
    ip rsvp bandwidth 512 512
    !
    router isis
    net 49.0001.0000.0000.0003.00
    is-type level-1
    metric-style wide
    mpls traffic-eng router-id Loopback0
    mpls traffic-eng level-1

    !
    ip classless
    !
    end
    Pulligny
    Current configuration:
    !
    version 12.1
    !
    hostname Pulligny
    !
    ip cef
    !
    mpls traffic-eng tunnels
    !
    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
    mpls traffic-eng tunnels
    tag-switching ip
    frame-relay interface-dlci 201
    ip rsvp bandwidth 512 512
    !
    interface Serial0/1.2 point-to-point
    bandwidth 512
    ip address 10.1.1.10 255.255.255.252
    ip router isis
    mpls traffic-eng tunnels
    tag-switching ip
    frame-relay interface-dlci 203
    ip rsvp bandwidth 512 512
    !
    router isis
    passive-interface Loopback0
    net 49.0001.0000.0000.0002.00
    is-type level-1
    metric-style wide
    mpls traffic-eng router-id Loopback0
    mpls traffic-eng level-1

    !
    ip classless
    !
    end
    Pauillac
    !
    version 12.1
    !
    hostname pauillac
    !
    ip cef
    mpls traffic-eng tunnels
    !
    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
    mpls traffic-eng tunnels
    tag-switching ip
    frame-relay interface-dlci 102
    ip rsvp bandwidth 512 512
    !
    interface Serial0/0.2 point-to-point
    bandwidth 512
    ip address 10.1.1.5 255.255.255.252
    ip router isis
    mpls traffic-eng tunnels
    tag-switching ip
    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
    mpls traffic-eng tunnels
    tag-switching ip
    frame-relay interface-dlci 104
    ip rsvp bandwidth 512 512
    !
    router isis
    net 49.0001.0000.0000.0001.00
    is-type level-1
    metric-style wide
    mpls traffic-eng router-id Loopback0
    mpls traffic-eng level-1

    !
    ip classless
    !
    end
    Verify

    show Commands

    This section provides information you can use to confirm your configuration is working properly.
    The Output Interpreter Tool (registered customers only) (OIT) supports certain show commands. Use the OIT to view an analysis of show command output.

    • show mpls traffic-eng tunnels brief
    • show mpls traffic-eng tunnels name Pesaro_t158
    • show ip rsvp interface
    • show mpls traffic-eng topology path destination 10.10.10.6 bandwidth 75

    Other useful commands (not illustrated here) include:

    • show isis mpls traffic-eng advertisements
    • show tag-switching forwarding-table
    • show ip cef
    • show mpls traffic-eng tunnels summary

    Sample show Output

    On any LSR, you can use show mpls traffic-eng tunnels 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):
    Pesaro#show mpls traffic-eng tunnels brief
    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
    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

    Displayed 2 (of 2) heads, 0 (of 0) midpoints,2 (of 2) tails
    This is what is seen while on a middle router:
    Pulligny#show mpls traffic-eng tunnels brief
    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
    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

    Displayed 0 (of 0) heads, 2 (of 2) midpoints, 0 (of 0) tails
    The detailed configuration of any tunnel can be seen using this:
    Pesaro#show mpls traffic-eng tunnels name Pesaro_t158

    Name: Pesaro_t158 (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: 10.1.1.21 10.1.1.10 10.1.1.1 10.1.1.14
    10.10.10.4

    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
    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).
    Pulligny#show ip rsvp interface
    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
    Se0/1.1 158K 512K 512K 30 0 1 0 0
    Se0/1.2 69K 512K 512K 13 0 1 0 0
    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:
    Note: Please note that this command is wrapped to a second line for spatial reasons.
    Pescara#show mpls traffic-eng topology path destination
    10.10.10.6 bandwidth 75

    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
    If the network does IP TTL propagation (refer to mpls ip ttl propagate ), issue a traceroute command and see that the path followed is the tunnel and that the tunnel routes according to what is configured:
    Pescara#traceroute 10.10.10.6

    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
    Related Information






    Updated: Aug 10, 2005





  5. #5
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    Configuring MPLS Basic VPN with RIP on Customer Side


    Document ID: 13732


    Contents

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

    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 MPLS Virtual Private Networks.
    Prerequisites

    Requirements

    There are no specific prerequisites for this document.
    Components Used

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

    • PE routers: The MPLS VPN functionality resides in the PE routers. Use Feature Navigator II (registered customers only) to determine which hardware and software combinations you can use.
    • CE routers: Use any router able to exchange routing information with its PE router.
    • P routers and switches: 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.

    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.
    Network Description

    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.
    Note: 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.
    Note: 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.
    Conventions

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

    • P: Provider's core router
    • PE: Provider's edge router
    • CE: Customer's edge router
    • C: Customer's router

    A typical configuration illustrating these conventions is shown in the diagram below:

    For more information on document conventions, refer to Cisco Technical Tips Conventions.
    Configuration Procedure

    In this section, you are presented with the information to configure the features described in this document. The Cisco IOS documentation found in MPLS Virtual Private Networks also describes this configuration procedure.
    Note: To find additional information on the commands used in this document, use the IOS Command Lookup tool (registered customers only)
    Network Diagram

    This document uses the network setup shown in the diagram below.

    Part I

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

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

      • 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.
        rd [VPN route distinguisher]
      • 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.
        route-target {export | import | both} [target VPN extended community]

    2. Configure the forwarding details for the respective interfaces using the ip vrf forwarding [table name]command and remember to set up the IP address afterwards.
    3. Depending on the PE-CE routing protocol used, do one or more of the following:

      • Configure the static routes as follows:
        ip route vrf vrf-name prefix mask [next-hop-address] [interface {interface-number}]
      • Configure the RIP using the following command:
        address-family ipv4 vrf [VPN routing | forwarding instance name]
        Once you have completed one or both of the steps above, enter the normal RIP configuration commands.
        Note: 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:
        router ospf process-id vrf [VPN routing | forwarding instance name]

      Note: 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.

    Part II

    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.

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

      • Redistribute the static routing information.
      • Redistribute the RIP routing information.
      • Redistribute the OSPF routing information.
      • Activate BGP neighboring with the CE routers.

    3. Enter the address-family vpnv4 mode and:

      • Activate the neighbors.
      • Specify that extended community must be used. This is mandatory.


    Configuration Examples

    In the Alcalzaba configuration, lines specific to the VPN configuration are shown in bold.
    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
    !
    interface Ethernet1/1
    ip vrf forwarding vrf101
    ip address 150.150.0.1 255.255.255.0

    !
    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
    !
    address-family ipv4 vrf vrf101
    version 2
    redistribute bgp 1 metric 0
    network 150.150.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.21 remote-as 1
    neighbor 223.0.0.21 update-source Loopback
    0
    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.21 activate
    neighbor 223.0.0.21 send-community extended

    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
    !
    debug and show Commands

    Before you use debug commands, refer to Important Information on Debug Commands. Routing-specific commands are listed here:

    • show ip rip database vrf - Shows information contained in the RIP database for a particular VRF.
    • show ip bgp vpnv4 vrf - Displays VPN address information from the BGP table.
    • show ip route vrf - Displays the IP routing table associated with a VRF.
    • show ip route - Displays all static IP routes, or those installed using the authentication, authorization, and accounting (AAA) route download function.

    Certain show commands are supported by the Output Interpreter tool (registered customers only) , which allows you to view an analysis of show 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:
    Alcazaba# show ip rip database vrf vrf101
    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,
    You can display the BGP information for a particular VRF using the show ip bgp vpnv4 vrf command. The PE-PE results from the internal BGP (iBGP) are indicated by an i in the output below.
    Alcazaba# show ip bgp vpnv4 vrf vrf101
    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 ?
    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 show ip route vrf command:
    Alcazaba# show ip route vrf vrf101
    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
    The equivalent command on Pivrnec is the show ip route command, since for every customer (and customer edge) router this is the standard routing table.
    Pivrnec# show ip route
    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
    MPLS Labels

    Check the label stack used for any route as follows:
    Alcazaba# show tag-switching forwarding-table vrf vrf101 11.5.5.5 detail
    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, Tag Stack{2/91(vcd=69) 37}
    00458847 0004500000025000
    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 How to Troubleshoot the MPLS VPN .
    Address Overlapping

    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 ping command on one site and the debug ip icmp command on the other site.
    Guilder# ping 6.6.6.6
    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# debug ip icmp
    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
    Sample Debug Output

    Refer to Packet Flow in an MPLS VPN Environment to see sample output using the same configuration.
    Troubleshoot

    There is currently no specific troubleshooting information available for this configuration.
    Related Information






    Updated: Nov 16, 2007






  6. #6
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    Multiprotocol Label Switching over ATM (MPLS over ATM)

    Configuring VPN MPLS over ATM with Cisco 7500 Routers and LightStream 1010 Switches


    Document ID: 10533


    Contents

    Introduction
    Prerequisites
    Requirements
    Conventions
    Configure
    Network Diagram
    Network Description
    Configurations
    Related Information
    Introduction

    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.
    Prerequisites

    Requirements

    There are no specific requirements for this document.
    Conventions

    Refer to Cisco Technical Tips Conventions for more information on document conventions.
    Configure

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

    This document uses this network setup:

    Network Description

    The current setup contains these elements in VPN terminology:

    • CE = Customer Edge Router
    • PE = Provider Edge Router
    • P=Provider Router

    The current setup contains these elements in MPLS terminology:

    • LER = Label Edge Router
    • LSR = Label Switch Router
    • TDP/LDP = Tag Distribution Protocol/Label Distribution Protocol

    Configurations

    This document uses these configurations:

    • 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.

    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
    !

    show Commands
    Use these commands to test that your network operates properly:

    • show ip route - Displays IP routing table entries.
    • show ip rip database vrf - Shows information contained in the RIP database for a particular VRF.
    • show ip bgp vpnv4 vrf - Displays VPN address information from the BGP table.
    • show tag-switching interfaces detail - Displays information about one or more interfaces that have the MPLS feature enabled.
    • show tag-switching tdp bindings - Displays the requested entries from the ATM LDP label binding database.
    • show tag-switching forwarding-table vrf - Checks the label stack used for a particular route.

    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.
    CE1
    Cisco4500#show ip route
    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
    PE1
    Cisco7500a#show ip route
    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#show ip route vrf NEW
    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#show ip rip database vrf NEW
    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#show ip bgp vpnv4 vrf NEW
    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#show tag-switching interfaces
    Interface IP Tunnel Operational
    ATM2/0/0.10 Yes No Yes (ATM tagging)

    Cisco7500a#show tag-switching interfaces detail
    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#show tag-switching ?
    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#show tag-switching tdp bindings
    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#show tag-switching atm-tdp bindings
    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#show tag-switching forwarding-table vrf NEW
    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
    P1
    LS1010#show ip route
    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#show tag-switching atm-tdp bindings
    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
    P2
    LS1010#show ip route
    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#show tag-switching atm-tdp bindings
    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
    PE2
    Cisco7500#show ip route
    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#show ip route vrf NEW
    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#show ip rip database vrf NEW
    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#show ip bgp vpnv4 vrf NEW
    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#show tag-switching interfaces
    Interface IP Tunnel Operational
    ATM3/1/0.1 Yes No Yes (ATM tagging)

    Cisco7500#show tag-switching interfaces detail
    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#show tag-switching ?
    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#show tag-switching tdp bindings
    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#show tag-switching atm-tdp bindings
    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#show tag-switching forwarding-table vrf NEW
    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
    CE2
    Cisco7100#show ip route
    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
    Related Information






    Updated: Jun 05, 2005





  7. #7
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    DiffServ Tunneling Modes for MPLS Networks


    Document ID: 47815


    Contents

    Introduction
    Prerequisites
    Requirements
    Components Used
    Conventions
    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
    DiffServ Tunneling Modes
    Uniform Mode
    Pipe Mode
    Short-Pipe Mode
    Tunnel Mode Summary
    Cisco Support Community - Featured Conversations
    Related Information
    Introduction

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

    Requirements

    Readers of this document should have knowledge of these topics:

    • 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)

    Components Used

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

    • 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.

    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.
    Conventions

    For more information on document conventions, refer to the Cisco Technical Tips Conventions.
    Background Information

    Default Behavior

    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:

    This remainder of this section describes the activity within the Default Behavior diagram.
    Imposition of Label (IP –> Label):

    • 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.

    MPLS forwarding (Label –> Label):

    • 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.

    Disposition of Label (Label –> IP):

    • At label disposition the EXP bits are not copied down to the IP precedence/DSCP field of the newly exposed IP packet.

    Pre Cisco IOS Software 12.2(13)T Command Usage and Behavior

    Before IOS Release 12.2(13)T, the set mpls experimental command was the only method available to modify the MPLS EXP bits.
    Post Cisco IOS Software 12.2(13)T Command Usage and Behavior

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


    Note: The new set mpls experimental topmost command is equivalent to the old set mpls imposition 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.
    DiffServ Tunneling Modes

    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 explicit-null 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:


    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.
    Note: 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.
    Uniform Mode

    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.

    Uniform mode configurations:
    PE1

    !--- This configuration maps the IP Precedence
    !--- of the incoming IP packets to the MPLS EXP bits.


    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

    policy-map set-MPLS-PHB
    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

    policy-map output-qos
    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
    service-policy output output-qos
    tag-switching ip
    !
    interface Ethernet1/0
    ip vrf forwarding v1
    ip address 10.0.0.2 255.255.255.0
    service-policy input set-MPLS-PHB
    !
    P1

    !--- This configuration swaps the top label from 3 to 2,
    !--- which does not need to occur to follow the previous configuration.


    class-map match-all mpls-in
    match mpls experimental topmost 3
    !
    policy-map mpls-in
    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
    service-policy input mpls-in
    tag-switching ip
    !
    P2

    !--- Remember to copy down the MPLS EXP value
    !--- from the newly exposed label after the PHP.


    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
    !
    policy-map qos-group-in
    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
    !
    policy-map qos-group-out
    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
    service-policy output qos-group-out
    tag-switching ip
    !
    interface Ethernet1/0
    ip address 192.168.1.2 255.255.255.0
    service-policy input qos-group-in
    tag-switching ip
    !
    PE2

    !--- Remember to copy down the MPLS EXP bits to the IP Precedence
    !--- of the newly exposed IP packet.


    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
    !
    policy-map qos-group-in
    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
    !
    policy-map qos-group-out
    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
    service-policy output qos-group-out
    !
    interface Ethernet1/0
    ip address 192.168.2.2 255.255.255.0
    service-policy input qos-group-in
    tag-switching ip
    !
    Pipe Mode

    Diffserv Tunneling Pipe Mode uses two layers of QoS:

    1. An underlying QoS for the data, which remains unchanged when traversing the core.
    2. A per-core QoS, which is separate from that of the underlying IP packets. This per-core QoS PHB remains transparent to end users.

    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.

    Pipe mode configurations:
    PE1

    !--- 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).


    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
    !
    policy-map set-MPLS-PHB
    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
    !
    policy-map output-qos
    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
    service-policy output output-qos
    tag-switching ip
    !
    interface Ethernet1/0
    ip vrf forwarding v1
    ip address 10.0.0.2 255.255.255.0
    service-policy input set-MPLS-PHB
    !
    P1

    !--- This configuration swaps the top label from 4 to 5,
    !--- which does not need to occur to follow the previous configuration.


    class-map match-all mpls-in
    match mpls experimental topmost 4
    !
    policy-map mpls-in
    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
    service-policy input mpls-in
    tag-switching ip
    !
    P2

    !--- Remember to copy down the MPLS EXP value from
    !--- the newly exposed label after the PHP.


    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
    !
    policy-map qos-group-in
    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
    !
    policy-map qos-group-out
    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
    service-policy output qos-group-out
    tag-switching ip
    !
    interface Ethernet1/0
    ip address 192.168.1.2 255.255.255.0
    service-policy input qos-group-in
    tag-switching ip
    !
    PE2

    !--- Remember to queue the newly exposed IP packet based in
    !--- the MPLS EXP bits of the label we just removed. Use
    !--- qos-groups to keep track of this value.


    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
    !
    policy-map qos-group-in
    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
    !
    policy-map qos-group-out
    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
    service-policy output qos-group-out
    !
    interface Ethernet1/0
    ip address 192.168.2.2 255.255.255.0
    service-policy input qos-group-in
    tag-switching ip
    !
    Short-Pipe Mode

    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.

    Short-pipe mode configurations:
    PE1

    !--- 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).


    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
    !
    policy-map set-MPLS-PHB
    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
    !
    policy-map output-qos
    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
    service-policy output output-qos
    tag-switching ip
    !
    interface Ethernet1/0
    ip vrf forwarding v1
    ip address 10.0.0.2 255.255.255.0
    service-policy input set-MPLS-PHB
    !
    P1

    !--- This configuration swaps the top label from 4 to 5,
    !--- which does not need to occur to follow the previous configuration.


    class-map match-all mpls-in
    match mpls experimental topmost 4
    !
    policy-map mpls-in
    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
    service-policy input mpls-in
    tag-switching ip
    !
    P2

    !--- Remember to copy down the MPLS EXP value from
    !--- the newly exposed label after the PHP.


    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
    !
    policy-map qos-group-in
    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
    !
    policy-map qos-group-out
    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
    service-policy output qos-group-out
    tag-switching ip
    !
    interface Ethernet1/0
    ip address 192.168.1.2 255.255.255.0
    service-policy input qos-group-in
    tag-switching ip
    !
    PE2

    !--- Remember to queue the newly exposed IP packet
    !--- based on the value of the IP Precedent.


    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
    !
    policy-map qos-group-out
    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
    service-policy output qos-group-out
    !
    interface Ethernet1/0
    ip address 192.168.2.2 255.255.255.0
    tag-switching ip
    !
    Tunnel Mode Summary

    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)

    Cisco Support Community - Featured Conversations

    Cisco Support Community 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 here


    • How to deploy MPLS Diff-serv in network?shan-cao1 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 SincerelySubscribe Reply



    • MPLS/DiffServ WAN designnotuteye1 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?Subscribe Reply



    • DiffServ & TE paths are required to...mpugliese@diveo.net.br2 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.Subscribe Reply



      • Re: DiffServ & TE paths are required to...thomas.chen12.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...Reply



        • Re: DiffServ & TE paths are required to...mpugliese@diveo.net.br15.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. Reply

    • MPLS QoS: RDM - DS-TEabayo1 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?.Subscribe Reply



      • Re: MPLS QoS: RDM - DS-TEANONYMOUS05.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. Reply

    • DiffServsschingel1 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.Subscribe Reply



    • Cisco support for diff-servrtshimizu0 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???Subscribe Reply

    • Hardware transcoder and DiffServmdeloach3 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?Subscribe Reply



      • Re: Hardware transcoder and DiffServpbarman25.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.Reply



        • Re: Hardware transcoder and DiffServmdeloach25.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...Reply



          • Re: Hardware transcoder and DiffServpbarman25.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, ParthaReply

    • ASK THE EXPERT - QoS FOR IP/MPLS...ciscomoderator42 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.Subscribe Reply



      • Re: ASK THE EXPERT - QoS FOR IP/MPLS...samuel090112.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, SamuelReply



        • Re: ASK THE EXPERT - QoS FOR IP/MPLS...aamercado13.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...Reply



          • Re: ASK THE EXPERT - QoS FOR IP/MPLS...mheusinger14.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...Reply

          • Re: ASK THE EXPERT - QoS FOR IP/MPLS...saalvare15.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.Reply

        • Re: ASK THE EXPERT - QoS FOR IP/MPLS...saalvare14.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.Reply



        • Re: ASK THE EXPERT - QoS FOR IP/MPLS...saalvare15.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 --Reply

      • Re: ASK THE EXPERT - QoS FOR IP/MPLS...bbaley15.08.2006 09:14 Hi Santiago, Can you please outline the main QoS differences and similarities between an IP and an MPLS network? Thanks - BillReply



        • Re: ASK THE EXPERT - QoS FOR IP/MPLS...saalvare15.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...Reply

      • More Replies
    • Is WFQ considered DiffServ?news2010a1 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. Subscribe Reply



      • Re: Is WFQ considered DiffServ?dgahm05.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...Reply

    • How are the exp bits used in a 6500midoherty9 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?Subscribe Reply



      • Re: How are the exp bits used in a 6500hritter20.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: Redirect: Internal Technical Support ITS Hope this helps, Reply



        • Re: How are the exp bits used in a 6500midoherty20.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 Redirect: Internal Technical Support ITS My problem is...Reply



          • Re: How are the exp bits used in a 6500hritter21.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. Reply



            • Re: How are the exp bits used in a 6500fcotichelli04.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 FrancescoReply



              • Re: How are the exp bits used in a 6500midoherty08.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. MichaelReply



                • Re: How are the exp bits used in a 6500fcotichelli09.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...Reply



                  • Re: How are the exp bits used in a 6500fcotichelli21.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 *************************************...Reply



                    • Re: How are the exp bits used in a 6500midoherty23.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...Reply



      • More Replies

    Subscribe Start A New Discussion

    Related Information






    Updated: Feb 15, 2008






  8. #8
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    GRE Tunnel with VRF Configuration Example


    Document ID: 46252


    Contents

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

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

    Requirements

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


    Components Used

    The information in this document is based on Cisco IOS® Software Release 12.3(4)T1 on 3725 Series routers.
    Use Cisco Feature Navigator II ( registered customers only) and search for the GRE Tunnel IP Source and Destination VRF Membership 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.
    Conventions

    For more information on document conventions, refer to the Cisco Technical Tips Conventions.
    Configure

    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:

    • 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.

    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.
    Note: To find additional information on the commands used in this document, use the Command Lookup Tool ( registered customers only) .
    Network Diagram

    This document uses this network setup:
    Figure 1 – Physical Topology

    Figure 2 – Logical VRF Topology

    Configurations

    This document uses these configurations:


    R3-PE (Tunnel Endpoint)
    R3-PE# show running-config

    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
    tunnel vrf blue

    !--- 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 tunnel vrf blue
    !--- command.


    !
    interface Ethernet0/0
    ip vrf forwarding blue
    ip address 20.20.20.3 255.255.255.0

    !--- Connection to the VRF BLUE network and the VRF GREEN
    !--- network using the GRE tunnel.


    !
    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

    !--- Static Host route to ensure that recursive routing
    !--- does not occur.


    no ip http server
    !
    .
    end
    R4-PE
    R4-PE# show running-config

    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# show running-config
    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

    !--- Both the tunnel source and destination address are in
    !--- the VRF BLUE, to provide transport for the VRF GREEN
    !--- network.


    !
    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

    !--- Access-group to allow only GRE packets through the
    !--- R2-CE network. However, R1-CE networks data is in the
    !--- GRE packet.


    !
    !
    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

    !--- Static Host route to ensure that recursive routing
    !--- does not occur.


    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

    !--- Permits only GRE packets between the endpoints.

    !
    .
    .
    end
    R2-CE
    R2-CE# show running-config

    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

    !--- Permits only GRE packets between the endpoints.

    .
    !
    end
    R5-CE
    R5-CE# show running-config

    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# show running-config

    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
    Verify

    This section provides information you can use to confirm your configuration is working properly.
    Certain show commands are supported by the Output Interpreter Tool ( registered customers only) , which allows you to view an analysis of show command output.

    • show ip route , show ip route vrf —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.
    • ping —Issue this command from the other end of the CE to ensure that the tunnels are reachable from the CE.
    • show ip bgp vpnv4 all labels —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.

    R3-PE# show ip route vrf blue 10.10.10.1

    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# show ip route vrf green

    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# show interfaces tunnel 0

    Tunnel0 is up, line protocol is up
    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
    Tunnel source 20.20.20.3 (Ethernet0/0), destination 10.10.10.1
    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# show ip bgp vpnv4 all labels

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

    R4-PE# show ip route vrf blue

    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# show ip route vrf green

    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# show ip route 20.20.20.3

    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# show interfaces tunnel 0

    Tunnel0 is up, line protocol is up
    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
    Tunnel source 10.10.10.1 (Ethernet0/0), destination 20.20.20.3
    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# ping 200.200.200.1

    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# ping 200.200.200.3

    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
    Troubleshoot

    There is currently no specific troubleshooting information available for this configuration.
    Caveats

    These known caveats are identified for the configuration of this feature. You can use the Bug Toolkit ( registered customers only) to search for bugs.

    • CSCea81266 ( registered customers only) —Resolved (R) GRE: Traffic stops flowing after clear ip route *.
    • CSCdx74855 ( registered customers only) —Resolved (R) Can not ping IP address of local GRE tunnel interface.
    • CSCdx57718 ( registered customers only) —Resolved (R) IP packet loss in GRE tunnel when Cisco Express Forwarding (CEF) disabled on outgoing interface.

    Cisco Support Community - Featured Conversations

    Cisco Support Community 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 here


    • Unusual GRE connectivity issuesvanderwaalr4 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.Attachments:



      Subscribe Reply



      • Re: Unusual GRE connectivity issuesmarwanshawi22.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 luckReply



        • Re: Unusual GRE connectivity issuesvanderwaalr22.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...Reply



          • Re: Unusual GRE connectivity issuesmarwanshawi22.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 mGREReply

          • Re: Unusual GRE connectivity issuespaluchpeter23.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...Reply

    • Gre tunnel in a vrfmathieu.ploton5 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 Subscribe Reply



    • Is it possible ot send VRF traffic over...keeleym@o2.ie11 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, MichaelAttachments:



      Subscribe Reply



      • Re: Is it possible ot send VRF traffic...giuslar24.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...Reply



        • Re: Is it possible ot send VRF traffic...keeleym@o2.ie24.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...Attachments:



          Reply



          • Re: Is it possible ot send VRF traffic...giuslar24.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 GiuseppeReply



            • Re: Is it possible ot send VRF traffic...keeleym@o2.ie24.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...Reply



              • Re: Is it possible ot send VRF traffic...sharifimr24.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...Reply



                • Re: Is it possible ot send VRF traffic...keeleym@o2.ie24.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, MichaelReply



                  • Re: Is it possible ot send VRF traffic...sharifimr24.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 Reply



                    • Re: Is it possible ot send VRF traffic...keeleym@o2.ie25.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...Reply



                      • Re: Is it possible ot send VRF traffic...giuslar25.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...Reply



                        • Re: Is it possible ot send VRF traffic...keeleym@o2.ie25.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...Reply

      • More Replies
    • GRE tunnel configuration helpbranfarm12 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 Subscribe Reply



      • Re: GRE tunnel configuration helprburts11.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...Reply

      • Re: GRE tunnel configuration helpleolaohoo12.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 IPSec/GRE with NAT on IOS Router Configuration Example - Cisco Systems GRE Tunnel with VRF Configuration Example...Reply

    • GRE Tunnel Configuration ??????afzaalq0075 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 Subscribe Reply



      • Re: GRE Tunnel Configuration ??????tdrais31.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. Reply

      • Re: GRE Tunnel Configuration ??????sean@managednetworks.com31.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.Reply



    • GRE Tunnel interfaces in MPLS VRFzahid.hassan10 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 Subscribe Reply



      • Re: GRE Tunnel interfaces in MPLS VRFpankajkulkarni20.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 - Cisco.com Login Page 2. While configuring tunnels with VRFs use...Reply



        • Re: GRE Tunnel interfaces in MPLS VRFzahid.hassan21.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 Reply



          • Re: GRE Tunnel interfaces in MPLS VRFpankajkulkarni21.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...Reply



            • Re: GRE Tunnel interfaces in MPLS VRFzahid.hassan21.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 Reply

      • Re: GRE Tunnel interfaces in MPLS VRFoettls21.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, StefanReply



        • Re: GRE Tunnel interfaces in MPLS VRFswaroop.potdar21.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,...Reply



          • Re: GRE Tunnel interfaces in MPLS VRFpankajkulkarni21.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, PankajReply



            • Re: GRE Tunnel interfaces in MPLS VRFswaroop.potdar21.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...Reply



              • Re: GRE Tunnel interfaces in MPLS VRFpankajkulkarni21.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,...Reply



      • More Replies
    • GRE Tunnel configuration over MPLSprasaddesai.in18 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. Attachments:



      Subscribe Reply



      • Re: GRE Tunnel configuration over MPLSmohammedmahmoud26.06.2007 05:01 Hi, Can you ping the tunnel destination from both sides ? BR, Mohammed Mahmoud.Reply



        • Re: GRE Tunnel configuration over MPLSmheusing26.06.2007 05:20 Hi, You might want to follow the config guide found at "GRE Tunnel with VRF Configuration Example" GRE Tunnel with VRF Configuration Example - Cisco Systems This should work with the proper IOS version installed. Hope this helps! Regards, MartinReply



          • Re: GRE Tunnel configuration over MPLSswaroop.potdar26.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...Reply

          • Re: GRE Tunnel configuration over MPLSswaroop.potdar26.06.2007 06:37 Hi Martin, Glad to see you, and welcome back in the new role !!! Cheers, SwaroopReply



            • Re: GRE Tunnel configuration over MPLSmheusing26.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...Reply



              • Re: GRE Tunnel configuration over MPLSprasaddesai.in26.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.Reply



                • Re: GRE Tunnel configuration over MPLSswaroop.potdar27.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. http://www.cisco.com/en/US/products/...0805e1e8e.html Now when you use a PE loopback as source and destination, they are reachable in the global table,...Reply



                  • Re: GRE Tunnel configuration over MPLSprasaddesai.in27.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...Reply



                    • Re: GRE Tunnel configuration over MPLSswaroop.potdar27.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, SwaroopReply

                    • Re: GRE Tunnel configuration over MPLSmheusing27.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...Reply

      • More Replies
    • GRE Tunnel configurationLavanholy6 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, Subscribe Reply



      • Re: GRE Tunnel configurationroyalblues07.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 PIX 6.x: Simple PIX-to-PIX VPN Tunnel Configuration Example - Cisco Systems HTH Narayan Reply

      • Re: GRE Tunnel configurationwilliamsdo@si.edu07.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 CCO Redirect Reply

      • Re: GRE Tunnel configurationCollin_Clark07.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. ...Reply



        • Re: GRE Tunnel configurationLavanholy11.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.Reply



          • Re: GRE Tunnel configurationCollin_Clark14.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! Reply

      • Re: GRE Tunnel configurationmedan11.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, DandyReply

    • Question regarding tunnel configuration...toerierz@telkom.co.za2 Replies14.11.2002 00:17 Please have a look at this example: Redirect: Internal Technical Support ITS 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. Subscribe Reply



      • Re: Question regarding tunnel...wkumari13.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...Reply



        • Re: Question regarding tunnel...toerierz@telkom.co.za14.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...Reply

    • GRE tunnel protocol status goes down...kaustav.gupta5 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 KasSubscribe Reply



      • Re: GRE tunnel protocol status goes...shivlu29.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 Reply



        • Re: GRE tunnel protocol status goes...kaustav.gupta29.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 .Reply

      • Re: GRE tunnel protocol status goes...hritter29.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 Reply



        • Re: GRE tunnel protocol status goes...kaustav.gupta29.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 commandReply



          • Re: GRE tunnel protocol status goes...hritter01.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 Reply


    Subscribe Start A New Discussion

    Related Information






    Updated: Jan 16, 2006




  9. #9
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    Implementing an MPLS VPN over TE Tunnels



    Document ID: 29828


    Contents

    Introduction
    Prerequisites
    Requirements
    Components Used
    Conventions
    Background Theory
    Initial VPN Setup Between CE1 and CE2 Without a TE Tunnel
    Topology
    Configuration
    Verification
    Case 1: VPN over a TE Tunnel When the TE Tunnel Is from PE1 to PE2
    Topology
    Configuration
    Verification
    Case 2: VPN over a TE Tunnel When the TE Tunnel Is from PE1 to P2
    Topology
    Configuration
    Verification
    Explanation
    Solution
    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
    Case 4: VPN over a TE Tunnel Between P1 and P2 with LDP Enabled
    Topology
    Configuration
    Verification
    Case 5: MPLS VPN over a Tunnel Between P1 and PE2
    Topology
    Configuration
    Verification
    Known Issues
    Conclusion
    Cisco Support Community - Featured Conversations
    Related Information
    Introduction

    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.
    Prerequisites

    Requirements

    Readers of this document should have knowledge of these topics:


    Components Used

    This document is not restricted to specific software and hardware versions.
    Conventions

    Refer to Cisco Technical Tips Conventions for more information on document conventions.
    Background Theory


    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 RFC 3031 . 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 above, 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 show outputs that follow demonstrate this and illustrate one possible solution to this problem.
    Initial VPN Setup Between CE1 and CE2 Without a TE Tunnel

    Topology


    Configuration

    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
    !
    Verification

    PE2 learns PE1 VPN IPv4 prefix 172.16.1.0/24 over MPBGP peering between PE1 and PE2. This is shown here:
    PE2# show ip route vrf aqua
    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 172.16.1.0 [200/0] via 10.2.2.2, 16:09:10
    C 172.16.13.0 is directly connected, POS5/1
    Similarly, PE1 learns PE2 VPN IPv4 prefix 172.16.13.0/24 over MPBGP peering between PE1 and PE2. This is shown here:
    PE1# show ip route vrf aqua
    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 172.16.13.0 [200/0] via 10.11.11.11, 16:09:49
    C 172.16.1.0 is directly connected, Ethernet2/0/1

    PE1# show ip route vrf aqua 172.16.13.13
    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# show ip cef vrf aqua 172.16.13.13
    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 {17 12308}

    !--- 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.



    PE1# show ip cef 10.11.11.11
    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 {17}

    !--- Outer label 17 is used to reach next hop 10.11.11.11.
    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 ping output confirms the connectivity:
    CE1# ping 172.16.13.13

    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
    Case 1: VPN over a TE Tunnel When the TE Tunnel Is from PE1 to PE2

    Topology


    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.
    Note: 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 Configuration, 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.
    Configuration

    The additional configuration on PE1 to establish a PE tunnel is shown here:
    PE1
    PE1# show run interface tunnel 0
    !
    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
    Verification

    PE1# show ip cef vrf aqua 172.16.13.13
    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.11.11.11, Tunnel0 via 10.11.11.11/32
    valid adjacency
    tag rewrite with Tu0, point2point, tags imposed {19 12308}

    !--- 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.



    PE1# show ip route 10.11.11.11
    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, via Tunnel0

    !--- The route is via Tunnel0.

    Route metric is 40, traffic share count is 1
    Now, confirm the outer label used to reach the next hop 10.11.11.11 via Tunnel0.
    PE1# show mpls traffic-eng tunnels tunnel 0

    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, 19

    !--- Label 19 from RSVP is used to reach destination 10.11.11.11/32.

    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
    Another way to view this information quickly is to use the output modifiers in the show commands, as shown here:
    PE1# show mpls traffic-eng tunnels tunnel 0 | include Label
    InLabel : -
    OutLabel : Ethernet2/0/2, 19

    !--- This is the label to reach 10.11.11.11.
    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.
    PE1# show tag forwarding-table 10.11.11.11 detail
    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 Tu0 point2point
    MAC/Encaps=14/18, MTU=1500, Tag Stack{19}, 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#
    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:
    PE2# show tag for tags 12308 detail
    Local Outgoing Prefix Bytes tag Outgoing Next Hop
    tag tag or VC or Tunnel Id switched interface
    12308 Aggregate 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#
    Note: 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:
    CE1# ping 172.16.13.13

    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#
    Case 2: VPN over a TE Tunnel When the TE Tunnel Is from PE1 to P2

    Topology


    Configuration

    The additional TE configuration over the basic configuration on PE1 is shown here:
    PE1
    PE1# show run interface tunnel 0
    !
    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
    !
    Verification

    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}.
    PE1# show ip cef vrf aqua 172.16.13.13
    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#
    Label 19, the outer label, is used to reach next hop 10.11.11.11/32, as shown here:
    PE1# show ip cef 10.11.11.11
    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 {19}
    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# show mpls traffic-eng tunnels tunnel 0

    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 : -
    OutLabel : Ethernet2/0/2, 19
    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# show mpls traffic-eng tunnels tunnel 0 | i Label
    InLabel : -
    OutLabel : Ethernet2/0/2, 19
    PE1#
    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 show command confirms this:
    P1> show tag for tag 19
    Local Outgoing Prefix Bytes tag Outgoing Next Hop
    tag tag or VC or Tunnel Id switched interface
    19 Pop tag 10.2.2.2 0 [33] 2130 Et2/0 10.8.8.5
    P1>

    P1> show tag for tag 19 detail
    Local Outgoing Prefix Bytes tag Outgoing Next Hop
    tag tag or VC or Tunnel Id switched interface
    19 Pop tag 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>
    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 show command output on P2:
    P2# show tag forwarding-table tags 12308 detail
    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#
    Explanation

    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 Solution, 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:

    • 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).

    Solution

    The solution is to enable TDP across the TE tunnel.
    Configuration

    Shown here is the TE tunnel configuration on PE1 with TDP enabled on it. The additions are in boldface.
    PE1
    PE1# show run interface tunnel 0
    !
    interface Tunnel0
    ip unnumbered Loopback0
    no ip directed-broadcast
    no ip route-cache distributed
    tag-switching ip

    !--- This enables TDP.

    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:
    P2# show run | i directed-hello
    tag-switching tdp discovery directed-hello accept

    !--- This configures P2 to accept directed TDP hellos.

    P2#
    Verification

    PE1# show tag tdp neighbor | i Peer
    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# show ip cef vrf aqua 172.16.13.13
    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 18 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 18 12308}
    PE1#

    PE1# show mpls traffic-eng tunnels tunnel 0 | i Label
    InLabel : -
    OutLabel : Ethernet2/0/2, 19

    !--- This is the TE label learned via RSVP.

    PE1#
    PE1# show tag tdp bind 10.11.11.11 32
    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: 18

    !--- This is the TDP label from P2.
    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.
    P2# show tag for tag 18
    Local Outgoing Prefix Bytes tag Outgoing Next Hop
    tag tag or VC or Tunnel Id switched interface
    18 Pop tag 10.11.11.11/32 117496 POS2/0/0 point2point

    P2# show tag tdp discovery
    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# show tag tdp neighbor 10.2.2.2
    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:
    Directed Hello 10.5.5.5 -> 10.2.2.2, passive
    Addresses bound to peer TDP Ident:
    10.7.7.2 172.16.47.166 10.2.2.2

    PE1# show tag tdp neighbor 10.5.5.5
    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:
    Directed Hello 10.2.2.2 -> 10.5.5.5, active

    !--- This indicates the directed neighbor.

    Addresses bound to peer TDP Ident:
    10.5.5.5 10.12.12.5 10.8.8.5

    PE1# show ip route 10.11.11.11
    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
    A ping command from CE1 to a host on CE2 confirms the solution.
    CE1# ping 172.16.13.13

    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#
    Case 3: VPN Between CE1 and CE2 over a TE Tunnel from P1 to P2 When TDP/LDP Is Not Enabled

    Topology


    Configuration

    The tunnel configuration on PE1 is shown here:
    PE1
    P1# show run interface tunnel 0
    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
    Verification

    Verify how packets destined to CE2 172.16.13.13 get switched here. The show ip cef command output shows that packets to destination 172.16.13.13 are switched with the label stack {17 12308}:
    PE1# show ip cef vrf aqua 172.16.13.13
    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 {17 12308}
    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.
    P1# show ip cef 10.11.11.11 detail
    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# show mpls traffic-eng tunnel tunnel 0 | i Label
    InLabel : -
    OutLabel : Ethernet2/0, implicit-null
    P1# show tag for 10.11.11.11 detail
    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# show ip route 10.11.11.11
    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
    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.
    P2# show tag for tag 12308 detail
    Local Outgoing Prefix Bytes tag Outgoing Next Hop
    tag tag or VC or Tunnel Id switched interface
    This breaks the path of VPN packets destined to CE2. It is confirmed by the ping to CE2 172.16.13.13/32.
    PE1#
    CE1# ping 172.16.13.13

    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#
    Solution

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

    Topology


    Configuration

    With LDP enabled on the tunnel, the configurations on P1 appear as shown here. Additions are in boldface.
    PE1
    P1# show run interface tunnel 0
    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
    !
    Verification

    PE1 sends packets to prefix 172.16.13.13/32 with the label stack {17 12308}.
    PE1#
    PE1# show tag for 10.11.11.11 detail
    Local Outgoing Prefix Bytes tag Outgoing Next Hop
    tag tag or VC or Tunnel Id switched interface
    21 17 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# show ip cef 10.11.11.11 detail
    10.11.11.11/32, version 60, 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 {17}

    PE1# show ip cef vrf aqua 172.16.13.13
    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 {17 12308}
    P1 receives the packet with label stack {17 12308} and looks at its LFIB for label 17.
    P1# show tag for tag 17 detail
    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# show ip cef 10.11.11.11 detail
    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}
    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.
    P2# show tag for tag 18 detail
    Local Outgoing Prefix Bytes tag Outgoing Next Hop
    tag tag or VC or Tunnel Id switched interface
    18 Pop tag 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#
    PE2 receives the packet with label 12308, which switches the packet to CE2 successfully.
    PE2# show tag forwarding tags 12308 detail
    Local Outgoing Prefix Bytes tag Outgoing Next Hop
    tag tag or VC or Tunnel Id switched interface
    12308 Aggregate 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# ping 172.16.13.13

    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#
    Case 5: MPLS VPN over a Tunnel Between P1 and PE2

    Topology


    Configuration

    PE1
    P1# show run interface tunnel 0
    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
    Verification

    PE1 sends a packet destined to 172.16.13.13 to its next hop 10.11.11.11 with the label stack {17 12308}.
    PE1# show ip cef vrf aqua 172.16.13.13
    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 {17 12308}
    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.
    P1# show tag for 10.11.11.11 detail
    Local Outgoing Prefix Bytes tag Outgoing Next Hop
    tag tag or VC or Tunnel Id switched interface
    17 Untagged 10.11.11.11/32 411 Tu0 point2point
    MAC/Encaps=14/18, MTU=1500, Tag Stack{17}, 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# show tag for tag 17 detail
    Local Outgoing Prefix Bytes tag Outgoing Next Hop
    tag tag or VC or Tunnel Id switched interface
    17 Untagged 10.11.11.11/32 685 Tu0 point2point
    MAC/Encaps=14/18, MTU=1500, Tag Stack{17}, 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# show ip cef 10.11.11.11
    10.11.11.11/32, version 67
    0 packets, 0 bytes
    tag information set
    local tag: 17
    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, tags imposed {17}
    P2 receives the packet with label stack {17 12308}. P2, being the penultimate hop router, pops label 17.
    P2# show tag for tag 17 detail
    Local Outgoing Prefix Bytes tag Outgoing Next Hop
    tag tag or VC or Tunnel Id switched interface
    17 Pop tag 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#
    PE2 then receives the packet with the label 12308. P2 is aware that the destination for label 12308 is directly connected. Therefore, the ping from CE1 to CE2 is 10.
    PE2# show tag for tag 12308 detail
    Local Outgoing Prefix Bytes tag Outgoing Next Hop
    tag tag or VC or Tunnel Id switched interface
    12308 Aggregate 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#
    Note: 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.
    CE1# ping 172.16.13.13

    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#
    Known Issues

    Refer to Field Notice: MPLS VPN with TE and MPLS InterAS Advisory on Cisco IOS® Software for more details.
    Conclusion

    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.
    Cisco Support Community - Featured Conversations

    Cisco Support Community 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 here


    • Pseudowire over MPLS-TE Tunnelsg.rodegari@lutech.it21 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. Subscribe Reply



      • Re: Pseudowire over MPLS-TE Tunnelshritter28.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 {...Reply



        • Re: Pseudowire over MPLS-TE Tunnelsg.rodegari@lutech.it29.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...Reply



          • Re: Pseudowire over MPLS-TE Tunnelshritter29.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...Reply



            • Re: Pseudowire over MPLS-TE Tunnelsg.rodegari@lutech.it29.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. Reply



              • Re: Pseudowire over MPLS-TE Tunnelshritter29.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...Reply



              • Re: Pseudowire over MPLS-TE Tunnelsjiangu30.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...Reply



                • Re: Pseudowire over MPLS-TE Tunnelshritter30.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...Reply



                  • Re: Pseudowire over MPLS-TE Tunnelshritter30.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,Reply

      • More Replies
    • RSVP TE FRRgauravprakash2 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, GauravSubscribe Reply



      • Re: RSVP TE FRRshivlu17.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 MPLSVPNReply



        • Re: RSVP TE FRRgauravprakash18.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 )...Reply

    • MPLS TE Tunnelsgalo6 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!Subscribe Reply



      • Re: MPLS TE Tunnelshritter22.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,Reply



        • Re: MPLS TE Tunnelsgalo22.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!Reply



          • Re: MPLS TE Tunnelshritter22.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,Reply



            • Re: MPLS TE Tunnelsgalo24.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?Reply



              • Re: MPLS TE Tunnelshritter24.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,Reply



                • Re: MPLS TE Tunnelsgalo26.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...Reply

    • MPLS TE Tunnels configurationp.diaz2 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. ThanksSubscribe Reply



    • Pseudowire over TE MPLSfrancisco_12 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.. FranciscoSubscribe Reply



      • Re: Pseudowire over TE MPLSlaaubert23.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. Reply



    • MPLS TE with MPLS VPNmaher@pd.jaring.my4 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. maherSubscribe Reply



    • MPLS over GRE Tunnelsefairbanks4 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.Subscribe Reply



      • Re: MPLS over GRE Tunnelshritter24.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,Reply



        • Re: MPLS over GRE Tunnelsefairbanks25.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.Reply



          • Re: MPLS over GRE Tunnelshritter25.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, Reply

      • Re: MPLS over GRE Tunnelsq-coelho30.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. Reply

    • MPLS TE tunnels with DS-TEscytmax1 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 DenisovSubscribe Reply



      • Re: MPLS TE tunnels with DS-TErajiva15.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...Reply

    • MPLS over a TE tunnelthedquoc2 Replies24.08.2006 12:45 Hi , I tried to configure MPLS over a TE tunnel by following this link : Implementing an MPLS VPN over TE Tunnels [MPLS] - Cisco Systems . 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 & RegardsSubscribe Reply



      • Re: MPLS over a TE tunnelsean@managednetworks.com24.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.Reply

      • Re: MPLS over a TE tunnelhritter24.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...Reply

    • MPLS VPN and MPLS TEokopp1 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, OldaSubscribe Reply




    Subscribe Start A New Discussion

    Related Information






    Updated: Aug 10, 2005





  10. #10
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    Inter-AS MPLS VPN Configuration with VPNv4 eBGP Sessions Between ASBRs


    Document ID: 5811


    Contents

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

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

    Requirements

    This document assumes a working knowledge of MPLS and MPLS VPN. Please see the Related Information section of this document for links to other MPLS VPN documents.
    Components Used

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

    • Cisco IOS® Software Releases 12.2 and 12.2T

    Note: 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 show tag forwarding command would become show mpls forwarding 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.
    Conventions

    For more information on document conventions, refer to the Cisco Technical Tips Conventions.
    Configure

    In this section, you are presented with the information to configure the features described in this document.
    Note: To find additional information on the commands used in this document, use the Command Lookup Tool (registered customers only) .
    Network Diagram

    This document uses the network setup shown in the diagram below.

    Configurations

    This document uses the configurations shown below for the routers in the network diagram above.


    Pulligny
    version 12.2
    !
    hostname Pulligny
    !
    ip cef

    !--- Cisco Express Forwarding (CEF) must be enabled for MPLS.

    !
    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

    !--- TDP or LDP needs to be enabled inside each AS.

    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

    !--- No TDP, LDP, or routing protocols enabled on the inter-AS link.

    !
    router isis
    redistribute connected metric 20

    !--- To get the host route created by the Border Gateway Protocol (BGP)
    !--- into the Interior Gateway Protocol (IGP).


    net 47.0000.5555.5555.5555.00
    metric-style wide
    !
    router bgp 1
    no bgp default ipv4-unicast

    !--- BGP is not used for IPv4 unicast.

    no bgp default route-target filter

    !--- Needed to accept VPNv4 prefixes.

    neighbor 10.1.1.9 remote-as 2

    !--- External BGP (eBGP) to Pomerol.

    neighbor 10.10.10.4 remote-as 1
    neighbor 10.10.10.4 update-source Loopback0

    !--- Internal BGP (iBGP) to PEscara.

    !
    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

    !--- Address family to allow BGP to carry VPN-IPv4 protocols.

    !
    ip classless
    !
    end
    PEscara
    hostname PEscara
    !
    ip vrf one
    rd 1:1
    route-target export 1:1
    route-target import 1:1

    !--- Create a virtual routing and forwarding (VRF) instance called one
    !--- with a route distinguished value of 1:1. Routes with route target
    !--- values of 1:1 will be imported into the VRF and exported out
    !--- of the VRF.

    ip cef

    !--- CEF must be enabled for MPLS.

    !
    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

    !--- Associates the interface with VRF one.

    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

    !--- iBGP to Pulligny.

    !
    address-family ipv4 vrf one
    redistribute connected
    no auto-summary
    no synchronization
    exit-address-family

    !--- 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).


    !
    address-family vpnv4
    neighbor 10.10.10.2 activate
    neighbor 10.10.10.2 send-community both
    exit-address-family

    !--- Address family to allow BGP to carry VPN-IPv4 protocols.

    !
    ip classless
    !
    end
    Pauillac

    !--- 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.


    !
    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

    !--- The Pomerol router is an autonomous system border router (ASBR)
    !--- like Pulligny and its configuration is very similar to Pomerol's.


    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

    !--- The PEsaro router is a PE router like the PEscara router, and its
    !--- configuration is very similar.


    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
    Configuration Notes


    • 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 no bgp default route-target filter 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.

    Verifying and Understanding Inter-AS MPLS VPN

    This section provides information which you can use to confirm that your configuration is working properly.
    Certain show commands are supported by the Output Interpreter Tool (registered customers only) , which allows you to view an analysis of show command output.
    For more information on the commands used below, please see How to Troubleshoot the MPLS VPN.
    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.
    PEsaro Router

    Below are the routes for VFR one in the PEsaro router.
    PEsaro# show ip route vrf one
    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 10.1.1.10, 00:26:49

    PEsaro# show ip cef vrf one 120.0.0.1
    120.0.0.0/24, version 10, cached adjacency to Serial0/1.1
    0 packets, 0 bytes
    tag information set
    local tag: VPN-route-head
    fast tag rewrite with Se0/1.1, point2point, tags imposed: {17 22}
    via 10.1.1.10, 0 dependencies, recursive
    next hop 10.1.1.21, Serial0/1.1 via 10.1.1.10/32
    valid cached adjacency
    tag rewrite with Se0/1.1, point2point, tags imposed: {17 22}
    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.
    PEsaro# show ip bgp vpnv4 vrf one tags
    Network Next Hop In tag/Out tag
    Route Distinguisher: 1:1 (one)
    120.0.0.0/24 10.1.1.10 notag/22

    !--- VPN label.

    220.0.0.0 0.0.0.0 18/aggregate(one)

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

    PEsaro# show ip route 10.1.1.10
    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
    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.
    Pomerol Router

    Pomerol# show tag forwarding
    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 1704 Se0/0.3 point2point

    Pomerol# show ip route 10.1.1.10
    Routing entry for 10.1.1.10/32
    Known via "connected", 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
    Note: 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.
    Pulligny Router

    Pulligny# show tag forwarding
    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
    22 16 1:1:120.0.0.0/24 1080 Se0/0.1 point2point
    The output above shows that Pulligny has local and outgoing tags for 120.0.0.0/24; consider, however, the following detailed TFIB entry:
    Pulligny# show tag forwarding detail | begin 22
    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
    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.
    Pulligny# show ip bgp vpnv4 all tagging
    Network Next Hop In tag/Out tag
    Route Distinguisher: 1:1
    120.0.0.0/24 10.10.10.4 22/23
    220.0.0.0 10.1.1.9 notag/18

    Pulligny# show tagging for 10.10.10.4
    Local Outgoing Prefix Bytes tag Outgoing Next Hop
    tag tag or VC or Tunnel Id switched interface
    19 16 10.10.10.4/32 0 Se0/0.1 point2point
    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]).
    Pauillac# show tag forwarding
    Local Outgoing Prefix Bytes tag Outgoing Next Hop
    tag tag or VC or Tunnel Id switched interface
    16 Pop tag 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
    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).
    PEscara# show tag forwarding
    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
    23 Aggregate 120.0.0.0/24[V] 1040

    PEscara# show tag forwarding detail | begin 23
    23 Aggregate 120.0.0.0/24[V] 1040
    MAC/Encaps=0/0, MTU=0, Tag Stack{}
    VPN route: one
    Feature Quick flag set
    The output below is an example of one packet being sent using the packet flow explained above.
    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
    The next-hop-self Command on ASBRs

    If you choose to configure the next-hop-self 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.
    Pomerol# show tag forwarding
    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
    19 22 1:1:120.0.0.0/24 0 Se0/0.1 point2point
    Troubleshoot

    There is currently no specific troubleshooting information available for this configuration.
    Related Information






    Updated: Aug 10, 2005




  11. #11
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    Internet Access from an MPLS VPN Using a Global Routing Table


    Document ID: 24508


    Contents

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

    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).
    Prerequisites

    Requirements

    A basic understanding of MPLS forwarding and MPLS VPN is required to fully understand the contents of this document.
    Components Used

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

    • 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

    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.
    Background Theory

    In this example configuration, these policies were in place:

    • 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.
      Note: 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.

    Conventions

    These acronyms are used in this document:

    • CE - Customer Edge router
    • PE - Provider Edge router
    • P - Provider core router

    For more information on document conventions, refer to Cisco Technical Tips Conventions.
    Configure


    • You can refer to the Network Diagram 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 Background Theory 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.

    Note: 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.
    ip route vrf customer1 0.0.0.0 0.0.0.0 192.168.67.1 global
    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.
    Note: 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 ip route command used in configuration on PE 1.
    ip route 11.11.11.0 255.255.255.0 Serial8/0 192.168.10.1
    Note: 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.
    ip route vrf customer1 11.11.11.0 255.255.255.0 192.168.10.1
    Note: To find additional information on the commands used in this document, use the Command Lookup Tool ( registered customers only) .
    Network Diagram

    This document uses the network setup shown in the diagram below.

    Configurations

    This document uses the configurations shown below.


    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

    !--- The interface is connected to PE 1.

    !
    ip classless
    ip route 0.0.0.0 0.0.0.0 192.168.10.2

    !--- This is the default route to route all packets to PE 1.

    !
    PE 1
    version 12.2
    !
    hostname PE-1
    !
    ip subnet-zero
    !
    ip vrf customer1

    !--- This configured VRF customer1.

    rd 100:1

    !--- This configured the route distiguisher for VRF.

    route-target export 1:1
    route-target import 1:1

    !--- This configured the export and import policies into VRF.

    !
    ip cef

    !--- This enabled Cisco Express Forwarding (CEF) switching.

    !
    interface Loopback0
    ip address 10.1.1.2 255.255.255.255
    !
    interface Ethernet0/0

    !--- It is connected to P router.

    ip address 10.10.23.2 255.255.255.0
    tag-switching ip

    !--- MPLS switching is enabled.

    !
    interface Serial8/0
    ! Connected to CE-1
    ip vrf forwarding customer1

    !--- Route forwarding based on customer1 VRF is enabled.

    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

    !--- Neighbor relationship with PE 2 is established.

    neighbor 10.1.1.4 update-source Loopback0
    neighbor 10.1.1.4 next-hop-self
    no auto-summary
    !
    address-family ipv4 vrf customer1

    !--- The address-family configuration mode specifies IPv4 unicast
    !---address prefixes for customer1 VRF.


    no auto-summary
    no synchronization
    network 11.11.11.0 mask 255.255.255.0

    !--- CE 1 network 11.11.11.0/24 to PE 2 is announced.

    network 192.168.10.0 mask 255.255.255.252
    exit-address-family
    !
    address-family vpnv4

    !--- This is the address-family VPNV4 configuration mode for
    !--- configuring BGP sessions.


    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

    !--- The static route in the global routing table is pointing to
    !--- the interface connected to CE 1.


    ip route vrf customer1 0.0.0.0 0.0.0.0 192.168.67.1 global

    !--- The static default route under customer1 VRF, routing packets
    !--- outside of VPN to the Internet gateway.


    ! routes
    ip route vrf customer1 11.11.11.0 255.255.255.0 192.168.10.1

    !--- 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.



    P
    version 12.2
    !
    hostname P
    !
    ip subnet-zero
    !
    ip cef

    !--- CEF switching is enabled.

    !
    interface Loopback0
    ip address 10.1.1.3 255.255.255.255
    !
    interface Ethernet0/0

    !--- This is connected to PE 1.

    ip address 10.10.23.3 255.255.255.0
    tag-switching ip

    !--- MPLS switching is enabled.

    !
    interface Ethernet1/0

    !--- This is connected to PE 2.

    ip address 10.10.34.3 255.255.255.0
    tag-switching ip
    !
    interface Ethernet2/0

    !--- This is connected to the Internet gateway.

    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

    !--- This enabled CEF switching.

    !
    interface Loopback0
    ip address 10.1.1.6 255.255.255.255
    !
    interface Ethernet2/0

    !--- This is connected to P router.

    ip address 10.10.36.6 255.255.255.0
    tag-switching ip
    !
    interface Serial8/0

    !--- This is connected to Internet R7.

    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

    !--- Customer1 VRF is configured.

    rd 100:1

    !--- Route Distinguisher for VRF is configured.

    route-target export 1:1
    route-target import 1:1

    !--- This configured the import and export policies for customer1
    !--- VRF.


    !
    ip cef

    !--- This enabled CEF switching.

    !
    interface Loopback0
    ip address 10.1.1.4 255.255.255.255
    interface Ethernet1/0

    !--- Connected to P router.

    ip address 10.10.34.4 255.255.255.0
    tag-switching ip

    !--- MPLS switching is enabled.

    !
    interface Serial9/0

    !--- Connected to CE 2 router.

    ip vrf forwarding customer1

    !--- This enables VRF forwarding on the interface.

    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

    !--- This is the address-family IPv4 configuration of customer1 VRF.

    no auto-summary
    no synchronization
    network 22.22.22.0 mask 255.255.255.0

    !--- This announces the CE 2 network to PE 1.

    exit-address-family
    !
    address-family vpnv4

    !--- This is the address-family VPNV4 configuration for BGP Sessions
    !--- with PE 1.


    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

    !--- 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.


    ip route vrf customer1 0.0.0.0 0.0.0.0 192.168.67.1 global

    !--- This is the static default route for customer VRF
    !--- for destinations outside the VPN.


    ip route vrf customer1 22.22.22.0 255.255.255.0 192.168.20.2

    !--- This is the static route within customer1 VRF for CE 2
    !--- network for VPN connectivity.



    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

    !--- This is connected to PE 2.

    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

    !--- This is the default route pointing to PE 2.


    Verify

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

    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 show commands are supported by the Output Interpreter Tool ( registered customers only) , which allows you to view an analysis of show command output.

    1. The show ip route vrf customer1 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.
      PE-1# show ip route vrf customer1
      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:00:50
      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
    2. Similarily, at PE 2, the route to network 11.11.11.0/24 in the customer1 VRF is shown in the example below.
      PE-2# show ip route vrf customer1
      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 11.11.11.0 [200/0] via 10.1.1.2, 01:00:09
      S* 0.0.0.0/0 [1/0] via 192.168.67.1
    3. 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.
      CE-1# ping
      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

    Connectivity to the Internet from CE 1

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

    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.
      CE-1# show ip route 0.0.0.0
      Routing entry for 0.0.0.0/0, supernet
      Known via "static", distance 1, metric 0, candidate default path
      Routing Descriptor Blocks:
      * 192.168.10.2
      Route metric is 0, traffic share count is 1
    2. 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.
      PE-1# show ip route vrf customer1
      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
      S* 0.0.0.0/0 [1/0] via 192.168.67.1
    3. 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.
      PE-1# show ip route 192.168.67.1
      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:
      * 10.10.23.3, from 10.1.1.6, 00:21:54 ago, via Ethernet0/0
      Route metric is 84, traffic share count is 1
    4. 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.
      IGW# show ip route 99.99.99.0
      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:
      * 192.168.67.2, from 192.168.67.2, 01:37:25 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      The packets that originated from CE-1 get routed to the Internet.
    5. 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.
      IGW# show ip route 11.11.11.0
      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# show ip route 11.11.11.0
      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:
      * 192.168.10.1, via Serial8/0
      Route metric is 0, traffic share count is 1
    6. 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.
      CE-1# ping
      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:
      !!!!!
      Success rate is 100 percent (5/5), round-trip min/avg/max = 20/24/32 ms
      CE-1#

    Troubleshoot

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

    Cisco Support Community 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 here


    • Internet Access from an MPLS VPN Using...mlj@sungard.com4 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 advanceSubscribe Reply



    • Redundant access from MPLS VPN to...andris.zarins15 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 Subscribe Reply



      • Re: Redundant access from MPLS VPN to...mheusinger30.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...Reply

      • Re: Redundant access from MPLS VPN to...mheusinger30.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 MartinReply



        • Re: Redundant access from MPLS VPN to...andris.zarins30.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...Reply



      • More Replies
    • MPLS and the Global Routing Table...efairbanks1 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.Subscribe Reply



    • DSL Access to MPLS VPN Global routing...paulledwidge2 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.Subscribe Reply



    • Full internet routing in an internet...m.amstelveen3 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, MikeSubscribe Reply



      • Re: Full internet routing in an...waris03.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...Reply



        • Re: Full internet routing in an...m.amstelveen03.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. -MikeReply



          • Re: Full internet routing in an...waris06.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. -WarisReply

    • Internet routes, Global Routing table...peter.danielsen1 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 /PeterSubscribe Reply



      • Re: Internet routes, Global Routing...mheusinger06.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"...Reply

    • access from the global routing table to...ji.xie1 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.Subscribe Reply



    • Global table to MPLS VPN problemplearmouth12 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 Subscribe Reply



      • Re: Global table to MPLS VPN problemgiuslar05.11.2008 10:29 Hello Paul, look at the following example: Route Leaking in MPLS/VPN Networks [Multiprotocol Label Switching for VPNs (MPLS for VPNs)] - Cisco Systems 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 Reply



        • Re: Global table to MPLS VPN problemplearmouth05.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 PaulReply



          • Re: Global table to MPLS VPN problemgiuslar05.11.2008 11:21 Hello Paul, have you got redistribute static within address-family ipv4 vrf vrf-name ? Hope to help Giuseppe Reply



            • Re: Global table to MPLS VPN problemplearmouth05.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)...Reply



              • Re: Global table to MPLS VPN problemplearmouth05.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 Reply



                • Re: Global table to MPLS VPN problemgiuslar05.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 Reply



                  • Re: Global table to MPLS VPN problemplearmouth06.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...Reply



                    • Re: Global table to MPLS VPN problemgiuslar13.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 Reply



                      • Re: Global table to MPLS VPN problemplearmouth13.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 Reply



                        • Re: Global table to MPLS VPN problembenjaminwang7417.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),...Reply

      • More Replies
    • MPLS/VPN internet accessv.matiakis3 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 advanceSubscribe Reply



      • Re: MPLS/VPN internet accessyagnesh_tel14.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...Reply



        • Re: MPLS/VPN internet accessv.matiakis15.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? Reply



          • Re: MPLS/VPN internet accessyagnesh_tel15.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...Reply

    • MPLS VPN internet access using L2TPianwarb3 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. Subscribe Reply




    Subscribe Start A New Discussion

    Related Information






    Updated: Aug 10, 2005




  12. #12
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    MPLS Basic Traffic Engineering Using OSPF Configuration Example



    Document ID: 13731


    Contents

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

    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.
    Prerequisites

    Requirements

    There are no specific requirements for this document.
    Components Used

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

    • Cisco IOS® Software Releases 12.0(11)S and 12.1(3a)T
    • Cisco 3600 routers

    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.
    Conventions

    Refer to Cisco Technical Tips Conventions for more information on document conventions.
    Functional Components

    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.

    Configure

    In this section, you are presented with the information to configure the features described in this document.
    Note: Use the Command Lookup Tool (registered customers only) to find more information on the commands used in this document.
    Network Diagram

    This document uses this network setup:

    Quick Configuration Guide

    You can use the following steps to perform a quick configuration. Refer to MPLS Traffic Engineering and Enhancements for more detailed information.

    1. Set up your network with the usual configuration. (In this case, we used Frame Relay.)
      Note: 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.
    2. 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:

      • For IS-IS:
        metric-style [wide | both]
        mpls traffic-eng router-id LoopbackN
        mpls traffic-eng [level-1 | level-2 |]
      • For OSPF:
        mpls traffic-eng area X
        mpls traffic-eng router-id LoopbackN (must have a 255.255.255.255 mask)

    3. Enable MPLS TE. Enter ip cef (or ip cef distributed if available in order to enhance performance) in the general configuration mode. Enable MPLS (tag-switching ip) on each concerned interface. Enter mpls traffic-engineering tunnel to enable MPLS TE, as well as RSVP for zero-bandwidth TE tunnels.
    4. Enable RSVP by entering ip rsvp bandwidth XXX on each concerned interface for non-zero bandwidth tunnels.
    5. Set up tunnels to be used for TE. There are many options that can be configured for MPLS TE Tunnel, but the tunnel mode mpls traffic-eng command is mandatory. The tunnel mpls traffic-eng autoroute announce command announces the presence of the tunnel by the routing protocol.
      Note: Do not forget to use ip unnumbered loopbackN 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.

    Configuration Files

    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 bold text.
    Pesaro
    Current configuration:

    !

    version 12.1

    !

    hostname Pesaro

    !


    ip cef


    !

    mpls traffic-eng tunnels

    !

    interface Loopback0

    ip address 10.10.10.6 255.255.255.255

    !

    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


    !

    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


    tag-switching ip


    mpls traffic-eng tunnels

    frame-relay interface-dlci 603

    ip rsvp bandwidth 512 512

    !

    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

    mpls traffic-eng area 9

    mpls traffic-eng router-id Loopback0

    !

    ip classless

    !

    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


    !

    end
    Pescara
    Current configuration:

    !

    version 12.0

    !

    hostname Pescara

    !


    ip cef


    !

    mpls traffic-eng tunnels

    !

    interface Loopback0

    ip address 10.10.10.4 255.255.255.255

    !

    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


    !

    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

    mpls traffic-eng tunnels


    tag-switching ip


    frame-relay interface-dlci 401

    ip rsvp bandwidth 512 512

    !

    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

    mpls traffic-eng area 9

    mpls traffic-eng router-id Loopback0


    !

    end
    Pomerol
    Current configuration:



    version 12.0

    !

    hostname Pomerol

    !


    ip cef


    !

    mpls traffic-eng tunnels

    !

    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

    mpls traffic-eng tunnels


    tag-switching ip


    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

    mpls traffic-eng tunnels


    tag-switching ip


    frame-relay interface-dlci 302

    ip rsvp bandwidth 512 512

    !

    interface Serial0/1.3 point-to-point

    bandwidth 512

    ip address 10.1.1.21 255.255.255.252

    mpls traffic-eng tunnels


    tag-switching ip


    frame-relay interface-dlci 306

    ip rsvp bandwidth 512 512

    !

    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

    mpls traffic-eng area 9

    mpls traffic-eng router-id Loopback0


    !

    ip classless

    !

    end
    Pulligny
    Current configuration:

    !

    version 12.1

    !

    hostname Pulligny

    !


    ip cef


    !

    mpls traffic-eng tunnels

    !

    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

    mpls traffic-eng tunnels


    tag-switching ip


    frame-relay interface-dlci 201

    ip rsvp bandwidth 512 512

    !

    interface Serial0/1.2 point-to-point

    bandwidth 512

    ip address 10.1.1.10 255.255.255.252

    mpls traffic-eng tunnels


    tag-switching ip


    frame-relay interface-dlci 203

    ip rsvp bandwidth 512 512

    !

    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

    mpls traffic-eng area 9

    mpls traffic-eng router-id Loopback0


    !

    ip classless

    !

    end
    Pauillac
    !

    version 12.1

    !

    hostname pauillac

    !


    ip cef


    !

    mpls traffic-eng tunnels

    !

    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

    mpls traffic-eng tunnels


    tag-switching ip


    frame-relay interface-dlci 102

    ip rsvp bandwidth 512 512

    !

    interface Serial0/0.2 point-to-point

    bandwidth 512

    ip address 10.1.1.5 255.255.255.252

    mpls traffic-eng tunnels


    tag-switching ip


    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

    mpls traffic-eng tunnels


    tag-switching ip


    frame-relay interface-dlci 104

    ip rsvp bandwidth 512 512

    !

    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

    mpls traffic-eng area 9

    mpls traffic-eng router-id Loopback0


    !

    ip classless

    !

    end
    Verify

    This section provides information you can use to confirm your configuration is working properly.
    General show commands are illustrated in Configuring MPLS Basic Traffic Engineering Using IS-IS. The following commands are specific to MPLS TE with OSPF and are illustrated below:

    • show ip ospf mpls traffic-eng link
    • show ip ospf database opaque-area

    The Output Interpreter Tool (registered customers only) (OIT) supports certain show commands. Use the OIT to view an analysis of show command output.
    Sample show Command Output

    You can use the show ip ospf mpls traffic-eng link 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).
    Pesaro# show ip ospf mpls traffic-eng link

    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
    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

    Affinity Bit : 0x0
    The show ip ospf database 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:
    Pesaro# show ip ospf database opaque-area

    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
    Troubleshoot

    There is currently no specific troubleshooting information available for this configuration.
    Related Information






    Updated: Aug 10, 2005





  13. #13
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272

  14. #14
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    MPLS Command Guide

    کد:
    http://www.cisco.com/en/US/docs/ios/12_1/switch/command/reference/xrdscmd9.html




کلمات کلیدی در جستجوها:

mpls configuration example

sample mpls configurationmpls configuration examplescisco mpls configuration examplebasic mpls configuration examplempls config examplesite to site vpn.pktmplscisco mpls configuration examples and technotestypical mpls network diagramcisco configuration example technote qos255.255.255.2552mpls example configurationmpls sample configurationcisco mpls example configurationjuniper mpls configuration examplestep by step mpls configuration examplesiii.on r1 direct all the traffic going to network 11.3.3.0 through the gre tunnel. depending on what 
routing protocol you use watch out for: example mpls configurationmpls configurations examples1juniper L2circuit testing PE To PEigw connectivity diagramredistribute bgp 64521 metric 100 subnets

برچسب برای این موضوع

مجوز های ارسال و ویرایش

  • شما نمی توانید موضوع جدید ارسال کنید
  • شما نمی توانید به پست ها پاسخ دهید
  • شما نمی توانید فایل پیوست ضمیمه کنید
  • شما نمی توانید پست های خود را ویرایش کنید
  •