Date: Sun, 15 Sep 2002 18:47:21 +0300 (EEST) From: Andrew Stesin <stesin@breaker.tormoz.net> To: freebsd-stable@FreeBSD.ORG Subject: Re: Bug? VLANs, fxp, Catalyst and link0 story Message-ID: <20020915182028.O1070-100000@chour.hostmaster.net.ua> In-Reply-To: <200209151519.g8FFJPGE072516@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Oliver, On Sun, 15 Sep 2002, Oliver Fromme wrote: > Do you really have to hardcode the media data? fxp cards No, that was left from long and desperate attempts to make it work. Autonegotiation also works perfectly between Cat and fxp. > Also, I'm not sure about the link0 option. It enables downloading of > microcode for ceceive bundling to the fxp card. Yes. > > ifconfig_vlan0="inet 10.99.25.1 netmask 255.255.255.0 vlan 25 \ > > vlandev fxp0 mtu 1500 up arp" > > You don't need to specify "arp". This way it works; I'll try to cleanup the config and try once again will it work or no, in an hour or so (now the system is in use, I need people to leave off from it first). > You don't need "mtu 1500" either, because fxp supports jumboframes > natively (and the vlan driver knows about it). This one is problematic. Does it *really* know? I feel I need mtu 1500 flag just to be safe. :) Quote from a manpage: "... Using such a NIC as a parent interface implies a reduced MTU on the corresponding vlan interfaces. In the modern Internet, this is likely to cause tcp(4) connectivity problems due to massive, inadequate icmp(4) filtering that breaks the Path MTU Discovery mechanism. ..." This flag does no harm anyway, doesn't it? :) > > The problem is: as soon as I say "link0" in ifconfigs for vlanXX > > interfaces, is just plain doesn't work. > > Of course it doesn't work. "link0" on a vlan interface specifies that > it should assume that its parent interface supports vlan tagging in > hardware. But the fxp can't do that. Gmm. Thanks, you enlightened me. My fault, sorry. I just misunderstood (missed?) a difference between a) native hardware support for 802.1q tagging, and b) fxp hardware capability of doing jumboframes. Sorry for taking your time. :( It works now, and I know it works *really* as it supposed to - that's nice. :) As for me, I'd note that maybe it would be nice to somewhat update manpages - so dumb people like me will recognize the abovementioned difference more easily. > > Catalyst doesn't see even a > > mac-addresses for vlanXX interfaces. > > Because there aren't any valid packets on the wire, not even ARP > packets. ;-) Khe-khe, *now* I recognize this. ;) > > Another problem is: as soon as I remove "link0" from ifconfigs for > > "carrier" interfaces fxp0 and fxp1 - again it doesn't work. > > That's interesting. I've never needed link0 for any fxp cards before, > and I'm not really sure what the microcode is good for. (Sure, I've > read the docs, but they don't say _when_ you should use it and what the > advantages and disadvantages are.) The only visible (for now) difference is appearance of lines: fxp0: Microcode loaded, int_delay: 1000 usec bundle_max: 6 fxp0: Microcode loaded, int_delay: 1000 usec bundle_max: 6 fxp1: Microcode loaded, int_delay: 1000 usec bundle_max: 6 fxp1: Microcode loaded, int_delay: 1000 usec bundle_max: 6 at the bottom of kernel boot output. I didn't do any testing, though - maybe it will either reduce interrupt load or somewhat increase throughoutput? Or maybe loading microcode makes Intel chips behave in somewhat more "standard", expected way? > Here's how I set up VLANs (I'm typing this from my memory, > as I'm currently not logged on a box using VLANs ... it's > Sunday, after all :-) > > new_vlan=$(ifconfig vlan create) > ifconfig $new_vlan vlan 42 vlandev fxp0 > ifconfig $new_vlan inet 10.20.30.40/255 > > Note that the vlan device number is created dynamically, so it works no > matter what other vlan interfaces may already be configured, and you > don't have to care about interface numbers. Thanks, I got the idea. Anyway, I prefer static vlanXX allocation and numbering - it's much more convenient with regard to setting IP filtering up. (You may be sure you apply say NAT to vlan12 and this *really* is an external interface ;) > I'm also doing the vlan/vlandev assignment and the actual configuration > in two separate steps, because it seemed that it didn't always work > reliably when I tried to do both things at once. Some microtimeout needed for actual vlan clone creation, maybe? > Obviously, you can't do the above within /etc/rc.conf > (unfortunately). One more reason to use static vlanXX allocation and numbering. On the machine which is administered by 2-3 people, like this exact one, it's better to have things done at the places where they are supposed to be done - rc.conf for network interfaces etc. Thanks a lot for pointing me at my mistake! Now I do not feel myself an idiot, just a man whoi is not attentive enough. It's a weekend, after all. ;) WBR, Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020915182028.O1070-100000>