Subject: vlan(4), native vlan/vlan1, OpenBSD v.s. NetBSD behavior
To: None <,>
From: Brian A. Seklecki <>
List: tech-net
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
         vlan: 1 parent: fxp0
         address: 00:90:27:5d:f3:ee
         inet netmask 0xffffff00 broadcast
         inet6 fe80::290:27ff:fe5d:f3ee%vlan1 prefixlen 64 scopeid 0x9

obsd% ifconfig vlan1
         address: 00:50:da:28:37:7f
         vlan: 1 parent interface: xl0
         inet6 fe80::250:daff:fe28:377f%vlan1 prefixlen 64 scopeid 0x7
         inet netmask 0xfffffff8 broadcast

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.

NetBSD Behavior:

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 > mrvlan-vlan1: icmp: echo request seq 3271
14:24:21.340518 > mrvlan-vlan1: icmp: echo request seq 3271
14:24:21.343818 > mrvlan-vlan1: icmp: echo request seq 3271
14:24:21.346420 > mrvlan-vlan1: icmp: echo request seq 3271
14:24:21.349690 > 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
? ( at 00:02:fd:e8:11:40 on vlan1 permanent
? ( at 00:04:27:95:6a:80 on vlan1 permanent

...and on the Cisco side:

# sh run
arp 0090.275d.f3ee ARPA

Return packets:

netbsd% tcpdump -i vlan 'proto \icmp' -- Vlan Logical 1:
14:24:50.199901 mrvlan-vlan1 > icmp: echo reply seq 738
14:24:50.205955 mrvlan-vlan1 > icmp: echo reply seq 738
14:24:50.210370 mrvlan-vlan1 > icmp: echo reply seq 738
14:24:50.212962 mrvlan-vlan1 > icmp: echo reply seq 738
14:24:50.216269 mrvlan-vlan1 > 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 >  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 > 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).

OpenBSD Behavior:

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 tell
15:01:07.562869 arp who-has tell
15:01:08.293927 arp who-has tell
15:01:08.293905 > icmp: echo request

-bash-3.00$ ifconfig xl0
         address: 00:50:da:28:37:7f
         inet netmask 0xfffffff8 broadcast

? ( at 00:02:fd:0e:f3:80 on xl0

# sh arp
Internet                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 
of test
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:

bs1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
bs1(config)#int vla
bs1(config)#int vlaN 1
bs1(config-if)#management ?





x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8