Date: Sun, 3 Jul 2005 23:05:13 -0600 From: "Lee S Clark" <mosfet@planet.eon.net> To: <freebsd-net@freebsd.org> Subject: EM(4), vlans & dhclient Message-ID: <003101c58055$f5eb2110$4b3010ac@antioch>
next in thread | raw e-mail | index | archive | help
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 =3D 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?003101c58055$f5eb2110$4b3010ac>