SFC Port-pair Tap
There are some SFs that operate in a passive mode and only receive packets on the ingress port but do not send packets on an egress port. An example of this is an Intrusion Detection Service (IDS). In order to include such a SF in a port chain, the packets must be delivered to this SF and also forwarded on to the next downstream SF in the port chain.
This type of SF will be marked as "tap" and the data-plane switch behavior will be to send the packets to the ingress port of the SF and also forward these packets to the ingress port of the next hop SF. This port-pair will in effect operate as a tap by passing packets to the passive SF and also forwarding these packets to the next downstream SF.
Blueprint information
- Status:
- Complete
- Approver:
- Louis Fourie
- Priority:
- Undefined
- Drafter:
- Louis Fourie
- Direction:
- Needs approval
- Assignee:
- Louis Fourie
- Definition:
- Approved
- Series goal:
- Accepted for pike
- Implementation:
-
Implemented
- Milestone target:
-
queens-1
- Started by
- Louis Fourie
- Completed by
- Louis Fourie
Related branches
Related bugs
Sprints
Whiteboard
Question: is there a use case for "tap chains"? I.e. not only you send traffic to your tap function, but then your tap function also sends traffic to a next hop too, so a full chain starts after traffic gets tapped at the first chain (the first chain also continues).
There is a specific use case where the tap SF if a passive device such as an IDS
Gerrit topic: https:/
Addressed by: https:/
[WIP] API changes for Passive TAP SF
Addressed by: https:/
[WIP] Driver changes for TAP SF support in portchain
