docs: record where the cgnat icmp error and feature arc work landed - #31
Merged
Conversation
Fix order items 1, 4 and 5, and findings B5, B7 and C7. Two of them landed differently from how the audit framed them, and the record says so rather than implying the plan was followed: Item 4 asked for the ip.reass.ip_proto fail-closed check to be restored in out2in. It was not, and should not be. ip4-icmp-error builds a locally generated error by copying the offending packet's buffer including its opaque, so a self-generated Time Exceeded carries the probe's ip_proto as well as its icmp type: the cross-check would have dropped exactly the packet the item set out to rescue. out2in now reads nothing from the metadata at all, which leaves the check with nothing to validate. B5 is also the reason osvbng#510 exists. The old jump to ip4-lookup skipped the arc end, and therefore skipped ip4-not-enabled, so PPPoE sessions restored onto a promoted node were forwarding off an interface with no IPv4 enabled. Keeping translated packets on the arc turned a latent HA gap into a traffic failure, which is worth recording next to the finding rather than only in the PR.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix order items 1, 4 and 5, and findings B5, B7 and C7, against veesix-networks/osvbng-vpp#35, veesix-networks/osvbng#508 and veesix-networks/osvbng#509.
Two landed differently from how the audit framed them, and the record says so rather than implying the plan was followed.
Item 4 / C7 asked for the
ip.reass.ip_protofail-closed check to be restored in out2in. It was not, and should not be.ip4-icmp-errorbuilds a locally generated error by copying the offending packet's buffer including its opaque, so a self-generated Time Exceeded carries the probe'sip_protoas well as its ICMP type — the cross-check would have dropped exactly the packet the item set out to rescue. out2in now reads nothing from the reassembly metadata, which leaves the check with nothing to validate. The comment in the plugin records the reasoning at the point of use.B5 is also why veesix-networks/osvbng#510 exists. The old jump to
ip4-lookupskipped the arc end and therefore skippedip4-not-enabled, so PPPoE sessions restored onto a promoted node were forwarding off an interface with no IPv4 enabled. Keeping translated packets on the arc turned a latent HA gap into a traffic failure. That belongs next to the finding, not only in the PR that fixed it.Each entry carries the before/after the rig actually showed, so the next session can tell a fixed thing from an asserted one.
scripts/check-adr-index.shpasses.