On 2007/05/09 14:08, Jon wrote:
> The switch is vlan aware and the hosts connected to it are plugged
> into ports which are assigned to vlans configured on the switch with
> the same numbers that I am putting in the /etc/hostname.vlan* vlan
> option fields.
Usually you can configure a switch port to have one untagged vlan,
and zero or more tagged vlans.
Tagged vlans simply have the ethernet frame marked with the number
of the vlan, and need support from the connected device. You would use
this on the connection to the router.
Frames sent to untagged vlans have any tags, if present, stripped off
by the switch and passed on. You can connect normal equipment to an
untagged port, it doesn't need to know anything about VLANs. The cheap
fanless managed switch I have at home gives a dropdown list to choose
'PVID', which is the untagged vlan. Procurve and Extreme switches
just use tagged/untagged. $DEITY knows what Cisco use, they like to
make up their own names.
You can have both types running on a port together.
>>> Using tcpdump on the vlan parent device DOES show
>>> all kinds of arp requests and such noise marked as 802.1Q coming
>>> from the hosts on the various vlans (mostly unanswered arp requests
>>> for the vlan device which is their gateway) and using tcpdump on the
>>> various vlan devices on the router shows only unanswered arp requests
>>> for the various other hosts.
Run two copies of tcpdump, one on em1, one on a vlan. All the frames
marked for that vlan should be shown twice, one on parent, one on the
vlan. Is that working ok?
>>> * I've uncommented net.inet.ip.forwarding=1 in /etc/sysctl.conf
You did either also set this manually, or reboot to activate it, I take
it? Please check output of 'sysctl net.inet.ip.forwarding' if you are not
absolutely certain.
>>> * packetfilter is off
ok ('Status: disabled' in pfctl -si?)
>>> * hostname.em0: inet 172.18.1.2 255.255.255.0 NONE (external side of the
>>> router, local to my desktop lan - pings go through this to the vlan
>>> devices and return just fine)
>>> * hostname.em1: up mtu 1518 (the mtu 1518 part is just cause a man page
>>> seemed to be suggesting I should set it to this)
Which man page seemed to be suggesting that? Maybe the wording needs
some adjustment. You should reset to 1500 and remove the setting from
hostname.em1. MTU is the maximum size of IP packets. Apart from on
extremely crappy nics, vlans do not affect that unless you stack them
on top of each other (e.g. vlandev vlanXXX).
>> The 802.1Q protocol will increase the frame by 4 bytes, but if your
>> destination cannot interpret the VLAN protocol ID, the packet will be
>> dropped.
Not necessarily; there is definitely some kit out there which just
strips the vlan tags and passes them through, I have a pseudowire WAN
circuit which does just that. (neos networks, for those in .uk-land
who are interested in such things: don't know whether it's them or
the modems on the telewest tail that's doing it...)
> So in this case that isn't just the switch and the firewall? I'm
> confused. :( I thought the wrapping and unwrapping of the network
> packets in the vlan protocol packets was handled solely by the switch
> and firewall.
picking nits: ethernet has frames, IP has packets.
> You're telling me this is not the case?
It *is* the case, at least on untagged ports. I think that must be
how you have things configured, or you wouldn't see tags coming in to
the firewall on the parent interface.
>From your earlier post,
"Traffic passes fine to the vlan devices from the external
side of the router (I can ping them) however traffic does not
seem to pass bewteen the vlan devices and their parent device
- I cannot ping stuff connected to the vlans on the switch."
this isn't quite clear. can you try rewriting it more completely?
"I cannot ping stuff" - what stuff, where from? It may be simpler to
just copy-and-paste bits of a terminal session. Also include
arp -an, netstat -rnfinet, ifconfig -A from the firewall.
If you can describe exactly how the switch is configured, that may
help too.
