Subject: vlan(4), native vlan/vlan1, OpenBSD v.s. NetBSD behavior
To: None <email@example.com, firstname.lastname@example.org>
From: Brian A. Seklecki <email@example.com>
Date: 12/14/2005 16:02:49
I've got a NetBSD 2.x box acting as a VLAN router for two Cisco 2924's
running IOS Version 12.0(5)WC10.
And I've also got an OpenBSD 3.7 box acting as a VLAN router for two Cisco
2924s running IOS Version 12.0(5)WC11
Both have a VLAN1 interface configured where I stick insecure services
(like telnet to the switchs, SNMP to UPSs, Hardware IPMI, Dell DRAC cards,
nbsd$ ifconfig vlan1
vlan1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
vlan: 1 parent: fxp0
inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
inet6 fe80::290:27ff:fe5d:f3ee%vlan1 prefixlen 64 scopeid 0x9
obsd% ifconfig vlan1
vlan1: flags=8943<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
vlan: 1 parent interface: xl0
inet6 fe80::250:daff:fe28:377f%vlan1 prefixlen 64 scopeid 0x7
inet 10.0.0.3 netmask 0xfffffff8 broadcast 10.0.0.7
Is there some major behavior difference in handling of the native VLAN
and/or Vlan#1 between the two platforms? I recently had it out pretty
badly with a support person from Dell regarding a PowerConnect switch that
refused to trunk Vlan1 with a 3com switch.
3com's switches use a vlan-a-la-cart model, e.g., "this port has Vlan X as
trunked, and Vlans Y,Z as untrunked", where as most "other" swithes take
the Cisco VLAN model: either Access (1 vlan untrunked) or Trunk (all VLANs
trunked, or limited trunk (and *yes*, I know about hybrid mode)).
Previously I had only worked with Cisco, so I supposed I made the
assumption that it was Cisco/general practice to tag Vlan1 (or whatever
the native VLAN is) on Trunk ports. I made this assumption based on what
I thought was known-working-behavior with my NetBSD VLAN Router, but after
taking a closer look, I'm seeing some odd behavior that may contradict
that. I may owe the Dell guy an appology.
When I ping from the Mgmnt./Vlan1 Interface on a c2924 to the IP assigned
to the Vlan1 interface on the NetBSD box in the same subnet, I see the
netbsd% tcpdump -i fxp0 'proto \icmp' -- Physical Interface:
14:24:21.337228 10.0.0.2 > mrvlan-vlan1: icmp: echo request seq 3271
14:24:21.340518 10.0.0.2 > mrvlan-vlan1: icmp: echo request seq 3271
14:24:21.343818 10.0.0.2 > mrvlan-vlan1: icmp: echo request seq 3271
14:24:21.346420 10.0.0.2 > mrvlan-vlan1: icmp: echo request seq 3271
14:24:21.349690 10.0.0.2 > mrvlan-vlan1: icmp: echo request seq 3271
The packets coming from the Cisco are untagged, but the subnet matches
that assigned to int vlan1.
But responses seem to leave as tagged w/ Vlan1 and as long as I have
static ARP entries setup for the master/base MAC address of the switch
(not the MAC of the physical interface port of the trunk).
nbsd% arp -an
? (10.0.0.2) at 00:02:fd:e8:11:40 on vlan1 permanent
? (10.0.0.3) at 00:04:27:95:6a:80 on vlan1 permanent
...and on the Cisco side:
# sh run
arp 10.0.0.1 0090.275d.f3ee ARPA
netbsd% tcpdump -i vlan 'proto \icmp' -- Vlan Logical 1:
14:24:50.199901 mrvlan-vlan1 > 10.0.0.2: icmp: echo reply seq 738
14:24:50.205955 mrvlan-vlan1 > 10.0.0.2: icmp: echo reply seq 738
14:24:50.210370 mrvlan-vlan1 > 10.0.0.2: icmp: echo reply seq 738
14:24:50.212962 mrvlan-vlan1 > 10.0.0.2: icmp: echo reply seq 738
14:24:50.216269 mrvlan-vlan1 > 10.0.0.2: icmp: echo reply seq 738
The packets do indeed make it back to the Switch.
Where tcpdump(8) would normally show packets on the physical interface
a VLAN tag:
14:28:03.508656 802.1Q vlan#10 P0 host-x-y-z-0.pit.choiceone.net.58394 >
ns4.choiceone.net.domain: 53401+ PTR?
The above ICMP packets on vlan1 are matched on tcpdump -i fxp0 with tagged
14:43:10.072794 802.1Q vlan#1 P0 10.0.0.1 > 10.0.0.3: icmp: echo reply seq
So it seems that NetBSD has some "magic code"(r) to deal with the native
VLAN, because most admins assume that a VLAN router can see a VLAN1
interface on a trunk regardless if the packets are tagged or not.
However, unless tcpdump(8) is lying, then Cisco must have a similar hook
because it's recieving the tagged return packet and accepting it as a
response to untagged send.
This this practicle in practice because it complies with the behavior most
vendors practice, and it avoids the need to assign an IPv4 address to the
physical interface (which is confusing and misleading).
When I run the ping on the OpenBSD system, vlan1 never sees the untagged
$ sudo tcpdump -n -i vlan1
tcpdump: listening on vlan1, link-type EN10MB
However the physical interface does see it. Unless, however, I configure
an IPv4 address on the physical interface which acts as the parent of all
the vlan interfaces on the router, the router will not ARP for VLAN1 (Even
with static ARP entries on both the Cisco and OpenBSD side. )
It would seem that OpenBSD is more strictly following what I presume is
the published behavior/standard.
$ sudo tcpdump -n -i xl0
15:01:05.562906 arp who-has 10.0.0.1 tell 10.0.0.3
15:01:07.562869 arp who-has 10.0.0.1 tell 10.0.0.3
15:01:08.293927 arp who-has 10.0.0.2 tell 10.0.0.3
15:01:08.293905 10.0.0.2 > 10.0.0.3: icmp: echo request
-bash-3.00$ ifconfig xl0
xl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
inet 10.0.0.3 netmask 0xfffffff8 broadcast 10.0.0.7
? (10.0.0.2) at 00:02:fd:0e:f3:80 on xl0
# sh arp
Internet 10.0.0.3 0 0050.da28.377f ARPA VLAN1
So now I'm wondering (I don't know how to change it, and I don't have set
equipment to run a test on), but if I were to change the Native VLAN
of the trunk port on the Cisco side facing NetBSD/OpenBSD, would the
switch start tagging
I know if I enter interface configuration for Vlan1 on the Cisco side,
exists a config directive to flag a Vlan as the management VLAN:
Enter configuration commands, one per line. End with CNTL/Z.
bs1(config)#int vlaN 1
x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8