Page MenuHomeVyOS Platform
Create Task
Maniphest T9527

pppoe-server subscriber cannot reach a kernel-side subscriber
Open, NormalPublicBUG
Actions

Description

When pppoe-server runs with one interface bound to VPP and another left on the kernel
(the same server, split across two interfaces), a subscriber dialed in on the VPP-bound interface
cannot reach a subscriber dialed in on the kernel-bound one.

# r2 (middle, server)
set vpp settings interface eth3
set service pppoe-server interface eth1
set service pppoe-server interface eth3
set service pppoe-server gateway-address '10.255.0.1'
set service pppoe-server client-ip-pool POOL1 range '10.255.0.10-10.255.0.20'
set service pppoe-server default-pool 'POOL1'
set service pppoe-server authentication mode 'local'
set service pppoe-server authentication local-users username rvtest password 'rvtest'
set service pppoe-server authentication local-users username rvtest2 password 'rvtest2'
commit
save
# r1 (kernel-mode client)
configure
set interfaces pppoe pppoe0 source-interface 'eth1'
set interfaces pppoe pppoe0 authentication username 'rvtest'
set interfaces pppoe pppoe0 authentication password 'rvtest'
commit
save
# r3 (VPP-side client)
configure
set interfaces pppoe pppoe0 source-interface 'eth1'
set interfaces pppoe pppoe0 authentication username 'rvtest2'
set interfaces pppoe pppoe0 authentication password 'rvtest2'
commit
save
vyos@vpp1-r3:~$ ping 10.255.0.10
PING 10.255.0.10 (10.255.0.10) 56(84) bytes of data.
^C
--- 10.255.0.10 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3068ms

Details

Version
1.5-rolling-202610191432
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Unspecified (please specify)

Event Timeline

a.pidnebesny created this task.Wed, Oct 28, 5:34 PM
pasik subscribed.Wed, Oct 28, 6:23 PM
Viacheslav subscribed.Thu, Oct 29, 12:34 PM

It is expected for VPP as it does not add a gateway IP address on its own PPP interfaces
But forwarding traffic should work fine

a.pidnebesny added a comment.Thu, Oct 29, 1:42 PM

Yes, thanks. Just to ensure we are on the same page, I'm talking about communication between two clients, one of which is connected to the VPP second to kernel-based

rherold subscribed.Thu, Oct 29, 3:28 PM

I could reproduce this on a 2026.10.16 rolling image (two VMs, VPP on eth0, kernel on eth2 of the server, same pppoe-server configuration as in the report, local users). Two sessions come up: rvtest2 on the VPP side (pppoe_session0, 10.255.0.10) and rvtest on the kernel side (ppp0, 10.255.0.11). From the VPP client a ping to the kernel client gets 100% loss, a ping to the gateway 10.255.0.1 as well. The kernel client reaches the gateway.

Where the packet goes (vppctl trace add dpdk-input, ping from 10.255.0.10 to 10.255.0.11): pppoe-input decapsulates it, ip4-lookup hits a receive entry and the packet goes ip4-receive -> ip4-icmp-input -> ip4-punt -> error-punt -> punt. VPP does not forward it, it treats it as a packet for itself. The FIB entry is created by linux-cp route sync:

10.255.0.11/32  lcp-rt  entry-flags:local ... path-list flags:local len:0
    [@0]: dpo-receive: 0.0.0.0 on local0

The kernel route 10.255.0.11 dev ppp0 proto kernel scope link src 10.255.0.1 belongs to an interface VPP does not know. show lcp has route-no-paths on (the VyOS default), and the entry has no paths and is a receive entry. The default route 0.0.0.0/0 in the VPP FIB looks the same (lcp-rt-dynamic, receive on local0). So VPP has no path towards a kernel-side subscriber.

The other direction has no route either: the kernel routes for 10.255.x.x on the server are only the one of ppp0, and ip route get 10.255.0.10 from 10.255.0.11 iif ppp0 goes via the management interface (default route). I did not run a full ping in this direction. My test used a VRF for the second client and the local table interfered, so I only measured the kernel route.

This matches Viacheslav's remark that VPP does not give its PPP interfaces a gateway address, but it is not only the gateway: in a mixed setup neither dataplane knows the subscribers of the other one. Whether client-to-client traffic across the two paths should work is a design question. Possible directions: document that VPP and kernel subscribers cannot reach each other, or route between them through the LCP pair, which would need routes in both directions. I have not tested a workaround.

I also tried the VyOS option set vpp settings ignore-kernel-routes (it sets route-no-paths off, also in startup.conf) on a clean start, both sessions redialed. The receive entries are gone and the default route in the VPP FIB is drop, but the result is the same: the packet from 10.255.0.10 to 10.255.0.11 now goes ip4-lookup -> ip4-drop -> error-drop, 100% loss, and the ping to the gateway 10.255.0.1 still fails. So the option changes punt into drop, it does not give VPP a path to the kernel subscriber.

Not checked: other VPP versions, VRFs, a workaround.

Viacheslav triaged this task as Normal priority.Thu, Oct 29, 5:30 PM