Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top


I am trying to setup an additional VLAN on our Debian-based router/firewall (which exists as a virtual machine on Hyper-V), our core switch (an HP Procurve 5406) and a remote HP ProCurve 2610 that is connected via a WAN Transparent Lan Service (TLS) link.

Let's work backwards from the network edge: The Debian server has an external connection attached to eth0. The internal interface is eth1, which is connected directly from our Hyper-V host to the 5406. The port that eth1 is attached to is setup as Trk12. The 2610 is attached to Trk9 (which trunks a whole slew of VLANs - Trk9 is our TLS head). I can successfully ping the management IP addresses for my VLAN from both switches but I cannot ping, from either switch, the virtual interface for my new VLAN on the Debian-base router and firewall. The existing VLAN works fine.

What gives? The port eth1 is attached to is a trunk, the existing VLAN (ID 98) is untagged on the trunk, the new VLAN (ID 198) is tagged. VLAN 198 is tagged on Trk9 on the 5406 and on the 2610. I can ping the other switch's management IP ( and from the other respective switch. That leg of the VLAN works - however I cannot communicate with eth1.198's I feel like I'm missing something elementary but what it is remains illusive to me. I suspect the issue is with the vconfig created eth1.198. It should pass the tagged VLAN 198 packets correct? But they cannot seem to get any further than the 5406.

Communication on the existing VLAN 98 works fine.

From the Debian box:


eth1      Link encap:Ethernet  HWaddr 00:15:5d:34:5e:03  
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::215:5dff:fe34:5e03/64 Scope:Link
          RX packets:12179786 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20210532 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1586498028 (1.4 GiB)  TX bytes:26154226278 (24.3 GiB)
          Interrupt:9 Base address:0xec00 


eth1.198  Link encap:Ethernet  HWaddr 00:15:5d:34:5e:03  
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::215:5dff:fe34:5e03/64 Scope:Link
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:72 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:3528 (3.4 KiB)

# cat /proc/net/vlan/eth1.198:

eth1.198  VID: 198       REORDER_HDR: 0  dev->priv_flags: 1
         total frames received            0
          total bytes received            0
      Broadcast/Multicast Rcvd            0

      total frames transmitted           72
       total bytes transmitted         3528
            total headroom inc            0
           total encap on xmit           39
Device: eth1
INGRESS priority mappings: 0:0  1:0  2:0  3:0  4:0  5:0  6:0 7:0
 EGRESS priority mappings: 

# ip route dev eth1.198  proto kernel  scope link  src dev eth0  proto kernel  scope link  src dev eth1  proto kernel  scope link  src 
default via dev eth0 

# iptables -L -v

Chain INPUT (policy DROP 6875 packets, 637K bytes)
 pkts bytes target     prot opt in     out     source               destination         
   41  4320 ACCEPT     all  --  lo     any     anywhere             anywhere            
11481 1560K ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED 
  107  8058 ACCEPT     icmp --  any    any     anywhere             anywhere            
    0     0 ACCEPT     tcp  --  eth1   any        anywhere            tcp dpt:ssh 
  701  317K ACCEPT     udp  --  eth1   any     anywhere             anywhere            udp dpts:bootps:bootpc 

Chain FORWARD (policy DROP 1 packets, 40 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 156K   25M ACCEPT     all  --  eth1   any     anywhere             anywhere            
 215K  248M ACCEPT     all  --  eth0   eth1    anywhere             anywhere            state RELATED,ESTABLISHED 
    0     0 ACCEPT     all  --  eth1.198 any     anywhere             anywhere            
    0     0 ACCEPT     all  --  eth0   eth1.198  anywhere             anywhere            state RELATED,ESTABLISHED 

Chain OUTPUT (policy ACCEPT 13048 packets, 1640K bytes)
 pkts bytes target     prot opt in     out     source               destination   

From the 5406:

# show vlan ports trk12 detail

 Status and Counters - VLAN Information - for ports Trk12

  VLAN ID Name                 | Status     Voice Jumbo Mode    
  ------- -------------------- + ---------- ----- ----- --------
  98      WIFI                 | Port-based No    No    Untagged
  198     VLAN198              | Port-based No    No    Tagged  
share|improve this question
Your INPUT policy is mentioning eth1, not eth1.198. This may be an error, or it may be an omission in the tool. Also, to directly answer your title question, Linux virtual interfaces created for VLANs are tagged, as that's how it operates. Not too helpful for the rest of your question. – Charles Mar 30 '12 at 2:58
Could you just post some screenshots from the networking configuration on your Hyper-V server? The answer to your question is probably hidden therein. – the-wabbit Apr 3 '12 at 11:24
up vote 2 down vote accepted

Your Linux machine is a Hyper-V VM, so I would assume that it is Hyper-V's virtual switch which is filtering your tagged traffic. You could simply work around this: create a new interface for the Debian VM in Hyper-V using the same virtual network as for eth1 and set the VLAN ID to 198.

set VLAN ID for virtual network adapter

(taken from

It will be exposed to your debian VM as eth2 (presumably) and have untagged frames. If you would prefer a different name (i.e. eth1.198) you should be able to rename it using ifrename or udev.

share|improve this answer
I took a look at the Hyper-V host - we have a two physical interfaces that are "mapped" through to the Linux VM as Legacy Network Adapters. There's no virtual switch being utilized as far as I can tell. – kce Mar 30 '12 at 23:52
What do you mean by "mapped"? You would have "virtual network" created and assigned to a physical network adapter. The virtual switch is implicitly created. You can create virtual interfaces for your VMs with respective VIDs. – the-wabbit Mar 31 '12 at 6:44
Sorry - It has been a while since I've worked with Hyper-V. I needed to review how it handles networking. If my understanding is correct there is an implicit Virtual Switch that exists between my virtual interface eth1.198 on the guest operating system and the HP5406 where vlan 198 is tagged and it is not passing the VLAN 198 tagged traffic, but it is passing the untagged VLAN 98 packets. – kce Apr 2 '12 at 19:57

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.