Community discussions

MikroTik App
 
millenium7
Long time Member
Long time Member
Topic Author
Posts: 538
Joined: Wed Mar 16, 2016 6:12 am

MPLS TE and OSPF. Some clarification?

Fri Jun 12, 2020 6:15 am

I been labbing MPLS TE and things aren't quite as they seem, and work a little differently to how i'd expect. I'm hoping someone can clarify

Reading through the wiki page https://wiki.mikrotik.com/wiki/Manual:Simple_TE
It gives some examples, but it's not thoroughly explaining everything in use

The first thing i'm interested in is the absolute bare minimum to make MPLS TE work, to ease troubleshooting and let me establish an 'absolute bare bones working baseline' if I encounter issues. And then to understand the role of each piece so I know exactly whats going on under the hood instead of just "oh hey its working, cool, now lets walk away"

So i've noticed the absolute bare minimum to establish a TE tunnel seems to be (for statically defined tunnel paths)
1) Have OSPF running on all routers in the path and an adjacency formed (Maybe OSPF not required and BGP/static routes would also work?)
2) Go into MPLS->Traffic Engineering. Add all outgoing interfaces in a path. Bandwidth not necessary
3) Create a tunnel path and specify hops
4) Create the TE interface, specify the to-address and choose the primary path
That's it, don't need MPLS TE/CSPF enabled, don't need LDP, don't need to specify bandwidth values or anything else. That seems to work

So my first question is, how are the labels actually distributed and the path built? Given that it doesn't seem to use LDP nor is it using BGP signalled MPLS. And MPLS TE is not enabled either.....
My expectation is that labels need to be exchanged and therefore LDP or BGP-MPLS should be enabled. This doesn't appear to be the case.
On the routers in-between there is a MPLS label created in the forwarding path with type = T. Yet no local/remote bindings
Is this expected behaviour? Is this something specific to MikroTik only that would break a TE path with any other vendor? Bug but also a 'feature'?
I need to know this because i.e. if there's limited L2MTU in a path or something else unexpected, can it cause an issue and break things?

Other questions:
- How does RouterOS know for sure that the tunnel interface is actually working? I know it goes into the running state, but if a end-to-end label path is not built, and tunnels can be 1 way, how can it determine this and knowing the tunnel actually is up and working and doesn't just die somewhere along the way?
- Should anything else be specified? If i'm not caring about RSVP will it cause any issues leaving bandwidth at 0?
- What about not specifying the 'from address' on the TE interface. Again, could this cause an outage or link flap with tunnels if routing changes or an interface goes up/down etc
- 'Record Route' just shows the actual path in case it doesn't match when using 'loose' hop paths right? but doesn't actually influence anything?

-------------------------------------------------------------------------------------

For dynamic paths i.e. CSPF it seems MPLS TE needs to be enabled, this is I expect. Again though, LDP not necessary. And it has to be enabled on all routers in a path. Good thing is it doesn't seem to drop adjacency when toggling it on/off.

- Is there any reason 'NOT' to have this turned on for every router in the OSPF network by default?
- Do all routers in a TE path need to be in the same OSPF area?
- Does CSPF work if routers are in a stub/nssa area?
- Is there a way to exclude a router/hop in a path? I.e. I don't care about the path to destination X, just as long as it doesn't go through Y (if any other path available)
- If the above cannot be specified, what exactly is the point of running CSPF? Just as a last resort that uses the regular routing table?

-------------------------------------------------------------------------------------

Defining a tunnel path:

The Wiki examples show specifying the IP address of every interface along the path, implying at least 2 entries for every router in between. I found this isn't required, whether using strict or loose routing. You only need to specify the next hop IP and can use loopbacks (when using loose) but with 2 exceptions
1) The first hop can actually be the interface IP of the local router, it doesn't even need to be the IP of the next router
2) The last IP 'must' be the actual interface that traffic is coming in on, it can't be any other IP of that router

Image

From D to A (Desired path = D->C->B->A)

*Works*
10.1.34.1
2.2.2.2 loose
10.1.12.1

*Works*
10.1.34.2
2.2.2.2 loose
10.1.12.1

*Works*
10.1.34.1
10.1.23.1
10.1.12.1

But if I try something like
3.3.3.3
2.2.2.2
1.1.1.1
it doesn't work.

So what are the exact rules regarding defining a hop path?

The first IP 'must' be 10.1.34.1. or 10.1.34.2 (strange that .2 works) and the last IP 'must' be 10.1.12.1. This could cause a scalability issue for final destination routers that have many paths, since i'm going to need 1 tunnel path for every interface that router has in the OSPF network. Or is there some other way around this?
And I don't have enough lab routers to test further.
If i'm using 'loose' hops do I still need to specify every single router in the path as a hop? Or i.e. if there another 2 routers between C and B would the first example still work? or would I need to specify the interface/loopback addresses of those routers as well?

Who is online

Users browsing this forum: jerryuser and 20 guests