- Test - lists.nanog.org

Elanti Inteligent Routing..
by Christian Koch 17 Jun '08

17 Jun '08

anyone with firsthand operational experience with this? pro's, con's? feedback? ck

1 0

Re: Cable Colors
by Martin Hannigan 16 Jun '08

16 Jun '08

A little bit of the rainbow might spice up your life, Randy. Staring at all that grey cat3 is making you cranky. Personally, I like orange for console, standard powder blue for in rack termination, and red for backbone dependent. ----- Original Message ----- From: Randy Bush <randy(a)psg.com> To: nanog(a)nanog.org <nanog(a)nanog.org> Sent: Mon Jun 16 23:00:45 2008 Subject: Re: Cable Colors all you people are just sooooo retro and boring. i like purple, fluorescent lime, ... the colors make no difference as long as you are consistent. labeling, consistent port use (oob port == power port == switch port ==) are what will bail you out at three in the morning. randy

1 0

Battle Creek/Kalamazoo/Coldwater (Michigan) datacenters
by Drew Linsalata 16 Jun '08

16 Jun '08

Not exactly operational, but I'm trying to help someone grab a fast-e link out of either Battle Creek or Kalamazoo for a wireless shot to Coldwater. Does anyone have any experience with facilities in that neck of the woods?

1 0

Re: Best utilizing fat long pipes and large file transfer
by goemon＠anime.net 16 Jun '08

16 Jun '08

afaik the limit is 10 *sessions* not 10 *tcp connections*. there should be nothing limiting you from opening 10,000 tcp connections in a single app. eg 10 smb shares, 10 sql sessions, etc. -Dan On Mon, 16 Jun 2008, Bob Bradlee wrote: > I have tested it with Icecast using audio streams and it is 100 not 10. > moved to w2k server and the glass wall at 100 streams went away. > > Bob > > On Mon, 16 Jun 2008 10:25:18 -0700 (PDT), goemon(a)anime.net wrote: > >> On Mon, 16 Jun 2008, Glen Turner wrote: >>> Then there's the deliberate nobbling of the TCP implementation, >>> such as the restriction to ten of connections to Windows Xp SP3. >>> Apparently you're meant to buy Windows Server if you are running >>> P2P applications :-) > >> are you quite sure it is *10 tcp connections*? >> have you tested this? > >> -Dan > > >

1 0

Google Contact
by Edward A. Trdina III 16 Jun '08

16 Jun '08

Can someone from Google please ping me off list please?

1 0

Bandcon Transport Services..
by Christian 16 Jun '08

16 Jun '08

Anyone here use Bandcon's transport services? Positive/Negative experiences, any feedback would be helpful.. Thanks ck

2 1

RE: Best utilizing fat long pipes and large file transfer
by Skywing 16 Jun '08

16 Jun '08

It's 10 half-open (SYN_SENT) outbound TCP connections as I recall. - S -----Original Message----- From: goemon(a)anime.net <goemon(a)anime.net> Sent: Monday, June 16, 2008 12:26 To: Glen Turner <gdt(a)gdt.id.au> Cc: nanog(a)merit.edu <nanog(a)merit.edu> Subject: Re: Best utilizing fat long pipes and large file transfer On Mon, 16 Jun 2008, Glen Turner wrote: > Then there's the deliberate nobbling of the TCP implementation, > such as the restriction to ten of connections to Windows Xp SP3. > Apparently you're meant to buy Windows Server if you are running > P2P applications :-) are you quite sure it is *10 tcp connections*? have you tested this? -Dan

1 0

DNS problems to RoadRunner - tcp vs udp
by Mark Price 16 Jun '08

16 Jun '08

I have seen intermittent problems on some client windows servers sending to rr.com recently. For example, the MX hosts for triad.rr.com are: # dig -t mx triad.rr.com ;; QUESTION SECTION: ;triad.rr.com. IN MX ;; ANSWER SECTION: triad.rr.com. 1609 IN MX 10 hrndva-smtpin01.mail.rr.com. triad.rr.com. 1609 IN MX 20 hrndva-smtpin02.mail.rr.com. The authoritative nameservers for mail.rr.com: # dig -t ns mail.rr.com ;; QUESTION SECTION: ;mail.rr.com. IN NS ;; ANSWER SECTION: mail.rr.com. 14204 IN NS cdptpa-admin02.mail.rr.com. mail.rr.com. 14204 IN NS hrndva-admin01.mail.rr.com. mail.rr.com. 14204 IN NS hrndva-admin02.mail.rr.com. mail.rr.com. 14204 IN NS cdptpa-admin01.mail.rr.com. All 4 of those queries will answer a UDP DNS query for host record hrndva-smtpin01.mail.rr.com. However, the hrndva-admin01.mail.rr.com and hrndva-admin02.mail.rr.com servers do not respond to TCP queries at all. Example: # dig hrndva-smtpin01.mail.rr.com @hrndva-admin01.mail.rr.com +tcp ; <<>> DiG 9.3.3rc2 <<>> hrndva-smtpin01.mail.rr.com @hrndva-admin01.mail.rr.com +tcp ; (1 server found) ;; global options: printcmd ;; connection timed out; no servers could be reached >From what I have read, public DNS servers should support both UDP and TCP queries. TCP queries are often used when a UDP query fails, or if the answer is over a certain length. Any clues would be appreciated. Mark -- Mark Price Tranquil Hosting www.tqhosting.com

24 33

Single IP routing problems through Level3
by Matt Palmer 15 Jun '08

15 Jun '08

We're seeing some really weird issues with connections that go through / to Level3 IP space. Basically, certain "pairs" of IPs (particular L3 IPs coupled with particular IPs of ours) have dodgy/nonexistent connectivity, but if you change the IP at either end everything's hunky dory. I've sniffed (from both ends) pings going from a host in L3 space to our end and seen the pings arrive at our end and head back in the direction of L3, but they never get to their destination. Traceroutes from L3 stop at the next-to-last hop, while traceroutes back get to the hop before L3 space and stop. All of this behaviour is source/dest *pair* specific -- if I ping/traceroute from another address (in the same netblock as the problematic IP, so all the same equipment is involved) at either end, or to another address (again, same netblock) at either end, it all works again. I've got two questions: 1) Has anyone else seen similar behaviour from L3 (or other providers, even), so I know I'm not going mad? 2) What sort of configuration problem or software bug would cause this sort of problem to occur? If it was an IP blacklist (or even a block routing issue) anywhere along the line, surely it wouldn't be sensitive to changing the other end's address to another one in the same /24? Any insight/anecdotes/etc would be greatly appreciated, as it's starting to do my head in. Just knowing I'm not alone with this insanity would be nice at this point. <grin> If it makes any difference, the blocks I'm working from at my end are Internap, in 74.201.254.0/23 (we don't have all of it, just most of it), while the far end is 8.12.35.0/24. - Matt

4 4

Re: Single IP routing problems through Level3
by Jon Wolberg 15 Jun '08

15 Jun '08

I've seen the exact same symptoms before with another provider and it was a L3 Port-Channel that was not balanced properly due to a link being down which wasn't detected as such. It was also causing very sporadic latency spikes and dropped packets. Jon ----- Original Message ----- From: "Matt Palmer" <mpalmer(a)hezmatt.org> To: nanog(a)nanog.org Sent: Sunday, June 15, 2008 10:39:56 AM GMT -05:00 US/Canada Eastern Subject: Re: Single IP routing problems through Level3 On Sun, Jun 15, 2008 at 11:12:25AM -0300, Rubens Kuhl Jr. wrote: > 1) I've seen this behavior before; you are not alone in the universe. Thank $DEITY for that. <grin> > 2) Most likely there is a balanced channel on the path, either L3 or > L2, and one of the links in the bundle is dead but has not been > detected as such. A multiple-link bundle which is load balanced by source/destination pair with an undetected dud link? I hadn't thought of that, but it does make an *awful* lot of sense. (Although, not being a big-network transit kinda person, I don't know if such a thing actually exists <grin>) I'll mention it (or ask about it) as a possibility next time I talk to the relevant people, though. Thanks, - Matt > On Sun, Jun 15, 2008 at 11:01 AM, Matt Palmer <mpalmer(a)hezmatt.org> wrote: > > We're seeing some really weird issues with connections that go through / to > > Level3 IP space. Basically, certain "pairs" of IPs (particular L3 IPs > > coupled with particular IPs of ours) have dodgy/nonexistent connectivity, > > but if you change the IP at either end everything's hunky dory. > > > > I've sniffed (from both ends) pings going from a host in L3 space to our end > > and seen the pings arrive at our end and head back in the direction of L3, > > but they never get to their destination. Traceroutes from L3 stop at the > > next-to-last hop, while traceroutes back get to the hop before L3 space and > > stop. > > > > All of this behaviour is source/dest *pair* specific -- if I ping/traceroute > > from another address (in the same netblock as the problematic IP, so all the > > same equipment is involved) at either end, or to another address (again, > > same netblock) at either end, it all works again. > > > > I've got two questions: > > > > 1) Has anyone else seen similar behaviour from L3 (or other providers, > > even), so I know I'm not going mad? > > > > 2) What sort of configuration problem or software bug would cause this sort > > of problem to occur? If it was an IP blacklist (or even a block routing > > issue) anywhere along the line, surely it wouldn't be sensitive to > > changing the other end's address to another one in the same /24? > > > > Any insight/anecdotes/etc would be greatly appreciated, as it's starting to > > do my head in. Just knowing I'm not alone with this insanity would be nice > > at this point. <grin> > > > > If it makes any difference, the blocks I'm working from at my end are > > Internap, in 74.201.254.0/23 (we don't have all of it, just most of it), > > while the far end is 8.12.35.0/24.

1 0