Re: Slashdot: Providers Ignoring DNS TTL?
On Sat, 23 Apr 2005, Christopher L. Morrow wrote: oh well, I tried to stay quiet :) Probably the PPLB problem isn't quite as simple as: "you have pplb you can't do anycast". I'd imagine that you have to have some substantial difference in the paths that the PPLB follows, yes? like links to differing ISP's or perhaps extremely diverse links inside the same ISP. Correct? For anybody who's confused by this thread, this is a quick explanation, after which I'm really hoping the thread will die: The "PPLB" Dean mentions is "per packet load balancing" in which you have two or more circuits, and packets to the same destination alternate which circuit they go down. In every case in which I've seen this used, it's been to combine multiple circuits taking the same path between the same pair of routers, to in effect create a bigger circuit. In theory, PPLB could also be used to split traffic between circuits going to different routers, perhaps even in different places. I've never seen anybody actually use the latter setup, and it seems to be universally regarded as something that would break things. I suppose it's possible that somebody's using it somewhere, probably with "interesting" results. It's the latter, theoretically possible, setup that Dean is talking about. Anycast is a technique in which two or more servers, generally in different locations, announce the same address space. Those sending traffic into a network via one POP or exchange point will have their traffic go to the server close to that entry point, while those sending traffic into a network via another POP or exchange point will have their traffic go to the server close to that point. To an outside network, it looks the same as regular peering -- you see the same route at each peering point and can hand off traffic. The only difference is that the packets may not have to travel as far once they enter the other network. So, just as a fun theoretical exercise, let's examine what happens in the PPLB to multiple locations scenario that Dean imagines: Let's say somebody is in the Midwest, and has T1s to Network A and network B. And let's say that their network administrator read on the NANOG list that per packet load balancing was the trendy thing to do, so they turn on per packet load balancing between the two T1s. Now they want to send some packets to a unicast host on network C, somewhere in California. They start with UDP DNS queries, each consisting of a single packet. Half go via network A, which peers with Network C in California. Responses come back with a 40 ms RTT. The other half go through network B, which has its closest peering point with Network C in Virginia. The packets go to Virginia and then to California, and the replies come back 80 ms later. Everything works fine. Then they try to set up a more persistent connection, and again half their packets are taking the 40 ms path while the others are taking the 80 ms path. Now things get interesting, because the packets are arriving out of order. Some applications may do ok with this, since they'll take the sequence numbers and reorder the packets, with some buffering and processing delay. But remember, the latency amounts here are numbers I just made up, and there's no reason why it couldn't be 40 ms vs. 1 second in some parts of the world. In either case, I suppose it's possible that you'd get an HTTP connection to sort of work, and an ssh session might just seem mildly painful. But good luck getting a VOIP call or anything of the sort to function over such a connection. Dean is correct that this setup would fall apart even further when anycast is thrown into the mix. In the anycast example, Network A hands off the packets to Network C in California, where they get sunk into a local server. Network B hands off the packets to Network C in Virginia, where they get sunk into a local server. Each server only sees half the packets, and half the retransmits, and is probably never going to get enough of the connection to put it all back together in a way that works. So, there are a couple of different conclusions that could be drawn from this. The conclusion I come to is that there are enough problems doing per packet load balancing on non-identical paths that nobody would actually do it. I'm made more comfortable in this conclusion by having been through this discussion several times without finding anybody who claims to actually do that sort of per packet load balancing. I, therefore, declare the PPLB thing to be a non-issue. It may also be valid to declare that PPLB over non-identical paths is important to allow people to use every last bit of bandwidth they're paying for, and that we shouldn't make their already painful predicament worse. But that's an argument I continue to be skeptical of.
Re: Slashdot: Providers Ignoring DNS TTL?
On Fri, Apr 22, 2005 at 11:55:23PM -0400, Dean Anderson wrote: > > On Wed, 20 Apr 2005, Patrick W. Gilmore wrote: > > > > > On Apr 20, 2005, at 3:29 PM, Dean Anderson wrote: > > > > >> Or don't. No one here cares if you do. Reality trumps lab tests. > > > > > > "Reality" for the last ten years has been that no one did either PPLB > > > or TCP DNS. That reality is changing. It'll probably start to change > > > faster, sooner. Then, users will start to notice the problems. > > > > People have been using TCP applications on anycast for at least a > > decade, as I mentioned before. Since DNS responses tend to be very > > short lived TCP session, it seems to me that if it works for other > > applications (e.g. HTTP), it should work for DNS. > > I don't know of any HTTP servers that do anycast. But their failure to > take account of PPLB doesn't change anything. IF they are anycasting under > false assumptions, they'll have problems, too. Remember that anycast configuration does not always require upper layer applications to specifically support "anycast featureset." It can be done in a setup similar to those currently being done with stateless/DNS, where it is dependent of how you want to route your packets to anycast listener address. Just make sure your routing between anycasting nodes and requesting node can actually deliver a clear picture, and it shouldn't be much of an issue for the majority :) -J -- James Jun Infrastructure and Technology Services TowardEX Technologies Office +1-617-459-4051 x179 | Mobile +1-978-394-2867 [EMAIL PROTECTED] | www.towardex.com
Re: Slashdot: Providers Ignoring DNS TTL?
On Apr 22, 2005, at 11:55 PM, Dean Anderson wrote: I don't know of any HTTP servers that do anycast. But their failure to take account of PPLB doesn't change anything. IF they are anycasting under false assumptions, they'll have problems, too. Been happening for many years. How do you think the original Boardwatch / Keynote speed tests were gamed? If you have any real experience on the Internet, you are well acquainted with anycast web servers. Okie, I give up. You clearly have no idea what you are actually talking about, so talk away, no one is listening. I started talking to you 'cause I was having a bad day and it's fun to feed the troll. It's not fun any more, and I'm sure others are tired of the thread. One last comment (although I doubt you will understand): Reality trumps... well, you. -- TTFN, patrick
Re: Slashdot: Providers Ignoring DNS TTL?
On Apr 22, 2005, at 11:20 PM, Dean Anderson wrote: People have been using TCP applications on anycast for at least a decade, as I mentioned before. Since DNS responses tend to be very short lived TCP session, it seems to me that if it works for other applications (e.g. HTTP), it should work for DNS. Its funny how I give you TWO conditions, and you ignore one of them. I'll try to use little tiny baby words: Well, I can set up "conditions" where anything you try to make work does not work. TCP Anycast does NOT work with PPLB (Per - packet - load - balancing) Say it slowly several times. How about I don't say it at all. Here, say this several times slowly: "If you use a standard phone cable between your NIC and the wall, it won't work." So why do you keep trying to not use anycast since I have arbitrarily decided that when you do not use anycast you must use a phone cable in your NIC? What? You don't want to use phone cables in your NIC? Strange, I don't want to use PPLB with my anycast setup, but you seem to think that is a condition of anycast. Which is about as intelligent as forcing you to use a phone cable in your NIC. (Actually, I bet many people here would think forcing you to a phone cable in your NIC would be intelligent) Isn't it interesting how sane^Wexperienced engineers can figure out networking basics like not using _per_packet_ load balancing on an application which might use TCP. If you study hard, maybe someday you will be able to figure these things out too. :-) -- TTFN, patrick P.S. I guess it didn't take much time to see which of us was insane.
Re: Slashdot: Providers Ignoring DNS TTL?
On Wed, 20 Apr 2005, Patrick W. Gilmore wrote: > > On Apr 20, 2005, at 3:29 PM, Dean Anderson wrote: > > >> Or don't. No one here cares if you do. Reality trumps lab tests. > > > > "Reality" for the last ten years has been that no one did either PPLB > > or TCP DNS. That reality is changing. It'll probably start to change > > faster, sooner. Then, users will start to notice the problems. > > People have been using TCP applications on anycast for at least a > decade, as I mentioned before. Since DNS responses tend to be very > short lived TCP session, it seems to me that if it works for other > applications (e.g. HTTP), it should work for DNS. I don't know of any HTTP servers that do anycast. But their failure to take account of PPLB doesn't change anything. IF they are anycasting under false assumptions, they'll have problems, too. Perhaps you should read RFC 1546, which prescribes how to do TCP anycast. Then note that TCP anycast requires OS support which is not implemented in any unix-like system (or any system) that I know of. So, instead of following this prescription, the (DNS) anycast promoters have relied on an assumption of unique and slowly changing paths to eliminate the possibility that "two successive TCP segments sent to the anycast peer might be delivered to completely different hosts." But PPLB makes that "paths change slowly" assumption false, because it can use different paths on sequential packets. >From RFC 1546 (page 5) How UDP and TCP Use Anycasting It is important to remember that anycasting is a stateless service. An internetwork has no obligation to deliver two successive packets sent to the same anycast address to the same host. Because UDP is stateless and anycasting is a stateless service, UDP can treat anycast addresses like regular IP addresses. A UDP datagram sent to an anycast address is just like a unicast UDP datagram from the perspective of UDP and its application. A UDP datagram from an anycast address is like a datagram from a unicast address. Furthermore, a datagram from an anycast address to an anycast address can be treated by UDP as just like a unicast datagram (although the application semantics of such a datagram are a bit unclear). TCP's use of anycasting is less straightforward because TCP is stateful. It is hard to envision how one would maintain TCP state with an anycast peer when two successive TCP segments sent to the anycast peer might be delivered to completely different hosts. The solution to this problem is to only permit anycast addresses as the remote address of a TCP SYN segment (without the ACK bit set). A TCP can then initiate a connection to an anycast address. When the SYN-ACK is sent back by the host that received the anycast segment, the initiating TCP should replace the anycast address of its peer, with the address of the host returning the SYN-ACK. (The initiating TCP can recognize the connection for which the SYN-ACK is destined by treating the anycast address as a wildcard address, which matches any incoming SYN-ACK segment with the correct destination port and address and source port, provided the SYN-ACK's full address, including source address, does not match another connection and the sequence numbers in the SYN-ACK are correct.) This approach ensures that a TCP, after receiving the SYN-ACK is always communicating with only one host. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000
Re: Slashdot: Providers Ignoring DNS TTL?
On Fri, 22 Apr 2005, Dean Anderson wrote: > On Wed, 20 Apr 2005, Patrick W. Gilmore wrote: > > > > > On Apr 20, 2005, at 3:29 PM, Dean Anderson wrote: > > > > >> Or don't. No one here cares if you do. Reality trumps lab tests. > > > > > > "Reality" for the last ten years has been that no one did either > > > PPLB or > > > TCP DNS. That reality is changing. It'll probably start to change > > > faster, > > > sooner. Then, users will start to notice the problems. > > > > People have been using TCP applications on anycast for at least a > > decade, as I mentioned before. Since DNS responses tend to be very > > short lived TCP session, it seems to me that if it works for other > > applications (e.g. HTTP), it should work for DNS. > > Its funny how I give you TWO conditions, and you ignore one of them. I'll > try to use little tiny baby words: > > TCP Anycast does NOT work with PPLB (Per - packet - load - balancing) > Say it slowly several times. oh well, I tried to stay quiet :) Probably the PPLB problem isn't quite as simple as: "you have pplb you can't do anycast". I'd imagine that you have to have some substantial difference in the paths that the PPLB follows, yes? like links to differing ISP's or perhaps extremely diverse links inside the same ISP. Correct?
Re: Slashdot: Providers Ignoring DNS TTL?
On Thu, 21 Apr 2005, Stephen J. Wilcox wrote: > On Wed, 20 Apr 2005, Dean Anderson wrote: > > > On Wed, 20 Apr 2005 [EMAIL PROTECTED] wrote: > > > > > > I'd rather expect this sort of behavior with anycasted servers... > > > > > > Where do you see any connection between anycast and ignoring DNS TTL? Or > > > is > > > this just part of your usual rant against anycast DNS service? > > > > The data he showed isn't necessarilly "ignoring ttl". If there are multiple > > anycasted caching servers behind a specific IP address, then those several > > cache's will each have a different state. Since, [as I > > I fail to see the correlation still.. anycasted caches should all be > operating > independently getting their DNS data from authoritative sources. > > If at any point one of them uses a TTL that it has not received from the > authoritative source it is ignoring the ttl, where does anycast get involved > with this particular problem? The queries produce different data, but none of the data is inconsistent if there are different caches responding on the same address. Here is the original description: (slightly reformated with roman numerals) (I) I ran a query for a name in a zone I control that has a five minute TTL on 204.127.198.4. The first query came up with 5 minutes. (II) I quickly made a change to the zone. (III) Thirty seconds after the initial query, I try again...err... and come up with the change. Hmm... Not caching at all? (IV) Another 30 seconds and I get the change, with 5m TTL. (V) Thirty seconds later, I get the original response with appropriately decremented TTL. (VI) Another thirty seconds, I get the change, with 4m TTL. Here is the detailed anycast explanation: (I) Cache 1 gets answer to query X? = Y (II) Authority changes X? to Z (III) Cache 2 gets answer to query X? = Z (IV) Cache 3 gets answer to query X? = Z (V) Cache 1 responds (VI) Cache 3 responds No TTLs were ignored. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000
Re: Slashdot: Providers Ignoring DNS TTL?
On Wed, 20 Apr 2005 [EMAIL PROTECTED] wrote: > On Wed, 20 Apr 2005 14:00:00 EDT, Dean Anderson said: > > On Wed, 20 Apr 2005 [EMAIL PROTECTED] wrote: > > > Where do you see any connection between anycast and ignoring DNS TTL? > > The data he showed isn't necessarilly "ignoring ttl". If there are > > multiple anycasted caching servers behind a specific IP address, then > > those several cache's will each have a different state. Since, [as I > > explained, and was supposed by the poster], there is "some kind of load > > balancing going on", and also since implementors of anycast caches have > > posted questions and explained their purposes [which could be seen as > > "load balancing"], this is a likely explanation. It may not be the only > > explanation: e.g. they could be restarting their nameservers every thirty > > seconds. But "anycast loadbalancing" of a caching server is probably the > > most likely. > > All fine and good. But nowhere in your long paragraph do you actually > address Steinar's question, which is "What does this rant have to do with > *ignoring* *DNS* *TTL*?" Try actually reading the long paragraph. It starts with the interesting sentence 'The data he showed isn't necessarilly "ignoring ttl".', and I then explain why that is. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000
Re: Slashdot: Providers Ignoring DNS TTL?
On Wed, 20 Apr 2005, Patrick W. Gilmore wrote: > > On Apr 20, 2005, at 3:29 PM, Dean Anderson wrote: > > >> Or don't. No one here cares if you do. Reality trumps lab tests. > > > > "Reality" for the last ten years has been that no one did either > > PPLB or > > TCP DNS. That reality is changing. It'll probably start to change > > faster, > > sooner. Then, users will start to notice the problems. > > People have been using TCP applications on anycast for at least a > decade, as I mentioned before. Since DNS responses tend to be very > short lived TCP session, it seems to me that if it works for other > applications (e.g. HTTP), it should work for DNS. Its funny how I give you TWO conditions, and you ignore one of them. I'll try to use little tiny baby words: TCP Anycast does NOT work with PPLB (Per - packet - load - balancing) Say it slowly several times. > Either way, reality still trumps lab tests, or mailing lists posts. > Since it has worked, and continues to work, in _THE REAL WORLD_ for > TCP applications much longer lived than DNS, I suggest that your > assertion that "users will start to notice the problems" is > incorrect. Of course, time will tell which of us is correct. > > Maybe I'm insane. Or maybe you are. Although I think time has > already told which of us is Yes, indeed, it has. I've been vindicated on a number of issues on a number of subjects. You? -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to [EMAIL PROTECTED] If you have any comments please contact Philip Smith <[EMAIL PROTECTED]>. Routing Table Report 04:00 +10GMT Sat 23 Apr, 2005 Analysis Summary BGP routing table entries examined: 160685 Prefixes after maximum aggregation: 93441 Unique aggregates announced to Internet: 77331 Total ASes present in the Internet Routing Table: 19488 Origin-only ASes present in the Internet Routing Table: 16946 Origin ASes announcing only one prefix:7942 Transit ASes present in the Internet Routing Table:2542 Transit-only ASes present in the Internet Routing Table: 69 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 29 Prefixes from unregistered ASNs in the Routing Table:15 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space: 14 Number of addresses announced to Internet: 1384702016 Equivalent to 82 /8s, 136 /16s and 224 /24s Percentage of available address space announced: 37.4 Percentage of allocated address space announced: 58.6 Percentage of available address space allocated: 63.7 Total number of prefixes smaller than registry allocations: 75129 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:32783 Total APNIC prefixes after maximum aggregation: 15452 Prefixes being announced from the APNIC address blocks: 30715 Unique aggregates announced from the APNIC address blocks:15525 APNIC Region origin ASes present in the Internet Routing Table:2250 APNIC Region origin ASes announcing only one prefix:662 APNIC Region transit ASes present in the Internet Routing Table:347 Average APNIC Region AS path length visible:4.4 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 181900160 Equivalent to 10 /8s, 215 /16s and 147 /24s Percentage of available APNIC address space announced: 67.5 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575 APNIC Address Blocks 58/7, 60/7, 124/7, 126/8, 202/7, 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes: 87296 Total ARIN prefixes after maximum aggregation:53207 Prefixes being announced from the ARIN address blocks:68081 Unique aggregates announced from the ARIN address blocks: 25036 ARIN Region origin ASes present in the Internet Routing Table: 9884 ARIN Region origin ASes announcing only one prefix:3588 ARIN Region transit ASes present in the Internet Routing Table: 937 Average ARIN Region AS path length visible: 4.3 Max ARIN Region AS path length visible: 21 Number of ARIN addresses announced to Internet: 246540032 Equivalent to 14 /8s, 177 /16s and 231 /24s Percentage of available ARIN address space announced: 70.0 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863 ARIN Address Blocks24/8, 63/8, 64/6, 68/7, 70/6, 198/7, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary Prefixes being announced by RIPE Region ASes: 30516 Total RIPE prefixes after maximum aggregation:21066 Prefixes being announced from the RIPE address blocks:27554 Unique aggregates announced from the RIPE address blocks: 18353 RIPE Region origin ASes present in the Internet Routing Table: 6575 RIPE Region origin ASes announcing only one prefix:3470 RIPE Region transit ASes present in the Internet Routing Table:1101 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 29 Number of RIPE addresses announced to Internet: 2
AW: Dual rackmountable power supply?
APC makes one, but it is a 1U device... IT does give you SNMP monitoring of the status of both circuits though, which is a rather cool feature. I have a similar situation at one of our POPs which is why I ended up needing the product. Thanks, John van Oppen PocketiNet Communications -Ursprüngliche Nachricht- Von: Mike Sawicki [mailto:[EMAIL PROTECTED] Gesendet: Friday, April 22, 2005 3:34 PM An: nanog@merit.edu Betreff: Dual rackmountable power supply? Do any of you know if there are companies who manufacture 1/2U rackmountable PDU's that take AC from redundant sources? I have equipment at a colo that seems to have issues with one of the two circuits in my cabinets about once a month. Since it would be a real pain in the neck for me to retrofit every server with dual-ps, I was thinking this could be a possible middle-of-the-road solution. Thanks. -- Mike Sawicki ([EMAIL PROTECTED])
Re: Dual rackmountable power supply?
Without 1-1 transformer and complex switching circuitry you really can't do safe switching from one to the other. That pretty much means any such device would be just as complex or more so as UPS, but less safe. So I think your best bet is to decide if your power problems last long and if they dont last more then several minutes and then just use regular UPS or if its bigger problem, then use UPS that can accept redundant power sources. For servers with redundant power supply its quite different because they do provide power to the board from multiple sources and each one is already DC so its not a problem to switch quickly then. On Fri, 22 Apr 2005, Mike Sawicki wrote: Do any of you know if there are companies who manufacture 1/2U rackmountable PDU's that take AC from redundant sources? I have equipment at a colo that seems to have issues with one of the two circuits in my cabinets about once a month. Since it would be a real pain in the neck for me to retrofit every server with dual-ps, I was thinking this could be a possible middle-of-the-road solution. Thanks. -- Mike Sawicki ([EMAIL PROTECTED])
Re: Dual rackmountable power supply?
On 23.04.2005 00:33 Mike Sawicki wrote Do any of you know if there are companies who manufacture 1/2U rackmountable PDU's that take AC from redundant sources? I have equipment at a colo that seems to have issues with one of the two circuits in my cabinets about once a month. Since it would be a real pain in the neck for me to retrofit every server with dual-ps, I was thinking this could be a possible middle-of-the-road solution. Thanks. Have a look at APC (http://www.apcc.com/products/family/index.cfm?id=14&ISOCountryCode=us) Arnold -- Arnold Nipper, AN45
Root DNS Servers 2
The problem appears to be with ipc.com nameserver = NS60.WORLDNIC.com. ipc.com nameserver = NS59.WORLDNIC.com. Anyone know what's happening?
RE: Root DNS servers
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Graeme Clark > Sent: Friday, April 22, 2005 5:52 PM > To: nanog@merit.edu > Subject: RE: Root DNS servers > > > > > On Fri, Apr 22, 2005 at 11:16:05AM -0400, Joseph Nuara wrote: > > > > > > Does anyone know what is currently happening with the root DNS > servers? > > > I'm currently unable to do A and MX lookups on some > domains while my > > > service providers DNS server appears to be ok ... > > > > well, not speaking for the rest of them... > > we seem to be answering every legal/legitimate > > query that we receive. > > > > why do you think your problem has -anything- to do > > with the root server system? > > > > --bill > > > > > I've got a dozen or so domains with NSI, and their story is > they lost 18 > servers to 'a crash' earlier today. Apparently all fixed now - things > just need to propagate. > > Graeme > > graeme clark | leader, network technologies and services | > lavalife inc. > | toronto tel 416 263 6300 x 3658 | fax 416 263 6303 > > -- > Hi Bill, > > the root is fine. > > I would like to know what domains. At least some of them. > [ SNIP ] Folks, these [this and "new worm?" ] are clearly on-topic operational posts. If we could up the content on any outage like assertions, I know a lot of us would appreciate the on topic post -and- the extra information. Thanks for the early warning, regardless. After the global sound of coffee mugs hitting the floor, it only takes us a few minutes to look into these things. The extra data helps. Regards, -M< -- Martin Hannigan (c) 617-388-2663 VeriSign, Inc. (w) 703-948-7018 Network Engineer IV Operations & Infrastructure [EMAIL PROTECTED]
Re: Dual rackmountable power supply?
On Fri, 22 Apr 2005, Mike Sawicki wrote: > Do any of you know if there are companies who manufacture 1/2U > rackmountable PDU's that take AC from redundant sources? I have > equipment at a colo that seems to have issues with one of the two > circuits in my cabinets about once a month. Since it would be a real > pain in the neck for me to retrofit every server with dual-ps, I was > thinking this could be a possible middle-of-the-road solution. Thanks. This is called a "Static Transfer Switch". (Sometimes "automatic transfer switch", particularly for smaller units). Number of companies make small ones: http://www.baytechdcd.com/cgi-private/showprod?prod=F5-RPC http://www.baytechdcd.com/cgi-private/showprod?prod=ATS12-30 http://twinsource.net/ http://www.apc.com/products/family/index.cfm?id=14 http://www.mgeups.com/products/pdt230/sts/psts/stsa.htm
Root DNS servers
Does anyone know what is currently happening with the root DNS servers? I'm currently unable to do A and MX lookups on some domains while my service providers DNS server appears to be ok ...
Re: Root DNS Servers 2
On Fri, 22 Apr 2005, Joseph Nuara wrote: > > The problem appears to be with > > ipc.com nameserver = NS60.WORLDNIC.com. > ipc.com nameserver = NS59.WORLDNIC.com. > > Anyone know what's happening? note, I'm not a dns admin nor a network engineer, BUT these aren't root servers... Perhaps your host(s) are being filtered at worldnic.com's host level while your provider's server(s) are not?
Re: Root DNS Servers 2
On Apr 22, 2005, at 11:47 AM, Christopher L. Morrow wrote: The problem appears to be with ipc.com nameserver = NS60.WORLDNIC.com. ipc.com nameserver = NS59.WORLDNIC.com. Anyone know what's happening? note, I'm not a dns admin nor a network engineer, BUT these aren't root servers... Perhaps your host(s) are being filtered at worldnic.com's host level while your provider's server(s) are not? I have been told by a Network Solutions hosting customer that the NSI name servers are down. This is (obviously) affecting their mail & web. Since WORLDNIC.com is NSI, this would make sense. But yeah, this ain't nuttin' to do wit da r00t servers. -- TTFN, patrick
Dual rackmountable power supply?
Do any of you know if there are companies who manufacture 1/2U rackmountable PDU's that take AC from redundant sources? I have equipment at a colo that seems to have issues with one of the two circuits in my cabinets about once a month. Since it would be a real pain in the neck for me to retrofit every server with dual-ps, I was thinking this could be a possible middle-of-the-road solution. Thanks. -- Mike Sawicki ([EMAIL PROTECTED])
Re: Root DNS servers
On Fri, Apr 22, 2005 at 11:16:05AM -0400, Joseph Nuara wrote: > > Does anyone know what is currently happening with the root DNS servers? > I'm currently unable to do A and MX lookups on some domains while my > service providers DNS server appears to be ok ... well, not speaking for the rest of them... we seem to be answering every legal/legitimate query that we receive. why do you think your problem has -anything- to do with the root server system? --bill
Re: Service providers that NAT their whole network?
Apologies for the late reply, but T-Mobile's US GPRS network hands out RFC1918 space as well. -C On Fri, Apr 15, 2005 at 01:40:12PM -0700, Scott Call wrote: > > On Fri, 15 Apr 2005, Philip Matthews wrote: > > > > >A number of IETF documents(*) state that there are some service providers > >that place a NAT box in front of their entire network, so all their > >customers get private addresses rather than public address. > >It is often stated that these are primarily cable-based providers. > > In my experience many cellular providers (at least in the US) do this as > well. A GPRS connection to Cingular, even from a laptop device, will get > a 1918 address. I don't mind since my phone runs linux with no root > password (thanks motorola). > > -Scott
Re: Service providers that NAT their whole network?
On Apr 22, 2005, at 1:14 PM, Chris Woodfield wrote: Apologies for the late reply, but T-Mobile's US GPRS network hands out RFC1918 space as well. Ah, that depends on if you're on WAP, T-Mobile Internet or T-Mobile VPN. The VPN service is exactly the same as the Internet one, except that it gives you non-NAT'd address space for VPN compatibility. (APN internet3.voicestream.com, everything else is the same). Note that you have to be provisioned on each APN now, you can't jump around like you used to be able to. -C On Fri, Apr 15, 2005 at 01:40:12PM -0700, Scott Call wrote: On Fri, 15 Apr 2005, Philip Matthews wrote: A number of IETF documents(*) state that there are some service providers that place a NAT box in front of their entire network, so all their customers get private addresses rather than public address. It is often stated that these are primarily cable-based providers. In my experience many cellular providers (at least in the US) do this as well. A GPRS connection to Cingular, even from a laptop device, will get a 1918 address. I don't mind since my phone runs linux with no root password (thanks motorola). -Scott
RE: Dual rackmountable power supply?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > [EMAIL PROTECTED] > Sent: Friday, April 22, 2005 8:07 PM > To: Mike Sawicki > Cc: nanog@merit.edu > Subject: Re: Dual rackmountable power supply? > > > > On Fri, 22 Apr 2005, Mike Sawicki wrote: > > > Do any of you know if there are companies who manufacture 1/2U > > rackmountable PDU's that take AC from redundant sources? I have > > equipment at a colo that seems to have issues with one of the two > > circuits in my cabinets about once a month. Since it would > be a real > > pain in the neck for me to retrofit every server with dual-ps, I was > > thinking this could be a possible middle-of-the-road > solution. Thanks. > This is called a "Static Transfer Switch". (Sometimes > "automatic transfer > switch", particularly for smaller units). Number of companies > make small > ones: > > http://www.baytechdcd.com/cgi-private/showprod?prod=F5-RPC > http://www.baytechdcd.com/cgi-private/showprod?prod=ATS12-30 > http://twinsource.net/ > http://www.apc.com/products/family/index.cfm?id=14 > http://www.mgeups.com/products/pdt230/sts/psts/stsa.htm I don't think you can place these on the pointy side of conditioned power. They require utility, IIRC, which means you also need to add in some UPS for the front side to make it work right since utility will tend to take 'switch hits' during peak as the utility moves load around. WRT to the flapping power circuit, blind guess, ask your colo provider to measure the load at your breaker and if it's fine then swap the strip and chords (twistlock or not) back to the first JB. -M< -- Martin Hannigan (c) 617-388-2663 VeriSign, Inc. (w) 703-948-7018 Network Engineer IV Operations & Infrastructure [EMAIL PROTECTED]
Any supply a live contact for mac.com?
Hey, Can anyone who has a good contact for mail/abuse issues at Mac.com please contact me offline? I've already tried the traditional routes with no success. Thanks. --Campbell
The Cidr Report
This report has been generated at Fri Apr 22 21:44:56 2005 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
15-04-05156270 107049
16-04-05156458 107074
17-04-05156453 107094
18-04-05156496 107190
19-04-05156537 107298
20-04-05156687 107243
21-04-05156814 107312
22-04-05156923 107451
AS Summary
19392 Number of ASes in routing system
7957 Number of ASes announcing only one prefix
1468 Largest number of prefixes announced by an AS
AS7018 : ATT-INTERNET4 - AT&T WorldNet Services
90503424 Largest address span announced by an AS (/32s)
AS721 : DLA-ASNBLOCK-AS - DoD Network Information Center
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 22Apr05 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 157106 1074544965231.6% All ASes
AS4323 1094 226 86879.3% TWTC - Time Warner Telecom
AS18566 7918 78399.0% COVAD - Covad Communications
AS4134 888 216 67275.7% CHINANET-BACKBONE
No.31,Jin-rong Street
AS721 1113 561 55249.6% DLA-ASNBLOCK-AS - DoD Network
Information Center
AS7018 1468 948 52035.4% ATT-INTERNET4 - AT&T WorldNet
Services
AS27364 518 22 49695.8% ACS-INTERNET - Armstrong Cable
Services
AS22773 479 23 45695.2% CCINET-2 - Cox Communications
Inc.
AS6197 886 468 41847.2% BATI-ATL - BellSouth Network
Solutions, Inc
AS3602 507 141 36672.2% SPRINT-CA-AS - Sprint Canada
Inc.
AS17676 430 77 35382.1% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS9929 346 44 30287.3% CNCNET-CN China Netcom Corp.
AS4766 570 277 29351.4% KIXS-AS-KR Korea Telecom
AS6478 387 101 28673.9% ATT-INTERNET3 - AT&T WorldNet
Services
AS7545 488 217 27155.5% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS9583 718 450 26837.3% SIFY-AS-IN Sify Limited
AS6140 399 141 25864.7% IMPSAT-USA - ImpSat
AS14654 2646 25897.7% WAYPORT - Wayport
AS9443 373 122 25167.3% INTERNETPRIMUS-AS-AP Primus
Telecommunications
AS1239 911 663 24827.2% SPRINTLINK - Sprint
AS23126 253 15 23894.1% KMCTELCOM-DIA - KMC Telecom,
Inc.
AS15270 267 36 23186.5% AS-PAETEC-NET - PaeTec.net -a
division of
PaeTecCommunications, Inc.
AS4755 450 220 23051.1% VSNL-AS Videsh Sanchar Nigam
Ltd. Autonomous System
AS6198 455 232 22349.0% BATI-MIA - BellSouth Network
Solutions, Inc
AS5668 489 270 21944.8% AS-5668 - CenturyTel Internet
Holdings, Inc.
AS2386 840 623 21725.8% INS-AS - AT&T Data
Communications Services
AS9498 287 73 21474.6% BBIL-AP BHARTI BT INTERNET
LTD.
AS11456 320 112 20865.0% NUVOX - NuVox Communications,
Inc.
AS6167 274 78 19671.5% CELLCO-PART - Cellco
Partnership
AS22909 349 157 19255.0% DNEO-OSP1 - Comcast Cable
Communications, Inc.
AS6517 315 125 19060.3% YIPESCOM - Yipes
Communications, I
