| gcds | Hi, maybe someone could help me with netplan stuff, I am going bald from trying to figure out what is wrong. Context: I have network 10.93.0.0/16 the server has a bridge with one interface and static IP address of 10.93.2.2/16, everything generates and works but for some reason I can't access anything higher than 10.93.127.254, I tried adding a | 10:03 |
|---|---|---|
| gcds | static route for 10.93.0.0/16 via 10.93.0.1 but didn't help, but then I removed default generated route which looked suspicious to me (the 10.93.0.0/16 via 10.93.2.2 in the paste) and it worked then, I would consider it's done but I know it's not permanent so maybe can help me figure out what's wrong with netplan so I would not need to make changes | 10:03 |
| gcds | after each reboot? https://paste.ubuntu.com/p/kPrPBwPQBx/ | 10:03 |
| slyon | gcds: interesting... I wonder where the 10.93.0.0/16 route is coming from... it states "proto kernel", so most probably didn't get applied through netplan. | 10:09 |
| slyon | does it re-appear if your run "netplan apply"? | 10:09 |
| gcds | hmm, so I have deleted it with "ip route del" and then run again netplan apply and it reappeared | 10:09 |
| gcds | https://paste.ubuntu.com/p/NB3t4WyhMy/ | 10:11 |
| slyon | Interesting. Sounds similar to this: https://unix.stackexchange.com/questions/665792/prevent-route-creation-when-bringing-up-network-interface | 10:12 |
| slyon | a workaround could be to install a routeable.d hook via networkd-dispatcher: https://netplan.io/faq/#use-pre-up%2C-post-up%2C-etc.-hook-scripts – but it's not a very clean solution | 10:13 |
| gcds | Yes, I am almost ready to make the script like in SE suggestion, but I wanted to understand whats wrong so that in future I would know why | 10:14 |
| gcds | the only thing I have is sysctl config file load on udev rules for bridge | 10:15 |
| gcds | but I dont think that can create a route | 10:16 |
| slyon | yes. I can confirm that the route is created in a local test system for me as well. so it's not specific to your system | 10:18 |
| gcds | worst part I spent like 1,5 days blaming unifi udm router with mDNS stuff when in the end it was server not accessible for this route issue :facepalm: | 10:19 |
| slyon | how about this: | 10:20 |
| slyon | In addition to your "default" route, add another static route in netplan: "to: 0.93.0.0/16, via: 10.93.2.2" (potentially using a higher priority metric than the kernel route)? | 10:21 |
| gcds | you mean adding higher metric value right? | 10:21 |
| slyon | argh via "10.93.0.1" that is | 10:21 |
| gcds | yes yes I understood | 10:22 |
| slyon | lower metric value, would have higher priority IIRC | 10:22 |
| gcds | issue is that kernel route is metric 0:D and -1 is not allowed:D | 10:25 |
| slyon | ugh | 10:26 |
| gcds | it's fine I guess I am gonna just add a script for it, I was just curious what is causing to generate such route | 10:27 |
| slyon | I think it's the kernel generating that route whenever br0 is brought up | 10:30 |
| slyon | And the route looks somewhat sensible IMO, too. it sends all trafic to 10.93.0.0/16 through br0 using its 10.93.2.2 IP address. which makes kind of sense | 10:31 |
| slyon | I don't know how that would explain why you can only reach part of your network | 10:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!