Add MPLS to VyOS documentation https://github.com/vyos/vyos-documentation
Create a guide based on popular use cases.
Description
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)
- Issue type
- Improvement (missing useful functionality)
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | FEATURE REQUEST | None | T915 MPLS Support | ||
Resolved | FEATURE REQUEST | None | T2227 MPLS documentation |
Event Timeline
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.
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.
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.