Page MenuHomeVyOS Platform

MPLS Support
Closed, ResolvedPublicFEATURE REQUEST

Description

hi,

recent linux kernel have mpls support included. frr builds in vyos have also mpls support included and the iproute2 on vyos is also mpls ready.
Documentation:

http://www.samrussell.nz/2015/12/mpls-testbed-on-ubuntu-linux-with.html
http://docs.frrouting.org/en/latest/zebra.html#mpls-commands

in 1.2.x frr raised an error cause the kernel is lacking mpls support...

Details

Version
-
Is it a breaking change?
Perfectly compatible
Issue type
Feature (new functionality)

Related Objects

StatusSubtypeAssignedTask
ResolvedFEATURE REQUESTNone
ResolvedFEATURE REQUESTc-po
ResolvedFEATURE REQUESTNone

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

PR https://github.com/vyos/vyos-1x/pull/531
Add discovery hello timers

vyos@r4-roll# set protocols mpls ldp discovery 
Possible completions:
   hello-holdtime
                Holdtime interval
   hello-interval
                Hello interval

PR https://github.com/vyos/vyos-1x/pull/531
Add discovery hello timers

Firstly, holy shit you guys are fast.

Secondly, when it gets put into rolling I'll immediately test :)

Thank you thank you thank you.

@Viacheslav what about abnormal label allocation behavior which I wrote earlier? Was it fixed?

@craterman Can you share an example of a configuration or how it looks in the frr? So that I can reproduce this in a test lab.
And share additional show the output and what you expect to see.

@Cheeze_It Timers available in the latest rolling release, VyOS 1.3-rolling-202008200357

Ok, I got the new version of code and here is what I found. As a baseline here's the Vyos config, and it's more or less the same as before but I moved lab environments:

set interfaces ethernet eth0 address '192.168.255.5/31'
set interfaces ethernet eth0 hw-id '0c:62:90:14:1d:00'
set interfaces ethernet eth0 ip ospf network 'point-to-point'
set interfaces ethernet eth1 address '192.168.255.7/31'
set interfaces ethernet eth1 hw-id '0c:62:90:14:1d:01'
set interfaces ethernet eth1 ip ospf network 'point-to-point'
set interfaces ethernet eth2 hw-id '0c:62:90:14:1d:02'
set interfaces ethernet eth3 hw-id '0c:62:90:14:1d:03'
set interfaces ethernet eth4 hw-id '0c:62:90:14:1d:04'
set interfaces ethernet eth5 hw-id '0c:62:90:14:1d:05'
set interfaces ethernet eth6 hw-id '0c:62:90:14:1d:06'
set interfaces ethernet eth7 hw-id '0c:62:90:14:1d:07'
set interfaces ethernet eth8 hw-id '0c:62:90:14:1d:08'
set interfaces ethernet eth9 hw-id '0c:62:90:14:1d:09'
set interfaces ethernet eth10 hw-id '0c:62:90:14:1d:0a'
set interfaces ethernet eth11 hw-id '0c:62:90:14:1d:0b'
set interfaces ethernet eth12 hw-id '0c:62:90:14:1d:0c'
set interfaces ethernet eth13 hw-id '0c:62:90:14:1d:0d'
set interfaces ethernet eth14 hw-id '0c:62:90:14:1d:0e'
set interfaces loopback lo address '192.168.0.5/32'
set protocols mpls ldp discovery transport-ipv4-address '192.168.0.5'
set protocols mpls ldp interface 'eth0'
set protocols mpls ldp interface 'eth1'
set protocols mpls ldp interface 'lo'
set protocols mpls ldp router-id '192.168.0.5'
set protocols ospf area 0 network '192.168.255.4/31'
set protocols ospf area 0 network '192.168.255.6/31'
set protocols ospf area 0 network '192.168.0.5/32'
set protocols ospf mpls-te router-address '192.168.0.5'
set system config-management commit-revisions '100'
set system console device ttyS0 speed '115200'
set system host-name 'vyos'
set system login user vyos authentication encrypted-password '$6$QxPS.uk6mfo$9QBSo8u1FkH16gMyAVhus6fU3LOzvLR9Z9.82m3tiHFAxTtIkhaZSWssSgzt4v4dGAL8rhVQxTg0oAG9/q11h/'
set system login user vyos authentication plaintext-password ''
set system ntp server 0.pool.ntp.org
set system ntp server 1.pool.ntp.org
set system ntp server 2.pool.ntp.org
set system syslog global facility all level 'info'
set system syslog global facility protocols level 'debug'

Good news, everything came back up on all devices. First it is vyos, second is Juniper, third is Juniper:

vyos@vyos:~$ show ip ospf neighbor

Neighbor ID     Pri State           Dead Time Address         Interface                        RXmtL RqstL DBsmL
192.168.0.2     128 Full/DROther      31.071s 192.168.255.4   eth0:192.168.255.5                   0     0     0
192.168.0.4     128 Full/DROther      39.406s 192.168.255.6   eth1:192.168.255.7                   0     0     0

user@JER2.LAX1> show ospf neighbor
Address          Interface              State     ID               Pri  Dead
192.168.255.0    ge-0/0/0.0             Full      192.168.0.1      128    36
192.168.255.5    ge-0/0/1.0             Full      192.168.0.5        1    31

user@JER2.NYC1> show ospf neighbor
Address          Interface              State     ID               Pri  Dead
192.168.255.2    ge-0/0/0.0             Full      192.168.0.3      128    37
192.168.255.7    ge-0/0/1.0             Full      192.168.0.5        1    39




vyos@vyos:~$ show  mpls ldp neighbor
AF   ID              State       Remote Address    Uptime
ipv4 192.168.0.2     OPERATIONAL 192.168.0.2     00:05:56
ipv4 192.168.0.4     OPERATIONAL 192.168.0.4     00:05:57

user@JER2.LAX1> show ldp session
  Address                           State       Connection  Hold time  Adv. Mode
192.168.0.1                         Operational Open          21         DU
192.168.0.5                         Operational Open          21         DU

user@JER2.NYC1> show ldp session
  Address                           State       Connection  Hold time  Adv. Mode
192.168.0.3                         Operational Open          27         DU
192.168.0.5                         Operational Open          27         DU

Now here's something that I thought was interesting. When I do a detail view it seems all of the sessions are using a 10/30 hello/hold timers. First it is vyos, second is Juniper, third is Juniper:

vyos@vyos:~$ show  mpls ldp neighbor detail
Peer LDP Identifier: 192.168.0.2:0
  TCP connection: 192.168.0.5:36975 - 192.168.0.2:646
  Authentication: none
  Session Holdtime: 30 secs; KeepAlive interval: 10 secs
  State: OPERATIONAL; Downstream-Unsolicited
  Up time: 00:07:46
  Messages sent/rcvd:
   - Keepalive Messages: 47/47
   - Address Messages: 1/1
   - Address Withdraw Messages: 0/0
   - Notification Messages: 0/0
   - Capability Messages: 0/0
   - Label Mapping Messages: 7/5
   - Label Request Messages: 0/0
   - Label Withdraw Messages: 0/0
   - Label Release Messages: 0/0
   - Label Abort Request Messages: 0/0
  Capabilities Sent:
   - Dynamic Announcement (0x0506)
   - Typed Wildcard (0x050B)
   - Unrecognized Notification (0x0603)
  Capabilities Received:
  LDP Discovery Sources:
    IPv4:
      Interface: eth0

Peer LDP Identifier: 192.168.0.4:0
  TCP connection: 192.168.0.5:51351 - 192.168.0.4:646
  Authentication: none
  Session Holdtime: 30 secs; KeepAlive interval: 10 secs
  State: OPERATIONAL; Downstream-Unsolicited
  Up time: 00:07:47
  Messages sent/rcvd:
   - Keepalive Messages: 47/47
   - Address Messages: 1/1
   - Address Withdraw Messages: 0/0
   - Notification Messages: 0/0
   - Capability Messages: 0/0
   - Label Mapping Messages: 9/5
   - Label Request Messages: 0/0
   - Label Withdraw Messages: 0/0
   - Label Release Messages: 0/0
   - Label Abort Request Messages: 0/0
  Capabilities Sent:
   - Dynamic Announcement (0x0506)
   - Typed Wildcard (0x050B)
   - Unrecognized Notification (0x0603)
  Capabilities Received:
  LDP Discovery Sources:
    IPv4:
      Interface: eth1



user@JER2.LAX1> show ldp session 192.168.0.5 detail
Address: 192.168.0.5, State: Operational, Connection: Open, Hold time: 23
  Session ID: 192.168.0.2:0--192.168.0.5:0
  Next keepalive in 3 seconds
  Passive, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1
  Neighbor types: discovered
  Keepalive interval: 10, Connect retry interval: 1
  Local address: 192.168.0.2, Remote address: 192.168.0.5
  Up for 00:07:37
  Capabilities advertised: none
  Capabilities received: none
  Protection: disabled
  Session flags: none
  Local - Restart: disabled, Helper mode: enabled
  Remote - Restart: disabled, Helper mode: disabled
  Local maximum neighbor reconnect time: 120000 msec
  Local maximum neighbor recovery time: 240000 msec
  Local Label Advertisement mode: Downstream unsolicited
  Remote Label Advertisement mode: Downstream unsolicited
  Negotiated Label Advertisement mode: Downstream unsolicited
  MTU discovery: disabled
  Nonstop routing state: Not in sync
  Next-hop addresses received:
    192.168.0.5
    192.168.255.5
    192.168.255.7



user@JER2.NYC1> show ldp session 192.168.0.5 detail
Address: 192.168.0.5, State: Operational, Connection: Open, Hold time: 25
  Session ID: 192.168.0.4:0--192.168.0.5:0
  Next keepalive in 4 seconds
  Passive, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1
  Neighbor types: discovered
  Keepalive interval: 10, Connect retry interval: 1
  Local address: 192.168.0.4, Remote address: 192.168.0.5
  Up for 00:07:35
  Capabilities advertised: none
  Capabilities received: none
  Protection: disabled
  Session flags: none
  Local - Restart: disabled, Helper mode: enabled
  Remote - Restart: disabled, Helper mode: disabled
  Local maximum neighbor reconnect time: 120000 msec
  Local maximum neighbor recovery time: 240000 msec
  Local Label Advertisement mode: Downstream unsolicited
  Remote Label Advertisement mode: Downstream unsolicited
  Negotiated Label Advertisement mode: Downstream unsolicited
  MTU discovery: disabled
  Nonstop routing state: Not in sync
  Next-hop addresses received:
    192.168.0.5
    192.168.255.5
    192.168.255.7

When looking at the discovery timers however, it seems that indeed everything is defaulting properly to 5/15 hello/hold timers. First it is vyos, second is Juniper, third is Juniper:

vyos@vyos:~$ show mpls ldp discovery
AF   ID              Type     Source           Holdtime
ipv4 192.168.0.2     Link     eth0                   15
ipv4 192.168.0.4     Link     eth1                   15
ipv4 192.168.0.5     Link     lo                     15

user@JER2.LAX1> show ldp neighbor
Address                             Interface       Label space ID     Hold time
192.168.255.5                       ge-0/0/1.0      192.168.0.5:0        13

user@JER2.NYC1> show ldp neighbor
Address                             Interface       Label space ID     Hold time
192.168.255.7                       ge-0/0/1.0      192.168.0.5:0        14

When I change to 1/10 for the timers it *does* change on Vyos, and I see the changes reflected in the actual packets on the Junipers. I verified the hello packets taking 1 second, and the discovery hold time changing to 10 seconds. I took 3 outputs from the Junipers to show the timer not changing as a way of showing indeed 1 second hellos were refreshing the hold time. Upon changing these parameters I also noticed the LDP sessions bounce, which seems reasonable. First it is vyos, second is Juniper, third is Juniper:

vyos@vyos# compare
[edit protocols mpls ldp discovery]
+hello-holdtime 10
+hello-interval 1

vyos@vyos:~$ show mpls ldp neighbor
AF   ID              State       Remote Address    Uptime
ipv4 192.168.0.2     OPERATIONAL 192.168.0.2     00:00:10
ipv4 192.168.0.4     OPERATIONAL 192.168.0.4     00:00:12

vyos@vyos:~$ show mpls ldp discovery
AF   ID              Type     Source           Holdtime
ipv4 192.168.0.2     Link     eth0                   10
ipv4 192.168.0.4     Link     eth1                   10
ipv4 192.168.0.5     Link     lo                     10


user@JER2.LAX1> show ldp neighbor 192.168.255.5
Address                             Interface       Label space ID     Hold time
192.168.255.5                       ge-0/0/1.0      192.168.0.5:0        9

user@JER2.LAX1> show ldp neighbor 192.168.255.5
Address                             Interface       Label space ID     Hold time
192.168.255.5                       ge-0/0/1.0      192.168.0.5:0        9

user@JER2.LAX1> show ldp neighbor 192.168.255.5
Address                             Interface       Label space ID     Hold time
192.168.255.5                       ge-0/0/1.0      192.168.0.5:0        9



user@JER2.NYC1> show ldp neighbor 192.168.255.7
Address                             Interface       Label space ID     Hold time
192.168.255.7                       ge-0/0/1.0      192.168.0.5:0        9

user@JER2.NYC1> show ldp neighbor 192.168.255.7
Address                             Interface       Label space ID     Hold time
192.168.255.7                       ge-0/0/1.0      192.168.0.5:0        9

user@JER2.NYC1> show ldp neighbor 192.168.255.7
Address                             Interface       Label space ID     Hold time
192.168.255.7                       ge-0/0/1.0      192.168.0.5:0        9

Ok so lastly, I changed the values to longer amounts (not super high but, longer than normal for the hello/hold values) on all routers and verified that indeed everything changed along with them properly on all routers. First it is vyos, second is Juniper, third is Juniper:

vyos@vyos# compare
[edit protocols mpls ldp discovery]
>hello-holdtime 60
>hello-interval 25

user@JER2.LAX1> show system rollback compare 1 0
[edit protocols ldp interface ge-0/0/1.0]
+    hello-interval 25;
+    hold-time 60;

user@JER2.NYC1> show system rollback compare 1 0
[edit protocols ldp interface ge-0/0/1.0]
+    hello-interval 25;
+    hold-time 60;



vyos@vyos:~$ show mpls ldp neighbor
AF   ID              State       Remote Address    Uptime
ipv4 192.168.0.2     OPERATIONAL 192.168.0.2     00:02:04
ipv4 192.168.0.4     OPERATIONAL 192.168.0.4     00:02:03

vyos@vyos:~$ show mpls ldp discovery
AF   ID              Type     Source           Holdtime
ipv4 192.168.0.2     Link     eth0                   60
ipv4 192.168.0.4     Link     eth1                   60
ipv4 192.168.0.5     Link     lo                     60



user@JER2.LAX1> show ldp neighbor 192.168.255.5
Address                             Interface       Label space ID     Hold time
192.168.255.5                       ge-0/0/1.0      192.168.0.5:0        41

user@JER2.LAX1> show ldp neighbor 192.168.255.5
Address                             Interface       Label space ID     Hold time
192.168.255.5                       ge-0/0/1.0      192.168.0.5:0        59



user@JER2.NYC1> show ldp neighbor 192.168.255.7
Address                             Interface       Label space ID     Hold time
192.168.255.7                       ge-0/0/1.0      192.168.0.5:0        36

user@JER2.NYC1> show ldp neighbor 192.168.255.7
Address                             Interface       Label space ID     Hold time
192.168.255.7                       ge-0/0/1.0      192.168.0.5:0        58

Last, but not the least I went to check on the routes in the routing tables and they *still* seem to be properly working fine as well. I decided to go one router away from the Vyos box and use it purely as an MPLS P. As a pure MPLS P role, Vyos works properly with routes shown on farther out Junipers transiting Vyos, including MPLS pings:

user@JER1.LAX1> show route protocol ldp table inet.3

inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.0.2/32     *[LDP/9] 00:01:12, metric 1
                    > to 192.168.255.1 via ge-0/0/0.0
192.168.0.3/32     *[LDP/9] 00:01:00, metric 1
                    > to 192.168.255.1 via ge-0/0/0.0, Push 299856
192.168.0.4/32     *[LDP/9] 00:01:00, metric 1
                    > to 192.168.255.1 via ge-0/0/0.0, Push 299872
192.168.0.5/32     *[LDP/9] 00:01:00, metric 1
                    > to 192.168.255.1 via ge-0/0/0.0, Push 299888

user@JER1.NYC1> show route protocol ldp table inet.3

inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.0.1/32     *[LDP/9] 00:00:54, metric 1
                    > to 192.168.255.3 via ge-0/0/0.0, Push 299840
192.168.0.2/32     *[LDP/9] 00:00:54, metric 1
                    > to 192.168.255.3 via ge-0/0/0.0, Push 299856
192.168.0.4/32     *[LDP/9] 00:01:08, metric 1
                    > to 192.168.255.3 via ge-0/0/0.0
192.168.0.5/32     *[LDP/9] 00:00:54, metric 1
                    > to 192.168.255.3 via ge-0/0/0.0, Push 299888


user@JER1.NYC1> ping mpls ldp 192.168.0.1/32 source 192.168.0.3
!!!!!
--- lsping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

One thing I did notice that did not work (and I think this would more or less be due to other options that can be enabled that FRR currently doesn't have yet) was that LSP pings from the Junipers directly connected to the Vyos VM failed but that's due to a specific corner case. FRR currently doesn't support explicit null in LDP, and Vyos doesn't have it implemented. However that shouldn't cause a problem in the current role that Vyos has. As an MPLS P Vyos works absolutely how it needs to. This seems to have a fix in FRR 7.4 as well per note "Ingress packets coming through broken LSP are no longer dropped."

I would say that for what it's worth....I think we're good here. I think that the new additions are working as expected. So I am unsure if the ordered label allocation will be added later when things are moved to FRR 7.4, or if you'll put in that now @Viacheslav. But for what it is, MPLS support with LDP is verifiably working as it should be per the implementation in FRR 7.3.1. Thank you sir :)

@craterman Can you share an example of a configuration or how it looks in the frr? So that I can reproduce this in a test lab.
And share additional show the output and what you expect to see.

@Viacheslav I have tried today the last rolling release (1.3-rolling-202008210118). It seams it works fine now

@Viacheslav

Hello sir. I am unsure if you're able to add more under LDP but I have found others if you possibly could add. They should be simple additions and are already supported under FRR 7.3.1.

One of them looks like this:

ISP4-EDGE(config-ldp-af)# session holdtime
  (15-65535)  Time (seconds)

Which is under:

mpls ldp
 router-id 192.168.255.252
 !
 address-family ipv4
  discovery hello holdtime 30
  discovery hello interval 10
  session holdtime 120      <--- HERE
  discovery transport-address 192.168.255.252
  label local allocate host-routes
  !
  interface eth0
  !
  interface eth1
  !
 exit-address-family
 !

For the config it would look like this:

vyos@ISP4-EDGE:~$ show configuration commands | match ldp
set protocols mpls ldp discovery hello-holdtime '30'
set protocols mpls ldp discovery hello-interval '10'
set protocols mpls ldp discovery session-ipv4-holdtime '120'     <---- HERE
set protocols mpls ldp discovery transport-ipv4-address '192.168.255.252'
set protocols mpls ldp interface 'eth0'
set protocols mpls ldp interface 'eth1'
set protocols mpls ldp router-id '192.168.255.252'

There's others to add too but I figure this one should be fairly simple and easy. I can add the others later if/when you have a moment. It should be fairly easy to add the allocate and no allocate ones as well. The IPv6 of this would also be valid as well.

I'm thinking we could follow the way it's done for the transport address and just do:

set protocols mpls ldp discovery session-ipv4-holdtime '120'     <---- For address family IPv4
set protocols mpls ldp discovery session-ipv6-holdtime '120'     <---- For address family IPv6

@Viacheslav

The next one that I think would be fairly easy to add would be the following:

ISP4-EDGE(config-ldp-af)# label local advertise explicit-null
  <cr>
  for   IP access-list for destination prefixes

So this one is under address family as well.

mpls ldp
 router-id 192.168.255.252
 !
 address-family ipv4
  discovery hello holdtime 30
  discovery hello interval 10
  discovery transport-address 192.168.255.252
  label local allocate host-routes
  label local advertise explicit-null     <---- HERE
  !
  interface eth0
  !
  interface eth1
  !
 exit-address-family
 !

I figure though we could make the configuration look like this:

set protocols mpls ldp export ipv4 explicit-null <optional access list here if wanted>     <---- For address family IPv4
set protocols mpls ldp export ipv6 explicit-null <optional access list here if wanted>     <---- For address family IPv6

@Viacheslav

The one after that I feel would be fairly easy to also implement is customized label allocation. Again, it is under the family of IPv4 or IPv6.

ISP4-EDGE(config-ldp-af)# label local allocate
  for          IP access-list
  host-routes  allocate local label for host routes only

Default seems to be:

address-family ipv4
 discovery hello holdtime 30
 discovery hello interval 10
 discovery transport-address 192.168.255.252
 label local allocate host-routes    <---- Here is the default

So, I would be curious if we could change this to where this is no longer there *but* it must be added. I figure it would be fairly easy to put in a commit failure if command is missing.

Either way, would it be possible for a configuration addition to be made to make it look like this in the config:

set protocols mpls ldp label-allocation ipv4 local-routes     <---- For address family IPv4
set protocols mpls ldp label-allocation ipv6 local-routes     <---- For address family IPv6

Then if someone wants to add their own specific access list it can look like this:

set protocols mpls ldp label-allocation ipv4 <access list name>     <---- For address family IPv4
set protocols mpls ldp label-allocation ipv6 <access list name>     <---- For address family IPv6

However it'll be one or the other but not both. Either it can be local-routes, or a named ACL.

@Viacheslav

Ok, so here's the export LDP FEC one that I think we could take advantage of.

This is for both IPv4 and IPv6.

So the config is like this under FRR:

address-family ipv4
 discovery hello holdtime 30
 discovery hello interval 10
 discovery transport-address 192.168.255.252
 label local allocate host-routes
 !
 interface eth0
 !
 interface eth1
 !
exit-address-family
ISP4-EDGE(config-ldp-af)# label local advertise
  <cr>
  explicit-null  Configure explicit-null advertisement
  for            IP access-list for destination prefixes
  to             IP Access-list specifying controls on LDP Peers

So a generic application that should apply to all neighbors would look like this:

ISP4-EDGE(config-ldp-af)# label local advertise for <access list name> 
  <cr>
  to    IP Access-list specifying controls on LDP Peers

Then if you want to go for a specific LDP peer then it would be:

ISP4-EDGE(config-ldp-af)# label local advertise for <access list name>  to <access list name> 
  <cr>

So I propose that we do this like this on the CLI, with the neighbor list being optional:

set protocols mpls ldp export ipv4 export-list <access list name> neighbor-list <access list name>     <---- For address family IPv4
set protocols mpls ldp export ipv6 export-list <access list name> neighbor-list <access list name>     <---- For address family IPv6

So the command should accept the export-list, or the export-list + neighbor-list.

@Viacheslav

Ok, so here's the import LDP FEC one that I think we could take advantage of as well.

This is for both IPv4 and IPv6.

So the config is like this under FRR:

address-family ipv4
 discovery hello holdtime 30
 discovery hello interval 10
 discovery transport-address 192.168.255.252
 label local allocate host-routes
 !
 interface eth0
 !
 interface eth1
 !
exit-address-family
ISP4-EDGE(config-ldp-af)# label remote accept
  for   IP access-list for destination prefixes
  from  Neighbor from whom to accept label advertisement

So a generic application that should apply to all neighbors would look like this:

ISP4-EDGE(config-ldp-af)# label remote accept for <access list name>
  <cr>
  from  Neighbor from whom to accept label advertisement

Then if you want to go for a specific LDP peer then it would be:

ISP4-EDGE(config-ldp-af)# label remote accept for <access list name>  from <access list name> 
  <cr>

So I propose that we do this like this on the CLI, with the neighbor list being optional:

set protocols mpls ldp import ipv4 import-list <access list name> neighbor-list <access list name>     <---- For address family IPv4
set protocols mpls ldp import ipv6 import-list <access list name> neighbor-list <access list name>     <---- For address family IPv6

@Viacheslav

The last thing I think we can add is the dual stack capability options. We only got 2.

The FRR config looks like this:

ISP4-EDGE(config-ldp)# dual-stack
  cisco-interop         Use Cisco non-compliant format to send and interpret the Dual-Stack capability TLV
  transport-connection  Configure TCP transport parameters

The first one looks like this:

ISP4-EDGE(config-ldp)# dual-stack cisco-interop
  <cr>

I propose that we implement it like this:

set protocols mpls ldp cisco-interop-tlv

The second one looks like this:

ISP4-EDGE(config-ldp)# dual-stack transport-connection prefer ipv4
  <cr>

I figure we could stick this option under discovery:

set protocols mpls ldp discovery transport-prefer-ipv4

PR https://github.com/vyos/vyos-1x/pull/571

Add new CLI commands for mpls

set protocols mpls ldp discovery session-ipv4-holdtime '33'
set protocols mpls ldp export ipv4 explicit-null

Vtysh

!
mpls ldp
 router-id 100.64.0.1
 !
 address-family ipv4
  discovery transport-address 100.64.0.1
  label local allocate host-routes
  label local advertise explicit-null
  session holdtime 33
  !
  interface eth1
  !
 exit-address-family
 !

I'll be giving those a test once T2981 is done. I'll report back here with results :)

Here is the test for Explicit Null.

Original route is:

vyos@ISP1-EDGE:~$ show ip route 4.0.2.0/32
Routing entry for 4.0.2.0/32
  Known via "bgp", distance 170, metric 0, best
  Last update 00:02:22 ago
    192.168.255.254 (recursive), weight 1
  *   192.168.0.1, via eth0, label implicit-null, weight 1

Changing config on router that is originating that:

vyos@ISP2-EDGE# compare
[edit protocols mpls ldp]
+export {
+    ipv4 {
+        explicit-null
+    }
+}

Route indeed changes to explicit null for LDP:

vyos@ISP1-EDGE:~$ show ip route 4.0.2.0/32
Routing entry for 4.0.2.0/32

Known via "bgp", distance 170, metric 0, best
Last update 00:00:03 ago
  192.168.255.254 (recursive), weight 1
*   192.168.0.1, via eth0, label IPv4 Explicit Null, weight 1

Ping works from the MPLS P core:

vyos@ISP1-EDGE:~$ ping 4.0.2.0
PING 4.0.2.0 (4.0.2.0) 56(84) bytes of data.
64 bytes from 4.0.2.0: icmp_seq=1 ttl=63 time=103 ms
^C
--- 4.0.2.0 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

Ping works from non-MPLS remote site using VyOS as MPLS core:

root@SITE-1-vQFX> ping 4.0.2.0 rapid
PING 4.0.2.0 (4.0.2.0): 56 data bytes
!!!!!
--- 4.0.2.0 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 108.847/184.857/205.198/38.033 ms

I think we can verify that MPLS explicit null works as expected. Awesome :)

Here is the test for the LDP session time change.

Original neighbor LDP sessions are:

vyos@ISP1-EDGE:~$ show mpls ldp neighbor detail | match "Peer LDP Identifier|Session Holdtime"
Peer LDP Identifier: 192.168.255.252:0
  Session Holdtime: 180 secs; KeepAlive interval: 60 secs
Peer LDP Identifier: 192.168.255.254:0
  Session Holdtime: 180 secs; KeepAlive interval: 60 secs

Changed hold time to 300:

vyos@ISP1-EDGE# compare
[edit protocols mpls ldp discovery]
+session-ipv4-holdtime 300
vyos@ISP2-EDGE# set protocols mpls ldp discovery session-ipv4-holdtime 300
[edit]
vyos@ISP2-EDGE# compare
[edit protocols mpls ldp discovery]
>session-ipv4-holdtime 300

The LDP session hold time shows changed:

vyos@ISP1-EDGE:~$ show mpls ldp neighbor detail | match "Peer LDP Identifier|Session Holdtime"
Peer LDP Identifier: 192.168.255.252:0
  Session Holdtime: 180 secs; KeepAlive interval: 60 secs
Peer LDP Identifier: 192.168.255.254:0
  Session Holdtime: 300 secs; KeepAlive interval: 100 secs

I think we can verify that MPLS session hold time command works as expected. Awesome :)

@Cheeze_It thank you for testing.

I add new commands that you asked before.

PR https://github.com/vyos/vyos-1x/pull/580

set protocols mpls ldp cisco-interop-tlv
set protocols mpls ldp discovery transport-prefer-ipv4

Updated PR with section "parameters"
https://github.com/vyos/vyos-1x/pull/580

set protocols mpls ldp parameters cisco-interop-tlv
set protocols mpls ldp parameters transport-prefer-ipv4

@Viacheslav

Can you add this commands

Vtysh

mpls ldp
 !
 address-family ipv4
  discovery transport-address X.X.X.X
//  label local allocate host-routes//
  !
 exit-address-family
 !
 address-family ipv6
  discovery transport-address X:X::X:X
//  label local allocate host-routes//
  !
 exit-address-family

For VyOS I propose to use the next one. Or something like this

set protocols mpls ldp allocate ipv4 label local host-routes
set protocols mpls ldp allocate ipv6 label local host-routes

and also this one

Vtysh

mpls ldp
 !
 address-family ipv4
  discovery transport-address X.X.X.X
//  label local allocate for <IP access-list name>//
  !
 exit-address-family
 !
 address-family ipv6
  discovery transport-address X:X::X:X
//  label local allocate for <IP access-list name>//
  !
 exit-address-family

For VyOS I propose to use the next one. Or something like this

set protocols mpls ldp allocate ipv4 label local for <network-group name>
set protocols mpls ldp allocate ipv6 label local for <network-group name>

@craterman

I put a request on this up top. We'll get to it eventually, but I was hoping we could put it like this:

set protocols mpls ldp export ipv4 export-list <access list name> neighbor-list <access list name>     <---- For address family IPv4
set protocols mpls ldp export ipv6 export-list <access list name> neighbor-list <access list name>     <---- For address family IPv6

set protocols mpls ldp import ipv4 import-list <access list name> neighbor-list <access list name>     <---- For address family IPv4
set protocols mpls ldp import ipv6 import-list <access list name> neighbor-list <access list name>     <---- For address family IPv6

Put in a PR to separate hello/hold timers for IPv4 and IPv6. Added IPv6 timers.

https://github.com/vyos/vyos-1x/pull/585

Put in a PR to add TTL security for static LDP neighbors.

https://github.com/vyos/vyos-1x/pull/595

Put in a PR to add session hold time for static LDP neighbors.

https://github.com/vyos/vyos-1x/pull/596

Put in a PR to add miscellaneous MPLS and LDP parameters.

https://github.com/vyos/vyos-1x/pull/598

Layer 2 mpls functions were merged in to the kernel on the 3rd of October, this should hopefully allow BGP signalled VPLS and static LDP pseudowire tunnels. Support still appears to be missing in FRR and it will probably be a while until VyOS is based on this newer kernel, but hoorray!

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20201006&id=ef743c0990337f3ed2648b6c6847eddc593241db

@bbs2web, oh don't you worry. I've had my eyes on it after I get LDP done. I'm almost done with it too.

My next thing is what @craterman has been asking for.

Then after that I hope to get VPWS and VPLS functionality coded in. I also have to test it, so it'll take me a little bit but I *hope* to get it all done before 1.3 is on feature freeze.

Put in a PR for refactor of LDP template, MPLS python handler, addition of global MPLS parameters (via Linux kernel config changes), and separation of MPLS interfaces from LDP interfaces. *PLEASE* know I did do testing but I want more people to test as well. I have uploaded the package file for this PR here so that people can test my work.

https://github.com/vyos/vyos-1x/pull/616

Is it expected that 'cat /proc/sys/net/mpls/platform_labels' yields '0' unless one defined 'set protocols mpls interface X'?

Configuration now:

set protocols mpls interface 'eth0.36'
set protocols mpls interface 'eth0.38'
set protocols mpls interface 'eth0.39'
set protocols mpls ldp discovery hello-ipv4-holdtime '10'
set protocols mpls ldp discovery hello-ipv4-interval '1'
set protocols mpls ldp discovery transport-ipv4-address '51.179.23.172'
set protocols mpls ldp interface 'eth0.36'
set protocols mpls ldp interface 'eth0.38'
set protocols mpls ldp interface 'eth0.39'
set protocols mpls ldp router-id '51.179.23.172'
set protocols mpls parameters no-propagate-ttl

Edit:
Ahh... I presume the 'set protocol mpls interface X' configuration stanzas replace the previous need to activate MPLS on the individual interfaces pseudo-manually:

set system sysctl custom net.mpls.conf.eth0/36.input value '1'
set system sysctl custom net.mpls.conf.eth0/38.input value '1'
set system sysctl custom net.mpls.conf.eth0/39.input value '1'

@bbs2web, yessir, this is a new changed behavior. In the past when you configured an LDP interface it also enabled MPLS on the same interface.

Those have now been disconnected. This is for the future when SR, and RSVP are enabled. That way you can enable SR or RSVP without having to also enable LDP.

I will update the documentation with it. Just haven't yet...

Or are you saying that ethernet interfaces with a sub interface are *not* enabling MPLS?

If I remove the manual sysctl lines it surprisingly still appears to work but proc net mpls is not flipped on as I would have expected.

I initially presumed that it needed to replace the full stop with a forward slash, when referencing the interface name, when calling sysctl but if I put them back and restart the output is identical.

sh-5.0# cat /proc/sys/net/mpls/platform_labels 
1048575
sh-5.0# cat /proc/sys/net/mpls/ip_ttl_propagate                                 0
sh-5.0# tail /proc/sys/net/mpls/conf/eth0*/input
==> /proc/sys/net/mpls/conf/eth0.11/input <==
0

==> /proc/sys/net/mpls/conf/eth0.13/input <==
0

==> /proc/sys/net/mpls/conf/eth0.14/input <==
0

==> /proc/sys/net/mpls/conf/eth0.15/input <==
0

==> /proc/sys/net/mpls/conf/eth0/input <==
0

To create a sub interface and manually attempt to enable MPLS:

set interfaces ethernet eth0 vif 11 address '100.127.0.6/30'
set system sysctl custom net.mpls.conf.eth0/11.input value '1'

Try the new rolling by the way. There was a problem initially that we had to fix. Do like the rolling from 11/25 or tomorrow of 11/26.

I just did some testing, and @bbs2web, you're right. Sub interfaces to not get enabled. However main interfaces *DO* get enabled.

Starting out from here:

vyos@vyos:~$ sysctl net.mpls
net.mpls.conf.eth0.input = 0
net.mpls.conf.lo.input = 0
net.mpls.default_ttl = 255
net.mpls.ip_ttl_propagate = 1
net.mpls.platform_labels = 0

Enabling:

vyos@vyos# compare
[edit protocols]
+mpls {
+    interface lo
+    interface eth0
+}
vyos@vyos:~$ sysctl net.mpls
net.mpls.conf.eth0.input = 1
net.mpls.conf.lo.input = 1
net.mpls.default_ttl = 255
net.mpls.ip_ttl_propagate = 1
net.mpls.platform_labels = 1048575

Removing one:

vyos@vyos# delete protocols mpls interface eth0
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# exit
Warning: configuration changes have not been saved.
exit
vyos@vyos:~$ sysctl net.mpls
net.mpls.conf.eth0.input = 0
net.mpls.conf.lo.input = 1
net.mpls.default_ttl = 255
net.mpls.ip_ttl_propagate = 1
net.mpls.platform_labels = 1048575

Adding VLAN sub interfaces:

vyos@vyos# compare
[edit interfaces ethernet eth0]
+vif 10 {
+}
+vif 11 {
+}
+vif 12 {
+}
+vif 13 {
+}
+vif 14 {
+}
+vif 15 {
+}
vyos@vyos:~$ sysctl net.mpls
net.mpls.conf.eth0.input = 0
net.mpls.conf.eth0/10.input = 0
net.mpls.conf.eth0/11.input = 0
net.mpls.conf.eth0/12.input = 0
net.mpls.conf.eth0/13.input = 0
net.mpls.conf.eth0/14.input = 0
net.mpls.conf.eth0/15.input = 0
net.mpls.conf.lo.input = 1
net.mpls.default_ttl = 255
net.mpls.ip_ttl_propagate = 1
net.mpls.platform_labels = 1048575

Adding sub interfaces to MPLS:

vyos@vyos# compare
[edit protocols mpls]
+interface eth0.10
+interface eth0.11
vyos@vyos:~$ sysctl net.mpls
net.mpls.conf.eth0.input = 0
net.mpls.conf.eth0/10.input = 0
net.mpls.conf.eth0/11.input = 0
net.mpls.conf.eth0/12.input = 0
net.mpls.conf.eth0/13.input = 0
net.mpls.conf.eth0/14.input = 0
net.mpls.conf.eth0/15.input = 0
net.mpls.conf.lo.input = 0
net.mpls.default_ttl = 255
net.mpls.ip_ttl_propagate = 1
net.mpls.platform_labels = 1048575

Removing all interfaces:

[edit protocols]
-mpls {
-    interface lo
-    interface eth0.10
-    interface eth0.11
-}
vyos@vyos:~$ sysctl net.mpls
net.mpls.conf.eth0.input = 0
net.mpls.conf.eth0/10.input = 0
net.mpls.conf.eth0/11.input = 0
net.mpls.conf.eth0/12.input = 0
net.mpls.conf.eth0/13.input = 0
net.mpls.conf.eth0/14.input = 0
net.mpls.conf.eth0/15.input = 0
net.mpls.conf.lo.input = 0
net.mpls.default_ttl = 255
net.mpls.ip_ttl_propagate = 1
net.mpls.platform_labels = 0

Just adding main interfaces:

[edit protocols]
+mpls {
+    interface eth0
+    interface lo0
+}
vyos@vyos:~$ sysctl net.mpls
net.mpls.conf.eth0.input = 1
net.mpls.conf.eth0/10.input = 0
net.mpls.conf.eth0/11.input = 0
net.mpls.conf.eth0/12.input = 0
net.mpls.conf.eth0/13.input = 0
net.mpls.conf.eth0/14.input = 0
net.mpls.conf.eth0/15.input = 0
net.mpls.conf.lo.input = 0
net.mpls.default_ttl = 255
net.mpls.ip_ttl_propagate = 1
net.mpls.platform_labels = 1048575

So it seems that the problem is VLAN sub interfaces in ethernet interfaces do not enable right now. I haven't had a chance to look at how to fix this, but give me a week and I'll give it a try.

Are you able to make them work manually?

@bbs2web, I figured it out. I know what's not working.

GIve me a week or so. I should be able to fix it.

Put in a PR to enable ethernet sub interface MPLS enablement

https://github.com/vyos/vyos-1x/pull/619

@bbs2web, if they give the approval for this then please let me know how things go :)

Put in a new PR to enable ethernet sub interface MPLS enablement. I screwed up the first one...but here's hoping this one is good.

https://github.com/vyos/vyos-1x/pull/624

Put in a new PR to enable LDP local label allocation control.

https://github.com/vyos/vyos-1x/pull/635

Put in another PR to update the documentation.

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

Hi,

Installed 1.3-rolling-202012060217 yesterday and the VLAN interfaces don't appear to get MPLS enabled. I essentially removed the following lines, which work as expected when present:

set system sysctl custom net.mpls.conf.eth0/11.input value '1'
set system sysctl custom net.mpls.conf.eth0/13.input value '1'
set system sysctl custom net.mpls.conf.eth0/14.input value '1'

Current MPLS related configuration commands:

admin@vyos-1.3-rolling-202012060217:~$ show configuration commands | grep mpls
set protocols mpls interface 'eth0.11'
set protocols mpls interface 'eth0.13'
set protocols mpls interface 'eth0.14'
set protocols mpls ldp discovery hello-ipv4-holdtime '10'
set protocols mpls ldp discovery hello-ipv4-interval '1'
set protocols mpls ldp discovery transport-ipv4-address '203.0.113.25'
set protocols mpls ldp interface 'eth0.11'
set protocols mpls ldp interface 'eth0.13'
set protocols mpls ldp interface 'eth0.14'
set protocols mpls ldp router-id '203.0.113.25'
set protocols mpls parameters no-propagate-ttl

MPLS doesn't appear to get enabled:

admin@vyos-1.3-rolling-202012060217:~$ sysctl net.mpls
net.mpls.conf.br0.input = 0
net.mpls.conf.eth0.input = 0
net.mpls.conf.eth0/11.input = 0
net.mpls.conf.eth0/13.input = 0
net.mpls.conf.eth0/14.input = 0
net.mpls.conf.eth0/15.input = 0
net.mpls.conf.lo.input = 0
net.mpls.default_ttl = 255
net.mpls.ip_ttl_propagate = 0
net.mpls.platform_labels = 1048575

@bbs2web, here's what I got...

vyos@vyos:~$ show ver

Version:          VyOS 1.3-rolling-202012070521
Release Train:    equuleus

Built by:         autobuild@vyos.net
Built on:         Mon 07 Dec 2020 05:21 UTC
Build UUID:       07e618db-a88e-41b7-b7b5-57bf78ecf62e
Build Commit ID:  04b14e52b77bb7

Architecture:     x86_64
Boot via:         installed image
System type:      KVM guest

Hardware vendor:  QEMU
Hardware model:   Standard PC (i440FX + PIIX, 1996)
Hardware S/N:     Unknown
Hardware UUID:    Unknown

This is the current state:

vyos@vyos:~$ sysctl net.mpls
net.mpls.conf.eth0.input = 0
net.mpls.conf.lo.input = 0
net.mpls.default_ttl = 255
net.mpls.ip_ttl_propagate = 1
net.mpls.platform_labels = 0

Added sub interfaces:

[edit]
vyos@vyos# set interfaces ethernet eth0 vif 10
[edit]
vyos@vyos# set interfaces ethernet eth0 vif 11
[edit]
vyos@vyos# set interfaces ethernet eth0 vif 12
[edit]
vyos@vyos# set interfaces ethernet eth0 vif 13
[edit]
vyos@vyos# set interfaces ethernet eth0 vif 14
[edit]
vyos@vyos# set interfaces ethernet eth0 vif 15
[edit]
vyos@vyos#
[edit]
vyos@vyos#
[edit]
vyos@vyos# compare
[edit interfaces ethernet eth0]
+vif 10 {
+}
+vif 11 {
+}
+vif 12 {
+}
+vif 13 {
+}
+vif 14 {
+}
+vif 15 {
+}
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# exit

The interfaces got created:

vyos@vyos:~$ sysctl net.mpls
net.mpls.conf.eth0.input = 0
net.mpls.conf.eth0/10.input = 0
net.mpls.conf.eth0/11.input = 0
net.mpls.conf.eth0/12.input = 0
net.mpls.conf.eth0/13.input = 0
net.mpls.conf.eth0/14.input = 0
net.mpls.conf.eth0/15.input = 0
net.mpls.conf.lo.input = 0
net.mpls.default_ttl = 255
net.mpls.ip_ttl_propagate = 1
net.mpls.platform_labels = 0

Added interfaces into MPLS:

vyos@vyos# compare
[edit protocols]
+mpls {
+    interface lo
+    interface eth0
+    interface eth0.10
+    interface eth0.11
+    interface eth0.12
+    interface eth0.13
+    interface eth0.14
+    interface eth0.15
+}
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# exit

Currently seeing:

vyos@vyos:~$ sysctl net.mpls
net.mpls.conf.eth0.input = 1
net.mpls.conf.eth0/10.input = 1
net.mpls.conf.eth0/11.input = 1
net.mpls.conf.eth0/12.input = 1
net.mpls.conf.eth0/13.input = 1
net.mpls.conf.eth0/14.input = 1
net.mpls.conf.eth0/15.input = 1
net.mpls.conf.lo.input = 1
net.mpls.default_ttl = 255
net.mpls.ip_ttl_propagate = 1
net.mpls.platform_labels = 1048575

Deleted two interfaces:

vyos@vyos# compare
[edit protocols mpls]
-interface eth0.12
-interface eth0.15
>interface eth0.13
>interface eth0.14
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# exit

Shows delete of functionality:

vyos@vyos:~$ sysctl net.mpls
net.mpls.conf.eth0.input = 1
net.mpls.conf.eth0/10.input = 1
net.mpls.conf.eth0/11.input = 1
net.mpls.conf.eth0/12.input = 0
net.mpls.conf.eth0/13.input = 1
net.mpls.conf.eth0/14.input = 1
net.mpls.conf.eth0/15.input = 0
net.mpls.conf.lo.input = 1
net.mpls.default_ttl = 255
net.mpls.ip_ttl_propagate = 1
net.mpls.platform_labels = 1048575

Complete deletion:

vyos@vyos:~$ configure
d[edit]
vyos@vyos# delete protocols mpls
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# exit

Removes state for MPLS processing on everything:

vyos@vyos:~$ sysctl net.mpls
net.mpls.conf.eth0.input = 0
net.mpls.conf.eth0/10.input = 0
net.mpls.conf.eth0/11.input = 0
net.mpls.conf.eth0/12.input = 0
net.mpls.conf.eth0/13.input = 0
net.mpls.conf.eth0/14.input = 0
net.mpls.conf.eth0/15.input = 0
net.mpls.conf.lo.input = 0
net.mpls.default_ttl = 255
net.mpls.ip_ttl_propagate = 1
net.mpls.platform_labels = 0

See if you can get absolute latest and see if it works...

Put in a PR to add LDP import/export control.

https://github.com/vyos/vyos-1x/pull/639

Also put in a PR to add documentation for that.

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

Put in a PR to add documentation for LDP import/export control again. I didn't rebase properly last time. Sorry everyone :(

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

Put in a PR to fix spelling/help string error. My bad. I didn't catch it before.

https://github.com/vyos/vyos-1x/pull/642

Put in a PR to add LDP ordered control operation for LDP.

https://github.com/vyos/vyos-1x/pull/657

Put in a PR to add LDP ordered control documentation change.

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

Need 'nopmtudisc' option for tunnel interface. This is required for MPLS over gre or Ethernet over gre applications. This option is described in the iproute2 manuals (ip-tunnel).

https://phabricator.vyos.net/T3173

See if you can get absolute latest and see if it works...

net.mpls.conf.X.input variable is not set after reboot.

In T915#83668, @daniil wrote:

See if you can get absolute latest and see if it works...

net.mpls.conf.X.input variable is not set after reboot.

I'll see what I can do to get this worked on. Have to talk to some people.

I think we have a workable solution to this.

Will be testing/working on it and seeing if it takes properly. Will let you guys know about it when I get it pushed in.

@daniil, I am not seeing this to be a problem on VyOS 1.4-rolling-202101151916. What specific version are you seeing this on?

@daniil, I am not seeing this to be a problem on VyOS 1.4-rolling-202101151916. What specific version are you seeing this on?

VyOS 1.3-beta-202102051633

Hmmm...I am still not able to replicate...

vyos@vyos:~$ show version

Version:          VyOS 1.3-beta-202102051633
Release Train:    equuleus

First boot MPLS status here on my VM:

vyos@vyos:~$ sysctl net.mpls
net.mpls.conf.eth0.input = 0
net.mpls.conf.lo.input = 0
net.mpls.default_ttl = 255
net.mpls.ip_ttl_propagate = 1
net.mpls.platform_labels = 0

Added MPLS to eth0:

vyos@vyos# compare
[edit protocols]
+mpls {
+    interface eth0
+}

Response to those config changes:

vyos@vyos:~$ sysctl net.mpls
net.mpls.conf.eth0.input = 1
net.mpls.conf.lo.input = 0
net.mpls.default_ttl = 255
net.mpls.ip_ttl_propagate = 1
net.mpls.platform_labels = 1048575

After reboot:

login as: vyos
Pre-authentication banner message from server:
| Welcome to VyOS
End of banner message from server
vyos@10.0.0.80's password:
Linux vyos 5.4.94-amd64-vyos #1 SMP Tue Feb 2 21:10:15 UTC 2021 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Feb 12 00:48:35 2021 from 10.0.0.2
vyos@vyos:~$
vyos@vyos:~$
vyos@vyos:~$
vyos@vyos:~$ sysctl net.mpls
net.mpls.conf.eth0.input = 1
net.mpls.conf.lo.input = 0
net.mpls.default_ttl = 255
net.mpls.ip_ttl_propagate = 1
net.mpls.platform_labels = 1048575

I take it you've reinstalled your version right?

Also, can you try this troubleshooting path as well?

Version:

$show version 

Version:          VyOS 1.3-beta-202102051633
Release Train:    equuleus

Built by:         autobuild@vyos.net
Built on:         Fri 05 Feb 2021 16:33 UTC
Build UUID:       9129dbdb-3c22-4f9a-b63d-e4898500a114
Build Commit ID:  d5abc54c056254

Architecture:     x86_64
Boot via:         installed image
System type:      KVM guest

Hardware vendor:  QEMU
Hardware model:   Standard PC (i440FX + PIIX, 1996)
Hardware S/N:     
Hardware UUID:    d4b1c41c-cc99-4717-9e4c-cac59f218e65
Configuration:

# show protocols mpls 
 interface bond0.4083
 interface tun1
 interface tun2
 interface tun3
 interface tun4
 ldp {
     discovery {
         transport-ipv4-address 10.1.0.6
     }
     interface bond0.4083
     interface tun1
     interface tun2
     interface tun3
     interface tun4
     router-id 10.1.0.6
 }

Before reboot:

sysctl net.mpls
net.mpls.conf.bond0.input = 0
net.mpls.conf.bond0/4082.input = 0
net.mpls.conf.bond0/4083.input = 1
net.mpls.conf.bond0/4084.input = 0
net.mpls.conf.erspan0.input = 0
net.mpls.conf.eth0.input = 0
net.mpls.conf.eth1.input = 0
net.mpls.conf.gre0.input = 0
net.mpls.conf.gretap0.input = 0
net.mpls.conf.lo.input = 0
net.mpls.conf.management.input = 0
net.mpls.conf.tun1.input = 1
net.mpls.conf.tun2.input = 1
net.mpls.conf.tun3.input = 1
net.mpls.conf.tun4.input = 1
net.mpls.default_ttl = 255
net.mpls.ip_ttl_propagate = 1
net.mpls.platform_labels = 1048575

After reboot:

sysctl net.mpls
net.mpls.conf.bond0.input = 0
net.mpls.conf.bond0/4082.input = 0
net.mpls.conf.bond0/4083.input = 0
net.mpls.conf.bond0/4084.input = 0
net.mpls.conf.erspan0.input = 0
net.mpls.conf.eth0.input = 0
net.mpls.conf.eth1.input = 0
net.mpls.conf.gre0.input = 0
net.mpls.conf.gretap0.input = 0
net.mpls.conf.lo.input = 0
net.mpls.conf.management.input = 0
net.mpls.conf.tun1.input = 0
net.mpls.conf.tun2.input = 0
net.mpls.conf.tun3.input = 0
net.mpls.conf.tun4.input = 0
net.mpls.default_ttl = 255
net.mpls.ip_ttl_propagate = 1
net.mpls.platform_labels = 1048575

Hmm.

Just curious.

This install of VyOS that you have. Did you upgrade to it from older versions? Or did you just format and straight up install this one?

I have a feeling your install and my install has a difference in our kernel modules and the order that they are loaded upon boot up.

I have updated from an older version.

I *think* that there was a fix that happened on a task somewhere by someone in the underlying operating system that happened to fix this problem, but I for the life of me don't know what/where it would be. I'll have to ask around on it as I think there was changes on it 100% certain. The reason is is because I *saw* this problem too on a very old install too but it went away very quickly and I made no changes to fix it.

So I finally stopped being lazy and got VyOS in to GNS3. As with our production routers MPLS remains off after restarting with either 1.3-rolling-202104021041 or 1.4-rolling-202104022042 for VLAN sub interfaces. Ethernet parent interfaces have their mpls state managed correctly.

sysctl net.mpls
  net.mpls.conf.eth0.input = 0
  net.mpls.conf.eth1.input = 0
  net.mpls.conf.lo.input = 0
  net.mpls.default_ttl = 255
  net.mpls.ip_ttl_propagate = 1
  net.mpls.platform_labels = 0
configure
  set interfaces ethernet eth0 vif 10
  set interfaces ethernet eth0 vif 11
  set protocols mpls interface 'eth0'
  set protocols mpls interface 'eth0.10'
  compare
    [edit interfaces ethernet eth0]
    +vif 10 {
    +}
    +vif 11 {
    +}
    [edit]
    +protocols {
    +    mpls {
    +        interface eth0
    +        interface eth0.10
    +    }
    +}
    [edit]
  commit
  save
  exit
sysctl net.mpls
  net.mpls.conf.eth0.input = 1
  net.mpls.conf.eth0/10.input = 0
  net.mpls.conf.eth0/11.input = 0
  net.mpls.conf.eth1.input = 0
  net.mpls.conf.lo.input = 0
  net.mpls.default_ttl = 255
  net.mpls.ip_ttl_propagate = 1
  net.mpls.platform_labels = 1048575
reboot
sysctl net.mpls
  net.mpls.conf.eth0.input = 1
  net.mpls.conf.eth0/10.input = 0
  net.mpls.conf.eth0/11.input = 0
  net.mpls.conf.eth1.input = 0
  net.mpls.conf.lo.input = 0
  net.mpls.default_ttl = 255
  net.mpls.ip_ttl_propagate = 1
  net.mpls.platform_labels = 1048575

The following work around works, perhaps '.' and '/' aren't flipped in the script?

configure
  set system sysctl custom net.mpls.conf.eth0/10.input value 1
  compare
    [edit system]
    +sysctl {
    +    custom net.mpls.conf.eth0/10.input {
    +        value 1
    +    }
    +}
    [edit]
  commit
  save
  exit
sysctl net.mpls
  net.mpls.conf.eth0.input = 1
  net.mpls.conf.eth0/10.input = 1
  net.mpls.conf.eth0/11.input = 0
  net.mpls.conf.eth1.input = 0
  net.mpls.conf.lo.input = 0
  net.mpls.default_ttl = 255
  net.mpls.ip_ttl_propagate = 1
  net.mpls.platform_labels = 1048575

Result is identical on 1.4-rolling-202104022042

PS: Really nice work on the 1.3 -> 1.4 migration scripts, appears to work with our BGP, OSPF and MPLS implementation. I'm aware of OSPF interface settings needing to be moved manually and there is a bug with route-map names containing dashes when used as (set protocols ospf route-map ospf-in).

c-po added a project: VyOS 1.4 Sagitta.
c-po set Is it a breaking change? to Unspecified (possibly destroys the router).
c-po set Issue type to Unspecified (please specify).

Setting this to resolved as implementation is almost complete. Please file individual tasks for bugs so we can properly track them in the 1.3 release cycle.

dmbaturin changed Is it a breaking change? from Unspecified (possibly destroys the router) to Perfectly compatible.Sep 29 2021, 2:27 PM
dmbaturin changed Issue type from Unspecified (please specify) to Feature (new functionality).
One thing I did notice that did not work (and I think this would more or less be due to other options that can be enabled that FRR currently doesn't have yet) was that LSP pings from the Junipers directly connected to the Vyos VM failed but that's due to a specific corner case. FRR currently doesn't support explicit null in LDP, and Vyos doesn't have it implemented. However that shouldn't cause a problem in the current role that Vyos has. As an MPLS P Vyos works absolutely how it needs to. This seems to have a fix in FRR 7.4 as well per note "Ingress packets coming through broken LSP are no longer dropped." 

I would say that for what it's worth....I think we're good here. I think that the new additions are working as expected. So I am unsure if the ordered label allocation will be added later when things are moved to FRR 7.4, or if you'll put in that now @Viacheslav. But for what it is, MPLS support with LDP is verifiably working as it should be per the implementation in FRR 7.3.1. Thank you sir :)

So ok with Vyos? https://github.com/FRRouting/frr/issues/8313