Page MenuHomeVyOS Platform

MPLS documentation
Closed, ResolvedPublicFEATURE REQUEST

Description

Add MPLS to VyOS documentation https://github.com/vyos/vyos-documentation
Create a guide based on popular use cases.

Details

Difficulty level
Unknown (require assessment)
Version
-
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)

Related Objects

StatusSubtypeAssignedTask
Needs testingFEATURE REQUESTNone
ResolvedFEATURE REQUESTNone

Event Timeline

Dmitry created this task.Apr 5 2020, 7:17 AM
s.lorente claimed this task.Jul 7 2020, 8:17 PM
s.lorente changed the task status from Open to On hold.Mon, Aug 10, 5:06 PM
s.lorente added a subscriber: ronie.

Currently the only application of VyOS LDP is as P router (backbone router in an MPLS cloud).

@ronie has just made some tests and found interoperability issues with Cisco routers using OSPF in the Core.

So, as it is not even clear if the only possible application of VyOS LDP works ok, I think MPLS documentation should wait.

ronie added a comment.EditedMon, Aug 10, 8:52 PM

In general, Service Providers implement IS-IS, not OSPF, as IGP in the Core. Maybe it is a good idea to develop VYOS support to IS-IS in order to make it more attractive as an immediate solution as P router to SPs.


In this lab OSPF is being used as IGP. Cisco routers are being implemented as PE/LSRs, because VYOS are not able to perform this role yet.
Everything is working from the Control Plane standpoint (VPNv4 addresses are exchanged and redistributed into OSPF).
OSPF reconverges in a strange way, as if the metric/cost were different (lower) over VYOS routers. After reviewing the configurations and activating MPLS LDP correctly between Cisco and VYOS routers, connectivity issues are solved.

Good. Things are getting better. Thank you @ronie

In theory, service providers use OSPF and ISIS for IGPs. LDP in theory shouldn't really care which protocol is used for the next hop as long as the next hop resolves and the label is there for the next hop for that LSP. Albeit I will admit I am not sure how it is organized in FRR. OSPF and ISIS should both be able to work though for next hops, and they should be consistent.

In regards to the type of LDP allocation type (ordered vs independent), generally Cisco does independent and Juniper does ordered. Cisco (from what I remember) usually allocates labels for *all* routes in the RIB except BGP. Juniper usually allocates labels for *only* the loopback. In Juniper though, the routes that resolve to the next hop (BGP ones) will also be attached to the same LSP/label as it's just more convenient for forwarding. I think it's because the forwarding table is made simpler. That way you can say all these routes use the same next hop path.

The type of LDP allocation (ordered vs independent) should generally not matter. The way that Juniper does it (ordered, and only on the loopback) allows for much less work for LDP and also makes it easier to have much less state. It also allows for one to reuse the same label for lots of different routes. For example by default it associates all BGP routes with the same LSP/outgoing label. One can also choose to use IGP routes with the same label as well, therefore assigning more routes to the same LSP/outgoing label (because they are all originated on that router at least). The way that Cisco does it creates more work for LDP, allocates a lot more labels, and generally uses more forwarding table space. Either is fine, but I don't know which one is used inside of FRR. The whole forwarding table consolidation is a bigger issue when you have constrained forwarding table space.

I also can do some testing on this, and help adding to the documentation. I have a Juniper and a Cisco I can test against.

s.lorente removed s.lorente as the assignee of this task.Wed, Aug 12, 6:10 PM
s.lorente added a subscriber: s.lorente.

For the time being I have created a document with the current limited possibilities.

https://github.com/vyos/vyos-documentation/pull/306

s.lorente closed this task as Resolved.Wed, Aug 12, 6:11 PM