locked
MPLS Setup on Windows Servers RRS feed

  • Question

  • I have two office locations. They are only 4 buildings away from each other. They are connected together via T1 and MPLS thru Windstream and Cisco routers. Lucky for me, the T1's only have one router to go thru to make the MPLS link.

    The computers can ping each other, but I cannot browse the network. I cannot attach to a network resource thru the MPLS. I cannot attach to a network resource using the IP address. This has gone on for a week and no luck.

    The Ciscos were installed by Windstream. The Ciscos are NOT my equipment and I cannot access them to fix them. The Ciscos handle the VOIP phone system, internet and the MPLS. The remote location's phones are working thru the MPLS to the main site's phone system so all of the extensions are working.

    Both Servers are Windows 2003 Enterprise Servers with the latest service pack. They are not Domain Controllers. They do not run on a domain - they are on the same Workgroup. The network at the main location has been running for years this way. For what they require - general file storage and SOS healthcare software - this is all that they need. The Servers run minimal services to keep them safe and clean.

    I have installed at each location the same network hardware. The switch is a gigabit Netgear and is basically a dumb switch. The router is a Netgear WNDR3700 Wireless and Gigabit enabled. The Netgear Router at both locations is providing the DHCP for the workstations only. The Servers have manual IP address. I can remote into the routers at both locations and remote desktop into both servers. The router has a static route programmed for the MPLS port at both ends.

    Network information:

     

    Main Site:

    IP addressing: 192.168.1.X

    subnet: 255.255.255.0

    gateway: 192.168.1.1

    MPLS: 192.168.1.200

    router/gateway: 192.168.1.1 (the internet is manually entered and the DNS server is Windstream's)

     

    Remote Site:

    IP addressing: 192.168.2.X

    subnet: 255.255.255.0

    gateway: 192.168.2.1

    MPLS: 192.168.2.200

    router/gateway; 192.168.2.1 (the internet is manually entered and the DNS server is Windstream's)

     

    Now then... According to everything that I have read, the MPLS is suppose to be transparent. Windstream technical support (after 22 hours of trying to fix this) is basically ignoring me. They said that if you can ping from one system to the other and back again, then the MPLS is working and the rest is my problem... So now I am asking... Does anyone know what this problem is?? This is as simple a network as it can get. Do I have to setup RRAS between the two servers so that the browsing will work?? VPN??? To I have to make a static route table on the servers or in the routers??? Do I have to do the DHCP on the Servers and shut down the Netgear DHCP... This is absolutely ridiculous as I CAN remote desktop thru the Internet connection on the servers and on my mac, but I cannot browse the network not connect to a network resource thru the MPLS with an IP address... The browser says that it isn't there....

    To me, it smells like a packet data problem. The VOIP phones work and use a small packet size. Ping uses a small packet size...

    Windstream said that the MTU is set to 1540. The Netgear cannot go above 1500. I set the ethernet card in both Servers to Jumbo packet size...

     

    Any help is greatly appreciated. I have exhausted all other resources and have read all the data on Cisco's web site that I can get access too. I also found the manual from AT&T informing installation companies of this service on how to install it. Technet has not been a help.

    Cheers!!

    • Moved by Tim Quan Monday, September 27, 2010 8:05 AM (From:Setup Deployment)
    Sunday, September 26, 2010 12:27 AM

Answers

  • Oh, ok, the MPLS VPN. That's cool. :-)

    The NetGears are fine for DHCP for your scenario. If I remeber correctly, they have a spot to specify the WINS address for DHCP distribution.

    Ace


    Ace Fekay
    MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003, Microsoft Certified Trainer, Microsoft MVP - Directory Services.

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    • Marked as answer by Tim Quan Friday, October 8, 2010 6:52 AM
    Monday, September 27, 2010 3:46 PM

All replies

  • Interesting scenario.

    Based on the following:

    This is absolutely ridiculous as I CAN remote desktop thru the Internet connection on the servers and on my mac, but I cannot browse the network not connect to a network resource thru the MPLS with an IP address...

    You can ping. Good. That tells me that you do have network connectivity, which is allowing you to use Remote Desktop to connect to a machine on the other side of the connection.MPLS So that tells me too, that the MPLS is working.

    If you can use Remote Desktop by IP, and you cannot connect to a network resources using an IP address, it may be based on the workgroup security settings (such as NTLM or SMB signing settings) on a machine, depending on the operating system version. Some do not allow by IP, rather by name. But then again, I'm not sure what operating systems you're running. It could also be based on a third party firewall that's installed, such as McAfee or Norton that was installed when you purchased the machines.

    As far as the Browser service:

    [...] but I cannot browse the network [...] The browser says that it isn't there.... [...]

    This is because the browser service is based on NetBIOS broadcasts, but routers do not allow such broadcasts to go across subnets. To overcome this, I would suggest to install WINS on one of your servers on either side of the MPLS. Pick one of the servers. For example, if you install WINS on a server on the 192.168.1.0 side, let's say on a server with an IP address of 192.168.1.10, then set the IP address of the WINS server on ALL machines.

    WINS works in a similar fashion as DNS, except it's soley designed for the NetBIOS (or computer) name. WINS is a dynamic database of single label names (such as computer name, workgroup name, NetBIOS service locations, etc), which can be queried to resolve those names. DNS is a dynamic database for domain names with a minimal of two name levels, such as domain.com, whereas computer names are single label.

    Also, if configured properly, WINS works hand in hand with the Browser service instead of relying on broadcasts.

    With WINS, whenever you try to use the Browser service, such as when you click on Network Neighborhood, or browse for a machine using Start/Run, browse for a printer, of even when you try to connect or ping by the computer name, WINS will be queried for the name to IP address. It the browser service will assemble and enumerate a list of network resources from WINS.

    The way WINS works, you simply install it on a machine, and configure all machines to use it in their NIC properties (IP properties, Advanced, WINS tab). That's it. If using DHCP, such as using a router for DHCP (which I'm assuming what's going on here), you'll have to consult the router folks, in your case Windstream, to ask them to configure it so it will give the WINS address to your DHCP clients. If using a Windows DHCP server, you would add the following two DHCP Options:

    • To configure the WINS addresses in DHCP Scope or Server Options, add the following options:
      Option 044: <WINS Server IP Address>    This sets the IP address of the WINS server(s) to offer DHCP Clients
      Option 046: 0x8    This sets the NetBIOS Node Type

    The computers can ping each other, but I cannot browse the network. I cannot attach to a network resource thru the MPLS. I cannot attach to a network resource using the IP address. This has gone on for a week and no luck.

    If you can ping, once again, the connection is working. That's why Windstream believes everything's ok. It's up to you to provide name resolution support for your Windows infrastructure.

    As far as the MTU:

    Windstream said that the MTU is set to 1540. The Netgear cannot go above 1500. I set the ethernet card in both Servers to Jumbo packet size...

    This concerns me. Optimally, it should be 1500. To summarize, it's the TCP, or specifically the ethernet frame size. Based on Cisco, the Ethernet frame size is 1518, however for TCP, optimally set at 1500. Anything less will cause problems. Anything higher on a TCP network may get dropped. Setting it larger, such as using the Jumbo size, may cause problems, too. It's more of a vendor specific setting for devices that can handle it. I would suggest to set it back to default. Here's more info at Cisco's site regarding this (not sure if this is what you read at their site or not):

    Jumbo/Giant Frame Support on Catalyst Switches Configuration Example
    http://www.cisco.com/en/US/products/hw/switches/ps700/products_configuration_example09186a008010edab.shtml

     

    Summary:

    • I would suggest installing and configuring WINS to resolve the name resolution problem.
    • If using DHCP on a Windows server, set the options as I mentioned above.
    • If using the Cisco routers as a DHCP server, consult with Windstream to set the option for offering WINS addresses.
    • Set the MTU back to default.
    • If using a third party firewall such as Norton or McAfee on a machine, you may need to allow connectivity from the other subnet you're trying to connect from. This is something you would need to tweak. You can test it by disabling it first to see if it works, then go from there.

     

    ==================================================================
    Here's more info on the Browser service and WINS...

    Browser Service

    The Browser service is what's used by Network Neighborhood, as well as UNC mappings. Some folks will argue that AD supports this using DirectSMB (TCP 445), however many will also argue that they've found it doesn't perform as expected, however that's a discussion for another time, since this doesn't fall under the scope of our discussion.

    Many folks rely on browsing to browse for resources, browse for printers (if not using AD to look for published printers), including mapped drive UNC paths, etc. However the Browser service relies on NetBIOS, but NetBIOS broadcasts are blocked by routers (including VLAN configurations). Lack of NetBIOS support will also affect mapped drive paths in a login script, or manually created on a workstation, especially if the mapped drives were configured in the form of \\serverName\sharename, where the 'serverName' is a single name, hence either DirectSMB or NetBIOS kicks in (in that order with Windows 2000 and newer) to resolve it.

    To support this lost functionality across subnets, you will need WINS to support NetBIOS across multiple subnets. WINS is used as a defactor in environments to support NetBIOS broadcasts.

    How to setup WINS Servers:
    http://technet.microsoft.com/en-us/library/cc780091(WS.10).aspx

    ==================================================================

    I hope that helps.

     


    Ace Fekay
    MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003, Microsoft Certified Trainer, Microsoft MVP - Directory Services.

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    Monday, September 27, 2010 1:30 PM
  • Thanks for the help. I will get the WINS working this afternoon. Both computers are Windows 2003 Enterprise Server with the latest service packs.

    Windstream won't change the MTU from 1540... all of their routers run that packet size. That is because MPLS added 4 bytes to the packets (or more) when transferring the packets. I asked Windstream about the MTU size and the tech didn't think that it was the problem. 

    Windstream is suppost to be handling the DNS for the internal VPN IP address, but I don't see how unless I gave them the list....

    I'll install WINS... it seems like the easiest thing to try. I really don't feel like setting up DHCP and DNS and all that rot just to browse a network!

    Monday, September 27, 2010 1:51 PM
  • You are welcome.

    If the MPLS requires those MTU settings, then it doesn't appear to be a problem. I was concerned with the Jumbo settings you set. Did you set them back to default?

    If you are not running Active Directory, and just using DNS for internet resolution, I don't see a problem with using Windstream's DNS servers. Of course, if you decide to change and implement Active Directory, that is a whole new ball of wax and requires to only use internal DNS. But then again, that's a whole different discussion.

    With VPNs, and I'm assuming you mean client VPN and not a VPN between the locations, DNS won't be used, since it appears you're connecting to resources using NetBIOS (computer) names. In this case WINS will be your solution.

    Unfortunately, setting up DHCP to use WINS is required to insure the DHCP clients, and your VPN clients (assuming VPN clients as mentioned above) in order to allow all clients to successfully resolve internal names and allow you to connect to them using the internal names.

    Once again, you are welcome. Please do report back with how you're making out.

    Regards,
    Ace

     


    Ace Fekay
    MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003, Microsoft Certified Trainer, Microsoft MVP - Directory Services.

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    Monday, September 27, 2010 2:44 PM
  • By VPN, I meant the MPLS as it is considered a VPN by Windstream.... it is just really secured as it doesn't use the internet to create the VPN.

     

    The Netgears are doing the DHCP. I would like to keep it that way. It is easy and simple and if it fails, the customer can go buy a new one and upload the configuration file. If the server failed... ugh! 

     

    Cheers! 

    Rachel Baker

    MCSE+TCP and ISS

    Monday, September 27, 2010 3:09 PM
  • Oh, ok, the MPLS VPN. That's cool. :-)

    The NetGears are fine for DHCP for your scenario. If I remeber correctly, they have a spot to specify the WINS address for DHCP distribution.

    Ace


    Ace Fekay
    MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003, Microsoft Certified Trainer, Microsoft MVP - Directory Services.

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    • Marked as answer by Tim Quan Friday, October 8, 2010 6:52 AM
    Monday, September 27, 2010 3:46 PM