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

calico-node use problem #9349

Open
Faker523 opened this issue Oct 16, 2024 · 4 comments
Open

calico-node use problem #9349

Faker523 opened this issue Oct 16, 2024 · 4 comments

Comments

@Faker523
Copy link

why calico-node always use the first int6 to as the ipv6 src address

Expected Behavior

the pod ipv6 ping normal

Current Behavior

i have three kubernetes node cluster, use dulstack, and the ingress-nginx use a ipv6 address bind to cube-02, but i found if the ipv6 vip set in the node ipv6 front, the cube-02 can not ping the other node pod ipv6, if the cube-02 node ipv6 in front the vip ipv6, the route is right? why?

Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

  • Calico version
  • Calico dataplane (iptables, windows etc.)
  • Orchestrator version (e.g. kubernetes, mesos, rkt):
  • Operating System and version:
  • Link to your project (optional):
@Faker523
Copy link
Author

if the cube-02 ip a show is blew, the pod ipv6 ping normal
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 3c:7c:3f:f1:7e:ba brd ff:ff:ff:ff:ff:ff
inet 10.12.14.235/24 brd 10.12.14.255 scope global noprefixroute em1
valid_lft forever preferred_lft forever
inet6 2024:1011::3/80 scope global
valid_lft forever preferred_lft forever
inet6 2024:1011::1111/128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::6249:bbfa:cb8a:a700/64 scope link noprefixroute
valid_lft forever preferred_lft forever

@Faker523
Copy link
Author

but if cube-02 is this, cube-02 pod ipv6 can not ping to other node
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 3c:7c:3f:f1:7e:ba brd ff:ff:ff:ff:ff:ff
inet 10.12.14.235/24 brd 10.12.14.255 scope global noprefixroute em1
valid_lft forever preferred_lft forever
inet6 2024:1011::1111/128 scope global
valid_lft forever preferred_lft forever
inet6 2024:1011::3/80 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::6249:bbfa:cb8a:a700/64 scope link noprefixroute
valid_lft forever preferred_lft forever

and the src address become 2024:1011::1111

@Faker523
Copy link
Author

and the calico-node log show the change
felix/int_dataplane.go 1358: Linux interface addrs changed. addrs=set.Set{10.12.14.235,2024:1011::1111,fe80::6249:bbfa:cb8a:a700} ifaceName="em1"
2024-10-16 01:12:27.479 [INFO][922] felix/int_dataplane.go 1972: Received interface addresses update msg=&intdataplane.ifaceAddrsUpdate{Name:"em1", Addrs:set.Typed[string]{"10.12.14.235":set.v{}, "2024:1011::1111":set.v{}, "fe80::6249:bbfa:cb8a:a700":set.v{}}}
2024-10-16 01:12:27.479 [INFO][922] felix/hostip_mgr.go 84: Interface addrs changed. update=&intdataplane.ifaceAddrsUpdate{Name:"em1", Addrs:set.Typed[string]{"10.12.14.235":set.v{}, "2024:1011::1111":set.v{}, "fe80::6249:bbfa:cb8a:a700":set.v{}}}
2024-10-16 01:12:27.479 [INFO][922] felix/hostip_mgr.go 84: Interface addrs changed. update=&intdataplane.ifaceAddrsUpdate{Name:"em1", Addrs:set.Typed[string]{"10.12.14.235":set.v{}, "2024:1011::1111":set.v{}, "fe80::6249:bbfa:cb8a:a700":set.v{}}}
2024-10-16 01:12:27.479 [INFO][922] felix/iface_monitor.go 238: Netlink address update for known interface. addr="2024:1011::1111" exists=false ifIndex=2
2024-10-16 01:12:30.163 [INFO][922] felix/iface_monitor.go 238: Netlink address update for known interface. addr="2024:1011::1111" exists=true ifIndex=2
2024-10-16 01:12:30.163 [INFO][922] felix/int_dataplane.go 1358: Linux

@Faker523
Copy link
Author

why this will happen? calico-node why always choose the first int6 address?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant