Downloads |
Table Of Contents
MPLS Traffic Engineering: Inter-AS TE
Prerequisites for MPLS Traffic Engineering: Inter-AS TE
Restrictions for MPLS Traffic Engineering: Inter-AS TE
Information About MPLS Traffic Engineering: Inter-AS TE
MPLS Traffic Engineering Tunnels
How to Configure MPLS Traffic Engineering: Inter-AS TE
Configuring an Explicit Path on the Tunnel That Will Cross the Inter-AS Link
Configuring a Route to Reach the Remote ASBR
Configuring a Static Route from the MP to the PLR
Configuring ASBR Forced Link Flooding
Configuring the Inter-AS Link as a Passive Interface Between Two ASBRs
Creating LSPs Traversing the ASBRs
Configuring Multiple Neighbors on a Link
Debugging ASBR Forced Link Flooding
Verifying the Inter-AS TE Configuration
Configuration Examples for MPLS Traffic Engineering: Inter-AS TE
Configuring Loose Hops: Examples
Configuring an Explicit Path on the Tunnel That Will Cross the Inter-AS Link: Example
Configuring a Route to Reach the Remote ASBR in the IP Routing Table: Example
Configuring a Static Route from the MP to the PLR: Example
Configuring ASBR Forced Link Flooding: Examples
Configuring the Inter-AS Link as a Passive Interface: Example
Creating LSPs Traversing the ASBRs: Example
Configuring Multiple Neighbors on a Link: Example
mpls traffic-eng passive-interface
Feature Information for MPLS Traffic Engineering: Inter-AS TE
MPLS Traffic Engineering: Inter-AS TE
First Published: August 09, 2004Last Updated: June 29, 2007The MPLS Traffic Engineering: Inter-AS TE feature provides Autonomous System Boundary Router (ASBR) node protection, loose path reoptimization, stateful switchover (SSO) recovery of label-switched paths (LSPs) that include loose hops, ASBR forced link flooding, Cisco IOS Resource Reservation Protocol (RSVP) local policy extensions for interautonomous system (Inter-AS), and per-neighbor keys:
•
ASBR node protection—Protects interarea and Inter-AS TE label-switched paths (LSPs) from the failure of an Area Border Router (ABR) or ASBR.
•
•
•
•
•
Finding Feature Information in This Module
Your Cisco IOS software release may not support all of the features documented in this module. To reach links to specific feature documentation in this module and to see a list of the releases in which each feature is supported, use the "Feature Information for MPLS Traffic Engineering: Inter-AS TE" section.
Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
•
•
•
•
•
Prerequisites for MPLS Traffic Engineering: Inter-AS TE
•
•
•
–
–
–
•
–
–
–
Restrictions for MPLS Traffic Engineering: Inter-AS TE
Loose Path Reoptimization
•
ASBR Forced Link Flooding
•
•
•
•
Information About MPLS Traffic Engineering: Inter-AS TE
To configure the MPLS Traffic Engineering: Inter-AS TE feature, you need to understand the following concepts:
•
MPLS Traffic Engineering Tunnels
MPLS TE lets you build LSPs across your network that you then forward traffic down.
MPLS TE LSPs, also called TE tunnels, let the headend of a TE tunnel control the path its traffic takes to a particular destination. This method is more flexible than forwarding traffic based only on a destination address.
Interarea tunnels allow you to do the following:
•
•
Some tunnels are more important than others. For example, you may have tunnels carrying Voice over IP (VoIP) traffic and tunnels carrying data traffic that are competing for the same resources. Or you may simply have some data tunnels that are more important than others. MPLS TE allows you to have some tunnels preempt others. Each tunnel has a priority, and more-important tunnels take precedence over less-important tunnels.
Multiarea Network Design
You can establish MPLS TE tunnels that span multiple IGP areas and levels. The tunnel headend routers and tailend routers do not have to be in the same area. The IGP can be either IS-IS or OSPF.
To configure an interarea tunnel, use the next-address loose command to specify on the headend router a loosely routed explicit path of the LSP that identifies each ABR the LSP should traverse. The headend router and the ABRs along the specified explicit path expand the loose hops, each computing the path segment to the next ABR or tunnel destination.
Fast Reroute
MPLS Fast Reroute (FRR) is a fast recovery local protection technique that protects TE LSPs from link, shared risk link group (SRLG), and node failure. One or more TE LSPs (called backup LSPs) are preestablished to protect against the failure of a link, node, or SRLG. If there is a failure, each protected TE LSP traversing the failed resource is rerouted onto the appropriate backup tunnels.
The backup tunnel must meet the following requirements:
•
•
•
ASBR Node Protection
A TE LSP that traverses an ASBR needs a special protection mechanism (ASBR node protection) because the MP and PLR will be in different autonomous systems that have different IGPs.
A PLR ensures that the backup tunnel intersects with the primary tunnel at the MP by examining the Record Route Object (RRO) of the primary tunnel to see if any addresses specified in the RRO match the destination of the backup tunnel.
Addresses specified in RRO IPv4 and IPv6 subobjects can be node-IDs and interface addresses. The traffic engineering RFC 3209 specifies that you can use a router address or interface address, but recommends using the interface address of outgoing path messages. Therefore, in Figure 1 router R2 is more likely to specify interface addresses in the RRO objects carried in the resv messages of the primary tunnel (T1) and the backup tunnel.
Node IDs allow the PLR to select a suitable backup tunnel by comparing node IDs in the resv RRO to the backup tunnel's destination.
RSVP messages that must be routed and forwarded to the appropriate peer (for example, an resv message) require a route from the MP back to the PLR for the RSVP messages to be delivered. The MP needs a route to the PLR backup tunnel's outgoing interface for the resv message to be delivered. Therefore, you must configure a static route from the MP to the PLR. For the configuration procedure, see the "Configuring a Static Route from the MP to the PLR" section.
Figure 1 illustrates ASBR node protection. Router R4 is node-protected with a backup tunnel from R2-R3-R5-R6.
Figure 1 ASBR Node Protection
In this configuration, IP addresses are as follows:
•
–
–
•
–
–
–
•
–
–
–
•
–
–
–
•
–
–
–
•
–
–
In Figure 1, the following situations exist:
•
•
•
•
•
•
•
•
•
•
Router R2 needs to ensure the following:
•
•
Node-IDs Signaling in RROs
ASBR node protection includes a node-ID flag (0x20), which is also called a node-ID subobject. When it is set, the flag indicates that the address specified in the RRO object in the resv message is the node-ID address. The node-ID address refers to the traffic engineering router ID.
A node must always use the same address in the RRO (that is, it must use IPv4 or IPv6, but not both).
To display all the hops, enter the following command on the headend router. Sample command output is as follows:
Router(config)# show ip rsvp reservations detailReservation:Tun Dest: 10.10.0.6 Tun ID: 100 Ext Tun ID: 10.10.0.1Tun Sender: 10.10.0.1 LSP ID: 31Next Hop: 10.10.1.2 on Ethernet0/0Label: 17 (outgoing)Reservation Style is Shared-Explicit, QoS Service is Controlled-LoadAverage Bitrate is 10K bits/sec, Maximum Burst is 1K bytesMin Policed Unit: 0 bytes, Max Pkt Size: 0 bytesRRO:10.10.0.2/32, Flags:0x29 (Local Prot Avail/to NNHOP, Is Node-id)10.10.4.1/32, Flags:0x9 (Local Prot Avail/to NNHOP)Label subobject: Flags 0x1, C-Type 1, Label 1710.10.0.4/32, Flags:0x20 (No Local Protection, Is Node-id)10.10.7.1/32, Flags:0x0 (No Local Protection)Label subobject: Flags 0x1, C-Type 1, Label 1710.10.0.6/32, Flags:0x20 (No Local Protection, Is Node-id)10.10.7.2/32, Flags:0x0 (No Local Protection)Label subobject: Flags 0x1, C-Type 1, Label 0Resv ID handle: 0100040E.Status:Policy: Accepted. Policy source(s): MPLS/TEFor a description of the fields, see the Cisco IOS Quality of Service Solutions Command Reference.
Addition of the Node-ID Subobject
When a fast reroutable LSP is signaled, the following actions occur:
•
•
If you enable record-route on the headend LSR, the interface addresses for the LSP are included in the RRO object of the resv message.
To enable record-route, enter the following command with the record-route keyword:
tunnel mpls traffic-eng record-routeProcessing of an RRO with Node-ID Subobjects
The node-ID subobject is added to the RECORD_ROUTE object before the label route subobject. If RECORD_ROUTE is turned on, the RRO object consists of the following in this order: node-ID, interface address, and label.
Merge Point Location
The destination of the backup tunnel is the node-ID of the MP. A PLR can find the MP and appropriate backup tunnel by comparing the destination address of the backup tunnel with the node-ID subobjects included in the resv RRO for the primary tunnel.
When both the IPv4 node-ID and IPv6 node-ID subobjects are present, a PLR can use either or both of them to find the MP address.
Determination of Backward Compatibility
To remain compatible with nodes that do not support RRO IPv4 or IPv6 node-ID subobjects, a node can ignore those objects. Those nodes cannot be the MP in a network with interarea or Inter-AS traffic engineering.
Loose Path Reoptimization
Interarea and Inter-AS LSPs
If the LSP of an MPLS TE tunnel traverses hops that are not in the headend router's topology database (that is, the hops are in a different OSPF area or IS-IS level), the LSP is called an interarea TE LSP.
If the LSP of the tunnel traverses hops that are in a different autonomous system (AS) from the tunnel's headend router, the LSP is called an Inter-AS TE LSP.
Interarea LSPs and Inter-AS TE LSPs can be signaled using loose hop subobjects in their EROs. The headend does not have "strict" knowledge of hops beyond its area, so the LSP's path is "loosely" specified at the headend. Downstream routers processing these loose hop subobjects (which do have the knowledge) are relied upon to expand them into strict hops.
Loose Hop Configuration
Beyond the headend area, configure hops as loose hops. Typically you specify only the ABRs and the tailend router of a tunnel, but any other combination is allowed.
Loose Hop Expansion
Loose hop expansion is the conversion of a single ERO loose hop subobject into one or more strict hop subobjects.
Interarea and Inter-AS TE LSPs can be signaled using loose hop subobjects in their EROs. When a router receives a path message containing an ERO that has a loose hop as the next address, the router typically expands the ERO by converting the single loose hop subobject into one or more strict hop subobjects. The router typically has the knowledge, in its topology database, of the best way to reach the loose hop and computes this path by using constraint-based shortest path first (CSPF). So the router substitutes this more specific information for the loose hop subobject found in the ERO. This process is called loose hop expansion or ERO expansion.
Loose hop expansions can occur at one or more hops along an LSP's path. This process is referred to as loose path reoptimization.
Tunnel Reoptimization Procedure
Tunnel reoptimization is the signaling of an LSP that is more optimal than the LSP a TE tunnel is currently using (for example, it may be shorter or may have a lower cost), and the switching over of the tunnel's data to use this new LSP.
The new more optimal TE LSP is always established and the data moved onto it before the original LSP is torn down (so it is called the "make before break" procedure). This ensures that no data packets are lost during the transition to the new LSP.
The TE LSPs reoptimization process is triggered under the following circumstances:
•
•
•
Regardless of how reoptimization is triggered, the headend router reoptimizes a tunnel only if it can find a better path than the one the tunnel currently uses. If there is not a better path in the local topology database, no new LSP is signaled and reoptimization does not occur.
Prior to the addition of loose path reoptimization, interarea TE LSPs were not reoptimized if a better path became available in any area beyond the headend area. This is because the headend router was not capable of finding a better path when the better path existed in an area beyond its view (that is, it was not in its local topology database).
With the addition of loose path reoptimization, a tunnel's headend can reoptimize LSPs even if they span multiple areas, levels, or autonomous systems. This is done via the implementation of a query and response protocol defined in draft-vasseur-mpls-loose-path-reopt-02.txt. This draft defines a protocol whereby a tunnel's headend may query downstream routers to perform ERO expansion for this tunnel's LSP. These downstream routers respond in the affirmative if they can find a more optimal path than the one in use. (This is done via a new ERO expansion.) Having received an affirmative answer to its query, a headend signals a new LSP for the tunnel, and the new LSP benefits from a new ERO expansion along the better path.
Loose path reoptimization is on by default, and cannot be disabled. Whenever an LSP reoptimization is attempted but the headend fails to find a better path, if the LSP contains loose ERO subobjects, a query is sent downstream to determine whether downstream routers can find a better path. If an affirmative answer comes back, the LSP is reoptimized. That is, a new LSP is signaled (which will follow the better path), the tunnel's data packets are switched over to use this new LSP, and the original LSP is torn down.
For details on this query and response protocol, see draft-vasseur-mpls-loose-path-reopt-02.txt.
ASBR Forced Link Flooding
When you configure forced link flooding on an interface, the MPLS TE link management module advertises the link to all nodes. As a result of this advertisement, the TE topology database on all the nodes within the Inter-AS is updated with this information.
ASBR forced link flooding allows the links to be advertised even if IGP adjacencies are not running over these links. TE LSPs can traverse these links at the edge of a network between two nodes running BGP (or static routes) even if the exit ASBR is not listed in the IP explicit path. Therefore, a headend LSR can consider that link when it computes its TE LSP path.
Configuration of ASBR Forced Link Flooding
To activate ASBR forced link flooding, configure a link as passive and provide neighbor information (that is, the neighbor IGP ID and the neighbor TE ID). The required configuration tasks are described in the "Configuring a Static Route from the MP to the PLR" section.
Link Flooding
A passive link is configured on an interface of an ASBR. The link is flooded in the ASBR's IGP. All the links are flooded as point-to-point links.
Flooding notifications are also sent when there is a change to a link's property.
OSPF Flooding
OSPF floods opaque link-state advertisement (LSA) Type 10 link information.
If a multiaccess link has more than one neighbor, a Type 10 LSA is advertised for each neighbor. In the topology database, neighbors are represented by point-to-point neighbor relationships.
Link TLV
A link TLV describes a single link and contains multiple sub-TLVs.
An opaque LSA contains a single link TLV.
For each ASBR-to-ASBR link, an ASBR must flood an opaque LSA containing one link TLV that has the link's attributes.
A link TLV comprises the following sub-TLVs:
•
•
•
•
•
•
•
•
•
IS-IS TLV
In IS-IS, when autonomous system A1 floods its LSP, it includes the system ID and a pseudonode number.
If three autonomous systems are connected to a multiaccess network LAN, each link is considered to be a point-to-point link. The links are marked with the maximum metric value so that the inter-ASBR links are considered by CSPF and not by shortest path first (SPF).
TE uses the protocol TLV type 22, which has the following data structure:
•
•
•
•
Table 1 defines the sub-TLVs.
Note
Topology Database
When the topology database module receives a link-state advertisement (LSA), the module scans the LSA to find the neighbors of the links. The ASBR link is part of the same LSA and is installed in the TE topology database like any other link.
During the CSPF operation, the TE headend module uses the TE topology database to find a path to the destination. Because the Inter-AS links are part of the TE topology database, the CSPF operation uses these links to compute the LSP path.
Link Flooding
The IGP floods information about a link in the following situations:
•
•
•
•
Flooding is a little different in IS-IS and OSPF. In OSPF, only information about the link that has changed is flooded, because a Type 10 LSA contains a single link advertisement. In IS-IS, information about all links on a node is flooded even if only one has changed, because the Type 22 TLV contains a list of all links on the router.
How to Configure MPLS Traffic Engineering: Inter-AS TE
This section contains the following procedures for configuring MPLS Traffic Engineering: Inter-AS TE:
•
•
Note
Configuring Loose Hops
The section describes how to do the following so that there can be loose hops:
•
•
Configuring an Explicit Path on the Tunnel That Will Cross the Inter-AS Link
If you want a tunnel to span multiple networks, configure an explicit path on the tunnel that will cross the Inter-AS link by performing the following steps.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Configuring a Route to Reach the Remote ASBR
To configure a route to reach the remote ASBR, perform the following steps.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Configuring a Static Route from the MP to the PLR
To enable Fast Reroute protection that spans across different autonomous systems, configure a static route from the MP to the PLR by performing the following steps.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Configuring ASBR Forced Link Flooding
This section describes how to do the following so that you can configure ASBR forced link flooding:
•
•
•
Configuring the Inter-AS Link as a Passive Interface Between Two ASBRs
To configure the Inter-AS link as a passive interface between two ASBRs, perform the following steps.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Creating LSPs Traversing the ASBRs
To create LSPs traversing the ASBRs, perform the following steps.
Note
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Configuring Multiple Neighbors on a Link
To configure multiple neighbors on a link, perform the following steps.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Debugging ASBR Forced Link Flooding
This section includes commands for the following procedures:
•
The debug commands are described in detail in the Cisco IOS Debug Command Reference, Release 12.4.
Debugging Headend of TE LSPs
debug mpls traffic-eng path lookupdebug mpls traffic-eng path verifydebug mpls traffic-eng path spfDebugging Head and Midpoint (Link-Related Debugs)
debug mpls traffic-eng link-management igp-neighborsdebug mpls traffic-eng link-management advertisementsdebug mpls traffic-eng link-management bandwidth-allocationdebug mpls traffic-eng link-management routingVerifying the Inter-AS TE Configuration
To verify the Inter-AS TE configuration, perform the following steps.
Note
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Step 1
Use this command to display the MP sender display for the primary tunnel when Fast Reroute is ready.
Router# show ip rsvp sender detailPATH:Tun Dest: 10.10.0.6 Tun ID: 100 Ext Tun ID: 10.10.0.1Tun Sender: 10.10.0.1 LSP ID: 31Path refreshes:arriving: from PHOP 10.10.7.1 on Et0/0 every 30000 msecsSession Attr:Setup Prio: 7, Holding Prio: 7Flags: (0x7) Local Prot desired, Label Recording, SE Stylesession Name: R1_t100ERO: (incoming)10.10.7.2 (Strict IPv4 Prefix, 8 bytes, /32)10.10.0.6 (Strict IPv4 Prefix, 8 bytes, /32)RRO:10.10.7.1/32, Flags:0x0 (No Local Protection)10.10.4.1/32, Flags:0x9 (Local Prot Avail/to NNHOP) !Available to NNHOP10.10.1.1/32, Flags:0x0 (No Local Protection)Traffic params - Rate: 10K bits/sec, Max. burst: 1K bytesMin Policed Unit: 0 bytes, Max Pkt Size 4294967295 bytesFast-Reroute Backup info:Inbound FRR: Not activeOutbound FRR: No backup tunnel selectedPath ID handle: 50000416.Incoming policy: Accepted. Policy source(s): MPLS/TEStatus: Proxy-terminatedStep 2
Use this command to display the MP sender display when the primary tunnel is Fast Reroute active:
Router# show ip rsvp sender detailPATH:Tun Dest: 10.10.0.6 Tun ID: 100 Ext Tun ID: 10.10.0.1Tun Sender: 10.10.0.1 LSP ID: 31Path refreshes:arriving: from PHOP 10.10.3.1 on Et1/0 every 30000 msecsSession Attr:Setup Prio: 7, Holding Prio: 7Flags: (0x7) Local Prot desired, Label Recording, SE StyleSession Name: R1_t100ERO: (incoming)10.10.0.4 (Strict IPv4 Prefix, 8 bytes, /32)10.10.0.6 (Loose IPv4 Prefix, 8 bytes, /32)RRO:10.10.3.1/32, Flags:0xB (Local Prot Avail/In Use/to NNHOP) !Ready10.10.1.1/32, Flags:0x0 (No Local Protection)Traffic params - Rate: 10K bits/sec, Max. burst: 1K bytesMin Policed Unit: 0 bytes, Max Pkt Size 4294967295 bytesFast-Reroute Backup info:Inbound FRR: ActiveOrig Input I/F: Et0/0Orig PHOP: 10.10.7.1Now using Bkup Filterspec w/ sender: 10.10.3.1 LSP ID: 31Outbound FRR: No backup tunnel selectedPath ID handle: 50000416.Incoming policy: Accepted. Policy source(s): MPLS/TEStatus: Proxy-terminatedStep 3
Use this command to display the influence of a passive link. On R2, the passive link to R4 is in the Link ID:: 1 section.
Router# show mpls traffic-eng link-management advertisementsFlooding Status: readyConfigured Areas: 2IGP Area[1] ID:: ospf 1 area 0System Information::Flooding Protocol: OSPFHeader Information::IGP System ID: 10.10.0.2MPLS TE Router ID: 10.10.0.2Flooded Links: 2Link ID:: 1Link Subnet Type: Point-to-PointLink IP Address: 10.10.4.1IGP Neighbor: ID 0-0-0-0-0-0-0, IP 10.10.0.4Physical Bandwidth: 1544 kbits/secRes. Global BW: 1158 kbits/secRes. Sub BW: 0 kbits/secDownstream::Global Pool Sub Pool----------- ---------Reservable Bandwidth[0]: 1158 0 kbits/secReservable Bandwidth[1]: 1158 0 kbits/secReservable Bandwidth[2]: 1158 0 kbits/secReservable Bandwidth[3]: 1158 0 kbits/secReservable Bandwidth[4]: 1158 0 kbits/secReservable Bandwidth[5]: 1158 0 kbits/secReservable Bandwidth[6]: 1158 0 kbits/secReservable Bandwidth[7]: 1148 0 kbits/secAttribute Flags: 0x00000000IGP Area[1] ID:: ospf 1 area 1System Information::Flooding Protocol: OSPFHeader Information::IGP System ID: 10.10.0.2MPLS TE Router ID: 10.10.0.2Flooded Links: 2Link ID:: 1Link Subnet Type: Point-to-PointLink IP Address: 10.10.4.1IGP Neighbor: ID 0-0-0-0-0-0-0, IP 10.10.0.4Physical Bandwidth: 1544 kbits/secRes. Global BW: 1158 kbits/secRes. Sub BW: 0 kbits/secDownstream::Global Pool Sub Pool----------- -----------Reservable Bandwidth[0]: 1158 0 kbits/secReservable Bandwidth[1]: 1158 0 kbits/secReservable Bandwidth[2]: 1158 0 kbits/secReservable Bandwidth[3]: 1158 0 kbits/secReservable Bandwidth[4]: 1158 0 kbits/secReservable Bandwidth[5]: 1158 0 kbits/secReservable Bandwidth[6]: 1158 0 kbits/secReservable Bandwidth[7]: 1148 0 kbits/secAttribute Flags: 0x00000000
Configuration Examples for MPLS Traffic Engineering: Inter-AS TE
This section provides the following configuration examples for MPLS Traffic Engineering: Inter-AS TE:
•
•
•
Configuring Loose Hops: Examples
This section includes the following:
•
•
Configuring an Explicit Path on the Tunnel That Will Cross the Inter-AS Link: Example
The following commands configure a loose IP explicit path named route1 suitable for use as a path option with Inter-AS TE with the destination 10.10.10.6 that is to traverse ABRs 10.10.0.2 and 10.10.0.4. The tunnel headend and the specified ABRs will find a path from the source AS100 to the destination 10.10.0.6 in AS200. See Figure 1.
Router(config)# ip explicit-path name route1 enableRouter(cfg-ip-expl-path)# next-address loose 10.10.0.2Router(cfg-ip-expl-path)# next-address loose 10.10.0.4Router(cfg-ip-expl-path)# next-address loose 10.10.0.6Note that the explicit path for an interarea TE tunnel need not specify the destination router because the tunnel configuration specifies it in the tunnel destination command. The following commands configure an explicit path named path-without-tailend that would work equally well for the interarea tunnel created in the previous example:
Router(config)# ip explicit-path name path-without-tailendRouter(cfg-ip-expl-path)# next-address loose 10.10.0.2Router(cfg-ip-expl-path)# next-address loose 10.10.0.4Configuring a Route to Reach the Remote ASBR in the IP Routing Table: Example
In the following example, packets for the ASBR whose router ID is 10.10.0.1 will be forwarded via tunnel 101:
Router> enableRouter# configure terminalRouter(config)# ip route 10.10.0.1 255.255.255.255 tunnel 101Configuring a Static Route from the MP to the PLR: Example
In the following example, a static route is configured from the MP to the PLR. The outgoing interface is tunnel 103.
Router> enableRouter# configure terminalRouter(config)# ip route 10.10.3.1 255.255.255.255 10.0.0.0 tunnel 103Configuring ASBR Forced Link Flooding: Examples
This section includes the following ASBR forced link flooding examples:
•
•
•
Configuring the Inter-AS Link as a Passive Interface: Example
For this example, see Figure 1.
Routers R2 and R4 have the following router IDs:
•
•
Router> enableRouter# configure terminalRouter(config)# interface serial 2/0Configures OSPF on Router R2 When Its Neighbor Is Running OSPF Too
Router(config-if)# mpls traffic-end passive-interface nbr-te-id 10.10.0.4
Note
Specifies That Both Router R2 and Its Neighbor Are Running OSPF (the nbr-igp-id Keyword Is Specified)
Router(config-if)# mpls traffic-eng passive-interface nbr-te-id 10.10.0.4 nbr-igp-id ospf 10.10.0.4Configures IS-IS on Router R1
Router(config-if)# mpls traffic-eng passive-interface nbr-te-id 10.10.0.4 nbr-igp-id isis 40.0000.0002.0001.00Configures the Neighbor IGP ID (nbr-igp-id) When There Is More than One Neighbor Specified on a Link
Router(config-if)# mpls traffic-end passive-interface nbr-te-id 10.10.0.4 nbr-igp-id ospf 10.10.0.4Router(config-if)# mpls traffic-eng passive-interface nbr-te-id 10.10.0.7 nbr-igp-id ospf 10.10.0.7
Note
Configures a Link as a Passive Interface (Includes Global TE Commands)
interface serial 2/0ip address 10.10.4.1.255.255.255.0
