TE lab testing flushing out how TE works, configured a primary and backup
tunnel between PEs, both directions.
Primary is dynamic and backup is explicit, initially priorities were the
same, I then choose
to make one tunnel preferred over the other adjusting the priorities, I
choose the tunnel that was backup
to become primary to watch the traffic shift. (primary path was P1-P2-P3,
backup path P1-P3). However,
the traffic did not shift, a manual shut on a P3-P2 interface made the
traffic shift, reintroduction
kept the traffic on P1-P3, then a "mpls traffic reoptimize" moved the
traffic back to P1-P2-P3.
Obviously the preferred MPLS tunnel is still P1-P2-P3 even though I
configured "tunnel mpls traffic-eng priority 1 1"
on P1-P3 and "tunnel mpls traffic-eng priority 7 7" on P1-P2-P3. What am I
missing here?
My setup:
CE-----PE-----P1----------P3-------PE----CE
\ /
\ /
P2
Mike
Hello Mike,
What exactly do you mean by primary and backup please?
As the tunnel "mpls traffic-eng priority" cmd simply only specifies the setup and hold priorities
(you'd use those when there are tunnels carrying low priority traffic filling up the available TE BW -and you need to setup a tunnel carrying voice through that link -because the primary link failed -the higher setup priority of the voice tunnel would knock down some of the scavenger tunnels with lower hold priority)
Now I'm not sure but I guess you can't have one tunnel act as backup for a specific te-tunnel
Though you can configure a te-tunnel to act as a backup for a link
Since one of your tunnels is dynamic it can be re-established around the failed link
Though which tunnel is going to be used to forward traffic is based on how you instruct the trafic to use one of the tunnes as primary path
adam
I am also looking at FRR which uses a backup tunnel for fast convergence. I
did however not think
about the dynamic nature of the tunnel and the potential for
reestablishment.
Mike
Even with primary/secondary paths, the secondary path will normally not get used if the primary can resignal to a different path. Implementations can get very vendor specific. Each vendor supports different subsets of the necessary protocols. I just had a single vendor network, that due to lack of SRLG support in their lower end boxes (and lack of admin-group in FRR) required setting facility based FRR with many bypasses (which luckily they did support at all levels and the manual bypasses did support admin-groups for setup).
The only time I usually use dual LSPs is to support load balancing across multiple circuits where vendor support is limited (1 LSP down each pipe, IGP balance between them, each LSP has secondary path on opposite pipe). The idea of MPLS is that the LSP should NOT be down. A path might go down and FRR/secondy paths might come into play, but the LSP itself should still be handling traffic. Even in complicated QOS setups, you can have primary, and multiple secondaries to allow stepdown of what a circuit should be reserving, and priorities to even preempt circuits to lower class of service (imagine a secondary trying for what it currently has without preemption, but then that failing, sets different requirements and preempts lesser circuits).
In simpler topologies where I don't need TE and I just want FRR, I've been playing with Juniper's LFA implementation. One of my current plans is using RSVP/FRR for mpls only services and using LFA for global routing. It works for my specific layout, and the only annoyance is setting BGP next-hops correctly.
Jack