Am going through a bit of pain at the moment trying to get around TE tunnels breaking RPF checks for multicast.
The common wisdom seems to be to use the "mpls traffic-eng multicast-intact" command, however this only seems to work for TE auto-route.
Is it reasonable to expect that this should work for forwarding-adjacency also?
The documentation says that by using the multicast-intact command, that it will not consider TE tunnels in the RPF check. It seems to me that this should work for forwarding-adjacency as well as auto-route.
This is on 7600s running RSP720s (SRB).
I can provide more details on the design if necessary.
The reason is the same, subtlv's are assigned for TE tunnels without FA, and with FA they are not. Autoroute is more a method of using that TE tunnel to route traffic. Instead of autoroute you can try using a static route pointing to the Tunnel Destination, even then with multicast intact the RPF would pass. So from observation I feel the multicast intact feature is more to do with the sub-tlv being assigned or not. Thats how it can differentiate.
Now loop may not be the appropriate term here, its kind of a loop or assymetric routing.
For eg if they are advertised with TE extensions as well, other TE tunnels will use the FA TE tunnel to reach their destination and when you
have explicity set superior FA metric to the tunnel destinations compared to the physical link metric this is aggravated. And may beat the purpose of
having FA tunnels with customized metrics.