Add a node to the device-input feature arc to handle RX processing, including
throwing away non-CCM packets received on timed-out (sub)interfaces, and
looking for CCM packets.
If you clear the admin-up flag on a subinterface / link-up flag on a physical
interface, that should quench output without quenching driver-level input.
Although a code tour suggests that I’m right about the link-up flag, Damjan (or
others) feel free to jump in.
I don’t think you’ll need a scanner process. To begin with, I wouldn’t bother
trying to avoid doing vlan tag parsing twice. For max performance, poach the
relevant bits from ethernet-input and combine with CCM processing. Your feature
arc node subsumes ethernet input, and skips it, but only for CCM-enabled
interfaces.
Should work from a plugin.
FWIW... Dave
From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Sylvain CADILHAC
Sent: Tuesday, March 10, 2020 7:43 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] How to suspend forwarding on a sw interface? #vnet
Hi VPP Experts,
I'm looking for some advice in order to properly implement a CFM (802.1ag) CCM
plugin.
CCM (Continuity Check Messages) are basic Ethernet keepalive messages --
missing several messages in a row should cause the Ethernet interface or
sub-interface [the CFM frames might be VLAN tagged] to be suspended from a
forwarding perspective.
Injecting the keepalives using a process node, and catching the incoming
keepalives with a ethernet_register_input_type-hooked (based on EtherType) node
look easy, but how to properly suspend forwarding in both directions on the sw
(sub) interface when keepalives are missing (while still being able to receive
further keepalives of course)? If possible as a pure plugin but I doubt it's
possible.
Thoughts so far:
Inbound direction:
* Option 1. Hook a new node before ethernet-input to catch the CFM frames,
identify the sub-interface (if tagged frame), drop other frames... but that
means re-running all what's already done in ethernet-input (finding the
matching sub-interface, etc.).
* Option 2. Hook a new node at the beginning of each next arc (IP4, IP6,
MPLS, L2...) to drop all packets there. Enable (vnet_feature_enable_disable)
this node only when CCM reports the link failure.
* Option 3. Implement a new vnet_sw_interface_flags_t flag into vnet code
to indicate that the interface is suspended, and add checks to ethernet-input
with a bypass option for some specific EtherTypes (CFM first).
* Note: VNET_SW_INTERFACE_FLAG_PUNT's description sounds attractive...
but I cannot see where and how it's actually used.
* Option 4. ?
Outbound direction:
* Option 1. Implement a new vnet_sw_interface_flags_t flag into vnet code,
its corresponding callback, and check this flag along
VNET_SW_INTERFACE_FLAG_ADMIN_UP in many locations.
* Option 2. Implement VNET_SW_INTERFACE_FLAG_OPER_UP new flag, controlled
by FLAG_ADMIN_UP and by CFM, and use it rather than FLAG_ADMIN_UP in callbacks.
* Option 3. ?
Any advice will be welcome.
Thanks,
Sylvain
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#15717): https://lists.fd.io/g/vpp-dev/message/15717
Mute This Topic: https://lists.fd.io/mt/71854861/21656
Mute #vnet: https://lists.fd.io/mk?hashtag=vnet&subid=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
