The same here.
Can someone show a real example of using RSVP LSPs to forward traffic towards BGP known destinations?
For now, the workaround is to set a route-filter on import with "set-in-nexthop-direct="LSP_to_whatsoever_ROUTER" and to filter out OSPF prefixes leaving just loopbacks and interconnection links.
On Junos software is much easier and understandable:
"set protocols mpls traffic-engineering bgp-igp-both-ribs".
This command copies routes from table inet.3 (RSVP) to inet.0 (global table).
That way, BGP and OSPF known routes are less specific than RSVP because of the administrative distance.
So, you need OSPF for initial convergence and BGP for other, external routes announcing as well as other protocol signaling. After that, RSVP comes in places and does all the magic.
I've tried in the lab all kind of different scenarios to meet the requirements stated on wiki:
(
http://wiki.mikrotik.com/wiki/Manual:TE ... TE_tunnels)
- traffic that is routed using route route learned from BGP, if BGP NextHop is tunnel endpoint (this default behaviour can be changed by setting route porperty "use-te-nexthop" to "no"), both - regular IP and VPNv4 (MP-BGP IP VPN) routes fit in this category;
^^^ DOES NOT WORK!
- traffic for VPLS interfaces, if remote endpoint of VPLS pseudowire is the same as TE tunnel endpoint.
^^^ Confirm, it behaves how it's written
If anybody can, please say that I'm wrong and show us a real working example! : )
PS: and stop publishing posts with examples of static routes over LSPs and even worse, - /24 subnets on 2 LSPs as they are an Ethernet link.
LSPs are unidirectional:
"An MPLS connection (LSP) is unidirectional—allowing data to flow in only one direction between two endpoints. Establishing two-way communications between endpoints requires a pair of LSPs to be established. Because 2 LSPs are required for connectivity, data flowing in the forward direction may use a different path from data flowing in the reverse direction."
Guys, serious... For those who create those articles, ...serious?! :