It is not necessary, because primary path is fine - tunnel establishes using it. The purpose of secondary paths is to provide alternative for tunnel if establishing tunnel using primary path is impossible.
Upon failure of primary-path (and this does not exactly mean data forwarding disruption, but failure of RSVP tunnel, which takes time to detect), primary path enters “on-hold” state and attempt is made to establish secondary path (if any). The difference between primary and secondary path is that in case primary path is active, secondary path is considered “not necessary”, but if secondary path is active, there are periodic attempts to establish primary path.
As to your question - if primary path becomes impossible, secondary path is the only option how to get TE tunnel back up.
Also, what is the difference between :static and :loose when configuring the hops of a tunnel-path?
It is “strict”, not “static” actually. It specifies how strict each hop must be about looking up the next hop. If next hop in explicit route is “strict”, it must be adjacent (reachable by connected route). If next hop is “loose”, it can be somewhere further (reachable by any other IGP route). Basically what it gives you is the ability to either specify exact path (this is the result of CSPF - it produces explicit route with all “strict” hops) or just specify the “key hops” in the path. Of course, you can also use combination of both approaches. For a complete discussion about “strict” and “loose” in explicit path see RFC 3209.
I have a wierd situation regarding a TE tunnel between two sites. VPLS works, so does BGP peering, aswell as IP routing between the loopback ips. But I cannot get the TE tunnel to come up with “use-cspf=no” and also tried “use-cspf=yes”
Would this be an OSPF issue? It is possble to create TE tunnels without OSPF?
In order to establish TE tunnel using CSPF you must:
configure interfaces on all routers for TE (/mpls traffic-eng interface add …)
configure OSPF to distribute TE information (/routing ospf set mpls-te-area=… mpls-te-router-id=…)
make sure that bandwidth and affinity constraints are met (CSPF will only find path if there is enough bandwidth as reported by OSPF available over links)
It is possible to create TE tunnels without OSPF, even without specifying explicit path (w/o specifying any intermediate hops), but again - all routers in the way must have TE enabled interfaces.
These settings are unsigned 32 bit numbers, so any number syntax will be fine. The operations applied to those numbers are bitwise operations, so probably using hexadecimal notation is the most descriptive. For example, if you specify as “include-any” value 0xff (255 decimal), this means that particular tunnel can be established over links that have any of lower 8 bits set in their affinity setting, for example over links that have affinity value: 0x1 (1), 0x3 (3), 0x8 (8), 0xff (255), 0x101 (257), 0xffff (65535), but not over links that have affinity value: 0x100 (256), 0xff00 (65280).
headstrong, affinity stuff has nothing to do with metrics. You can think of affinity stuff as of color labels you give to links (each bit in value telling if link has particular color label or not). Then you can make tunnel such that it only uses links that have e.g. red label (“include” part). Or make a tunnel that does not use links with blue label (“exclude” part). Or make tunnel that uses links that have either red or blue label (“include-any” part). Or combination of these rules.
