Page MenuHomeVyOS Platform

MPLS Support
Needs testing, LowPublicFEATURE 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

Difficulty level
Unknown (require assessment)
Version
-
Why the issue appeared?
Will be filled on close

Related Objects

StatusSubtypeAssignedTask
Needs testingFEATURE REQUESTNone
ResolvedFEATURE REQUESTc-po
ResolvedFEATURE REQUESTNone

Event Timeline

rherold created this task.Oct 18 2018, 9:09 AM
syncer triaged this task as Low priority.Oct 18 2018, 9:16 AM

Second this. Came here looking for MPLS support as its supported in FRR.

I can see on boot that it displays the message ZEBRA: Disabling MPLS support (no kernel support)

pasik added a subscriber: pasik.Mar 12 2019, 6:09 PM

hi,

I want write an follow up.

We have here some tasks todo:

  1. Enable MPLS Support in Kernel
  2. Make protocol ldp configurable see: http://docs.frrouting.org/en/latest/ldpd.html
  3. Extend ospf an bgp protocol configurable
syncer added a subscriber: syncer.

Ok,
the first step is done

maznu added a subscriber: maznu.Sep 23 2019, 3:24 PM
c-po moved this task from Need Triage to Backlog on the VyOS 1.3 Equuleus board.Oct 13 2019, 3:07 PM

MPLS requires Linux Kernel 4.5 or higher (LDPcan be built, but may have limited use without MPLS).
Ref https://readthedocs.org/projects/frrouting-developers-guide/downloads/pdf/latest/

Viacheslav added a comment.EditedJan 9 2020, 10:11 AM

First tests for MPLS.
Latest rolling releases is supported it.

Load mpls modules and turn on it in sysctl.

sudo modprobe mpls_router
sudo modprobe mpls_gso
sudo modprobe mpls_iptunnel

sudo sysctl -w net.mpls.conf.eth0.input=1
sudo sysctl -w net.mpls.conf.eth1.input=1
sudo sysctl -w net.mpls.conf.lo.input=1
sudo sysctl -w net.mpls.platform_labels=1048575
sudo sysctl -w net.ipv4.conf.all.rp_filter=2

Enable ldpd daemon in frr.

vyos@mpls:~$ sudo cat /etc/frr/daemons | grep ldp
ldpd=yes
ldpd_options="  --daemon -A 127.0.0.1"

Restart frr

vyos@mpls:~$ restart frr

vtysh

router ospf
 ospf router-id 2.2.2.2
 network 0.0.0.0/0 area 0
!
mpls ldp
 router-id 2.2.2.2
 neighbor 3.3.3.3 password test
 !
 address-family ipv4
  discovery transport-address 2.2.2.2
  !
  interface eth1
  !
  interface lo
  !
 exit-address-family
 !
!

Show routing table with label.

vyos@mpls:~$ show ip route | match label
O>* 3.3.3.3/32 [110/1] via 192.168.122.172, eth0, label implicit-null, 00:09:28
O>* 192.168.3.0/25 [110/1001] via 192.168.122.172, eth0, label implicit-null, 00:09:28
vyos@mpls:~$

Vtysh show mpls table

mpls# show mpls table 
 Inbound Label  Type  Nexthop          Outbound Label  
 ------------------------------------------------------
 16             LDP   192.168.122.172  implicit-null   
 17             LDP   192.168.122.172  implicit-null   

mpls# 
mpls# show mpls ldp neighbor 
AF   ID              State       Remote Address    Uptime
ipv4 3.3.3.3         OPERATIONAL 3.3.3.3         00:11:54
mpls#

Tcpdump

vyos@mpls:~$ sudo tcpdump -ni eth1 port 646
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
10:12:41.911859 IP 192.168.1.3.646 > 224.0.0.2.646: LDP, Label-Space-ID: 3.3.3.3:0, pdu-length: 38
10:12:43.279738 IP 192.168.1.1.646 > 224.0.0.2.646: LDP, Label-Space-ID: 2.2.2.2:0, pdu-length: 38
10:12:46.914300 IP 192.168.1.3.646 > 224.0.0.2.646: LDP, Label-Space-ID: 3.3.3.3:0, pdu-length: 38
10:12:48.281244 IP 192.168.1.1.646 > 224.0.0.2.646: LDP, Label-Space-ID: 2.2.2.2:0, pdu-length: 38

Need tests from community.
Someone can help in writing the correct cli ?

Dmitry added a subscriber: Dmitry.Jan 10 2020, 8:43 AM

PR https://github.com/vyos/vyos-1x/pull/203
Adding commands for show mpls

vyos@mpls:~$ show mpls table 
 Inbound Label  Type  Nexthop      Outbound Label  
 --------------------------------------------------
 16             LDP   192.168.1.1  implicit-null   
 17             LDP   192.168.1.1  implicit-null 

vyos@mpls:~$ show mpls ldp neighbor 
AF   ID              State       Remote Address    Uptime
ipv4 2.2.2.2         OPERATIONAL 2.2.2.2         01:39:16

vyos@mpls:~$ show mpls ldp interface 
AF   Interface   State  Uptime   Hello Timers  ac
ipv4 eth0        ACTIVE 01:44:05 5/15           1
ipv4 lo          ACTIVE 01:44:05 5/15           1

This is working nicely, many thanks!

I stumbled whilst attempting to enable mpls on vlan interfaces though, due to sysctl replacing all periods with forward slashed.

We use the following VyOS configuration command to create VLAN sub interfaces:

set interfaces ethernet eth0 vif 35 address 192.0.2.6/30

Populating /etc/sysctl.conf with 'net.mpls.conf.eth0.35.input = 1' and then applying changes (sysctl -p) results in it attempting to set /proc/sys/net/mpls/conf/eth0/35/input, which doesn't exist. Couldn't find a way to escape the period so worked around the issue by adding the following lines to the VyOS post configuration bootup script.

/config/scripts/vyos-postconfig-bootup.script

#!/bin/sh
# Enable MPLS on all interfaces:
for dev in /proc/sys/net/mpls/conf/*/input; do echo 1 > $dev; done

Automatically load required kernel modules to support MPLS by creating /etc/modules-load.d/vyatta_mpls.conf:

mpls_gso
mpls_iptunnel
mpls_router

PS: Unrelated but VyOS disregards 'set interfaces ethernet eth0 vif 35 ip source-validation 'loose'' so we set 'all' and 'default' to function in RPF loose mode (2) with the following sysctl.conf

# Enable MPLS via '/config/scripts/vyos-postconfig-bootup.script'
net.mpls.platform_labels = 1048575

# Do not copy IP TTL to MPLS header
net.mpls.ip_ttl_propagate = 0

# VyOS disregards interface 'ip source-validation' configuration
net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 2

vtysh commands:

mpls ldp
 router-id 192.0.2.45
 !
 address-family ipv4
  discovery transport-address 192.0.2.45
  label local allocate host-routes
  !
  interface eth0.35
   discovery hello holdtime 10
   discovery hello interval 1
  !
  interface eth0.37
   discovery hello holdtime 10
   discovery hello interval 1
  !
  interface eth0.39
   discovery hello holdtime 10
   discovery hello interval 1
  !
 exit-address-family
 !
!

Regards
David Herselman

@bbs2web you can try use sysctl params from set

set interfaces ethernet eth1 vif 35 address '10.35.35.1/30'
set system sysctl custom net.mpls.conf.eth1/35.input value '1'
# sudo sysctl -a --pattern mpls
net.mpls.conf.eth0.input = 1
net.mpls.conf.eth1.input = 1
net.mpls.conf.eth1/35.input = 1
net.mpls.conf.lo.input = 1
net.mpls.default_ttl = 255
net.mpls.ip_ttl_propagate = 1
net.mpls.platform_labels = 1048575

In the future, I think these commands will be executed automatically based on the CLI logic.

Many thanks again, I much prefer having interface specific settings in a single place instead of arbitrary script locations.

As a point of reference, herewith equivalent MPLS configuration commands for DANOS vRouter (old Brocade vRouter, based on Vyatta Subscription Edition (VSE)) which also now uses FRRouting:

set protocols mpls-ldp address-family ipv4 discovery interfaces interface dp0s18.35 hello-holdtime 10
set protocols mpls-ldp address-family ipv4 discovery interfaces interface dp0s18.35 hello-interval 1
set protocols mpls-ldp address-family ipv4 discovery interfaces interface dp0s18.37 hello-holdtime 10
set protocols mpls-ldp address-family ipv4 discovery interfaces interface dp0s18.37 hello-interval 1
set protocols mpls-ldp address-family ipv4 discovery interfaces interface dp0s18.39 hello-holdtime 10
set protocols mpls-ldp address-family ipv4 discovery interfaces interface dp0s18.39 hello-interval 1
set protocols mpls-ldp address-family ipv4 label-policy allocate host-routes
set protocols mpls-ldp address-family ipv4 transport-address 192.0.2.45
set protocols mpls-ldp lsr-id 192.0.2.45

I’ll mark it here for the future. "ldpd 100% CPU utilization"
ref_cpu_utilization

Some tests results

vyos@R8:~$ show configuration commands | match mpls
set protocols mpls ldp discovery transport-ipv4-address '2.2.2.2'
set protocols mpls ldp interface 'eth1'
set protocols mpls ldp interface 'eth2'
set protocols mpls ldp router-id '2.2.2.2'
vyos@R8:~$ show mpls ldp neighbor 
AF   ID              State       Remote Address    Uptime
ipv4 10.0.0.1        OPERATIONAL 10.0.0.1        00:00:22
ipv4 3.3.3.3         OPERATIONAL 10.0.255.2      00:00:33
vyos@R8:~$ show mpls ldp interface 
AF   Interface   State  Uptime   Hello Timers  ac
ipv4 eth1        ACTIVE 00:00:51 5/15           1
ipv4 eth2        ACTIVE 00:00:52 5/15           1

vyos@R8:~$ show mpls table 
 Inbound Label  Type  Nexthop     Outbound Label  
 -------------------------------------------------
 16             LDP   10.0.255.2  implicit-null   
 17             LDP   10.0.0.1    implicit-null   

vyos@R8:~$ sudo tcpdump -n -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
22:53:30.943787 MPLS (label 16, exp 0, [S], ttl 64) IP 1.1.1.1 > 3.3.3.3: ICMP echo request, id 12228, seq 13, length 64
22:53:30.950979 IP 10.0.0.2.646 > 224.0.0.2.646: LDP, Label-Space-ID: 2.2.2.2:0, pdu-length: 38
22:53:30.951170 IP 3.3.3.3 > 1.1.1.1: ICMP echo reply, id 12228, seq 13, length 64
22:53:31.944912 MPLS (label 16, exp 0, [S], ttl 64) IP 1.1.1.1 > 3.3.3.3: ICMP echo request, id 12228, seq 14, length 64
22:53:31.956304 IP 3.3.3.3 > 1.1.1.1: ICMP echo reply, id 12228, seq 14, length 64
22:53:32.636023 IP 10.0.0.2 > 224.0.0.5: OSPFv2, Hello, length 48
22:53:32.640385 IP 10.0.0.1.646 > 224.0.0.2.646: LDP, Label-Space-ID: 10.0.0.1:0, pdu-length: 38
22:53:32.947048 MPLS (label 16, exp 0, [S], ttl 64) IP 1.1.1.1 > 3.3.3.3: ICMP echo request, id 12228, seq 15, length 64
22:53:32.954004 IP 3.3.3.3 > 1.1.1.1: ICMP echo reply, id 12228, seq 15, length 64
Dmitry changed the task status from Open to Needs testing.Mar 19 2020, 12:57 PM

Dmitry,

hi,
Please show router configurations, VyOS_R7, VyOS_R8, VyPS_R9.
I tried mpls configuration as your sample, but I could not establish ldp neighbor.

My testing version is "VyOS 1.3-rolling-202004040117".

Dmitry added a comment.Apr 5 2020, 7:31 AM

Hi @Shakapon

vyos@R7# run show configuration commands | match "mpls|address|ospf"
set interfaces dummy dum0 address '1.1.1.1/32'
set interfaces ethernet eth1 address '10.0.0.1/24'
set protocols mpls ldp discovery transport-ipv4-address '1.1.1.1'
set protocols mpls ldp interface 'eth1'
set protocols mpls ldp router-id '1.1.1.1'
set protocols ospf area 0 network '0.0.0.0/0'
set protocols ospf parameters abr-type 'cisco'
set protocols ospf parameters router-id '1.1.1.1'
set interfaces dummy dum0 address '2.2.2.2/32'
set interfaces ethernet eth1 address '10.0.0.2/24'
set interfaces ethernet eth2 address '10.0.255.1/24'
set protocols mpls ldp discovery transport-ipv4-address '2.2.2.2'
set protocols mpls ldp interface 'eth1'
set protocols mpls ldp interface 'eth2'
set protocols mpls ldp router-id '2.2.2.2'
set protocols ospf area 0 network '0.0.0.0/0'
set protocols ospf parameters abr-type 'cisco'
set protocols ospf parameters router-id '2.2.2.2'
set interfaces dummy dum0 address '3.3.3.3/32'
set interfaces ethernet eth1 address '10.0.255.2/24'
set protocols mpls ldp discovery transport-ipv4-address '3.3.3.3'
set protocols mpls ldp interface 'eth1'
set protocols mpls ldp router-id '3.3.3.3'
set protocols ospf area 0 network '0.0.0.0/0'
set protocols ospf parameters abr-type 'cisco'
set protocols ospf parameters router-id '3.3.3.3'

Hi, Dmitry

Thanks a lot!
I also connected ldp neighbor.

I need to delete this configuration.

set interfaces dummy dum0 address '1.1.1.1/32'
delete interfaces loopback lo address 1.1.1.1/32 
delete protocols ospf redistribute connected route-map CONNECT
delete policy route-map CONNECT rule 10 action permit
delete policy route-map CONNECT rule 10 match interface lo

This configuration is referenced by VyOS Wiki.

c-po moved this task from Backlog to In Progress on the VyOS 1.3 Equuleus board.May 4 2020, 2:55 PM

Hi, everyone.
As I understood from my lab VyOS generate label in cisco fashion (for all presented prefixes in routing table). And it is good as for me. But I think it is necessary to be able to filter the FEC for which labels will be generated (for example only for /32 routes, or only for particular routes).

craterman added a comment.EditedMay 18 2020, 4:10 PM

I found abnormal behavior during label allocation. As I wrote above VyOS generate label for all prefixes presented in routing table. But when we have for example 5 connected routes (four /24 and one /32) on Egress LSR and we start mpls VyOS allocates labels for all routes and neighbor (downstream LSR) receives label=3 (implicit null). But if we have 2 connected routes (one /24 and one /32) then we start mpls, Egress LSR allocates labels for all routes (two in this case), but if we add on Egress LSR one, two or more new connected routes VyOS does not allocate label=3 for this routes and does not send Label Mapping Message to its neighbors for FECs related to new added routes. The software version is 1.3-rolling-202005160117

And it does not matter which label allocation method uses. According rfc5036


s.lorente changed the status of subtask T2227: MPLS documentation from Open to On hold.Aug 10 2020, 5:06 PM

I also want to add more verification. I was able to bring up LDP *properly* to a Juniper as well. The one thing I was not able to 100% verify was that the labels themselves were proper from end to end *BUT* the Junipers did properly see the labels and did allocate from Vyos. Vyos itself also did the same. Due to a lack of ability to specify an explicit null I cannot absolutely verify yet, but I hope to be able to in the future. SO far though it seems that you guys have done a good job making sure that the P functionality works, and label allocation works. Well done. I was *ALSO* able to make the MPLS label pop up properly. Please check the very bottom for the verification of it working :)

On this version of code:

vyos@vyos:~$ show version

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

Built by:         autobuild@vyos.net
Built on:         Tue 18 Aug 2020 01:18 UTC
Build UUID:       598a5615-f6d4-41e1-9eac-f8283a578540
Build Commit ID:  17e52722af795d

With this configuration:

set interfaces ethernet eth0 address '10.0.0.75/27'
set interfaces ethernet eth0 mtu '1542'
set interfaces ethernet eth0 offload-options generic-receive 'on'
set interfaces ethernet eth0 offload-options generic-segmentation 'on'
set interfaces ethernet eth0 offload-options scatter-gather 'on'
set interfaces ethernet eth0 offload-options tcp-segmentation 'on'
set interfaces ethernet eth0 offload-options udp-fragmentation 'on'
set interfaces loopback lo address '10.10.10.1/32'
set interfaces loopback lo address '10.10.10.2/32'
set interfaces loopback lo address '10.10.10.3/32'
set interfaces loopback lo address '10.10.10.4/32'
set interfaces loopback lo address '10.10.10.5/32'
set interfaces loopback lo address '10.10.10.6/32'
set interfaces loopback lo address '10.10.10.7/32'
set interfaces loopback lo address '10.10.10.8/32'
set interfaces loopback lo address '10.10.10.9/32'
set protocols mpls ldp discovery transport-ipv4-address '10.10.10.1'
set protocols mpls ldp interface 'eth0'
set protocols mpls ldp interface 'lo'
set protocols mpls ldp router-id '10.10.10.1'
set protocols ospf area 0 network '10.0.0.64/27'
set protocols ospf area 0 network '10.10.10.1/32'
set protocols ospf area 0 network '10.10.10.2/32'
set protocols ospf area 0 network '10.10.10.3/32'
set protocols ospf area 0 network '10.10.10.4/32'
set protocols ospf area 0 network '10.10.10.5/32'
set protocols ospf area 0 network '10.10.10.6/32'
set protocols ospf area 0 network '10.10.10.7/32'
set protocols ospf area 0 network '10.10.10.8/32'
set protocols ospf area 0 network '10.10.10.9/32'
set protocols ospf mpls-te enable
set protocols static route 0.0.0.0/0 next-hop 10.0.0.65
set service ssh
set system config-management commit-revisions '100'
set system console device ttyS0 speed '115200'
set system host-name 'vyos'
set system ip multipath ignore-unreachable-nexthops
set system ip multipath layer4-hashing
set system ipv6 multipath layer4-hashing
set system login user vyos authentication encrypted-password '$6$f3pb5vfKVb$JZAsVCKDsHyX0tNquGIH5mf1G69e03YJOf7Y/biFdZWINv6CdDlxdvYYu9.q8W0RB36NYU94WmSi1deef2UpD1'
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'

I was able to get this on the Vyos side:

vyos@vyos:~$ show mpls ldp discovery
AF   ID              Type     Source           Holdtime
ipv4 10.10.10.1      Link     lo                     15
ipv4 10.255.255.254  Link     eth0                   15

vyos@vyos:~$ show mpls ldp binding
AF   Destination          Nexthop         Local Label Remote Label  In Use
ipv4 10.0.0.64/27         0.0.0.0         imp-null    -                 no
ipv4 10.0.0.248/30        0.0.0.0         16          -                 no
ipv4 10.10.10.1/32        10.255.255.254  imp-null    299792            no
ipv4 10.10.10.2/32        10.255.255.254  imp-null    299792            no
ipv4 10.10.10.3/32        10.255.255.254  imp-null    299792            no
ipv4 10.10.10.4/32        10.255.255.254  imp-null    299792            no
ipv4 10.10.10.5/32        10.255.255.254  imp-null    299792            no
ipv4 10.10.10.6/32        10.255.255.254  imp-null    299792            no
ipv4 10.10.10.7/32        10.255.255.254  imp-null    299792            no
ipv4 10.10.10.8/32        10.255.255.254  imp-null    299792            no
ipv4 10.10.10.9/32        10.255.255.254  imp-null    299792            no
ipv4 10.255.255.252/32    10.255.255.254  17          299776           yes
ipv4 10.255.255.254/32    10.255.255.254  18          imp-null         yes
ipv4 192.168.0.0/30       0.0.0.0         19          -                 no

vyos@vyos:~$ show mpls ldp neighbor
AF   ID              State       Remote Address    Uptime
ipv4 10.255.255.254  OPERATIONAL 10.255.255.254  00:04:41

On the Juniper side I was able to get this:

user@router> show ldp neighbor 10.0.0.75 extensive
Address                             Interface       Label space ID     Hold time
10.0.0.75                           ge-0/0/2.0      10.10.10.1:0         14
  Local Transport address: 10.255.255.254, Transport address: 10.10.10.1, Configuration sequence: 10
  Up for 00:05:26
  Reference count: 1
  Hold time: 15, Proposed local/peer: 15/15
  Neighbor types: discovered


user@router> show ldp database session 10.10.10.1
Input label database, 10.255.255.254:0--10.10.10.1:0
Labels received: 5
  Label     Prefix
      3      10.0.0.64/27
     16      10.0.0.248/30
      3      10.10.10.1/32
      3      10.10.10.2/32
      3      10.10.10.3/32
      3      10.10.10.4/32
      3      10.10.10.5/32
      3      10.10.10.6/32
      3      10.10.10.7/32
      3      10.10.10.8/32
      3      10.10.10.9/32
     17      10.255.255.252/32
     18      10.255.255.254/32
     19      192.168.0.0/30

Output label database, 10.255.255.254:0--10.10.10.1:0
Labels advertised: 3
  Label     Prefix
 299792      10.10.10.1/32
 299792      10.10.10.2/32
 299792      10.10.10.3/32
 299792      10.10.10.4/32
 299792      10.10.10.5/32
 299792      10.10.10.6/32
 299792      10.10.10.7/32
 299792      10.10.10.8/32
 299792      10.10.10.9/32
 299776      10.255.255.252/32
      3      10.255.255.254/32

user@router> show ldp session 10.10.10.1 extensive
Address: 10.10.10.1, State: Operational, Connection: Open, Hold time: 23
  Session ID: 10.255.255.254:0--10.10.10.1:0
  Next keepalive in 3 seconds
  Active, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1
  Neighbor types: discovered
  Keepalive interval: 10, Connect retry interval: 1
  Local address: 10.255.255.254, Remote address: 10.10.10.1
  Up for 00:07:17
  Capabilities advertised: p2mp, make-before-break, upstream-label-assignment
  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:
    10.0.0.75
    10.10.10.1
    10.10.10.2
    10.10.10.3
    10.10.10.4
    10.10.10.5
    10.10.10.6
    10.10.10.7
    10.10.10.8
    10.10.10.9
  Queue depth: 0
Message type               Total                     Last 5 seconds
                       Sent      Received          Sent      Received
Initialization            1             1             0             0
Keepalive                44            44             1             1
Notification              0             0             0             0
Address                   1             1             0             0
Address withdraw          0             0             0             0
Label mapping             3            16             0             0
Label request             0             0             0             0
Label withdraw            0             0             0             0
Label release             0             0             0             0
Label abort               0             0             0             0

Lastly, here is the ping verification of LABELED traffic *PROPERLY* working. What this is is a ping from source 10.10.10.1 (loopback on Vyos) to destination 10.255.255.252 (loopback on a Juniper that is 1 hop down, and not directly connected to the Vyos VM). This ping uses label 299776, which can be seen above in the Juniper label outbound and Vyos label binding as remote label. The ping results looks like this:

vyos@vyos:~$ monitor traffic interface eth0 filter "mpls"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
03:55:10.813124 MPLS (label 299776, exp 0, [S], ttl 255) IP 10.10.10.1 > 10.255.255.252: ICMP echo request, id 6833, seq 1, length 64
03:55:11.814181 MPLS (label 299776, exp 0, [S], ttl 255) IP 10.10.10.1 > 10.255.255.252: ICMP echo request, id 6833, seq 2, length 64
03:55:12.815279 MPLS (label 299776, exp 0, [S], ttl 255) IP 10.10.10.1 > 10.255.255.252: ICMP echo request, id 6833, seq 3, length 64
03:55:13.816368 MPLS (label 299776, exp 0, [S], ttl 255) IP 10.10.10.1 > 10.255.255.252: ICMP echo request, id 6833, seq 4, length 64

Well done everyone at the Vyos team. You guys have properly worked in MPLS functionality using LDP and it works and verifiable. I look forward to more integration with LDP if possible, but awesome freaking work.

@Cheeze_It Thank's. Can you describe what features you are missing?
And if possible, an example configuration.

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

Cheeze_It added a comment.EditedAug 19 2020, 3:28 PM

@Cheeze_It Thank's. Can you describe what features you are missing?
And if possible, an example configuration.

Yessir, so there's arguably 2 things missing which would be quite useful to have. However I am unsure both can be added as FRR 7.4 brings with it additional features in ldpd. FRR 7.4 specifically adds "LDP ordered label distribution." This is what @craterman is talking about.

However the ordered control would be (under FRR at least) under the main MPLS hierarchy:

mpls ldp
 **ordered-control**
 router-id 2.2.2.2
 neighbor 1.1.1.1 password test
 neighbor 3.3.3.3 password test
 !
 address-family ipv4
  discovery transport-address 2.2.2.2
  !
  interface eth1
  !
  interface eth3
  !
 exit-address-family
 !

The second thing if it could be possible to add would be the ability to add the "discovery hello holdtime <hold time integer>" and "discovery hello interval <interval integer>" on a per interface basis?

The manual for these can be found here (http://docs.frrouting.org/en/latest/ldpd.html). Sadly, the discovery hello hold time and interval per interface isn't shown as an example. It might be a global parameter, which honestly would be fine too. But most preferable would be per interface.

These *should* be easy to add but I won't assume as I am not a developer. But they are there and given as options.

@Viacheslav, if I am told where the config file is that ldpd and/or FRR uses then I can try to see if I can manually update the file and see if I can make the changes needed inside of FRR itself. Then when I can verify those changes I can show you the way the configuration file is supposed to look so I can give you the example :)

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

Cheeze_It added a comment.EditedAug 20 2020, 3:52 PM

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 added a comment.EditedAug 21 2020, 4:38 AM

@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

Cheeze_It added a comment.EditedMon, Oct 12, 3:46 PM

@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
Cheeze_It added a comment.EditedMon, Oct 12, 4:51 PM

@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
Cheeze_It added a comment.EditedMon, Oct 12, 5:05 PM

@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.

Cheeze_It added a comment.EditedMon, Oct 12, 7:38 PM

@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