BGP邻居未建立是Calico网络层故障，需按“TCP 179连通性→BIRD进程状态→IP自动发现配置→BGP对等体参数一致性”顺序排查；先验证双向端口可达，再kill假死bird进程，最后核对AS号、网卡与路由策略。
当kubectl get nodes显示节点状态为NotReady，且describe node日志中反复出现“BIRD is not ready: BGP not established with 10.10.20.11”类报错时，说明Calico的BGP控制平面已明确判定邻居握手失败——这不是配置加载异常或证书错误，而是BGP协议层在TCP三次握手或OPEN协商阶段卡死，必须按网络连通性→服务状态→配置一致性路径逐层验证。
确认BIRD进程是否真正在工作
进入calico-node容器执行birdc命令前，先检查BIRD进程是否处于假死状态：在故障节点上运行ps aux | grep bird，若进程存在但netstat -ltnp | grep :179无输出，说明BIRD已崩溃或被OOM killer挂起，此时birdc会直接报“connection refused”。
执行kubectl exec -it -n kube-system calico-node-xxxxx -- sh，然后运行birdc show protocols；如果返回“birdc: connect: connection refused”，【必须立刻终止bird进程再重启】，否则所有后续诊断都无效。
用kill -9 $(pgrep bird)强制结束进程，等待calico-node自动拉起新BIRD实例。
验证节点间TCP 179端口连通性
这是BGP建立的前提，不通则一切归零。不要只测一个方向，必须双向验证：
方法一：从故障节点向任一正常节点发起连接测试
nc -vz 10.10.20.12 179（替换为目标节点业务IP）
方法二：从正常节点反向连故障节点
nc -vz 10.10.20.11 179
若任一方向失败，立即检查云厂商安全组、主机iptables/nftables规则、以及内核参数net.ipv4.ip_forward是否为1——【很多私有云环境默认关闭ip_forward，导致BGP路由无法转发】。
核对Calico节点IP自动发现配置
第一步：提取当前生效的IP_AUTODETECTION_METHOD
kubectl get pod -n kube-system calico-node-xxxxx -o yaml | grep -A3 "IP_AUTODETECTION_METHOD\|IP:"
第二步：确认该配置是否匹配真实业务网卡
登录节点执行ip addr | grep "inet " | grep -v "127.0.0.1\|::1"，比对输出中的eth0/ens33等网卡IP与calicoctl node status中显示的“Local IP”是否一致。
第三步：若不一致，修改DaemonSet强制指定网卡
编辑calico-node DaemonSet，在env区块中添加：
- name: IP_AUTODETECTION_METHOD
value: "interface=eth0"
注意：不能写成interface=eth*，某些旧版本Calico会因正则解析失败退回到first-found逻辑，反而更不可控。
直查BIRD日志定位具体失败阶段
执行kubectl logs -n kube-system calico-node-xxxxx | grep -i "bgp\|179\|error"，重点关注三类输出：
• 出现“Connection refused” → 对端BIRD未监听或防火墙拦截
• 出现“Connection timed out” → 路由不可达或中间设备丢包
• 出现“Open message received from … but not accepted” → 两端AS号、hold time或router id配置不匹配
若日志中反复出现“Idle → Connect → Active → Idle”循环，说明TCP能建连但BGP OPEN协商失败，此时必须对比两端calicoctl get bgppeer -o wide输出中的spec.asNumber和spec.nodeSelector字段。
