Jon wrote:
This was very informative. Thank you very much. After re-evaluating
the vlan/tagging settings on the 3com switch ports we noticed that
they were all set to "hybrid" mode (so some could be on multiple
vlans) but the connection to the router was set to "trunking" mode
instead of hybrid. Changing it to hybrid fixed everything.
Ok, that's weird, that has nothing to do with VLAN. I'm still not
convinced that everything is setup correctly, even though it is working.
Are you using VLANs for the purpose of creating separate Ethernet
domains? Do the end-nodes (hosts connected to a VLAN-aware switch port)
belong to multiple VLANs?
Stuart Henderson wrote:
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.
If you are just using VLANs for Ethernet domain segmentation only, the
end-nodes do not need to speak 802.1Q. You could disable VLAN on your
hosts if your 3COM switch accepts _only_ untagged frames (as opposed to
accepting tagged only and both) from hosts in a VLAN. Then, before the
switch forwards frames to these hosts, it will strip the 802.1Q protocol
bytes. Also, when the switch receives a VLAN tagged frame from a host on
an "untagged frames only" configured switch port, it will discard it.
This can be a security feature because it will make it more difficult
for a cracker to VLAN hop by injecting spoofed VLAN IDs into frames.
Such a frame could be forwarded by your switch to a normally unreachable
segment, thus bypassing your routing firewall.
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).
See the diagnostics section of vlan(4).
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...)
Well, then that device would be VLAN-aware. VLAN-aware devices can
transparently forward 802.1Q enhanced frames or strip the protocol
bytes, recalculate the FCS and forward.
Tag-aware devices manipulate and/or create 802.1Q enhanced frames.
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.
Not if you involve a tag-aware end-node (a device connected to a switch
port in a VLAN).
In Ethernet "Type Encapsulation," the 802.1Q bytes are inserted between
the source address and the frame type. No un/wrapping occurs.
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.
I'm still confused about your setup, but thought I'd offer a few
pointers nonetheless.
