Microsoft Windows Vista Community Forums - Vistaheads
Recommended Download



Welcome to the Microsoft Windows Vista Community Forums - Vistaheads, YOUR Largest Resource for Windows Vista related information.

You are currently viewing our boards as a guest which gives you limited access to view most discussions and access our other features. By joining our free community you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content and access many other special features. Registration is fast, simple and absolutely free so , join our community today!

If you have any problems with the registration process or your account login, please contact us.

Driver Scanner

CIDR

microsoft.public.windowsupdate






Speedup My PC
Reply
  #1 (permalink)  
Old 05-08-2009
oextreme
 

Posts: n/a
CIDR
I am looking for the CIDR of the addresses needed for WSUS to work. Currently
I have my main WSUS01 server set to full internet access. I want to have a
rule on my firewall that will allow access to only the IP address needed for
WSUS. I want to segment the bandwidth off one internet connection and have it
pull from a second internet connection. If the WSUS sites are not part of a
CIDR then I would accept the CIDR for Microsoft.com. I also plan to do this
with Symantec Endpoint Protection if anyone knows the CIDR for them.

Below are the needed URLs
http://windowsupdate.microsoft.com
http://*.windowsupdate.microsoft.com
https://*.windowsupdate.microsoft.com
http://*.update.microsoft.com
https://*.update.microsoft.com
http://*.windowsupdate.com
http://download.windowsupdate.com
http://download.microsoft.com
http://*.download.windowsupdate.com
http://wustat.windows.com
http://ntservicepack.microsoft.com

Reply With Quote
Sponsored Links
  #2 (permalink)  
Old 05-08-2009
MowGreen
 

Posts: n/a
Re: CIDR
Cross posted to the WSUS NG for poster's convenience.

You'd be better served posting WSUS issues/concersn to a WSUS newsgroup.
The Windows Update NG deals with client issues.
BTW, the IP addresses of the update servers change constantly, for
obvious reasons.

WSUS General
http://www.microsoft.com/communities... date_services


MowGreen
===============
*-343-* FDNY
Never Forgotten
===============


oextreme wrote:

> I am looking for the CIDR of the addresses needed for WSUS to work. Currently
> I have my main WSUS01 server set to full internet access. I want to have a
> rule on my firewall that will allow access to only the IP address needed for
> WSUS. I want to segment the bandwidth off one internet connection and have it
> pull from a second internet connection. If the WSUS sites are not part of a
> CIDR then I would accept the CIDR for Microsoft.com. I also plan to do this
> with Symantec Endpoint Protection if anyone knows the CIDR for them.
>
> Below are the needed URLs
> http://windowsupdate.microsoft.com
> http://*.windowsupdate.microsoft.com
> https://*.windowsupdate.microsoft.com
> http://*.update.microsoft.com
> https://*.update.microsoft.com
> http://*.windowsupdate.com
> http://download.windowsupdate.com
> http://download.microsoft.com
> http://*.download.windowsupdate.com
> http://wustat.windows.com
> http://ntservicepack.microsoft.com
>

Reply With Quote
  #3 (permalink)  
Old 05-08-2009
Lawrence Garvin [MVP]
 

Posts: n/a
Re: CIDR
> oextreme wrote:
>
>> I am looking for the CIDR of the addresses needed for WSUS to work.


My first impression is that we have a disconnect caused by a
misunderstanding of the term 'CIDR'.

CIRD = "Classless Inter-Domain Routing" and is the description of a
*methodology* for allocating IP Addresses more efficiently than the original
"Class" based methodologies.

http://en.wikipedia.org/wiki/Classle...Domain_Routing

>> Currently I have my main WSUS01 server set to full internet access. I
>> want to
>> have a rule on my firewall that will allow access to only the IP address
>> needed for WSUS.


This should have been your first sentence. It describes ever so much better
what you're trying to do. However, as Robear has already pointed out quite
accurately -- no such list exists, nor is any such list likely to be
accurate for any period of time. IP Addresses change -- that's why the
Domain Name Service exists; and that's why the hostnames and domain names of
the services that WSUS needs are listed in the documentation -- that's the
part that won't change.


>> I want to segment the bandwidth off one internet connection and have it
>> pull from a second internet connection. If the WSUS sites are not part of
>> a CIDR then I would accept the CIDR for Microsoft.com.


Although, here, I'm starting to see why you might be thinking in terms of
CIDR, but you're still beyond the scope of the term. Let's just make it
simple and call them IP Networks or IP Subnetworks. In fact, we really don't
know if Microsoft, or their hosting vendor (which is a more appropriate
consideration), has implemented CIDR on those resources -- it's more likely
in a large datacenter that they have not. CIDR was created to allow =ISPs=
to more efficiently manage routing tables from multiple downstream clients
using small subnets, and to allow the Internet backbone to more efficiently
manage routing tables from multiple ISPs. It's a rare scenario indeed where
an end-user has implemented any features defined in CIDR.


Now, back to the real question: The fact is that the IP Network that WSUS
traffic is routed to is entirely REGIONAL -- based on the query responses
from DNS lookups on the specific destination hostnames
(update.microsoft.com; download.microsoft.com).

>> Below are the needed URLs
>> http://windowsupdate.microsoft.com http://*.windowsupdate.microsoft.com
>> https://*.windowsupdate.microsoft.com http://*.update.microsoft.com
>> https://*.update.microsoft.com http://*.windowsupdate.com
>> http://download.windowsupdate.com
>> http://download.microsoft.com http://*.download.windowsupdate.com
>> http://wustat.windows.com http://ntservicepack.microsoft.com


Many of the above URLs are still contained in the documentation, but are
functionally dead. That's the good news.

The closest thing to a solution to your stated objective is to execute
appropriate and sufficient queries against the Domain Name Service to
determine what your regional IP Networks are that support the current
functionality. The primary "hostnames" are update.microsoft.com and
download.microsoft.com -- but those are identifiers for multi-server
load-balanced environments, thus the requirement to also configure the
firewall to support ANY machine contained within the update.microsoft.com
and download.microsoft.com domains -- as well as the variations that also
may exist in the domain windowsupdate.com.

Simple fact is, you can determine that list of IP Addreses today -- but if
you enumerate it in your firewall, tomorrow something may try to hit a new
machine in that domain and fail because it's on a new IP network.

Furthermore, Microsoft is not the only customer of the vendor who actually
provides these hosted environments, so you'll not only be routing WSUS/WU/MU
traffic, but also traffic for any other vendor who hosts their download
services at nsatc.net, et.al.

In addition, merely configuring rules in your firewall won't be sufficient.
You'll also need to tell each and every machine in your network which
firewall to route traffic to, depending on destination subnet(s). You'll
also need to maintain that routing table, and have some methodology for
distributing it on a regular basis -- this might involve enabling a routing
protocol to distribute/update those route table entries as they get changed.

Simply stated == while I believe I understand what you're trying to do ==
it's not practical to try to implement it.

Not to mention that the actual volume of traffic that will come down that
pipeline is a miniscule percentage of the total traffic that will pass
through your pipe. Frankly, I'm not even sure the expense of a second
firewall or second connection is justified by this plan.

Perhaps we should back up and discuss the *PROBLEM* that you are trying to
solve, and discuss appropriate solutions to that problem, rather than
discussing one solution (to an unidentified problem), which will only create
more problems.


--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

Reply With Quote
  #4 (permalink)  
Old 05-08-2009
oextreme
 

Posts: n/a
Re: CIDR
The ultimate goal to the reduce bandwidth for WSUS on our T1 VPN link to out
headquarters. We have 7 sites each with about 10 computers. There is a WSUS
server in the HQ that manages all the client pc’s I do not want to have
servers in the remote sites.

The remote sites are all linked with an ATT MPLS T1 to HQ and a local ISP
with internet server greater that 5mb. The local ISP is used for backup
incase the T1 drops. We have routing capable to directing traffic between the
WAN connection based on type and destination. The HQ has DS3 to the internet

I thought about having a down stream server that would still be hosted at
the HQ but instead of having the updates stored local have them pulled from
the internet but since the clients default route is to the HQ and then to the
internet the bandwidth would still be placed on the T1 connection.

That is why I thought having a rule that says if going to the windows
updates sites use the faster ISP route and not the T1.


"Lawrence Garvin [MVP]" wrote:

> > oextreme wrote:
> >
> >> I am looking for the CIDR of the addresses needed for WSUS to work.

>
> My first impression is that we have a disconnect caused by a
> misunderstanding of the term 'CIDR'.
>
> CIRD = "Classless Inter-Domain Routing" and is the description of a
> *methodology* for allocating IP Addresses more efficiently than the original
> "Class" based methodologies.
>
> http://en.wikipedia.org/wiki/Classle...Domain_Routing
>
> >> Currently I have my main WSUS01 server set to full internet access. I
> >> want to
> >> have a rule on my firewall that will allow access to only the IP address
> >> needed for WSUS.

>
> This should have been your first sentence. It describes ever so much better
> what you're trying to do. However, as Robear has already pointed out quite
> accurately -- no such list exists, nor is any such list likely to be
> accurate for any period of time. IP Addresses change -- that's why the
> Domain Name Service exists; and that's why the hostnames and domain names of
> the services that WSUS needs are listed in the documentation -- that's the
> part that won't change.
>
>
> >> I want to segment the bandwidth off one internet connection and have it
> >> pull from a second internet connection. If the WSUS sites are not part of
> >> a CIDR then I would accept the CIDR for Microsoft.com.

>
> Although, here, I'm starting to see why you might be thinking in terms of
> CIDR, but you're still beyond the scope of the term. Let's just make it
> simple and call them IP Networks or IP Subnetworks. In fact, we really don't
> know if Microsoft, or their hosting vendor (which is a more appropriate
> consideration), has implemented CIDR on those resources -- it's more likely
> in a large datacenter that they have not. CIDR was created to allow =ISPs=
> to more efficiently manage routing tables from multiple downstream clients
> using small subnets, and to allow the Internet backbone to more efficiently
> manage routing tables from multiple ISPs. It's a rare scenario indeed where
> an end-user has implemented any features defined in CIDR.
>
>
> Now, back to the real question: The fact is that the IP Network that WSUS
> traffic is routed to is entirely REGIONAL -- based on the query responses
> from DNS lookups on the specific destination hostnames
> (update.microsoft.com; download.microsoft.com).
>
> >> Below are the needed URLs
> >> http://windowsupdate.microsoft.com http://*.windowsupdate.microsoft.com
> >> https://*.windowsupdate.microsoft.com http://*.update.microsoft.com
> >> https://*.update.microsoft.com http://*.windowsupdate.com
> >> http://download.windowsupdate.com
> >> http://download.microsoft.com http://*.download.windowsupdate.com
> >> http://wustat.windows.com http://ntservicepack.microsoft.com

>
> Many of the above URLs are still contained in the documentation, but are
> functionally dead. That's the good news.
>
> The closest thing to a solution to your stated objective is to execute
> appropriate and sufficient queries against the Domain Name Service to
> determine what your regional IP Networks are that support the current
> functionality. The primary "hostnames" are update.microsoft.com and
> download.microsoft.com -- but those are identifiers for multi-server
> load-balanced environments, thus the requirement to also configure the
> firewall to support ANY machine contained within the update.microsoft.com
> and download.microsoft.com domains -- as well as the variations that also
> may exist in the domain windowsupdate.com.
>
> Simple fact is, you can determine that list of IP Addreses today -- but if
> you enumerate it in your firewall, tomorrow something may try to hit a new
> machine in that domain and fail because it's on a new IP network.
>
> Furthermore, Microsoft is not the only customer of the vendor who actually
> provides these hosted environments, so you'll not only be routing WSUS/WU/MU
> traffic, but also traffic for any other vendor who hosts their download
> services at nsatc.net, et.al.
>
> In addition, merely configuring rules in your firewall won't be sufficient.
> You'll also need to tell each and every machine in your network which
> firewall to route traffic to, depending on destination subnet(s). You'll
> also need to maintain that routing table, and have some methodology for
> distributing it on a regular basis -- this might involve enabling a routing
> protocol to distribute/update those route table entries as they get changed.
>
> Simply stated == while I believe I understand what you're trying to do ==
> it's not practical to try to implement it.
>
> Not to mention that the actual volume of traffic that will come down that
> pipeline is a miniscule percentage of the total traffic that will pass
> through your pipe. Frankly, I'm not even sure the expense of a second
> firewall or second connection is justified by this plan.
>
> Perhaps we should back up and discuss the *PROBLEM* that you are trying to
> solve, and discuss appropriate solutions to that problem, rather than
> discussing one solution (to an unidentified problem), which will only create
> more problems.
>
>
> --
> Lawrence Garvin, M.S., MCITP:EA, MCDBA
> Principal/CTO, Onsite Technology Solutions, Houston, Texas
> Microsoft MVP - Software Distribution (2005-2009)
>
> MS WSUS Website: http://www.microsoft.com/wsus
> My Websites: http://www.onsitechsolutions.com;
> http://wsusinfo.onsitechsolutions.com
> My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin
>
>

Reply With Quote
  #5 (permalink)  
Old 05-09-2009
Lawrence Garvin [MVP]
 

Posts: n/a
Re: CIDR
"oextreme" <oextreme@discussions.microsoft.com> wrote in message
news:A6727837-39A7-4839-8F80-E3B4545B6569@microsoft.com...
> The ultimate goal to the reduce bandwidth for WSUS on our T1 VPN link to
> out
> headquarters. We have 7 sites each with about 10 computers. There is a
> WSUS
> server in the HQ that manages all the client pc’s I do not want to have
> servers in the remote sites.


Okay, Fair enough. I would generally recommend against deploying remote
servers in the described scenario.


> The remote sites are all linked with an ATT MPLS T1 to HQ


More than sufficient bandwidth to support 10 clients per remote site.

> and a local ISP with internet server greater that 5mb.


Still more than sufficient bandwidth to support 10 clients per remote site.

> The HQ has DS3 to the internet


More than sufficient bandwidth to support a single WSUS Server
installation -- many organizations are supporting a WSUS Server deployment
on < T-1 bandwidth availability!


> That is why I thought having a rule that says if going to the windows
> updates sites use the faster ISP route and not the T1.


Ah... so you're trying to manage the *CLIENT* download source, not the
*SERVER* download source.

First, as noted above, the MPLS T-1 to your HQ site is more than sufficient
to support the download bandwidth requirements of the ten clients at each
site -- so, truly, I think you're overmanaging the situation. Empirical and
theoretical calculations of bandwidth requirements have shown that standard
update deployment requires about 5kb/sec of bandwidth per PC on a
connection -- this means that a site with 10 PCs needs about 50kb/sec of
bandwidth availability (on average) to support transfering update content
from a WSUS Server to the local PCs. If deploying service packs or other
multi-megabyte updates, a temporary increase to 10kb/sec is useful -- so
about 100kb/sec, worst case, per remote connection.

Since you already have 15x that 100kb/sec available on your standard
intra-organizational WAN connection -- bandwidth is the least of your
issues.

See, this is why discussing the *problem* is always better than discussing
how to implement a specific *solution*. To be brutally honest, IMNSHO,
you're overdesigning a complex solution to a non-existent problem.


--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/pro...awrence.Garvin

Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




All times are GMT +1. The time now is 13:16.




Driver Scanner - Free Scan Now

Vistaheads.com is part of the Heads Network. See also XPHeads.com , Win7Heads.com and Win8Heads.com.


Design by Vjacheslav Trushkin for phpBBStyles.com.
Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.6.0 RC 2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120