All:

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
         address: 00:90:27:5d:f3:ee
         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
         address: 00:50:da:28:37:7f
         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.


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 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

Return packets:

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 
with
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 
equiv.

14:43:10.072794 802.1Q vlan#1 P0 10.0.0.1 > 10.0.0.3: icmp: echo reply seq 
5183

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 
traffic.

$ sudo tcpdump -n -i vlan1
tcpdump: listening on vlan1, link-type EN10MB

[nothing]

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
         address: 00:50:da:28:37:7f
         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 
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
VLAN1?

I know if I enter interface configuration for Vlan1 on the Cisco side, 
there
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)#man
bs1(config-if)#management ?
   <cr>

bs1(config-if)#management


Thoughts?

~BAS

l8*
 	-lava

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