Windows 7 VLANs

[Circuitsoft]

I'm wondering if there's a way to connect a Windows 7 machine to multiple VLANs on a trunk port. Here's why.

At my company, we oftentimes develop network-based devices, and sometimes the devices need to talk to each other despite being on different people's desks. If we had VLANs available for developer use, then I could bridge a non-default VLAN to a second ethernet card on the PC, and use that as the network for the device I'm developing. As a side-benefit, I could attach Wireshark to that device.

Does that make sense, or is there a different way I should be doing this?

 

[yinan]

Server quality cards allow you to install software that allows you to do this.

 

[imagoon]

Sounds like to me you guys need a second network drop that is the dev network. Using windows 7 to trunk and then bridge ports randomly is a recipe for network loops that can take down the local segment.

Add in further that Windows without a lot specialized config has issues being multiholmed I wouldn't expect it to work well.

 

[Circuitsoft]

Can you define "server quality card?" I've used VLANs under Linux, but the Windows support for multiple VLANs seems to require vendor software, and I can't tell from product specs whether it's included.

For example, the Intel PWLA8391GT PRO/1000 GT ethernet card says it supports VLAN tag insertion and stripping for up to 4096 VLAN tags. That doesn't mean it comes with software to support this ability under Windows, but maybe it does.

 

[Circuitsoft]

Sounds like to me you guys need a second network drop that is the dev network. Using windows 7 to trunk and then bridge ports randomly is a recipe for network loops that can take down the local segment.

Hopefully, by having the second port on the bridge limited to one developer's desk, we won't have network loops to worry about.

Add in further that Windows without a lot specialized config has issues being multiholmed I wouldn't expect it to work well.

The proper config for this would remove TCP/IP support from the second interface and the bridge that contains it, so hopefully Windows would mostly ignore that interface except for the bridge.

 

[imagoon]

Hopefully, by having the second port on the bridge limited to one developer's desk, we won't have network loops to worry about.

The proper config for this would remove TCP/IP support from the second interface and the bridge that contains it, so hopefully Windows would mostly ignore that interface except for the bridge.

That is not how it works. When you start bridging, you can end up with loops in the VLAN itself.

While removing TCP/IP from the second NIC could work, the proper way is to use a monitoring port on a switch. You could do that with out having a second nic in the PC. I am not quite sure how windows will handle network bridging with protocols disabled. I have never tried it.

 

[Circuitsoft]

That is not how it works. When you start bridging, you can end up with loops in the VLAN itself.

That seems like a serious problem with Windows implementation of bridging. Am I just misunderstanding something, or don't software bridges usually support STP?

While removing TCP/IP from the second NIC could work, the proper way is to use a monitoring port on a switch. You could do that with out having a second nic in the PC. I am not quite sure how windows will handle network bridging with protocols disabled. I have never tried it.

Since network bridging is an L2-switch in software, Windows shouldn't care that no protocols are enabled.

 

[imagoon]

That seems like a serious problem with Windows implementation of bridging. Am I just misunderstanding something, or don't software bridges usually support STP?


Since network bridging is an L2-switch in software, Windows shouldn't care that no protocols are enabled.

Windows 7 doesn't implement STP. Most switch gear doesn't support spanning tree until you get up to SMB level and have management interfaces. Ie the $50 linksys box is dumb out of the box. Windows bridging is (supposed to be) the same as throwing a patch cable between the 2 ports. And yes while a bridge is a layer 2 device, there is nothing that really says that the software bridge Windows offers is actually that.

 

[theevilsharpie]

Does that make sense, or is there a different way I should be doing this?

I'm not really following your description, so I won't comment on whether it makes sense.

With regards to VLANs on Windows, Windows relies on driver manufacturers to implement VLAN support. Every modern NIC vendor that I'm aware of has such a utility, although some are definitely better than others.

 

[Circuitsoft]

Windows 7 doesn't implement STP. Most switch gear doesn't support spanning tree until you get up to SMB level and have management interfaces. Ie the $50 linksys box is dumb out of the box. Windows bridging is (supposed to be) the same as throwing a patch cable between the 2 ports. And yes while a bridge is a layer 2 device, there is nothing that really says that the software bridge Windows offers is actually that.

We have some sort of Cisco managed switch - this office totals >150 ports. I'm not in IT, but I'm trying to figure out exactly what to ask IT for. Maybe STP isn't what I'm looking for, though? Actually, I think I'm just thinking of usual switch operation, where frames are routed according to a table that's filled by what port gets traffic for what SMAC.

With regards to VLANs on Windows, Windows relies on driver manufacturers to implement VLAN support. Every modern NIC vendor that I'm aware of has such a utility, although some are definitely better than others.

Looking at Intel NICs, I'm not seeing any "Tools/Utilities" downloads for any Windows 7 or 2008 system. Would this utility be included in the "Driver" download, and will it make multiple virtual interfaces like I expect to see in Linux?

 

[theevilsharpie]

What Intel NIC do you have?

 

[imagoon]

We have some sort of Cisco managed switch - this office totals >150 ports. I'm not in IT, but I'm trying to figure out exactly what to ask IT for. Maybe STP isn't what I'm looking for, though? Actually, I think I'm just thinking of usual switch operation, where frames are routed according to a table that's filled by what port gets traffic for what SMAC.


Looking at Intel NICs, I'm not seeing any "Tools/Utilities" downloads for any Windows 7 or 2008 system. Would this utility be included in the "Driver" download, and will it make multiple virtual interfaces like I expect to see in Linux?

Intel you need the Proset drivers. As long as your chip is listed as supported, that tool can configure it.

At L2 frames are not routed. The MAC table is used in unicast frames so frames only go out the port they need to. They do get flooded though after the table times out. The floods can get looped around over and over again as well as any multicast frames. These loops eventually utilized 100% of the network until the loop is broken.

 

[Circuitsoft]

What Intel NIC do you have?

I don't, yet. Looking to see what to (maybe) buy for workstations.

Intel you need the Proset drivers. As long as your chip is listed as supported, that tool can configure it.

Onboard NIC in standard workstation is 82579LM fed by "Intel 6 Series/C200 Series Chipset". If a separate card is needed, that's worth looking into.

At L2 frames are not routed. The MAC table is used in unicast frames so frames only go out the port they need to. They do get flooded though after the table times out. The floods can get looped around over and over again as well as any multicast frames. These loops eventually utilized 100% of the network until the loop is broken.

I'm not aware of any uses of Multicast on our network, and if there were, I really doubt devices we work on would need them, but stranger things have happened. As for unicast loops, what do you mean about the table timing out? Like, if it never receives any frames from a MAC that is now a destination on a frame so it doesn't know what port to send it to? Wouldn't those just broadcast to all the ports? Either way, a switch shouldn't send a frame back out a port it just came in though, so I don't quite see how a loop could happen. Maybe I'm just expecting software bridges (802.1q?) to be smarter than they are.

 

[imagoon]

I don't, yet. Looking to see what to (maybe) buy for workstations.



Onboard NIC in standard workstation is 82579LM fed by "Intel 6 Series/C200 Series Chipset". If a separate card is needed, that's worth looking into.


I'm not aware of any uses of Multicast on our network, and if there were, I really doubt devices we work on would need them, but stranger things have happened. As for unicast loops, what do you mean about the table timing out? Like, if it never receives any frames from a MAC that is now a destination on a frame so it doesn't know what port to send it to? Wouldn't those just broadcast to all the ports? Either way, a switch shouldn't send a frame back out a port it just came in though, so I don't quite see how a loop could happen. Maybe I'm just expecting software bridges (802.1q?) to be smarter than they are.

You network cannot exist without multicast (I really meant broadcast here even though it is the same basic tech at layer 2). Switches only keep MAC addresses in the table for a certain amount of time before they drop (ie not see frames from that mac on that port) after that the frame will get flooded out all ports that the frame didn't arrive on. If there is any place in the network where that frame can loop back and land at the switch, it will keep being flooded until the segment collapses.

Bridges are rarely 802.1q aware. They are very stupid devices and not used anymore. The software ones are just as stupid and typically just spit out whatever arrives on one side to the other. So if this bridge decides to start bridging both VLANs on to the second NIC that you have the test device attached to you will see frame leakage and the like. Also if one guy decided to bridge it wrong, there may not be and issue until user #2 makes a mistake and you end up with 2 bridges on that network forming the loop for example.

I am not saying you can't make it work, I am more concerned about putting network config like this in that hands of developers who likely have varying understandings of the mess the could potentially cause. I know as an IT guy I wouldn't even consider exporting 802.1q frames out to a workstation like that.

 

[Lemieux66]

If you have 2 drops at each desk just made make them different vlans and install a second nic in the workstations assuming that you can bind your software to use the desired interface.

If the problem is that you only have 1 drop at each desk then you could make that a trunk port and install a small managed switch at the desk.

I personally wouldn't want a trunk port going to a switch that isn't physically secured, and if that's the opinion of your IT department then they would be much happier to pay to have another drop run.

 

[thatchrisp]

I found this thread whilst looking for information on Windows 7 and VLAN tagging support. imagoon, who is obviously trying to be very helpful, is off on quite a few routing/switching comments, so I am going to clarify and correct.

You network cannot exist without multicast (I really meant broadcast here even though it is the same basic tech at layer 2). Switches only keep MAC addresses in the table for a certain amount of time before they drop (ie not see frames from that mac on that port) after that the frame will get flooded out all ports that the frame didn't arrive on. If there is any place in the network where that frame can loop back and land at the switch, it will keep being flooded until the segment collapses.

Your network absolutely can exist without multicast. It is completely different. It uses a one-to-many method. Only IPv4 networks require broadcast, which is a one-to-all method used for building ARP tables, which are used for delivering packets within a broadcast domain. IPv6 does not use broadcast.

Switches don't have "MAC" tables. They have ARP tables, in which an IP address is mapped to a MAC address. Much like a cookie in a browser, the entry in the ARP table refreshes as long as you keep the session active. ARP entries do time out, but only after some inactivity.

sw1#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.0.254.246 6 10bf.48bc.10ea ARPA Vlan254
Internet 10.0.254.241 0 001d.92dd.c610 ARPA Vlan254
Internet 10.0.254.226 145 0090.a99f.768c ARPA Vlan254

If there is no IP -> MAC entry, no "frames" go to all ports. An ARP request is then broadcast and, if there is an ARP reply, a new entry is put into the ARP table. Packets containing actual data (headers and payload) only make their way to every port if you are using a hub.

Bridges are rarely 802.1q aware. They are very stupid devices and not used anymore. The software ones are just as stupid and typically just spit out whatever arrives on one side to the other. So if this bridge decides to start bridging both VLANs on to the second NIC that you have the test device attached to you will see frame leakage and the like. Also if one guy decided to bridge it wrong, there may not be and issue until user #2 makes a mistake and you end up with 2 bridges on that network forming the loop for example.

You're confusing a hub for a bridge. Hubs are indeed "dumb" and seldom used anymore. A bridge is entirely different. A bridge is taking a router port (not a switch) and bridging two broadcast domains, in order to create one. In order to do this, you need a router and it has to be managed in order to configure it as a bridge port, or simplified, you are turning a router port into a switch port.

I am not saying you can't make it work, I am more concerned about putting network config like this in that hands of developers who likely have varying understandings of the mess the could potentially cause. I know as an IT guy I wouldn't even consider exporting 802.1q frames out to a workstation like that.

I disagree. VLAN tagging is an excellent way to minimize network cabling and simplify network management. I have three tagged VLANs on my FreeBSD workstation and I've never had an issue; it only increases topology efficiency and security.

If you are worried about this being above someone's pay grade, then perhaps hiring a network engineering consultant for a day or two is something you should consider.

 

[theevilsharpie]

Switches don't have "MAC" tables. They have ARP tables, in which an IP address is mapped to a MAC address. Much like a cookie in a browser, the entry in the ARP table refreshes as long as you keep the session active. ARP entries do time out, but only after some inactivity.

sw1#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.0.254.246 6 10bf.48bc.10ea ARPA Vlan254
Internet 10.0.254.241 0 001d.92dd.c610 ARPA Vlan254
Internet 10.0.254.226 145 0090.a99f.768c ARPA Vlan254

If there is no IP -> MAC entry, no "frames" go to all ports. An ARP request is then broadcast and, if there is an ARP reply, a new entry is put into the ARP table. Packets containing actual data (headers and payload) only make their way to every port if you are using a hub.

This is completely incorrect. Ethernet switches make "switching" decisions based on Ethernet MAC address. It does not use an IP address or anything else involved in the TCP/IP suite, including ARP.

(Before someone mentions Layer 3 switches, routing decisions rely on IP, but the actual "switching" of frames from one port to another relies on the switch's MAC address table.)

A switch maintains an ARP cache for the same reason any other IP host does: so IPv4 communication between the switch and another host doesn't have to repeatedly discover the MAC address for each new flow.

You're confusing a hub for a bridge. Hubs are indeed "dumb" and seldom used anymore. A bridge is entirely different. A bridge is taking a router port (not a switch) and bridging two broadcast domains, in order to create one. In order to do this, you need a router and it has to be managed in order to configure it as a bridge port, or simplified, you are turning a router port into a switch port.

Lulz.

 

[imagoon]

I found this thread whilst looking for information on Windows 7 and VLAN tagging support. imagoon, who is obviously trying to be very helpful, is off on quite a few routing/switching comments, so I am going to clarify and correct.



Your network absolutely can exist without multicast. It is completely different. It uses a one-to-many method. Only IPv4 networks require broadcast, which is a one-to-all method used for building ARP tables, which are used for delivering packets within a broadcast domain. IPv6 does not use broadcast.

Switches don't have "MAC" tables. They have ARP tables, in which an IP address is mapped to a MAC address. Much like a cookie in a browser, the entry in the ARP table refreshes as long as you keep the session active. ARP entries do time out, but only after some inactivity.

sw1#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.0.254.246 6 10bf.48bc.10ea ARPA Vlan254
Internet 10.0.254.241 0 001d.92dd.c610 ARPA Vlan254
Internet 10.0.254.226 145 0090.a99f.768c ARPA Vlan254

If there is no IP -> MAC entry, no "frames" go to all ports. An ARP request is then broadcast and, if there is an ARP reply, a new entry is put into the ARP table. Packets containing actual data (headers and payload) only make their way to every port if you are using a hub.



You're confusing a hub for a bridge. Hubs are indeed "dumb" and seldom used anymore. A bridge is entirely different. A bridge is taking a router port (not a switch) and bridging two broadcast domains, in order to create one. In order to do this, you need a router and it has to be managed in order to configure it as a bridge port, or simplified, you are turning a router port into a switch port.



I disagree. VLAN tagging is an excellent way to minimize network cabling and simplify network management. I have three tagged VLANs on my FreeBSD workstation and I've never had an issue; it only increases topology efficiency and security.

If you are worried about this being above someone's pay grade, then perhaps hiring a network engineering consultant for a day or two is something you should consider.

theevilsharpie has this pretty well summed up but you are quite incorrect in lot of your comments.

#1 Ethernet switches entirely switch via the MAC address. ARP is a protocol for matching IP to the MAC addresses. Using your example:

Internet 10.0.254.246 6 [b]10bf.48bc.10ea[/b] ARPA Vlan254
Internet 10.0.254.241 0 [b]001d.92dd.c610[/b] ARPA Vlan254
Internet 10.0.254.226 145 [b]0090.a99f.768c[/b] ARPA Vlan254

These are the MAC addresses stored in the ARP table. The difference is that at layer 2, IP isn't even considered. These could be "cookie monster 2.0" frames for all the switch cares, it will just a) dump the frame to the port that has that MAC address or b) broadcast it out on all ports except the port the frame was received.

To demonstrate here is a random Cisco 3560:

INE-SW1#show mac address-table ?
  address       Address to lookup in the table
  aging-time    MAC address table aging parameters
  count         Number of MAC addresses in the table
  dynamic       List dynamic MAC addresses
  interface     List MAC adresses on a specific interface
  learning      Display learning on VLAN or interface
  move          MAC Move information
  multicast     List multicast MAC addresses
  notification  MAC notification parameters and history table
  secure        List secure MAC addresses
  static        List static MAC addresses
  vlan          List MAC addresses on a specific vlan

As you can see, the switch is quite aware what the difference between a MAC address table and ARP table is. Quite honestly, for a managed layer 2 switch, the ARP table is only used for it's own management system in most cases since the switch has minimal to no need to be layer 3 aware.

I am not confusing a bridge for a hub. A hardware bridge is a segment repeater. It is generally dumb and just filters any and all packets sent to it to all other ports based on MAC address tables. Bridges were the first "network switches." The bridge technology morphed in the switch tech we have to day.

What you are confusing is a) a router b) a 802.1q trunk c) "router on a stick"

As for using VLANs for "VLAN tagging is an excellent way to minimize network cabling and simplify network management. I have three tagged VLANs on my FreeBSD workstation and I've never had an issue; it only increases topology efficiency and security.

Minimize network cabling: yes that is the point of 801.1q trunk ports
Simplify network management: hardly. Bringing 802.1q tagging out to the desktop now requires the machines to be configured to even connect. DHCP and the like go out the window. You can try to set ports to Negotiate but that is hit or miss.
Security: VLANs (to a desktop port) has no inherent security. It is elementary to frame hop on an exposed 802.1q port. It takes one setting in the network card driver.

I guess what I really should be asking is "why would some random person come here and post once on a 4 month old post?"