Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove redundant log in fillPodInfo/fillServiceInfo and update deny connection store. #5592

Merged
merged 6 commits into from
Nov 14, 2023

Conversation

yuntanghsu
Copy link
Contributor

@yuntanghsu yuntanghsu commented Oct 17, 2023

  1. Remove redundant logs in fillPodInfo/fillServiceInfo to avoid Flow
    Exporter from flooding logs.
  2. Add Mark field for deny connections. We were missing this field
    previously, resulting in trying to fill service information for
    non-service IPs.
  3. Update the DestinationServiceAddress for deny connections when we can
    find this information in PacketIn.
  4. Update e2e/unit tests to verify that the Service-relateds field are
    filled correctly.

Fixes #5573

@yuntanghsu yuntanghsu marked this pull request as draft October 18, 2023 01:11
@yuntanghsu yuntanghsu force-pushed the rm_log branch 2 times, most recently from d0eb624 to e5ed605 Compare October 24, 2023 20:22
@yuntanghsu yuntanghsu changed the title Remove redundant log in fillPodInfo/fillServiceInfo Remove redundant log in fillPodInfo/fillServiceInfo and update deny connection store. Oct 24, 2023
@yuntanghsu yuntanghsu marked this pull request as ready for review October 24, 2023 20:24
@yuntanghsu yuntanghsu requested a review from dreamtalen October 25, 2023 22:34
test/e2e/flowaggregator_test.go Outdated Show resolved Hide resolved
test/e2e/flowaggregator_test.go Outdated Show resolved Hide resolved
test/e2e/flowaggregator_test.go Outdated Show resolved Hide resolved
test/e2e/flowaggregator_test.go Outdated Show resolved Hide resolved
test/e2e/flowaggregator_test.go Outdated Show resolved Hide resolved
test/e2e/flowaggregator_test.go Outdated Show resolved Hide resolved
test/e2e/flowaggregator_test.go Outdated Show resolved Hide resolved
test/e2e/flowaggregator_test.go Outdated Show resolved Hide resolved
test/e2e/flowaggregator_test.go Outdated Show resolved Hide resolved
pkg/agent/controller/networkpolicy/packetin.go Outdated Show resolved Hide resolved
pkg/agent/controller/networkpolicy/packetin.go Outdated Show resolved Hide resolved
pkg/agent/controller/networkpolicy/packetin.go Outdated Show resolved Hide resolved
pkg/agent/flowexporter/connections/connections.go Outdated Show resolved Hide resolved
test/e2e/flowaggregator_test.go Outdated Show resolved Hide resolved
pkg/agent/controller/networkpolicy/packetin.go Outdated Show resolved Hide resolved
pkg/agent/controller/networkpolicy/packetin.go Outdated Show resolved Hide resolved
test/e2e/bandwidth_test.go Outdated Show resolved Hide resolved
func testHelper(t *testing.T, data *TestData, podAIPs, podBIPs, podCIPs, podDIPs, podEIPs *PodIPs, isIPv6 bool) {
svcB, svcC, err := createPerftestServices(data, isIPv6)
func testHelper(t *testing.T, data *TestData, isIPv6 bool) {
svcB, svcC, svcD, svcE, err := createPerftestServices(data, isIPv6)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we also move createPerftestServices to TestFlowAggregator, and maybe simplify the code by creating one Service for each Pod indiscriminately?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it should be kept in testHelper as the services need to be created based on the isIPv6 condition?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it doesn't have to be done in this PR necessarily, but it would be better to create the Services once, in TestFlowAggregator. The IPFamilies field in the ServiceSpec is a list, and based on what the cluster supports, it can be set to [IPv4], [IPv4, IPv6], or [IPv6]. Then the test can access the service using the correct IP. What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be a good idea as IPFamilies is a list. Since CreateServiceWithAnnotations is used by many functions, I think it might be better to open another PR to make this change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I opened another PR to change the type of IPFamily. #5690

test/e2e/flowaggregator_test.go Outdated Show resolved Hide resolved
Comment on lines 132 to 136
if dstSvcAddress != nil {
denyConn.DestinationServiceAddress = *dstSvcAddress
}
if dstSvcPort != 0 {
denyConn.DestinationServicePort = dstSvcPort
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't get this. How do we know this is ServiceAddress and ServicePort? Every tracked connection can have these two fields.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these represent the Original Direction IPv4 Destination Address and Original Direction Transport Layer Source Port. If they do not belong to a service (by checking the CTMark), we won't fill the service information.
I think we do the same strategy for the connection in the conntrack table?

DestinationServiceAddress: conn.TupleOrig.IP.DestinationAddress,

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then this is perhaps a naming thing, is there any reason why we don't call them OriginalDestinationAddress and OriginalDestinationPort? They mean the ServiceAddress and ServicePort when this is a Service connection.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know the reason why we name it DestinationServiceAddress/DestinationServicePort. I agree with you that it should be filled only when it is a service connection. I think we can either rename it or fill this field only when CTMark belongs to a service. Changes for the latter one will be easier as we don't need to rename these two fields for all the packages. What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yuntanghsu I don't think you addressed this? Did you discuss it with Quan offline or did you plan to have a follow up PR?

Copy link
Contributor Author

@yuntanghsu yuntanghsu Nov 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I don't. I was waiting for @tnqn 's opinion. If we need to rename it, I think it's better to open another PR to address this issue. Otherwise, we can fill these two fields only when the CTMark belongs to a service in this PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I thought you were going to update the PR to go with the second option (omit fields if we cannot identify the packet as belonging to Service traffic). That's assuming that we don't use these fields for anything else.

Copy link
Contributor Author

@yuntanghsu yuntanghsu Nov 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I found that we won't see the values for these two fields in the FlowAggregator or the ClickHouse if it is a non-service traffic. We reset these two fields before we export the records if DestinationServicePortName is an empty string (non-service connection or we can't find the service info).

case "destinationClusterIPv4":

case "destinationServicePort":

I think the current logic is:

  1. We temporarily fill OriginalDestinationAddress and OriginalDestinationPort to DestinationServiceAddress and DestinationServicePort
  2. We use these two values to check if we can find service info. If we find the info, we fill DestinationServicePortName
  3. If DestinationServicePortName is an empty string, we reset DestinationServiceAddress and DestinationServicePort because it is a non-service traffic or we can't find the service information.

Do you think we still need to omit it when we do Poll() or when we have packet from PacketIn?

Copy link
Contributor

@antoninbas antoninbas Nov 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I talked to Yun-Tang offline. We think it makes more sense to rename the fields to OriginalDestinationAddress and OriginalDestinationPort. He will do it in a follow-up PR.

pkg/agent/flowexporter/connections/connections.go Outdated Show resolved Hide resolved
@tnqn tnqn added action/backport Indicates a PR that requires backports. action/release-note Indicates a PR that should be included in release notes. labels Nov 1, 2023
Signed-off-by: Yun-Tang Hsu <hsuy@vmware.com>
Signed-off-by: Yun-Tang Hsu <hsuy@vmware.com>
Signed-off-by: Yun-Tang Hsu <hsuy@vmware.com>
Signed-off-by: Yun-Tang Hsu <hsuy@vmware.com>
Signed-off-by: Yun-Tang Hsu <hsuy@vmware.com>
@yuntanghsu yuntanghsu force-pushed the rm_log branch 2 times, most recently from 5baf97d to 1d0fd4e Compare November 1, 2023 23:17
@yuntanghsu yuntanghsu marked this pull request as draft November 2, 2023 01:34
@yuntanghsu yuntanghsu force-pushed the rm_log branch 5 times, most recently from 16b2b53 to 10c0cf5 Compare November 2, 2023 18:27
Signed-off-by: Yun-Tang Hsu <hsuy@vmware.com>
@yuntanghsu yuntanghsu marked this pull request as ready for review November 3, 2023 16:32
@yuntanghsu yuntanghsu requested review from antoninbas and tnqn November 8, 2023 18:44
Copy link
Member

@tnqn tnqn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@antoninbas
Copy link
Contributor

/test-all

@antoninbas antoninbas merged commit d6766cc into antrea-io:main Nov 14, 2023
42 of 44 checks passed
@yuntanghsu yuntanghsu deleted the rm_log branch November 14, 2023 18:28
yuntanghsu added a commit to yuntanghsu/antrea that referenced this pull request Jan 22, 2024
…onnection store. (antrea-io#5592)

1. Remove redundant logs in fillPodInfo/fillServiceInfo to avoid Flow
   Exporter from flooding logs.
2. Add Mark field for deny connections. We were missing this field
   previously, resulting in trying to fill service information for
   non-service IPs.
3. Update the DestinationServiceAddress for deny connections when we can
   find this information in PacketIn.
4. Update e2e/unit tests to verify that the Service-relateds field are
   filled correctly.

Fixes antrea-io#5573

Signed-off-by: Yun-Tang Hsu <hsuy@vmware.com>
antoninbas pushed a commit that referenced this pull request Jan 23, 2024
…onnection store. (#5592)

1. Remove redundant logs in fillPodInfo/fillServiceInfo to avoid Flow
   Exporter from flooding logs.
2. Add Mark field for deny connections. We were missing this field
   previously, resulting in trying to fill service information for
   non-service IPs.
3. Update the DestinationServiceAddress for deny connections when we can
   find this information in PacketIn.
4. Update e2e/unit tests to verify that the Service-relateds field are
   filled correctly.

Fixes #5573

Signed-off-by: Yun-Tang Hsu <hsuy@vmware.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
action/backport Indicates a PR that requires backports. action/release-note Indicates a PR that should be included in release notes.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

FlowExporter floods log file with confusing logs
4 participants