Advanced MPLS: From JUNOS

  • Constrained Shortest path first (CSPF)
    • CSFP is the modified version of SPF algorithm where the data is taken from TED (Traffic engineering database) which has much information about networks like each router’s interface bandwidth, available priority values and other administrative values.
    • User-defined criteria are passed to CSPF which then consults TED (which has information from TE-capable IGP protocols) and filters available paths based on criteria. Shortest path from ingress to egress is calculated with filtered info and the end result is passed to RSVP protocol as strict-hop Explicit Route Object (ERO).
  • OSPF TE extensions:
    • OSPF uses Type-10 Opaque LSA for advertising traffic engineering information.
    • Area-wide flooding scope. So, each area has a TED database.
    • Opaque LSA has following fields:
      • Link state age – 2 octets – age since LSA was originated.
      • Options – 1 octet – local router capabilities. Bit 6 is set to support TE.
      • Link state type/opaque type set to 10 and 1.
      • Instance – 2 octets- Used by local router to support multiple, separate LSA. Router generates one LSP for router itself and one for each operational interface.
      • Advertising Router – Router ID of OSPF device that originated the LSA.
      • Link-state SN – to guarantee all routers have recent version of LSA.
      • Link-state checksum – checksum for entire LSA.
      • Traffic engineering type – currently 2 TLVs are supported.
        • Router address TLV – type code of 1
        • Link TLV – type code of 2
        • Traffic engineering length / value in TLV format.
    • Configure ‘traffic-engineering’ command to enable TE extension inside OSPF global level.
    • Loopback address of router is advertised as router address TLV.
    • Each operational interface details are sent in link TLV via sub-TLVs.
    • Format: Sub-TLV : type code; Length ; Value
      • Link Type:  1; 1; 1 if point-point interfaces. 2 if broadcast interface.
      • Link ID: 2; 4; describes opposite end of the link. For P2P interface, other end router ID is used in value field. Interface address of DR router if the interface n/w is BC.
      • Local interface IP address: 3; 4; interface address of the local router being described in opaque LSA.
      • Remote interface IP address: 4; 4; P2P n/w use remote routers’ address. BC use 0.0
      • TE metric: 5; 4; Metric value to be used by CSPF algo. Same value as in router LSA.
      • Max BW: 6; 4; value contains the true bandwidth of local interface in bytes/sec.
      • Max reservable BW: 7; 4; amount of BW available for RSVP in bytes/sec.
      • Unreserved BW: 8; 32; amount of BW currently available in 8 priority levels.
      • Color: 9; 4; Contains 32-bit vector used to represent administrative groups.
  • ISIS TE extensions:
    • Used ‘Extended IS reachability’ to advertise TE information via Sub-TLV.
    • No additional configuration required. When the interface included in ISIS is enabled for RSVP, ISIS advertises below sub-TLV to represent the links information.
    • Administrative group: 32-bit vector used to encode admin groups of a link.
    • IPv4 interface address, neighbor address, Maximum link BW, Max reservable BW, unreserved BW and TE default metric sub-TLVs are included.
    • TE default metric sub-TLV is advertised only if the interface metric to be used for TE differs from normal routing process. Uselevel 2 te-metric’ command inside [isis interface] mode.
  • CSPF algorithm steps:
    • Remove paths which don’t have enough unreserved BW at given setup priority.
    • Include admin-group check. Removes all links that do not have requested admin-group.
    • Exclude admin-group check.
    • When ERO is configured, CSPF is run to find path from ingress to 1st hop, until egress router is reached.
    • When multiple equal cost path exist, path with last-hop interface = egress router is selected.
    • If tie, path with fewest number of physical hops.
    • If tie, based on load balancing configuration (random, most-fill, least-fill) a path is selected.
    • CSPF provides a strict ERO having physical interface address of nodes are given to RSVP.
  • Administrative group:
    • Each interface can be configured with one or more groups. 32 groups can be configured. If G=1 is configured, first bit is set. If G=10, tenth bit is set (bit vector representation).
    • Inside [protocols mpls] mode, configure an admin-group template and assign it to interfaces
    • When configuring LSP in [protocols mpls] mode, use ‘set admin-group include/exclude xxx’
  • LSP Priority and Preemption:
    • Setup priority – to determine whether BW is available at that priority level to establish LSP.
    • Hold priority – used by established LSP to retain its BW reservation in network.
    • Default settings is (7, 0) representing (setup, hold). Level 0 being best and level 7 as worst.
      • Reasons: To establish a new LSP, bw check is done at lowest level and it doesn’t consume BW already consumed by established LSP (for setup priority)
      • Established LSP cannot have its reserved BW taken away by new LSP (for hold)
    • If need to alter above priority, use same value for both setup and hold. Recommended.
    • User-defined setup priority should be <= hold priority.
      • Reason: While establishing new LSP, we check available BW at setup priority level and place the reservation at hold priority level and below.
      • So, if hold < setup priority,  there might be situation when BW check is passed due to large BW available at higher level, but when reservation is placed there might not enough BW at hold priority level. Results in one LSP preempting another and loop.
    • Updated BW information is advertised by junos after a change in 10% of interface BW. To alter, use ‘update-threshold’ command within [edit protocols rsvp].
    • Configure ‘bandwidth’ and ‘priority x y’ under [edit protocols mpls label-switched-path]

LSP traffic protection:

  • Three methods to protect LSP traffic are primary path, secondary paths and fast reroute.
  • Primary LSP path:
    • An LSP can have zero or one primary path.
    • Primary path is revertive in nature, means whenever primary path is UP, we need to use it.
    • ‘retry-timer’ and ‘retry-limit’ controls the revertive capability.
      • retry-timer’ – Length of time ingress router waits for next attempt. 30 sec default.
      • retry-limit’ – number of times router will attempt. Default: 0 means continues attempt. If configured limit is reached, we need to manually clear LSP for retry.
  • Secondary LSP Path:
    • An LSP can have zero or one/more secondary LSP paths which are used in configured sequence manner. When primary path is torn down, router will try to establish first secondary path and user traffic is forwarded across that path.
    • If primary path is established, secondary path is still used until ‘waiting period’ is expired, which is twice the amount of retry-timer. In reality, it is less than 60 seconds. After this time expired, traffic is forwarded via primary path and the secondary path is torn down.
  • Standby secondary path:
    • In above case, packet loss occurs by the time ingress router, tries to establish secondary LSP after the primary LSP torn down.
    • To circumvent, all possible secondary paths are established once the primary is operation.
    • Include ‘standby’ command inside secondary LSP configuration.
  • There is no way to make primary path to take over traffic from secondary. Can configure many secondary paths without primary path, to avoid reverting from one path to another.

Fast reroute:

  • Above methods experience some packet drops which are injected into LSP between the time failure occurs and the time ingress router is notified. To avoid this, fast reroute is used.
  • Each router along the LSP creates a detour path to protect against its next downstream neighbor or next downstream link.
  • When failure happens, the next upstream router from failure point (Point of local repair-PLR) forwards traffic via detour path and informs to ingress router about failure occurred and using retour path.
  • Actions which can be taken by ingress router can be:
    • If standby secondary path (SP) is already established, traffic is passed via secondary path and primary path (PP) is torn down and router attempts to establish new primary path with the specified constraints.
    • If SP is configured but not up, router establish SP and move the traffic and then torn down the PP.
    • If no SP is configured, ingress router checks TED and tries to establish new primary LSP and move traffic. This can be done in two fashions:
      • Create new path, move traffic and then tears down old path (‘adaptive’ CLI)
      • Tear down old path, create new path and move traffic
    • If no SP configured and CSPF couldn’t find new primary, no action is taken by ingress router.
  • Node Protection:
    • Each router along the path builds a detour path from itself to egress router.
    • By default, detour path inherits the group settings of main LSP.
    • This method also protects downstream link.
    • Configure ‘fast-reroute’ inside MPLS LSP configuration. Ingress router will send fast reroute in Path message to alert path routers to build detour once the main LSP is established.
    • The downstream router send Resv msg with a flag, in RRO to its upstream indicating detour has been established. 0x09 – both link and node are protected. 0x01: only link is protected.
  • Link protection:
    • A bypass LSP is created from one router to its next downstream router avoiding direct link.
    • link-protection’ command has to be configured on all interfaces requiring protection. Also need to be configured on ingress router inside MPLS LSP configuration.
    • During failure, PLR swaps the label with one advertised by downstream router and perform label push operation to forward packet along bypass LSP. Penultimate router pops bypass LSP label and traffic reaches downstream router.

Controlling LSP behavior:

  • Adaptive mode:
    • By default, JUNOS uses fixed filter (FF) reservation style. Unique BW reservations for each RSVP session. To make JUNOS to use Explicit Shared (ES), configure ‘adaptive’ inside global LSP configuration mode. This makes both PP and SP to share same bandwidth.
    • Enables ‘make-before-break’ operation. SP is established before breaking PP.
  • Explicit Null advertisement:
    • PHP removes label before forwarding it (as IP packet) to egress router. This makes egress router to perform Cos based on customer-defined IP precedence value in IP header.
    • To make penultimate hop router to advertise with explicit label with value 0, use ‘explicit-null’ in [edit protocols mpls] configuration mode.
  • Hiding  LSP paths:
    • Configuring ‘no-decrement-ttl’ command in [edit protocols mpls label-switched-path <>]
      • Ingress router while establishing this LSP tries to negotiate with all downstream routers using specific label request object (juniper specific). If succeed, whole LSP will look as one hop to transit traffic.
      • Proprietary incompatibility applies only to RSVP-signaled LSP and not LDP.
      • Ingress does not copy the ‘decremented IP TTL’ to MPLS TTL, instead places 255.
      • Egress router is visible
    • Configuring ‘no-propagate-ttl’ command in [edit protocols mpls]
      • Ingress router does not decrement the IP TTL but places 255 in MPLS TTL.
      • Egress router is not visible.
  • Using LSP in routing protocols:
    • By default only BGP transit traffic are passed via LSP by looking next-hop reachability to LSP address in inet.3 table.
    • To use LSP for forwarding IGP routing traffic, we need to use the LSP into link state database. We need bidirectional LSP between ingress and egress router for forwarding adjacency to form.
    • Once formed, we can use the local LSP as an interface in IGP protocol configuration.
  • Using LSP for normal IP routing lookup at ingress router:
    • traffic-engineering bgp-igp’ command in [protocols mpls] moves the content of inet.3 table into inet.0. Cut/paste operation.
    • traffic-engineering bgp-igp-both-ribs’ copies the content of inet.3 table into inet.0.
    • In above two methods, routes moved from inet.3 table (LSP) are preferred over routes already in inet.0 table (IGP). This makes some routing policy to mis-functional as only active routes are eligible for routing policy. ‘traffic-engineering mpls-forwarding’ makes routes from inet.3 table active for forwarding alone. The IGP version is active for routing purpose.
  • Commands:
    • Show ted database – to see info in TED
    • Show mpls lsp extensive – to see path for LSP protection and much more information. Buffer history can be deleted by deactivating and reactivating MPLS configuration.
    • Show rsvp session detail – to see detailed information about fast reroute and detour EROs.


Advertisements
This entry was posted in jncis, Junos, ldp, mpls, rsvp and tagged , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s