Talk:VLAN

From ArchWiki
Jump to: navigation, search

For my system with a Sun Cassini Quad-NIC the command

ip link set dev eth0.100 up

doesn't work, it always says "Network unreachable". I think this has to be

ip link set dev eth0 up

as you have to up the interface, not the VLAN. Tomtom (talk) 20:10, 9 May 2014 (UTC)

Sounds OK to up a VLAN device, but it should probably be created first.
I would try
ip link add link eth0 name eth0.100 type vlan id 100
before the "up".
ip link set dev eth0.100 up
Seems to work with similar commands on my config.
RegisC (talk) 21:24, 11 May 2014 (UTC)

Interface Naming

I think it'd be helpful to replace the interface names (e.g. eth0) with new systemd device names (e.g. wwp0s20u4c2i12). The new names are definitely more verbose, but more accurately reflect the current state of networking on Arch systems. Zeal J. (talk) 16:54, 2 April 2015 (UTC)

I'm neutral on the matter; your argument is sound, but eth0/wlan0 is easy to keep consistent across articles. In either case, pseudo-variables should be added. -- Alad (talk) 18:41, 2 April 2015 (UTC)

Issues with lacp and the routing examples.

I had some issues with this article.

root@vHost /home/flo # ping 8.8.8.8
connect: Network is unreachable
2 root@vHost /home/flo # ping 192.168.1.1                                                                       :(
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.756 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.306 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.329 ms
^C
--- 192.168.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.306/0.463/0.756/0.208 ms
root@vHost /home/flo # ip route 
0.0.0.0 via 192.168.1.1 dev vlan2 proto static 
10.0.0.0/24 dev vlan1 proto kernel scope link src 10.0.0.3 
172.18.0.0/30 dev ens10f3 proto kernel scope link src 172.18.0.2 
172.18.0.4/30 dev ens10f2 proto kernel scope link src 172.18.0.6 
192.168.1.0/24 dev vlan2 proto kernel scope link src 192.168.1.3 
root@vHost /home/flo # ip route delete 0.0.0.0
root@vHost /home/flo # ip route
10.0.0.0/24 dev vlan1 proto kernel scope link src 10.0.0.3 
172.18.0.0/30 dev ens10f3 proto kernel scope link src 172.18.0.2 
172.18.0.4/30 dev ens10f2 proto kernel scope link src 172.18.0.6 
192.168.1.0/24 dev vlan2 proto kernel scope link src 192.168.1.3 
root@vHost /home/flo # ip route add default via 192.168.1.1 
root@vHost /home/flo # ip route 
default via 192.168.1.1 dev vlan2 
10.0.0.0/24 dev vlan1 proto kernel scope link src 10.0.0.3 
172.18.0.0/30 dev ens10f3 proto kernel scope link src 172.18.0.2 
172.18.0.4/30 dev ens10f2 proto kernel scope link src 172.18.0.6 
192.168.1.0/24 dev vlan2 proto kernel scope link src 192.168.1.3 
root@vHost /home/flo # ping 8.8.8.8    
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=46 time=28.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=46 time=26.4 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 26.446/27.398/28.351/0.966 ms

As you can see, the default route definition described in that article doesn't work.

/etc/systemd/network/vlan10.network
[Match]
Name=vlan10

[Network]
VLAN=vlan10

[Address]
Address=10.10.10.2/24

[Route]
Destination=default
Gateway=10.10.10.1

fixed it.

I'm not sure if that's always the case. In my opinion 0.0.0.0 should work to but it doesn't.

Another thing that doesnt work is lacp with bond0.

https://forum.manjaro.org/t/how-to-create-lacp-802-3ad-bond-using-systemd-networkd/14655 This guy had the same problem with bond0

bond0 seems to be working but if you check it with cat /proc/net/bonding/bond0 its using round robin, bond0 is always there even when it is not used. It can't be configured.


The problem is that network connection works but lacp not. So double check the configuration of lacp.

On my TP Link Switch (should also work on Cisco)

 MainSwitch#show lacp neighbor 
Flags:  S - Device is requesting Slow LACPDUs
        F - Device is requesting Fast LACPDUs
        A - Device is in active mode       P - Device is in passive mode

Channel group 2
                  LACP port                  Admin  Oper   Port    Port
Port      Flags   Priority   Dev ID          Key    Key    Number  State
Gi1/0/18  FA      255        3e9e.0031.be28  0      0x9    0x2     0x3f
Gi1/0/19  FA      255        3e9e.0031.be28  0      0x9    0x1     0x3f

Channel group 3
                  LACP port                  Admin  Oper   Port    Port
Port      Flags   Priority   Dev ID          Key    Key    Number  State
Gi1/0/20  SA      32768      6805.ca08.e066  0      0xcb   0x1     0x3d
Gi1/0/21  SA      32768      6805.ca08.e066  0      0xcb   0x2     0x3d

To get LACP working i used a config like this

/etc/systemd/network/bond1.netdev
[NetDev]
Name=bond1
Kind=bond

[Bond]
Mode=802.3ad
LACPTransmitRate=fast

I don't want to edit the article without testing. Has anyone similar problems?

DarkHelmet (talk) 02:12, 24 February 2017 (UTC)

Hi, I have not had time to test, but I think the default route simply missed the subnet. Can you perhaps try if [1] fixes the first issue in your case? --Indigo (talk) 01:20, 20 February 2017 (UTC)
Thx, both Destinations work Destination=default or Destination=0.0.0.0/0
The thing with bond0. It's not a bug It's a feature
https://bugzilla.redhat.com/show_bug.cgi?id=1119347
https://lists.freedesktop.org/archives/systemd-devel/2015-March/029041.html
The kernel creates bond0 and systemd-networkd doesn't change allready configured netdevs
https://cgit.freedesktop.org/systemd/systemd/commit/?id=7c1cff4
That explains a lot.
https://lists.freedesktop.org/archives/systemd-devel/2015-March/029047.html
That's the best solution to prevent the kernel to create bond0, I think. Without thats it's impossible to use systemd-networkd to configure bond0 DarkHelmet (talk) 02:12, 24 February 2017 (UTC)
Your references read sound to me, but I have still not run through the example myself. I've left Storrgie a note to have a look here, so we can clarify which bond is most generally applicable (and why using bond1 may confuse). --Indigo (talk) 18:07, 24 February 2017 (UTC)
Those are interesting references. I've personally not run into any issues with bond0 and we're using it on a LOT of deployments now. Those references are sound though. My concern is that arbitrarily selecting an index that is higher would be confusing to me without substantiation. I wonder if this thing with bond0 is a legacy thing that isn't in current Arch package versions. I'd propose that we add some caveats to bond name selection with references to what DarkHelmet dug up. --storrgie (talk) 10:36, 24 February 2017 (UTC)
upon further review, bond0 should be avoided. It appears that if you "modprobe bonding" you will immediately see "bond0". I'd say that bond0 should be avoided and I'm going to make the modification now. --storrgie (talk) 11:06, 24 February 2017 (UTC)
Ok, I've merged your versions and made a nice green tip out of modprobe.d part with [2]. Using a pseudovariable is preferable, so users adapt depending on individual system's config. Thanks both. Item appears clarified, closing. --Indigo (talk) 11:39, 26 February 2017 (UTC)