|
| 1 | +# CNC troubleshooting |
| 2 | + |
| 3 | +This document explains how to troubleshoot issues that you may encounter while using the Citrix Kubernetes node controller (CNC). Using this document, you can collect logs to determine the causes and apply workarounds for some of the common issues related to the configuration of the CNC |
| 4 | + |
| 5 | +To validate Citrix ADC and the basic node configurations, refer to the image on the [deployment](README.md) page. |
| 6 | + |
| 7 | +### Service status DOWN |
| 8 | + |
| 9 | +To debug the issues when the service is in down state, |
| 10 | + |
| 11 | +1. Verify the logs of the CNC pod using the following command:: |
| 12 | + |
| 13 | + ``` |
| 14 | + kubectl logs <cnc-pod> -n <namespace> |
| 15 | + ``` |
| 16 | + |
| 17 | + Check for any 'permission' errors in the logs. CNC creates kube-cnc-router pods which require NET_ADMIN privilege to perform the configurations on nodes. So, the CNC service account must have the NET_ADMIN privilege and the ability to create host mode kube-cnc-routerpods. |
| 18 | + |
| 19 | +2. Verify the logs of the kube-cnc-router pod using the following command: |
| 20 | + |
| 21 | + ``` |
| 22 | + kubectl logs <kube-cnc-pod> -n <namespace> |
| 23 | + ``` |
| 24 | + |
| 25 | + Check for any error in the node configuration. The following is a sample typical router pod log: |
| 26 | + |
| 27 | + <img src="../images/router-pod-log.png" width="600" height="300"> |
| 28 | + |
| 29 | +3. Verify the kube-cnc-router configmap output using the following command: |
| 30 | + |
| 31 | + ``` |
| 32 | + kubectl get configmaps -n <namespace> kube-cnc-router -o yaml |
| 33 | + ``` |
| 34 | + Check for empty field in the data section of the configmap. The following is a sample typical two node data section: |
| 35 | + |
| 36 | + <img src="../images/router-cmap-data.png" width="600" height="300"> |
| 37 | + |
| 38 | +4. Verify the node configuration and make sure the following: |
| 39 | + - CNC interface cncvxlan<md5_of_namespace> should be created. |
| 40 | + - Assigned VTEP IP address should be the same as the corresponding router gateway entry in Citrix ADC. |
| 41 | + - Status of interface should be functioning. |
| 42 | + - iptable rule port should be created. |
| 43 | + - Port should be the same that of VXLAN created on Citrix ADC. |
| 44 | + |
| 45 | + <img src="../images/worker-1.png" width="600" height="300"> |
| 46 | + |
| 47 | + |
| 48 | +### If the service status is up and operational, but the ping from Citrix ADC is not working |
| 49 | + |
| 50 | +If you are not able to ping the service IP address from Citrix ADC even though the services are in operational state. One reason may be the presence of a PBR entry which directs the packets from Citrix ADC with SRCIP as NSIP to the default gateway. |
| 51 | + |
| 52 | +It does not impact any functionality. You can use the VTEP of Citrix ADC as source IP address using the -S option of ping command in the Citrix ADC command line interface. For example: |
| 53 | + |
| 54 | + ``` |
| 55 | + ping <serviceIP> -S <vtepIP> |
| 56 | + ``` |
| 57 | +Note: If it is necessary to ping with NSIP itself, then, you must remove the PBR entry or add a new PBR entry for the endpoint with high priority. |
| 58 | + |
| 59 | +### cURL to the pod endpoint or VIP is not working |
| 60 | + |
| 61 | +Though, services are in up state, still you cannot cURL to the pod endpoint, that means, the stateful TCP session to the endpoint is failing. One reason may be the ns mode 'MBF' is set to enable. This issue depends upon deployments and might occur only on certain versions of Citrix ADC. |
| 62 | +To resolve this issue, you should disable MBF ns mode or bind a netprofilewith the netprofile disabled to the servicegroup. |
| 63 | +Note: If disabling the MBF resolves the issue, then it should be kept disabled. |
| 64 | + |
| 65 | +## Customer support |
| 66 | + |
| 67 | +For general support, when you raise issues, provide the following details which help for faster debugging. |
| 68 | +cURL or ping from Citrix ADC to the endpoint and get the details for the following: |
| 69 | + |
| 70 | +For the node, provide the details for the following commands: |
| 71 | + |
| 72 | +1. tcpdump capture on CNC interface on nodes |
| 73 | + ``` |
| 74 | + tcpdump -i cncvxlan<hash_of_namesapce> -w cncvxlan.pcap |
| 75 | + ``` |
| 76 | +2. tcpdump capture on node Mgmt interface lets say "eth0" |
| 77 | + ``` |
| 78 | + tcpdump -i eth0 -w mgmt.pcap |
| 79 | + ``` |
| 80 | +3. tcpdump capture on CNI interface lets say "vxlan.calico" |
| 81 | + ``` |
| 82 | + tcpdump -i vxlan.calico -w cni.pcap |
| 83 | + ``` |
| 84 | +4. output of "ifconfig -a" on the node. |
| 85 | +5. output of "iptables -L" on the node. |
| 86 | + |
| 87 | + |
| 88 | +For ADC, provide the details for the following show commands: |
| 89 | +1. show ip |
| 90 | +2. show vxlan <vxlan_id> |
| 91 | +3. show route |
| 92 | +4. show arp |
| 93 | +5. show bridgetable |
| 94 | +6. show ns pbrs |
| 95 | +7. show ns bridgetable |
| 96 | +8. show ns mode |
| 97 | +9. Try and capture nstrace while ping/curl: |
| 98 | + ``` |
| 99 | + start nstrace -size 0 -mode rx new_rx txb tx -capsslkeys enABLED |
| 100 | + ``` |
| 101 | + ``` |
| 102 | + stop nstrace |
| 103 | + ``` |
0 commit comments