Closed GeorgeGuo2018 closed 4 years ago
GeorgeGuo2018
commented
4 years ago It is clear that, the incoming ipv6 packets are transferred successfully, but not vice versa through the bib and session still exist. Is there any log or other commands i can check to figure out what was wrong during the 4-to-6 process?
my Envrionment: Host: centos 7.6 3.10.0-957.1.3.el7.x86_64 Jool: v4.0.7
ydahhrk
commented
4 years ago Disclaimer: I'm not familiar with "k8s clusters" nor "cni flannels."
Using tcpdump, within the Jool pod，I can see the request is transferred to 172.31.1.2 --> 10.6.115.244. And I can also get reply from 10.6.115.244, the response packet I get within jool pod is 10.6.115.244 --> 10.6.115.244.
This seems wrong to me.
If Jool translates a packet into 172.31.1.2 --> 10.6.115.244, the response needs to be 10.6.115.244 --> 172.31.1.2, otherwise Jool doesn't recognize it.
10.6.115.244 --> 10.6.115.244
Are you sure about this?
Is there any logs I can check to find the reason?
Yes, but you have to recompile Jool first.
In any case, your stats output already says a lot to me:
The following infos seems all right.
[root@nat64-7f984bb7bf-tjs2l /]# jool stats display JSTAT_SUCCESS: 228 JSTAT_BIB_ENTRIES: 8 JSTAT_SESSIONS: 8 JSTAT_BIB4_NOT_FOUND: 8 JSTAT_SYN4_EXPECTED: 9
BIB4_NOT_FOUND and SYN4_EXPECTED mean that it's receiving IPv4 packets for which it has no state. This is the same as my observation above: In the 6->4 direction, the packet became 172.31.1.2 --> 10.6.115.244, not 10.6.115.244 --> 10.6.115.244. Therefore, the BIB Jool has expects packet 10.6.115.244 --> 172.31.1.2, not 10.6.115.244 --> 10.6.115.244.
It is clear that, the incoming ipv6 packets are transferred successfully, but not vice versa through the bib and session still exist.
There is a serviceable BIB, but no session. If you want Jool to translate 10.6.115.244 --> 10.6.115.244, then you need a session that looks somewhat like this:
(ESTABLISHED) Expires in x:xx:xx.xxx
Remote: 10.6.115.244#xxxxx xx::xx#xxxxx
Local: 10.6.115.244#xxxxx xx::xx#xxxxxDisclaimer: I'm not familiar with "k8s clusters" nor "cni flannels."
Using tcpdump, within the Jool pod，I can see the request is transferred to 172.31.1.2 --> 10.6.115.244. And I can also get reply from 10.6.115.244, the response packet I get within jool pod is 10.6.115.244 --> 10.6.115.244.
This seems wrong to me.
If Jool translates a packet into
172.31.1.2 --> 10.6.115.244, the response needs to be10.6.115.244 --> 172.31.1.2, otherwise Jool doesn't recognize it.10.6.115.244 --> 10.6.115.244
Are you sure about this?
Is there any logs I can check to find the reason?
Yes, but you have to recompile Jool first.
In any case, your stats output already says a lot to me:
The following infos seems all right. [root@nat64-7f984bb7bf-tjs2l /]# jool stats display JSTAT_SUCCESS: 228 JSTAT_BIB_ENTRIES: 8 JSTAT_SESSIONS: 8 JSTAT_BIB4_NOT_FOUND: 8 JSTAT_SYN4_EXPECTED: 9
BIB4_NOT_FOUNDandSYN4_EXPECTEDmean that it's receiving IPv4 packets for which it has no state. This is the same as my observation above: In the 6->4 direction, the packet became172.31.1.2 --> 10.6.115.244, not10.6.115.244 --> 10.6.115.244. Therefore, the BIB Jool has expects packet10.6.115.244 --> 172.31.1.2, not10.6.115.244 --> 10.6.115.244.It is clear that, the incoming ipv6 packets are transferred successfully, but not vice versa through the bib and session still exist.
There is a serviceable BIB, but no session. If you want Jool to translate
10.6.115.244 --> 10.6.115.244, then you need a session that looks somewhat like this:(ESTABLISHED) Expires in x:xx:xx.xxx Remote: 10.6.115.244#41343 xx::xx#xxxxx Local: 10.6.115.244#xxxxx xx::xx#xxxxxHi, ydahhrk. Sorry, my mistake. The response packet I get within jool pod is correct: 10.6.115.244 --> 172.31.1.2. It was a clerical error .
GeorgeGuo2018
commented
4 years ago It seems that the 4-->6 direction didnot workout as expected. But how can i figure out what is going wrong. exec jool bib dispaly, jool stats dispaly, jool session display, did not get any exception info.
ydahhrk
commented
4 years ago Sorry, my mistake. The response packet I get within jool pod is correct: 10.6.115.244 --> 172.31.1.2. It was a clerical error .
But you iptables match address is 172.30.1.2, not 172.31.1.2. If your destination address is really 172.31.1.2, then iptables will never send it to Jool.
It seems that the 4-->6 direction didnot workout as expected. But how can i figure out what is going wrong. exec jool bib dispaly, jool stats dispaly, jool session display, did not get any exception info.
You can enable debug by following these instructions.
GeorgeGuo2018
commented
4 years ago will try jool's debug mode. Thanks a lot.
Hi, I deployed Jool in a pod within a k8s cluster with cni flannel. My config of Jool is as follows(using jool as nat64 mode):
My client's IP is fe::10/96 ,and from it I start up a request fe::10 --> fdff:ffff:ffff:ffff:3:0::a06:73f4. Using tcpdump, within the Jool pod，I can see the request is transferred to 172.31.1.2 --> 10.6.115.244. And I can also get reply from 10.6.115.244, the response packet I get within jool pod is 10.6.115.244 --> 10.6.115.244. Using iptables -t mangle -L -n -v, I am sure the responsed ipv4 packages go to the JOOL module, because the packets num target by the -j JOOL rule is increased. But the those ipv4 packagets did not cameout as ipv6 packaget. something went wrong for the responsed ipv4 packet to be transferred back to ipv6.
I deploy the same Jool pod in a k8s cluster under calico network, and all works well. Seems that some thing was wrong when k8s's network is flannel.
Is there any logs I can check to find the reason? The following infos seems all right.