Hi - I'm having a very basic routing issue for my LAN/br0. The unraid server can get out to the internet but it can't ping devices in other networks. What are some basic first steps I can take to troubleshoot this, since I've been unsuccessful in trying to solve this? I think it has to do with some config on unraid.

 

Note: I don't see any traffic/denies on the firewall either.

 

 

Edited April 5, 20197 yr by surfshack66

Hopefully the title isn't misleading. I moved unraid into a new interface called br0.100 and having the same issue. It seems that no matter what network unraid is in, it cannot ping other networks.

Unraid uses the untagged interface "br0" as management interface.

 

16 minutes ago, bonienl said:

Unraid uses the untagged interface "br0" as management interface.

 

I'm not sure I follow what the means exactly. Are you saying the "issue" I'm having is expected behavior?

 

@ken-ji

 

I've been reading multiple forums posts, including this

 

In this post, you say:

"With only a single NIC, and no VLAN support on your network, it is impossible for the host unRAID to talk to the containers and vice versa; the macvlan driver specifically prohibits this."

 

My question is how do I get the host unraid to talk to the containers and vice versa IF I have VLAN support on my network?

@surfshack66

Simple.

Configure docker networks on the VLANs you have defined. Do take note that the VLAN subinterfaces preferably should not have an IP address, as it will cause confusion with asymmetric routing on Unraid.

It will look like this:

(Sorry but my only server has 2 network interfaces, but it should be identical)

place the containers on the VLANs, while keeping Unraid on the unbridged main network eth0/br0/bond0.

so when container A (ie 192.168.95.129) in VLAN 3 talks to Unraid (192.168.2.5) it will always talk to the router (192.168.95.1) instead of trying to talk to Unraid directly (which the lack of IP prevents)

 

 

@ken-ji If only things were simple.

 

So I have the VLANs and Custom Networks defined per the attached screenshots, but still having this issue.

 

Ignore br0.100 in the custom networks. It's the same network as br0 and I created it for testing.

 

 

 

Sorry since you pulled me in the discussion. What exactly is your issue?

Unraid cannot ping the other subnets?

try grabbing the output of traceroute -n <unpingable ip>

 

Also, i'm amazed you were allowed to define br0.100 as I'm fairly sure docker won't let you create networks to the same gateway 

Edited April 8, 20197 yr by ken-ji

Thanks for joining. I really appreciate it.

 

I pulled you because I read one of your posts from a while back but having an issue despite configuring everything correctly. The issue is unraid cannot ping other subnets and vice versa.

 

there's something wrong with your config.

can you show the output of ip route

because from your screen shots it seems the default route is to 192.168.1.1 but br0 has an ip of 192.168.100.100 which is not in the same subnet as your gateway?

2 hours ago, ken-ji said:

there's something wrong with your config.

can you show the output of ip route

because from your screen shots it seems the default route is to 192.168.1.1 but br0 has an ip of 192.168.100.100 which is not in the same subnet as your gateway?

Which screenshot shows default route to 192.168.1.1? This is my LAN network. I just recently moved unraid to VL100 as a test to see if the issue persists.

VL100 = 192.168.100.1

 

 

you have two interfaces for the subnet 192.168.100.0/24 - br0 & br0.100

you can see it in the routing table that there are two entries for 192.168.100.0/24 there only be one unless you know what you are doing.

the default metric is 0 which makes br0.100 the default interface to use to talk to the gateway. but going to other subnets the routing table indicates to use br0 to talk to the gateway.

 

I think you have asymmetric routing going on here - packets go out one interface and the response comes back on another.

 

You must delete the ip from br0.100 so its not considered a possible route for packets for the 192.168.100.0/24 subnet

The fact that all your interfaces have routes mean you have IP addresses on all the VLANs, which I mentioned previously tends to be a confusing and messy config, particularly if you are trying to perform VLAN segregation. Additionaly, if the docker networks were autocreated (they will be if the VLAN interfaces have IP addresses), they might need to be deleted when you remove the IP from the interface (Its been a while since I configured this)

 

Sorry about that. I said before to ignore br0.100 since I created that as a test. In any case, I cleaned up the test VL100.

 

Unraid is 192.168.1.2 in the LAN 192.168.1.0

 

 

Unraid cannot ping containers in other networks.

 

 

Also, I don't think I have IP addresses on all the VLANs. Is this screenshot what you mean by having IP addresses on the VLANs?

You can reach the gateway?

ping 192.168.1.1

 

Also

ip addr

Because you routing table mentions the various subnets for some reason.

I can reach the gateway

 

 

 

Just curious, but have you restarted Unraid? Because your routing table has entries for the subnets but no IP addresses are assigned. A quick test is to run

ip route del 192.168.80.0/24

ping 192.168.80.15

I have this custom script since entries in the routing table don't persist a reboot.

And that is the totally wrong script to be using since you shouldn't be specifying local direct attached subnets specially when the interface does not have an ip address.

When you assign an IP to an interface, the networking stack will automatically define an route to the subnet on that interface. You never define this route manually.

I did that based on this recommendation.

 

 

Let's try that test you just mentioned.

 

I think you solved it!

 

A quick test from a container in br0.80 subnet

 

 

I can't believe that script was the reason I was having issues. Thank you so much for helping. Does everything seem right now if I delete that script?

 

The script is useful for custom routes but you don't have any in this case.

Also. The correct key to stop most Linux commands is Ctrl+c not Ctrl+z.

I had a few until I migrated to real router and left the custom routes there.