are there any plans or does anyone has an idea how to prioritize the LCP-Control-Packet,
in particular the echo request and echo reply - Packet, if mpd5 listens on a VLAN ( CoS VLAN ( 1...7 ))?
It depends on what protocol do you use and what exactly do you mean by "prioritizing" - just marking or pushing LCP Control to the NIC before other traffic?
If your NIC is overloaded with outgoing traffic, pushing LCP will not buy you much and you better think about adding more bandwidth like lagg or moving from 1G to 10G (40G etc.)
If your NIC is not overloaded and you want just mark it with some CoS, it should be doable with exiting tools but it depends on your protocol - PPPoE? Something else?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the problem is behind mpd5 in the network infrastructure, e.g. a botteleck at a switch or the xdsl DSLAM. If it was possible to set CoS 7 = network contol traffic, it would be very unlikely , that a lcp echo request packets get lost even on heavy load
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The trick part is that after PPPoE session is established, mpd5 does not process its traffic as it goes completely in-kernel, including locally originated LCP frames (requests or responses). With luck, FreeBSD has means to selectively alter CoS for outgoing Ethernet Frames on-the-fly.
Each frame is carried with mbuf kernel structure that may have optional set of mbuf_tags attached. The driver vlan(8) supports the tag MTAG_8021Q defined in /usr/include/net/if_vlan_var.h (decimal value 1326104895) with m_tag_cookie MTAG_8021Q_PCP_OUT (value 1) to set 802.1p PCP three-bit desired value overriding default one, if sysctl net.link.vlan.mtag_pcp set to 1.
The default for vlan interface may be set with command like: ifconfig vlan2 vlanpcp 1
It will be used for all outgoing Ethernet frames without mbuf_tag MTAG_8021Q/MTAG_8021Q_PCP_OUT attached.
So all you need is: 1) filter PPPoE Session frames with PPP/LCP control packets and 2) attach MTAG_8021Q/MTAG_8021Q_PCP_OUT tags with needed PCP value, probably 7 (network control).
The node ng_ipfw should be configured to accept frames with its cookie 1 (used with above "netraph 1" command) and pass them to ng_bpf node for further filtering: if PPP Protocol field (16-bit value at 6 byte offset) contains the value 0xc021 (LCP protocol). If not, ng_bpf will pass the packet back unchanged and if yes, it should pass it to ng_tag node that is able to attach mbuf_tag MTAG_8021Q/MTAG_8021Q_PCP_OUT with needed PCP value.
I have not tried to perform that myself, so I cannot supply you with exact commands, so you'll need to read manual pages for ng_bpf and ng_tag and make experiments. Also, ipfw(8) manual page (section EXAMPLES) has an example of ng_ipfw usage, but for another task.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On the other hand, much more efficient, clean and simple solution is to teach ng_pppoe attaching needed mbuf_tag all by itself before passing the frame to underlying driver (vlan).
Here I attach preliminary patch for ng_pppoe that is compile-only tested and probably contains bugs. It is supposed to introduce new sysctl net.graph.pppoe.lcp_pcp with default value 0. If it stays zero, system behaviour is not changed. You are allowed to set it to another value in range of 1..7, so ng_pppoe assigns this value to 802.1p PCP for LCP frames.
You are welcome to test it and report back. After applying it to /usr/src, you need to rebuild ng_pppoe.ko if you use it as a module or rebuild the kernel if you compile it statically.
To rebuild the module:
cd /usr/src
patch < /path/to/patch
cd sys/modules/netgraph/pppoe
make obj depend && make all install
Note that sysctl net.link.vlan.mtag_pcp=1 is still needed for vlan(8) to insert PCP into a frame.
The compiler complains on my freebsd 12.2 about
static VNET_DEFINE(u_int32_t, ng_pppoe_lcp_pcp) = 0;
"static"
after removing "static" compiling succeeds,
the sysctl net.graph.pppoe.lcp_pcp appears and can be set.
( net.link.vlan.mtag_pcp = 1 set of course )
but after establishing a pppoe-session on a vlan-interface
the lcp-echo-packets still remain on pcp-value best-effort (0 )
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've found time to test it with my home PPPoE connection. I reconfigured my own port to tagged 802.1q trunk mode, applied second patch and it just works with net.graph.pppoe.lcp_pcp=7
The second patch is also more correct and it does not need a change of net.link.vlan.mtag_pcp to work (works with net.link.vlan.mtag_pcp=0, too).
Please make sure you tested it right: do not forget to reinstall and load modified code after building kernel or ng_ppppoe.ko module.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I worry whether different priority for LCP packets may put them into different queue, that may cause packet reorder, IIRC generally unacceptable for PPP.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the number of ( unwanted ) disconnects seems to decrease. :-) compared to a Mikrotik PPPoE.
Without the patch there's no difference. But I should watch the number of disconnects a few days more. Until now, I found only on Cisco-Routers the possibilty to adjust the VLAN-prio settings for LCP-Control-Packets.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
are there any plans or does anyone has an idea how to prioritize the LCP-Control-Packet,
in particular the echo request and echo reply - Packet, if mpd5 listens on a VLAN ( CoS VLAN ( 1...7 ))?
It depends on what protocol do you use and what exactly do you mean by "prioritizing" - just marking or pushing LCP Control to the NIC before other traffic?
If your NIC is overloaded with outgoing traffic, pushing LCP will not buy you much and you better think about adding more bandwidth like lagg or moving from 1G to 10G (40G etc.)
If your NIC is not overloaded and you want just mark it with some CoS, it should be doable with exiting tools but it depends on your protocol - PPPoE? Something else?
the problem is behind mpd5 in the network infrastructure, e.g. a botteleck at a switch or the xdsl DSLAM. If it was possible to set CoS 7 = network contol traffic, it would be very unlikely , that a lcp echo request packets get lost even on heavy load
PPPoE. I don't have any idea how to manage it with netgraph
The trick part is that after PPPoE session is established, mpd5 does not process its traffic as it goes completely in-kernel, including locally originated LCP frames (requests or responses). With luck, FreeBSD has means to selectively alter CoS for outgoing Ethernet Frames on-the-fly.
Each frame is carried with mbuf kernel structure that may have optional set of mbuf_tags attached. The driver vlan(8) supports the tag MTAG_8021Q defined in /usr/include/net/if_vlan_var.h (decimal value 1326104895) with m_tag_cookie MTAG_8021Q_PCP_OUT (value 1) to set 802.1p PCP three-bit desired value overriding default one, if sysctl net.link.vlan.mtag_pcp set to 1.
The default for vlan interface may be set with command like: ifconfig vlan2 vlanpcp 1
It will be used for all outgoing Ethernet frames without mbuf_tag MTAG_8021Q/MTAG_8021Q_PCP_OUT attached.
So all you need is: 1) filter PPPoE Session frames with PPP/LCP control packets and 2) attach MTAG_8021Q/MTAG_8021Q_PCP_OUT tags with needed PCP value, probably 7 (network control).
First part may be performed in part with ipfw(8):
(continued)
Last edit: Eugene Grosbein 2021-04-01
The node ng_ipfw should be configured to accept frames with its cookie 1 (used with above "netraph 1" command) and pass them to ng_bpf node for further filtering: if PPP Protocol field (16-bit value at 6 byte offset) contains the value 0xc021 (LCP protocol). If not, ng_bpf will pass the packet back unchanged and if yes, it should pass it to ng_tag node that is able to attach mbuf_tag MTAG_8021Q/MTAG_8021Q_PCP_OUT with needed PCP value.
I have not tried to perform that myself, so I cannot supply you with exact commands, so you'll need to read manual pages for ng_bpf and ng_tag and make experiments. Also, ipfw(8) manual page (section EXAMPLES) has an example of ng_ipfw usage, but for another task.
aah,
sysctl net.link.ether.ipfw=1
does the trick. I try it on my own, and if I get a result I will post it here.
And do not forget sysctl sysctl net.link.vlan.mtag_pcp=1
On the other hand, much more efficient, clean and simple solution is to teach ng_pppoe attaching needed mbuf_tag all by itself before passing the frame to underlying driver (vlan).
Here I attach preliminary patch for ng_pppoe that is compile-only tested and probably contains bugs. It is supposed to introduce new sysctl net.graph.pppoe.lcp_pcp with default value 0. If it stays zero, system behaviour is not changed. You are allowed to set it to another value in range of 1..7, so ng_pppoe assigns this value to 802.1p PCP for LCP frames.
You are welcome to test it and report back. After applying it to /usr/src, you need to rebuild ng_pppoe.ko if you use it as a module or rebuild the kernel if you compile it statically.
To rebuild the module:
cd /usr/src
patch < /path/to/patch
cd sys/modules/netgraph/pppoe
make obj depend && make all install
Note that sysctl net.link.vlan.mtag_pcp=1 is still needed for vlan(8) to insert PCP into a frame.
EDIT: attachment updated.
Last edit: Eugene Grosbein 2021-04-01
thank you very much , I try and test it :-)
hi,
until now no success.
The compiler complains on my freebsd 12.2 about
static VNET_DEFINE(u_int32_t, ng_pppoe_lcp_pcp) = 0;
"static"
after removing "static" compiling succeeds,
the sysctl net.graph.pppoe.lcp_pcp appears and can be set.
( net.link.vlan.mtag_pcp = 1 set of course )
but after establishing a pppoe-session on a vlan-interface
the lcp-echo-packets still remain on pcp-value best-effort (0 )
OK, I'll test it myself.
Try this patch instead. If it still does not work, please describe your hardware NIC and how do you check for on-the-wire PCP.
Last edit: Eugene Grosbein 2021-04-03
still no luck,
something like
"pass out from x.y.z.1 to any set prio 6"
within pf.conf for e.g. VoIP works for VLAN + PPPoE encapsulated packets
I do an tcpdump from the "bceX" - Interface...
I've found time to test it with my home PPPoE connection. I reconfigured my own port to tagged 802.1q trunk mode, applied second patch and it just works with net.graph.pppoe.lcp_pcp=7
The second patch is also more correct and it does not need a change of net.link.vlan.mtag_pcp to work (works with net.link.vlan.mtag_pcp=0, too).
Please make sure you tested it right: do not forget to reinstall and load modified code after building kernel or ng_ppppoe.ko module.
... I think, I have to create one more test-machine ...
hi works with a fresh freebsd13 on my ( old ) Dell - Server, but not tested in production yet, whereas the patch#1 still does a good job
tcpdump -i bce1 -nv -s0 -w /tmp/bce1.pcap
and --> wireshark
in the first patch I disabled the code lines concerning sysctl
and set pcp = 7
-->
(uint8_t )(mtag + 1) = 7;
that's working! Every lcp echo request comes now with nework - control - prority
Glad to know that. Unfortunately, I'm pretty short of time these days, so I will deal with it later then I wanted.
I put it online, with a backup PPPoE-Server, of course.
In a few days I can do some statistics about PPPoE - disconnects
I worry whether different priority for LCP packets may put them into different queue, that may cause packet reorder, IIRC generally unacceptable for PPP.
Nice catch. However, this is PPPoE-specific and should not break order between LCP packets themselves. I don't think it could do any harm.
the number of ( unwanted ) disconnects seems to decrease. :-) compared to a Mikrotik PPPoE.
Without the patch there's no difference. But I should watch the number of disconnects a few days more. Until now, I found only on Cisco-Routers the possibilty to adjust the VLAN-prio settings for LCP-Control-Packets.
Can you share a link to Cisco documentation for such a feature?