Repository navigation
fix(cpworker): keep the packet direction in the gre key when service_tag is unset - #317
Merged
Merged
Conversation
…tag is unset The GRE key is service_tag | (direction << 28). Without a configured service_tag, cpworker used 0xFFFFFFFF, whose high nibble already fills the direction bits, so every packet carried key 0xFFFFFFFF whatever its direction. cpdaemon produces this config for every CPM GRE strategy without a service tag, so the request/response marking from req_pattern was lost. A configured tag above 28 bits overlapped the direction bits the same way. The default service_tag is now 0x0FFFFFFF, and the key takes only the low 28 bits of the tag: (service_tag & 0x0FFFFFFF) | (direction << 28). Without a service tag, the key is 0x0FFFFFFF / 0x1FFFFFFF / 0x2FFFFFFF instead of 0xFFFFFFFF; receivers reading the tag as key & 0x0FFFFFFF see the same 0xFFFFFFF as before. USAGE-CPWORKER documents the GRE header and key layout. Tests: config_validation expects the 0x0FFFFFFF default; TestWireFormat/gre checks the key without a service_tag in all three directions and with a tag above 28 bits. Both failed before the change.
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
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.
Problem
The GRE output writes the packet direction into the high 4 bits of the GRE key:
service_tag | (direction << 28). Without a configuredgre.service_tag, cpworker used0xFFFFFFFF, whose high nibble already fills the direction bits, so every packet was sent with key0xFFFFFFFFwhatever its direction.cpdaemon produces this config for every CPM GRE strategy where "enable service tag" is off (
Gre.ServiceTagis nil and omitted), so with areq_patternthe request/response marking was lost for all mirrored traffic. A configured tag above 28 bits overlapped the direction bits the same way; the CPM UI limits the tag to 0-4095, but cpdaemon and cpworker accept up to 32 bits.Change
gre.service_tagis0x0FFFFFFFinstead of0xFFFFFFFF.(service_tag & 0x0FFFFFFF) | (direction << 28). A tag above 28 bits is still accepted with a warning that names the value carried in the key.0x0FFFFFFF/0x1FFFFFFF/0x2FFFFFFF(none / request / response) instead of0xFFFFFFFF. Receivers that read the tag askey & 0x0FFFFFFFsee the same0xFFFFFFFas before.Tests
config_validation:test_gre_service_tag_defaultexpects0x0FFFFFFF. Failed before the change (Was 0xFFFFFFFF).TestWireFormat/gre: keys without aservice_tagin all three directions, and tag0xF0000123with areq_pattern. Failed before the change (keysffffffffandf0000123).make test12/12,run_test.sh allok.Fixes #296