EM(4), vlans & dhclient

[Lee S Clark]

This is likely a rehash of something that has been addressed in the archives (and I couldn't find).  Omitting the network design in favor of general questions.  Let me know if more details are required.

I have a FreeBSD 5.4-Release box with an Intel PRO/1000 T desktop adapter (82544GC) on which I need to have three, possibly more, vlan interfaces lease IPs by dhclient on an ISP facing dot1q trunk.  Each vlan on the trunk is bridged onto an ATM PVC which terminates at a unique ISP edge router (eg. each vlan interface leases an IP from a disperate subnet).  The FBSD box is intended to replace a Cisco 4500M+ which is working fine in this configuration.

Everything works great when IP addresses are manually configured on the vlan interfaces, but the use of dhclient is mandatory.

This is what I'm seeing:

- dhclient's interactions with either em(4) or some part of vlan(4) is flakey at best.  occasionally all 3 vlan interfaces will obtain an IP, in other instances there is no traffic placed on the wire at all.  typically one vlan int will get an IP the other two will not.  i suppose this has something to do with em not liking promisc.

- the vlan interfaces _must_ have the same MAC as the parent (em0) otherwise the parent must be in promisc in order for the vlan int to recieve frames destined for it if a unique lladdr is applied.  this may seem obvious, but is there a way to alter this behaviour to allow "unicast" MAC forwarding up from the parent to the vlan interfaces without enabling promisc (this might be another request for Linux veth on FreeBSD ;)?  our ISP requires MAC registration in order to allocate IPs, one MAC = one IP, period.

- the PRO/1000 achieves link with the switch (Nortel 350-24T) after rc.conf is parsed (i think); thus after dhclient sends its first discover broadcasts for the vlan interfaces.  pf ends up having an aneurysm because there are no IPs bound to the vlan interfaces.. that's going to be hit & miss anyway since we have a 1/5 or so chance of actually getting an IP when the trunk is up.  i tested this on both trunk and access ports with and without vlan ints on a couple of switches... the driver is slow to report link up.

- note that spanning tree is not running on the switch since there is only one switching path, therefore the port should not be subject to a forwarding delay which would further aggravate dhclient.

- both ends of the link have been manually configured for 100Mbps fdx operation, no autonegotiation on any device this box interfaces with.

The real question is - should I toss these NICs and get something else?

That's pretty much it!  Incidentally, I have an identical box running OpenBSD 3.7 and it's utterly hopeless as well, nothing is put on the wire when dhclient is invoked, ever.  :\


Thanks for any thoughts on this!
Lee