Routing

I was reading the JNCIA study guide http://www.juniper.net/training/certification/JNCIA_studyguide.pdf for instructions on how to set up static LSPs thru a network.

Seems like things have changed some since that code and I have some unanswered questions.

From the Guide - For an ingress router (Pg. 497)

[edit protocols mpls]
user@Cabernet# show
static-path inet {
    172.16.0.0/16 {
        next-hop 10.100.10.2;
        push 912;
    }
}

 The latest configuration from the technical documentation - http://www.juniper.net/techpubs/en_US/junos12.1/topics/usage-guidelines/mpls-configuring-static-lsps.html#id-37203

nbhasin@Cabernet# show protocols mpls 
static-label-switched-path 172.16 {
    ingress {
        next-hop 10.100.10.2;
        to 1.1.1.1;
        push 1000912;
    }
}

[edit]
nbhasin@Cabernet# show routing-options 
static {
    route 172.16.0.0/16 {
        static-lsp-next-hop 172.16;
    }
}

 It seems mostly straightforward except the following two things :-

1. to address—Address of the egress router.

This has been stated as a mandatory field and indeed the router would not let me commit the configuration without it. The recommendation was to configure the egress router's router-ID. That does not seem relevant to me for the setup of a static LSP.

Furthermore, I was able to configure a dummy address (1.1.1.1 does not exist on my lab network) and the configuration was accepted and in fact the LSP was functional. That actually makes sense to me because there is nothing in the static LSP that should require any more information than next-hop and push label.

So the question is why is this field even present and since it is present, why is it mandatory? Am I not understanding something?

2. On the transit routers - 

The allowed label ranges are different for incoming vs outgoing labels

nbhasin@Muscat# ...th 172.16/16 transit ?               
Possible completions:
  <incoming-label>     Incoming label value (1000000..1048575)
  1000912              Incoming label value
[edit]
nbhasin@Muscat# set protocols mpls static-label-switched-path 172.16/16 transit 1000912 swap ? 
Possible completions:
  <swap>               Swap top label with this label (0..1048575)
[edit]
nbhasin@Muscat# set protocols mpls static-label-switched-path 172.16/16 transit 1000912 swap    

 Why is there a restriction on the incoming label but not on outgoing label? Any valid reasoning for that?

Thanks as always in advance.

Nic

Hello,

Have you checked out Juniper free no-registration-needed a-mouse-click-away 24x7x365-online documentation?

http://www.juniper.net/techpubs/en_US/junos10.2/information-products/topic-collections/config-guide-mpls-applications/topic-30943.html

In the to statement, you configure the IP destination address to check when incoming packets are analyzed. If the address matches, the specified label (push out-label) is assigned to the packet, and the packet enters an LSP. Each prefix that you specify is installed as a static route in the routing table.

 HTH

Thanks

Alex

Thanks Alex. I am aware of the documentation, in fact the last two snippets of codes are directly pasted (altered for IP addresses) from the Junos documentation, albeit for 12.1, which is the code I am running.

It seems like things have changed between 10.2, the documentation link you posted and 12.1 and now if there is no static route to the defined LSP, then the path is not installed. I tried the 10.2 code that you posted and the LSP never populates the routing table. You need that static route in routing-options for it to be installed.

This is also apparant in the display of the configuration.

10.2

protocols {
     mpls {
          static-label-switched-path path1 {
               to 10.0.0.0 {
                    next-hop 11.1.1.1;
                    push 1000123;
               }
           }
           interface so-0/0/0;
     }
}

 12.1

protocols {
     mpls {
          static-label-switched-path path1 {
                ingress {
                      next-hop 11.1.1.1;
                      to 10.0.0.0;
                      push 1000123;
                }
          }
          interface so-0/0/0.0;
     }
}
routing-options {
      static {
            route 10.0.0.0/8 {
                  static-lsp-next-hop path1;
      }
}

 If you see in 10.2 code, under the definition of the static-label-switched-path, the next-hop and push objects used to be leaf objects under the to object. They no longer are in 12.1. They share the same level in the heirarchy. Thus, the "next-hop" and "push" no longer define the "to" object hence the "route" is never installed.

Like I said 

Furthermore, I was able to configure a dummy address (1.1.1.1 does not exist on my lab network) and the configuration was accepted and in fact the LSP was functional. That actually makes sense to me because there is nothing in the static LSP that should require any more information than next-hop and push label.

The actual path (documentation-wise) to 10.0.0.0/8 is defined in the routing-options and not in the protocol mpls, which simply defines the LSP to be usable by any address.

So, I rephrase my question, is the "to" field relevant in the 12.1 code or not?

Thanks,

Nic

Hi Nic,

Give it a try to this:

set routing-options static route 172.16.0.0/16 next-hop 1.1.1.1 resolve

Think of the "to" address as a BGP next hop.

Ato

I think I finally got it. Thanks Ato.

So, succinctly, two things :-

1. The "to" field is mandatory for the setup of the LSP.

2. Any BGP routes with a next-hop equal to the IP in the "to" field will now be installed and use the LSP

3. Any static routes can be defined in two different ways :-

3a. Using the actual NAME of the defined LSP. 

routing-options {
    static {
        route X.X.X.X/YY {
            static-lsp-next-hop <LSP_NAME>;
        }
    }
}

 3b. Using the "to" address of the LSP as the next-hop with recursive routing lookups enabled.

routing-options {
        route X.X.X.X/YY {
            next-hop <LSP_TO_IP>;
            resolve;
        }
}

Each way a path will be installed in the forwarding table using the LSP.

Thanks again (and Kudos), that little endeaver makes my understanding much better.

Nic