Category Archives: Networking

ExpressRoute Providers in Southern California

If you work in Southern California, you may be interested in finding out which telecommunications providers have connectivity into Microsoft Data Centers such as Azure and Office 365.

The list below ranks providers based on their proximity to Southern California. For the full list of locations and providers, scroll down.

image

Note: This is not an endorsement for any particular provider, but just a list of those who have local connections near Los Angeles.

Need help with your next Office 365 Project? We can help you deploy any or all of the 21 features Included in Office 365 for a flat rate per month.  Contact us at [email protected].

The full list of providers is located here: https://azure.microsoft.com/en-us/documentation/articles/expressroute-locations/

802.1x Wireless Authentication differences in Windows 7 and Windows

Leave a reply

Rolling out WPA2/Enterprise and all Windows 8 clients could connect fine but Windows 7 clients could not connect. Client side errors in event viewer logged Event 8002 (Reason Code 16)  “authentication failed due to a user credentials mismatch” and on the Windows NPS Server Event 6273 “Authentication failed due to a user credentials mismatch.”

Both errors are bogus because the username and password are correct.

Client computers can be configured to validate server certificates by using the Validate server certificate option on the client computer or in Group Policy. If this box is unchecked, then Windows 8 clients honor that and they will not inspect the NPS server’s certificate. However, Windows 7 clients are either more strict or there is a bug because they will not authenticate if the subject name field is blank in the NPS server’s certificate, even if this check box is unchecked.

The fix was to roll out the RAS and IAS Server template in Certificate Authority per this technet article: http://technet.microsoft.com/en-us/library/cc754198.aspx 

This is because other certificate templates might get deployed that use Server authentication in the EKU which makes it seem like the cert should work fine for NPS but the problem is they may lack a value in the subject name field of the certificate. This is what generates the bogus errors about username and password mismatch. It would have been nice if the errors had said “hey, the SSL cert on your server is missing a subject name. go fix that!”

A few helpful netsh commands to troubleshoot wireless:

netsh wlan show profiles

netsh wlan show profile <profile name>

netwsh wlan set tracing mode=yes   (try to reproduce the issue then issue the same statement with =no)  This will create a .CAB file with tons of good information, especially the report.html file inside the .CAB file

Network Load Balancing: Multicast vs Unicast

Leave a reply

Windows Network Load Balancing (NLB) is a pretty popular (free!) solution for quickly setting up load balancers.

You must chose either Unicast or Multicast operational mode.

Unicast – Each NLB cluster node replaces its real (hard coded) MAC address with a new one (generated by the NLB software) and each node in the NLB cluster uses the same (virtual) MAC. Because of this virtual MAC being used by multiple computers, a switch is not able to learn the port for the virtual NLB cluster MAC and is forced to send the packets destined for the NLB MAC to all ports of a switch to make sure packets get to the right destination
Multicast – NLB adds a layer 2 MAC address to the NIC of each node. Each NLB cluster node basically has two MAC addresses, its real one and its NLB generated address. With multicast, you can create static entries in the switch so that it sends the packets only to members of the NLB cluster. Mapping the address to the ports being used by the NLB cluster stops all ports from being flooded. Only the mapped ports will receive the packets for the NLB cluster instead of all ports in the switch. If you don’t create the static entries, it will cause switch flooding just like in unicast.

So which one should you chose? And why?

In general, you should enable and use multicast NLB whenever possible. Use unicast mode only if your network equipment—switches and routers—don’t support multicast or if they experience significant performance issues when multicast is enabled.

Other considerations

If you don’t have administrative access to modify the configuration of the switches and routers in your environment then you may be forced to use Unicast. You might also be forced to use Unicast if your routers do not support mapping a unicast IP to a multicast MAC address.
A second network adapter is required to provide peer-to-peer communication between cluster hosts in Unicast mode. A side effect of Unicast mode is “switch flooding;” network traffic is simultaneously delivered to all cluster hosts. 

If you only have a single NIC, then it is recommended to use Multicast, but you will need to plan on adding a static ARP entry into the switches and routers on your LAN because most do not support multicast by default. This is easy to do in a small environment, but in a large routed environment, with multiple “side-car” routers then you would need to add an entry to each “side-car” router.
For example, on each Cisco router that has a “leg” into the LAN where the NLB cluster resides, enter configuration mode and enter these commands:

arp [ip] [cluster multicast mac*] ARPA
arp 192.168.1.100 03bf.c0a8.0164 ARPA
*the cluster’s multicast MAC address can be obtained from the Network Load Balancing Properties dialog box

By using the multicast method with Internet Group Membership Protocol (IGMP), you can limit switch flooding, if the switch supports IGMP snooping. IGMP snooping allows the switch to examine the contents of multicast packets and associate a port with a multicast address. Without IGMP snooping, switches might require additional configuration to tell the switch which ports to use for the multicast traffic. Otherwise, switch flooding occurs, as with the unicast method. Here are the commands to tell the switch which ports to use for multicast traffic:

mac-address-table static [cluster multicast mac] [vlan id] [interface]
mac-address-table static 03bf.c0a8.0164 vlan 1 interface GigabitEthernet1/1 GigabitEthernet1/2

[Update 2/16/2013]

Note: the highlighted section above is fantastic when your environment is fairly static, however, if your NLB hosts are virtual machines, and if those virtual machines reside in an NLB cluster, then the above hardcoded configuration will prevent the NLB nodes from converging when the virtual machines are migrated to other hypervisors in the cluster. This is because the other hypervisor nodes are connected to the switch via separate ports than those hardcoded above. And you can’t hardcode all the hypervisor nodes in advance because the VM’s don’t reside on all nodes at the same time. Therefore, I recommend avoiding using the mac-address-table command and relying only on the arp command.

References

http://technet.microsoft.com/en-us/library/bb742455.aspx

http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1006525