MPLS L3VPN transport issue?

I’m trying out a simple topology for testing MPLS L3VPN with VyOS, and I’m running 1.4-rolling-202204130521.

I have a simple topology with 2 MPLS PE, and two CE routers (each one connected to a PE), with a VRF called blue. Each CE announces over BGP the loopback address and a local subnet.

2022-04-13 12 43 12

I am encountering some issues on the transport plane, while the control plane seems good.

When pinging from the network 100.64.1.x to 100.64.2.x (from CE1 to CE2), I see the ICMP ECHO between PE1 and PE2 (MPLS encapsulated)… but nothing goes out from PE2 to CE2 (edge2).
From PE2 I am able to ping CE2 (so I can exclude any problem between that two).

CAPTURE ON PE2 eth1 (interface between PE1-PE2):

vagrant@pe2:~$ sudo tcpdump -n -i eth1
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:46:14.825542 MPLS (label 80, exp 0, [S], ttl 63) IP 100.64.1.21 > 100.64.2.22: ICMP echo request, id 57916, seq 1006, length 64
10:46:15.849529 MPLS (label 80, exp 0, [S], ttl 63) IP 100.64.1.21 > 100.64.2.22: ICMP echo request, id 57916, seq 1007, length 64
10:46:16.873433 MPLS (label 80, exp 0, [S], ttl 63) IP 100.64.1.21 > 100.64.2.22: ICMP echo request, id 57916, seq 1008, length 64

PE2 routing table for VRF blue:

vagrant@pe2:~$ show ip route vrf blue
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
       f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup
       t - trapped, o - offload failure

VRF blue:
B>  10.0.0.21/32 [20/0] via 10.0.0.11 (vrf default) (recursive), label 80, weight 1, 00:18:46
  *                       via 10.1.0.1, eth1 (vrf default), label implicit-null/80, weight 1, 00:18:46
B>* 10.0.0.22/32 [20/0] via 10.1.0.9, eth2, weight 1, 00:19:00
B>  10.1.0.4/30 [20/0] via 10.0.0.11 (vrf default) (recursive), label 80, weight 1, 00:18:46
  *                      via 10.1.0.1, eth1 (vrf default), label implicit-null/80, weight 1, 00:18:46
C>* 10.1.0.8/30 is directly connected, eth2, 00:19:21
B>  100.64.1.0/24 [20/0] via 10.0.0.11 (vrf default) (recursive), label 80, weight 1, 00:18:46
  *                        via 10.1.0.1, eth1 (vrf default), label implicit-null/80, weight 1, 00:18:46
B>* 100.64.2.0/24 [20/0] via 10.1.0.9, eth2, weight 1, 00:19:00

MPLS table on PE2:

vagrant@pe2:~$ show mpls table
 Inbound Label  Type  Nexthop   Outbound Label
 -----------------------------------------------
 16             LDP   10.1.0.1  implicit-null
 80             BGP   blue      -

So, as you can see, the next hop for the service label 80 is VRF blue.
The packets are arriving at PE2 with that correct label (see 80 in tcpdump capture above), but then they get lost somewhere.

Working ping from PE2 to CE2, just to make sure PE2 can reach CE2 on blue vrf:

vagrant@pe2:~$ ping 100.64.2.22 vrf blue count 2
PING 100.64.2.22 (100.64.2.22) 56(84) bytes of data.
64 bytes from 100.64.2.22: icmp_seq=1 ttl=64 time=0.756 ms
64 bytes from 100.64.2.22: icmp_seq=2 ttl=64 time=0.676 ms

--- 100.64.2.22 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1010ms
rtt min/avg/max/mdev = 0.676/0.716/0.756/0.040 ms

Not sure whether it’s a bug or a configuration issue (but the config looks fine to me)… Kindly asking for your help :wink:

relevant PE2 config (symmetrical on PE1):

interfaces {
    dummy dum0 {
        address 10.0.0.12/32
    }
    ethernet eth0 {
        address dhcp
        description Out-Of-Band
        hw-id 08:4f:a9:00:00:0c
        vrf management
    }
    ethernet eth1 {
        address 10.1.0.2/30
        description "pe2 -> pe1"
        hw-id 52:54:00:bf:4c:db
    }
    ethernet eth2 {
        address 10.1.0.10/30
        description "pe2 -> edge2 [external]"
        hw-id 52:54:00:a1:b7:c3
        vrf blue
    }
    loopback lo {
    }
}
protocols {
    bgp {
        address-family {
            ipv4-unicast {
                network 10.0.0.12/32 {
                }
            }
        }
        local-as 65000
        neighbor 10.0.0.11 {
            address-family {
                ipv4-unicast {
                    nexthop-self {
                    }
                }
                ipv4-vpn {
                    nexthop-self {
                    }
                }
            }
            description pe1
            remote-as 65000
            update-source dum0
        }
        parameters {
            router-id 10.0.0.12
        }
    }
    mpls {
        interface dum0
        interface eth1
        ldp {
            discovery {
                transport-ipv4-address 10.0.0.12
            }
            interface dum0
            interface eth1
            router-id 10.0.0.12
        }
    }
    ospf {
        interface dum0 {
            area 0.0.0.0
            passive {
            }
        }
        interface eth1 {
            area 0.0.0.0
            network point-to-point
        }
        parameters {
            router-id 10.0.0.12
        }
    }
}

vrf {
    name blue {
        protocols {
            bgp {
                address-family {
                    ipv4-unicast {
                        export {
                            vpn
                        }
                        import {
                            vpn
                        }
                        label {
                            vpn {
                                export auto
                            }
                        }
                        rd {
                            vpn {
                                export 65000:1
                            }
                        }
                        redistribute {
                            connected {
                            }
                        }
                        route-target {
                            vpn {
                                export 65000:1
                                import 65000:1
                            }
                        }
                    }
                }
                local-as 65000
                neighbor 10.1.0.9 {
                    address-family {
                        ipv4-unicast {
                            nexthop-self {
                            }
                        }
                    }
                    description edge2
                    remote-as 65102
                }
            }
        }
        table 100
    }
    name management {
        table 65530
    }
}

thanks!
Stefano

First note:
If I run

vagrant@pe2:~$ sudo ip -f mpls route show
16 via inet 10.1.0.1 dev eth1 proto ldp
vagrant@pe2:~$

I don’t see any action for the label 80. Should I be able to see it here, or somewhere else?

Hello, ssasso! In my configuration, I did this and everything works. I can send my configuration for comparison.

Hi @ssasso , try to add address-family ipv4-unicast as-override for the VRF blue bgp neighbor 10.1.0.9 and check if that helps.

Thanks @Anna , please send the config so I can compare them, and see if there is some mismatch or it’s a sw issue.

@e.khudiyev I’m using different AS numbers, so I don’t think that using as-override will change something. As you can see from the routing table, the signaling plane seems to work well (the routes are present, and, most important, the traffic is flowing from PE1 to PE2… but it gets nowhere when it arrives at PE2). Anyway, I’ll give it a try. Thanks!!

tried to set as-override, nothing changes.
Packet still arriving at PE2 over MPLS, but not getting routed anywhere from PE2.

vagrant@pe2:~$ sudo tcpdump -n -i eth1
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:00:43.881521 MPLS (label 80, exp 0, [S], ttl 63) IP 100.64.1.21 > 100.64.2.22: ICMP echo request, id 63060, seq 124, length 64
13:00:44.905503 MPLS (label 80, exp 0, [S], ttl 63) IP 100.64.1.21 > 100.64.2.22: ICMP echo request, id 63060, seq 125, length 64
13:00:45.929475 MPLS (label 80, exp 0, [S], ttl 63) IP 100.64.1.21 > 100.64.2.22: ICMP echo request, id 63060, seq 126, length 64
13:00:46.953576 MPLS (label 80, exp 0, [S], ttl 63) IP 100.64.1.21 > 100.64.2.22: ICMP echo request, id 63060, seq 127, length 64

Can you also provide a capture from the CE device?

monitor traffic interface any filter "icmp"

CE1 sending the ping:

vagrant@edge1:~$ monitor traffic interface any filter "icmp"
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
13:11:03.636451 eth1  Out IP 100.64.1.21 > 100.64.2.22: ICMP echo request, id 51913, seq 42, length 64
13:11:04.660455 eth1  Out IP 100.64.1.21 > 100.64.2.22: ICMP echo request, id 51913, seq 43, length 64
13:11:05.684438 eth1  Out IP 100.64.1.21 > 100.64.2.22: ICMP echo request, id 51913, seq 44, length 64
13:11:06.708445 eth1  Out IP 100.64.1.21 > 100.64.2.22: ICMP echo request, id 51913, seq 45, length 64
13:11:07.732470 eth1  Out IP 100.64.1.21 > 100.64.2.22: ICMP echo request, id 51913, seq 46, length 64
13:11:08.756456 eth1  Out IP 100.64.1.21 > 100.64.2.22: ICMP echo request, id 51913, seq 47, length 64
13:11:09.780447 eth1  Out IP 100.64.1.21 > 100.64.2.22: ICMP echo request, id 51913, seq 48, length 64
13:11:10.804452 eth1  Out IP 100.64.1.21 > 100.64.2.22: ICMP echo request, id 51913, seq 49, length 64

CE2 which should receive the ping displays nothing. Also PE2 displays nothing with that filter (only incoming MPLS traffic, reported above).

PE1 receives the traffic from CE1:

vagrant@pe1:~$ monitor traffic interface any filter "icmp"
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
13:13:32.196989 eth2  In  IP 100.64.1.21 > 100.64.2.22: ICMP echo request, id 24048, seq 1, length 64
13:13:33.235257 eth2  In  IP 100.64.1.21 > 100.64.2.22: ICMP echo request, id 24048, seq 2, length 64
13:13:34.259173 eth2  In  IP 100.64.1.21 > 100.64.2.22: ICMP echo request, id 24048, seq 3, length 64

PE2: (removing SSH traffic)

vagrant@pe2:~$ monitor traffic interface any filter "not port 22"
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
13:14:35.177637 eth1  In  MPLS (label 80, exp 0, [S], ttl 63) IP 100.64.1.21 > 100.64.2.22: ICMP echo request, id 24048, seq 62, length 64
13:14:35.236795 eth0  M   STP 802.1d, Config, Flags [none], bridge-id 8000.52:54:00:d8:3f:0d.8004, length 35
13:14:36.201678 eth1  In  MPLS (label 80, exp 0, [S], ttl 63) IP 100.64.1.21 > 100.64.2.22: ICMP echo request, id 24048, seq 63, length 64
13:14:37.220790 eth0  M   STP 802.1d, Config, Flags [none], bridge-id 8000.52:54:00:d8:3f:0d.8004, length 35
13:14:37.225664 eth1  In  MPLS (label 80, exp 0, [S], ttl 63) IP 100.64.1.21 > 100.64.2.22: ICMP echo request, id 24048, seq 64, length 64
13:14:38.249682 eth1  In  MPLS (label 80, exp 0, [S], ttl 63) IP 100.64.1.21 > 100.64.2.22: ICMP echo request, id 24048, seq 65, length 64
13:14:38.396463 eth1  M   IP 10.1.0.1.646 > 224.0.0.2.646: LDP, Label-Space-ID: 10.0.0.11:0, pdu-length: 38
13:14:38.396523 eth1  Out IP 10.1.0.2.646 > 224.0.0.2.646: LDP, Label-Space-ID: 10.0.0.12:0, pdu-length: 38
13:14:39.236779 eth0  M   STP 802.1d, Config, Flags [none], bridge-id 8000.52:54:00:d8:3f:0d.8004, length 35
13:14:39.273642 eth1  In  MPLS (label 80, exp 0, [S], ttl 63) IP 100.64.1.21 > 100.64.2.22: ICMP echo request, id 24048, seq 66, length 64
13:14:40.297628 eth1  In  MPLS (label 80, exp 0, [S], ttl 63) IP 100.64.1.21 > 100.64.2.22: ICMP echo request, id 24048, seq 67, length 64

thanks!

I can’t send the configuration, because the system writes me: Sorry, new users can only put 2 links in a post.

UPDATE:

After a reboot of both PEs, the topology works.
After the reboot, if I lookup at the kernel mpls table, I find:

vagrant@pe2:~$ sudo ip -f mpls r s
16 via inet 10.1.0.1 dev eth1 proto ldp
80 dev blue proto bgp

which label 80 was not present before.
So it seems like something is not really applied until a reboot.
Any idea?

(this is systematic. every time I start from zero, do the configuration, it does not work. After a reboot, it does.)

Good observation… could you try to repeat the same issue and compare VyOS and FRR configurations?
For VyOS: show configuration commands | no-more
For FRR: type vtysh in the command line, then type show run, and then exit to return into VyOS CLI mode.

Possibly, the configuration has not been fully applied before the reboot. Any logs pointing to the issue would be also very helpful.

@e.khudiyev thanks for the hints!
I’ll do my best to try to capture differences in config and behavior and let you know

Difference between before and after reboot:
The “router bgp xxx vrf xxx” before reboot is before the main “router bgp”, while after reboot it is after:

But I am not sure that’s a real issue.

So I did another test:
Instead of reboot, I simply killed bgpd:

vagrant@pe2:~$ sudo ip -f mpls r s
16 via inet 10.1.0.1 dev eth1 proto ldp
vagrant@pe2:~$ sudo pidof bgpd
851
vagrant@pe2:~$ sudo kill 851
vagrant@pe2:~$ sudo ip -f mpls r s
16 via inet 10.1.0.1 dev eth1 proto ldp
80 dev blue proto bgp
vagrant@pe2:~$ sudo pidof bgpd
5092

As you can see, after the daemon restart, the MPLS table entry is present.

thanks,
Stefano

UPDATE:

different behaviour following different actions order:
(NON WORKING)

  1. add protocols bgp / bgp with vrf stuff
  2. commit
  3. add protocols mpls/ldp
  4. commit

(WORKING)

  1. add protocols mpls/ldp
  2. commit
  3. add protocols bgp / bgp with vrf stuff
  4. commit

Hi @ssasso , could you please create a bug report on https://phabricator.vyos.net/ for this issue and post there all your observations? That would be very helpful in further investigation.

@e.khudiyev ⚓ T4360 Issues on MPLS L3VPN Service Label

thanks!
Stefano

1 Like