Solved Can't Assign IP Addresses to VLAN Interfaces in rc.conf

R

rajl

This is one of those problems that I cannot figure out why it will not work even though I've tried several different approaches.

For background, I have two network interfaces that are bonded together as a lagg interface. The lagg interface's configuration is specified in /etc/rc.conf and gets it's IP address and other information via DHCP. The lagg interface works. On top of the lagg interface I have one tagged vlan interface. I also have it's configuration specified in /etc/rc.conf. However, FreeBSD refuses to obtain an IP address on boot via DHCP for the vlan interface.

For example, this configuration in /etc/rc.conf will create the lagg interface (lagg0), assign it an ip address via DHCP, and create the vlan interface (vlan10). However, vlan10 does not get assigned an ip address via DHCP.
Code: 
    #LACP Config
    ifconfig_re0="up"
    ifconfig_re1="up"
    cloned_interfaces="lagg0 lo1 vlan10"
    ifconfig_lagg0="laggproto lacp laggport re0 laggport re1 DHCP"
    ifconfig_lagg0_ipv6="inet6 accept_rtadv"
    ifconfig_vlan10="vlan 10 vlandev lagg0 DHCP"
Similarly, this configuration for my /etc/rc.conf file (stolen from the FreeBSD) handbook has the same result - lagg0 gets an IP address via DHCP, but the vlan interface does not get an IP address via DHCP.
Code: 
    #LACP Config
    ifconfig_re0="up"
    ifconfig_re1="up"
    cloned_interfaces="lagg0 lo1"
    ifconfig_lagg0="laggproto lacp laggport re0 laggport re1 DHCP"
    ifconfig_lagg0_ipv6="inet6 accept_rtadv"
    vlans_lagg0="10"
    ifconfig_lagg0_10="DHCP"
However, I can statically assign addresses (less than optimal for my network) with the following /etc/rc.conf file.
Code: 
    #LACP Config
    ifconfig_re0="up"
    ifconfig_re1="up"
    cloned_interfaces="lagg0 lo1"
    ifconfig_lagg0="laggproto lacp laggport re0 laggport re1 DHCP"
    ifconfig_lagg0_ipv6="inet6 accept_rtadv"
    vlans_lagg0="10"
    ifconfig_lagg0_10="inet 192.168.10.10/24"
Any chance anyone can help me figure out why I can't assign IP addresses to VLAN interfaces in /etc/rc.conf via DHCP? I'm getting tired of manually typing "dhclient lagg0.10" or "dhclient vlan10" after startup, and I would prefer to have IP address configuration handled by DHCP instead of statically.

Thanks!
 
Last edited:
This is what I have on my bhyve host:
Code: 
cloned_interfaces="lagg0 vlan10"
ifconfig_igb0="up mtu 9014"
ifconfig_igb1="up mtu 9014"
ifconfig_lagg0="laggproto lacp laggport igb0 laggport igb1"
ifconfig_vlan10="inet 192.168.10.180 netmask 255.255.255.0 vlan 10 vlandev lagg0"
It's been working fine since I installed it.
 
Try adding an "up" to the vlans configuration line. IIRC dhclient only tries to get an address when an interface comes up, but it doesn't bring it up by itself.

And to dig even deeper: does the vlan actually work if you manually assign it an IP address? I'm thinking e.g. about a misconfigured or misbehaving switch or port. (A while ago we had a Cisco SG200 that randomly started dropping vlan packets!)
 
sko said:
Try adding an "up" to the vlans configuration line. IIRC dhclient only tries to get an address when an interface comes up, but it doesn't bring it up by itself.

And to dig even deeper: does the vlan actually work if you manually assign it an IP address? I'm thinking e.g. about a misconfigured or misbehaving switch or port. (A while ago we had a Cisco SG200 that randomly started dropping vlan packets!)
Click to expand...
Yep, it works if I manually assign it an ip address (e.g. ifconfig_vlan10="inet 192.168.10.10/24"). The problem is that I want DHCP to handle addresses rather than statically assign them.
 
SirDice said:
This is what I have on my bhyve host:
Code: 
cloned_interfaces="lagg0 vlan10"
ifconfig_igb0="up mtu 9014"
ifconfig_igb1="up mtu 9014"
ifconfig_lagg0="laggproto lacp laggport igb0 laggport igb1"
ifconfig_vlan10="inet 192.168.10.180 netmask 255.255.255.0 vlan 10 vlandev lagg0"
It's been working fine since I installed it.
Click to expand...
But you're not using DHCP, which is what my problem is. Static assignment is not a problem. ;-)
 
I just realized I've never seen a loopback interface specified in the "cloned interfaces" list...
What happens if you remove it or place vlan10 before lo1 in the list? The lo(4) manpage clearly states loopback interfaces should be configured last (and doesn't specify it as a cloneable interface like e.g. wlan or lagg), so I'd give that a shot.
 
sko said:
I just realized I've never seen a loopback interface specified in the "cloned interfaces" list...
What happens if you remove it or place vlan10 before lo1 in the list? The lo(4) manpage clearly states loopback interfaces should be configured last (and doesn't specify it as a cloneable interface like e.g. wlan or lagg), so I'd give that a shot.
Click to expand...

It's a leftover relic from how I configured a number of my jails.

That said, I found the solution to this problem. I needed to specify "SYNCDHCP" instead of "DHCP" for both the lagg and vlan interfaces (for reasons I do not fully understand). The "SYNCDHCP" option was buried deep in the handbook discussing the behavior of dhclient and was completely unrelated to the topic of VLANs.
 
SYNCDHCP should only affect behaviour at DHCP renewal when a new IP is assigned, i.e. it ensures a restart of PF and other services if necessary (=IP change), but it shouldn't interfere with initial configuration at startup AFAIK. We're using SYNCDHCP only on gateways which need to use PPPoE for WAN with dynamic IP; a lot of systems/jails here run on VLANs with DHCP but did'nt need SYNCDHCP. In a 'static' DHCP environment SYNCDHCP shouldn't be necessary, but I'd really like to hear the details on how/why it fixed this problem if you can spare some time and elaborate on that.
 
sko said:
SYNCDHCP should only affect behaviour at DHCP renewal when a new IP is assigned
Click to expand...
If I recall correctly it also waits until it actually receives an IP address before continuing the rest of the boot process. Normally the start script doesn't wait, which could lead to a situation where something else is loaded later in the process but the interface hasn't received an IP address yet.
 
SirDice said:
If I recall correctly it also waits until it actually receives an IP address before continuing the rest of the boot process. Normally the start script doesn't wait, which could lead to a situation where something else is loaded later in the process but the interface hasn't received an IP address yet.
Click to expand...

My google skills aren't good enough to find the random forum post that suggested I used SYNCDHCP instead of DHCP, but this was essentially the reason. The explanation I found (which could very well be wrong) is that there is essentially a race condition in the start script that is created when you use "DHCP" to assign an IP address to the parent untagged interface as well as the VLAN interfaces. What supposedly happens is that the the untagged interface (e.g., lagg0 in my instance) hasn't finished obtaining an IP address via DHCP by the time the start script begins processing the configuration for the VLAN. That causes the configuration of the VLAN via DHCP to fail. By changing DHCP to SYNCDHCP, you force everything to happen in order, as if you were typing the commands in on the command line manually, so that there is no race condition.
 
You must log in or register to reply here.
Back
Top