Routing

Dear Experts,

We have a full mesh RSVP LSP session's built between 3 PE routers in distant locations. The complete sample LSP configuration is as below(inheritance configuration included):

set protocols mpls label-switched-path PE-1_to_PE-2 to 100.X.X.X
set protocols mpls label-switched-path PE-1_to_PE-2 no-decrement-ttl
set protocols mpls label-switched-path PE-1_to_PE-2 optimize-timer 3600
set protocols mpls label-switched-path PE-1_to_PE-2 fast-reroute


The only current requirement as of now for the LSP's is 'Fast-reroute'.
Do we still need to enable the 'traffic-engineering' knob under OSPF protocol hierarchy ?

 
Thank you in Advance !!

Prathmesh D

By default, traffic engineering support is disabled, You need to configure it.

https://www.juniper.net/documentation/en_US/junos/topics/topic-map/ospf-traffic-engineering.html
   

Hello Karan,

Yes we had it configured. Thats what i meant to ask , whether we have an option of deleting it.

Anyways thank you for taking out the time to answer.

Thank you,

Prathmesh D

Hello,

---

@achowdhury wrote:

The only current requirement as of now for the LSP's is 'Fast-reroute'.
Do we still need to enable the 'traffic-engineering' knob under OSPF protocol hierarchy ?
 

---

Short answer is yes.

Long answer is You need Traffic Engineering Database (TED) for the detour LSPs to automatically establish.

More reading:

- OSPF Ttraffic Engineering  https://www.blackhole-networks.com/OSPF/ 

- RSVP detour LSP https://www.juniper.net/documentation/en_US/junos/topics/concept/mpls-fast-reroute-overview.html

HTH

Thx
Alex

Yep,

Computing and setting up detours is done independently at each node. On a node, if an LSP has fast reroute enabled and if a downstream link or node can be identified, the router performs a Constrained Shortest Path First (CSPF) computation using the information in the local traffic engineering database. For this reason, detours rely on your IGP supporting traffic engineering extensions. Without the traffic engineering database, detours cannot be established.

More: Detour Computations

Dear Aarseniev/T3mpo,

Thank you for taking out your time to answer my query. Really appreciate it.

Did a small testing in our LAB environment and following were the observations:

1. RSVP LSP's do not come up in the absence of 'traffic-engineering' extension knob under OSPF heirarchy.

2. Once we establish them in the presence of the TE knob, they remain in the UP state on the distant PE routers(as ingress LSP's) even if you disable TE under OSPF hierarchy on the local router.

3. Upon clearing OSPF from the local router, these ingress LSP's on the distant PE routers transition to a 'Dn' state.

My observations are based upon preliminary testing under LAB environment. They may or may not differ in case of actual taffic forwaring.

Please let me know in case i have missed anything.

Thanks & regards,

Prathmesh D

Hello,

---

@achowdhury wrote:

 

2. Once we establish them in the presence of the TE knob, they remain in the UP state on the distant PE routers(as ingress LSP's) even if you disable TE under OSPF hierarchy on the local router.

 

---

 Obviously, You did not wait long enough. Default RSVP LSP reoptimization timer is 1 hour/3600 secs if memory serves. so after 1 hour You should see RSVP LSP going down en masse because CSPF algorithm could not find any paths in TED.

HTH

Thx

Alex

Dear Aarseniev,

Yeah that makes sense. i just did not wait long enough to see the optimization timer come into play.

Regards,

Prathmesh D

Even without fast-reroute, you would still need a TED because you didn't specify "no-cspf" on your LSP configuration. By default, even without constraints, it will still go through CSPF calculation and come out with an EROs list for RSVP to signal.