#network troubleshooting

1 messages ยท Page 1 of 1 (latest)

molten perch
#

(making a thread)

wise grove
#
wget http://repo.huaweicloud.com
Connecting to repo.huaweicloud.com (123.125.16.225:80)
Connecting to mirrors.huaweicloud.com (124.70.125.167:443)

It could fetch in pod

#

but failed in buildkit

molten perch
#

hmm, trying to think of ideas but it's getting late here, it's hard to guess what might be going wrong. would need to know more about the infrastructure/network, but ideally this could be narrowed down more ๐Ÿค”

#

it doesn't seem DNS or resolv.conf related at least, since it was able to resolve to an IP

#

i'm not sure what exact error code 'connection failed' corresponds to, knowing that could help (i.e. ECONNREFUSED?)

#

sometimes this sort of thing happens with overlapping CIDR ranges, so ours is 10.87.0.0/16 if that helps

wise grove
#

Not sure. I couldn't found the network settings

scenic vessel
#

@wise grove are you having issues with that specific ip only? or no connection work at all?

wise grove
scenic vessel
#

do you have access to the VM where your pod is currently running to troubleshoot? Since Dagger services make use of bridge networks, I'm wondering if ip forwarding is set correctly since it's required for that to work.

wise grove
#

DNS works well.
Now just network hangs when request https

scenic vessel
#

what CNI is your k8s cluster using?

wise grove
#

coredns

scenic vessel
#

or which k8s hosted service is that? At this point we need to replicate your setup so we can troubleshoot. Since k8s CNI's operate differently

wise grove
autumn aurora
#

Is it possible to run ip addr in the pod @wise grove ? If installed that might show the mtu of the interface being used in there

wise grove
# autumn aurora Is it possible to run `ip addr` in the pod <@134121434749337601> ? If installed ...
/ # ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0@if1077: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue state UP 
    link/ether 22:89:6b:2d:38:a4 brd ff:ff:ff:ff:ff:ff
    inet 10.58.5.91/24 brd 10.58.5.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::2089:6bff:fe2d:38a4/64 scope link 
       valid_lft forever preferred_lft forever
3: dagger0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000
    link/ether ca:59:36:b6:79:3b brd ff:ff:ff:ff:ff:ff
    inet 10.87.0.1/16 brd 10.87.255.255 scope global dagger0
       valid_lft forever preferred_lft forever
    inet6 fe80::c859:36ff:feb6:793b/64 scope link 
       valid_lft forever preferred_lft forever
autumn aurora
#

mtu 1450
Yeah that's lower than 1500...

#

So that's suspicious

molten perch
#

oh fun

autumn aurora
molten perch
wise grove
#

Could I update it directly ?

molten perch
#

yeah, I think it should take effect in new containers

#

hm, actually not sure, since the interface already exists

#

i can just build an image that hardcodes it, lol

#

@wise grove vito/dagger-engine:dev3

scenic vessel
molten perch
#

yeah, since it's a regular file we just add in the build process

#

so you could do a ConfigMap

wise grove
molten perch
#

๐Ÿ˜ฎ that fixed it?

wise grove
molten perch
#

@autumn aurora from the top rope!

autumn aurora
#

lol I wrote a CNI plugin for firecracker years ago and am pretty sure I hit this exact thing, it triggered some deep memory

wise grove
#

May could be better generated. I don't want to hard code in config map. ๐Ÿ˜‚

{
  "cniVersion": "0.4.0",
  "name": "dagger",
  "plugins": [
    {
      "bridge": "dagger0",
      "hairpinMode": true,
      "ipMasq": true,
      "ipam": {
        "ranges": [
          [
            {
              "subnet": "10.87.0.0/16"
            }
          ]
        ],
        "type": "host-local"
      },
      "isDefaultGateway": true,
      "mtu": 1450,
      "type": "bridge"
    },
    {
      "type": "firewall"
    },
    {
      "capabilities": {
        "aliases": true
      },
      "domainName": "dns.dagger",
      "type": "dnsname"
    }
  ]
}
molten perch
#

lol yeah definitely, I think ideally we'd find some way to detect the right value

molten perch
#

@scenic vessel @autumn aurora thanks for your help! ๐Ÿ™

wise grove
#

I just a question, why http pass but https not.

molten perch
#

could just be down to packet size difference

#

actually it seemed like https worked, but not http

#

the baidu request showed it following the https redirect to http

molten perch
#

oh that's a screenshot from when it worked, nvm

wise grove
molten perch
#

yay! thanks for checking

#

saw your comment about writing to /etc/dagger/, that's an easy enough fix

#

I can have it write the generated config somewhere else, doesn't really matter