Practical Applications

 < Day Day Up > 



Riverstone graciously provided the information for the following practical applications.

Designating Backup Paths

Creating a strict explicit path using only a single primary path provides pinpoint control over how the data associated to the label switch path will flow. However, in the event of failure, service must be able to recover without manual intervention. Loose explicit routing allows RSVP-TE to signal a new path around a failure, at the expense of control.

Figures 4.12–4.16 show this configuration. Figure 4.12 shows the generic command set on a top level. Figure 4.13 shows the configuration example. Figures 4.14 and 4.15 build from that configuration. In Figure 4.14, we see the commands previously shown in Chapter 3. Figure 4.15 shows the four basic steps needed to configure a backup path, and Figure 4.16 shows the correct syntax.

click to expand
Figure 4.12: Top-Level Configuration

click to expand
Figure 4.13: Configuration Example

click to expand
Figure 4.14: Previous RSVP Command

click to expand
Figure 4.15: Four Steps to Configure Back Path

click to expand
Figure 4.16: Detailed Syntax Commands for Secondary Path

Two categories, primary or secondary, are assigned to paths when they’re assigned to an LSP. There can only be a single primary path associated to an LSP. It is always preferred over any secondarily designated path. Numerous secondary paths can be associated to an LSP, with a configurable order of preference. The obvious benefit to this approach is the ability to define disparate paths across the backbone, should the network have such a physical configuration.

To associate an existing path to an LSP as a primary or secondary:

RS(config)# mpls set label-switched-path <name> primary|secondary  <path  name>

Secondary paths are selected based on preference, with the higher numerical value preferred. To define the preference of secondary paths:

RS(config)# mpls set label-switched-path <name> secondary <path name>  preference  <1-255>

Finally, the secondary path may be defined as a hot or cold standby. A cold standby is the default action and will not be established until the primary has failed. This means that once the instantiating router realizes the primary path is no longer valid, the preferred secondary must be signalled and established before it can be used. A hot standby is the ability to have a pre-established backup that takes for a failed primary as soon as it is recognized. To configure a hot standby:

RS(config)# mpls set label-switched-path <name> secondary <path name>  preference  <1-255> standby 

One possible solution is to define a completely explicit primary route that is best suited for the traffic carried within the LSP. To protect the primary path, a completely disparate path capable of servicing the LSP could exist and be explicitly configured as a preferred secondary. Since there are no common transit points, it might make sense to configure this secondary path as a hot standby. Finally, a less preferred hop-by-hop backup path can be configured as a backup of last resort. Its main role is to try to establish a path through a network that has already observed multiple failures that have impacted service on the primary and preferred secondary paths. It is pointless to pre-establish this path, because it would be unforeseeable to predetermine what paths may remain from ingress to egress.

Recall the configurations from Chapters 2 and 3. In Chapter 3, we established RSVP strict paths. The items in bold in the figures are new to the configuration.

The detailed commands are as simple as the four steps shown in Figure 4.15 and 4.16.

Commands are shown in bold in Figure 4.16. The commands in black were covered in Chapter 3.

The summary of commands is as follows, with new commands shown in bold:

interface create ip To-LSR1 address-netmask 192.168.1.2/30 port gi.2.1 interface create ip To-LSR2 address-netmask 192.168.1.6/30 port gi.2.2 interface add ip lo0 address-netmask 2.2.2.1/32 ip-router global set router-id 2.2.2.1 ospf create area backbone ospf add interface To-LSR1 to-area backbone ospf add interface To-LSR2 to-area backbone ospf add stub-host 2.2.2.1 to-area backbone cost 10 ospf start mpls add interface To-LSR1 mpls add interface To-LSR2 mpls create path ERO-Path1 num-hops 4 mpls create path ERO-Path2 num-hops 3 mpls create path Path-Back1 mpls set path ERO-Path1 hop 1 ip-addr 192.168.1.6 type strict mpls set path ERO-Path1 hop 2 ip-addr 192.168.1.5 type strict mpls set path ERO-Path1 hop 3 ip-addr 192.168.1.26 type strict mpls set path ERO-Path1 hop 4 ip-addr 192.168.1.22 type strict mpls set path ERO-Path2 hop 1 ip-addr 192.168.1.2 type strict mpls set path ERO-Path2 hop 2 ip-addr 192.168.1.1 type strict mpls set path ERO-Path2 hop 3 ip-addr 192.168.1.18 type strict mpls create label-switched-path LSP from 2.2.2.1 to 2.2.2.2 no-cspf mpls set label-switched-path LSP primary ERO-Path1  mpls set label-switched-path LSP secondary ERO-Path2 preference 100 standby mpls set label-switched-path LSP secondary Path-Back1 preference 10 mpls start rsvp add interface To-LSR1 rsvp add interface To-LSR2 rsvp start ospf set traffic-engineering on

Show Paths

Show paths are similar to the material covered in Chapters 2 and 3. A look at the high-level LSP information indicates only the LSP-based information, not the underlying path information.

LER1# mpls show label-switched-paths all      Ingress LSP:  LSPname           To                From              State LabelIn  LabelOut  LSP               2.2.2.2           2.2.2.1           Up    -       17         Transit LSP: LSPname           To                From              State LabelIn  LabelOut    Egress LSP: LSPname           To                From              State LabelIn  LabelOut 

In order to check the path information, the verbose option must be coded as part of the display command. When a specific path is being used to forward traffic for the LSP, the status of the protection-path field state is <Active, disposition>. In steady state, the primary path will be filling the active role. However, during times of network issues, one of the secondary paths will enter the active state based on order of preference. Console messaging will show transition events.

LER1# mpls show label-switched-paths all verbose    Ingress LSP:       Label-Switched-Path: "LSP"         state: Up               lsp-id: 0xa         status: Success         to: 2.2.2.2             from: 2.2.2.1                  proto: <rsvp>           protection: primary         setup-pri: 7            hold-pri: 0         attributes: <FROM_ADDR PRI SEC>           Protection-Path "ERO-Path1": <Active, Primary>             state: Up           lsp-id: 0x4004             status: Success             attributes: <>             inherited-attributes: <>         Path-Signalling-Parameters:             attributes: <>             inherited-attributes: <NO-CSPF>             label in:           label out: 17             retry-limit: 5000   retry-int: 15 sec.             retry-count: 5000   next_retry_int: 0.000000 sec.             preference: 7       metric: 1             ott-index: 3        ref-count: 1                                   bps: 0              mtu: 1500             hop-limit: 255      opt-int: 600 sec.             explicit-path: "ERO-Path1"  num-hops: 4                 192.168.1.6     - strict                 192.168.1.5     - strict                 192.168.1.26    - strict                 192.168.1.22    - strict             record-route:                  192.168.1.5                 192.168.1.26                 192.168.1.22           Protection-Path "Path-Back1": <Secondary>             state: Null         lsp-id: 0x4015             status: Success             attributes: <PREF>             inherited-attributes: <>         Path-Signalling-Parameters:             attributes: <>             inherited-attributes: <NO-CSPF>             label in:           label out:              retry-limit: 5000   retry-int: 15 sec.             retry-count: 5000   next_retry_int: 0.000000 sec.                  preference: 10      metric: 1             ott-index: 0        ref-count: 0              bps: 0              mtu: 1500             hop-limit: 255      opt-int: 600 sec.             explicit-path: "Path-Back1" num-hops: 0            Protection-Path "ERO-Path2": <Secondary>             state: Up           lsp-id: 0x4012             status: Success             attributes: <PREF>             inherited-attributes: <>         Path-Signalling-Parameters:             attributes: <STANDBY>             inherited-attributes: <NO-CSPF>             label in:           label out: 17             retry-limit: 5000   retry-int: 15 sec.             retry-count: 5000   next_retry_int: 0.000000 sec.             preference: 100     metric: 1             ott-index: 1        ref-count: 1              bps: 0              mtu: 1500             hop-limit: 255      opt-int: 600 sec.             explicit-path: "ERO-Path2"  num-hops: 3                 192.168.1.2     - strict                 192.168.1.1     - strict                                           192.168.1.18    - strict             record-route:                  192.168.1.1                 192.168.1.18   Transit LSP:   Egress LSP:

When a primary fails and one of the secondary paths assumes the active role, a message is written to the console indicating that the primary has failed and which secondary path is taking over.

%MPLS-I-LSPPATHSWITCH, LSP "LSP" switching to Secondary Path "ERO-Path2".

When the primary path is re-established, it automatically assumes the active role and the associated message is written to the console.

MPLS-I-LSPPATHSWITCH, LSP "LSP" switching to Primary Path "ERO-Path1". 

The default switch back from secondary to primary can be overridden. If the overrides are in place to prevent the automatic switchback, a failure along the active secondary path or manual intervention will cause the secondary to switch back to the primary. Manual intervention requires an operator to use the comment command to remove the active secondary path statement from the configuration. This will immediately fail the path back to the primary. The command line in the configuration can be commented back in immediately following the act of commenting it out.

To override the automatic switchback function:

RS(config)# mpls set label-switched-path <name> no-switchback

The use of the comment command:

RS(config)# comment in|out <linenum> 

Fast Reroute and Detour LSP

The Internet draft draft-gan-fast-reroute-00.txt defines a process that allows intermediate nodes along a main LSP to pre-establish detours around possible failure points. It introduces four new RSVP objects:

  • Fast reroute: This is the trigger carried in the RSVP session information to indicate that the main LSP requires a detour LSP to be pre-established across the components. This object includes all the necessary information to allow transit routers to execute the Carrier Pre-Select File (CPSF) process and select detours that meet the criteria of the main LSP. The object information includes setup and hold priorities, bandwidth, and link affinity (include and exclude). The constraint-based information is not required to be the same on the detour path as it is on the main LSP. If these are not specifically configured when fast reroute is configured, the constraints are inherited.

  • Detour: Includes the IP address of the router requesting the detour LSP and the destination that should be bypassed in the event of failure. The goal is to create the detour around the link and the immediate next hop.

  • Merge node: The node where the detour and the main path join. The merge node is responsible for mapping both the main LSP inbound label and the detour LSP inbound label to the same outbound action. On the RS platform this will mean that multiple related hw-ilm-tbl entries will share a common hw-ott-index, which determines the outbound action.

  • Branch node: The node where a detour LSP is instantiated to protect the main path.

The simple diagram in Figure 4.17 represents a main LSP protected by a detour LSP. If the main LSP traverses a more complex longer path, detour LSPs will be established around all possible failure points that have an alternate available. When a failure occurs, as in Figure 4.18, the traffic will take the predefined backup path.

click to expand
Figure 4.17: Path without a Failure

click to expand
Figure 4.18: Path After Failure

An older Internet draft (draft-swallow-rsvp-bypass-label-01.txt, November 2000) defines a different approach to the fast reroute concept. With the older approach, the detour LSP uses label stacking to create the “bypass” LSP. Encapsulating the main LSP label within the label for the bypass LSP, the penultimate hop on the bypass LSP removes the top-level label, the bypass tunnel label, delivering the main LSP label back to the merge node.

There is a possibility these drafts may merge into a single specification.



 < Day Day Up > 



Rick Gallagher's MPLS Training Guide. Building Multi-Protocol Label Switching Networks
Rick Gallahers MPLS Training Guide: Building Multi Protocol Label Switching Networks
ISBN: 1932266003
EAN: 2147483647
Year: 2003
Pages: 138

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net