Restoration after Hurricane Frances

2004-09-10 Thread Sean Donelan

In Florida after Hurricane Frances: 17 fatalities attributed to the
Hurricane and its affects.

Wireless companies are reporting 95% service restoration statewide.

Wireline companies have restored over half of the damaged lines statewide.
Bellsouth: 385,000 and Sprint: 177,000 out of service.  No figures
available from other individual wireline companies.

Adelphia reported it had restored 68% of its service.

Comcast reports significant progress.

I heard of no reports of damage to any major co-location or Internet
data center in Florida due to Hurricane Frances.  NASA shutdown at least
a portion of its computer networks at the Kennedy Space Center in advance
of Hurricane Frances.

Next up, Hurricane Ivan.  The lower Florida Keys have evacuation orders
for non-residents, RV's, boats and parks starting on September 10.



Re: ISP Policies

2004-09-10 Thread Rohit Gupta
On a related note : Do ISPs ever tweak around with Local Prefs and weights so as to select BGP paths with greater AS PATH length?

Would it ever make sense for a provider to chose a longer AS PATH length BGP route against a shorter AS PATH length route?

Rohit

MTech Comp Sc.
Institute of Technology
Banaras Hindu University

- Original Message - 
From: "Howard C. Berkowitz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 09, 2004 11:27 PM
Subject: Re: ISP Policies


> 
> At 11:04 AM +0530 9/9/04, Tulip Rasputin wrote:
>>Hi Chris,
>>
>>>Or, you just don't want to send traffic through Bill Manning's ASN because
>>>you dislike his hawiian T-Shirt Policy? There are probably a few hundred
>>>reasosn why you'd avoid an ASN... In general though I'd think that like
>>>Michel said: "It's a pain and its doing something that bgp should do for
>>>you without lots of messing about"
>>
>>That's why i explicitly asked for some "social/political/etc." 
>>reasons where an ISP may not want his traffic to traverse some 
>>particular AS number(s). Something which is beyond BGP to determine 
>>as of now ! :-)
Indiatimes Email now powered by APIC Advantage. Help! HelpClick on the image to chat with me


Re: ISP Policies

2004-09-10 Thread James

On Fri, Sep 10, 2004 at 11:36:58AM +0530, Rohit Gupta wrote:
 On a related note : Do ISPs ever tweak around with Local Prefs and weights so as to 
 select BGP paths with greater AS PATH length?
 
 Would it ever make sense for a provider to chose a longer AS PATH length BGP route 
 against a shorter AS PATH length route?
 

Yes many do - Prefer your customer routes via customer interfaces, over
transit and peering interfaces.

Higher LP over cust interfaces = more bits = more revenue. There is nothing
wrong with this IMO, considering many of them who do this, also provide
a community for customers to override this behaviour.

-J


-- 
James JunTowardEX Technologies, Inc.
Technical LeadNetwork Design, Consulting, IT Outsourcing
[EMAIL PROTECTED]  Boston-based Colocation  Bandwidth Services
cell: 1(978)-394-2867   web: http://www.towardex.com , noc: www.twdx.net


Re: ISP Policies

2004-09-10 Thread Stefan Mink
On Thu, Sep 09, 2004 at 05:10:21AM +, Christopher L. Morrow wrote:
 I'm not a router guy (routing atleast), but perhaps there are performance
 problems inside an ASN along a path which you connect to other places? So
 you might lengthen paths through/to that ASN to force traffic across
 another ASN's direct connection which is less problematic?
 
 Or, you just don't want to send traffic through Bill Manning's ASN because
 you dislike his hawiian T-Shirt Policy? There are probably a few hundred
 reasosn why you'd avoid an ASN... In general though I'd think that like
 Michel said: It's a pain and its doing something that bgp should do for
 you without lots of messing about

choosing a route whose AS path doesn't contain an AS is no garantee
that packets won't flow through that AS nevertheless. Forwarding is
being done hop-by-hop. Examples for that szenario are
 * more specifics that aren't distributed globally
 * broken/complicated routing setups where a router chooses a route it got
   via IBGP and where on the path to the corresponding nexthop another
   router decides to rather use his own route (e.g. a router chooses his
   own route due to step external vs.  internal in the BGP decision process, 
   but the original decision was based on lowest router id) This can happen
   in not-full-mesh environments, e.g. with route reflector setups...

I use the AS-path rather to grab chunks of prefixes (e.g. all routes
via ASxyz) to do loadbalancing over transit providers whose announcements
look so similar that the decision is only based on lowest router id of the
IBGP speaker. I know this can be somewhat solved via multi-path bgp but
there are other issues with that (fib size, multiple exit points behind
one route-reflector etc)...

   tschuess
 Stefan
-- 
Stefan Mink, Schlund+Partner AG (AS 8560)
Primary key fingerprint: 389E 5DC9 751F A6EB B974  DC3F 7A1B CF62 F0D4 D2BA


pgpW8b1fkvfs8.pgp
Description: PGP signature


Re: Intel calls for Internet overhaul

2004-09-10 Thread Eric A. Hall


On 9/9/2004 4:12 PM, Paul Vixie wrote:

 update SAN FRANCISCO--The Internet needs to be upgraded with a new layer
 of abilities that will deal with imminent problems of capacity, security
 and reliability, Intel Chief Technology Officer Pat Gelsinger said
 Thursday.

hmmph. Many moons ago I used to argue that the IETF should adopt/hijack
the DCE suite, and for the same basic reasons that this guy is arguing for
their thingy. DCE is probably a better idea still, but his payscale and
business card guarantee a wider audience so... Who knows, maybe he'll have
better luck with it. I'll salute if its architected and spec'd right, with
a good distributed directory, platform-neutral APIs, targetted use, etc.

-- 
Eric A. Hallhttp://www.ehsco.com/
Internet Core Protocols  http://www.oreilly.com/catalog/coreprot/


Re: Verisign vs. ICANN

2004-09-10 Thread Dan Hollis

On Fri, 10 Sep 2004, Joe Rhett wrote:
 On Thu, Sep 09, 2004 at 04:01:46PM -0700, Dan Hollis wrote:
  If the patent is strong enough, wouldnt some patent attorney be willing to 
  defend it on a contingency basis?
  With the potential $$ in a patent violation judgement against verisign, I 
  would think attorneys would be all over it.
 Patent violation can be easily gathered, but the penalty is always based on
 the lost revenue, which must be documented and validated.
 In short, if you want to make money selling your patent to someone then you
 must have a valid business that loses money so that your lawsuit against
 them will have teeth.

So the attorney creates an IP holding company to which the patent is 
assigned, and the company offers to license the patent to Verisign. 
When Verisign refuses, they get sued for lost revenue.

There are companies whos entire revenue stream revolves around licensing 
patents / litigating. This is quite normal.

-Dan



Re: Spammers Skirt IP Authentication Attempts

2004-09-10 Thread Stephane Bortzmeyer

On Wed, Sep 08, 2004 at 04:59:51PM +,
 Paul Vixie [EMAIL PROTECTED] wrote 
 a message of 27 lines which said:

 you could bet that by closing off this avenue, SPF will force
 spammers to use other methods that are more easily
 detected/filtered, and that if you play this catmouse game long
 enough, it will drive the cost of spam so high (or drive the volume
 benefit so low) that it'll just die out.

Good summary. This is the right strategy.

 but to me, SPF is just a way to rearrange the deck chairs on the
 Titanic.

I can swim but I believe that the water under the Titanic was quite
too cold to stay. Any advice to the people on the NANOG mailing list
before the boat goes down?



Re: Spammers Skirt IP Authentication Attempts

2004-09-10 Thread Stephane Bortzmeyer

On Wed, Sep 08, 2004 at 03:15:14PM -0500,
 Robert Bonomi [EMAIL PROTECTED] wrote 
 a message of 37 lines which said:

 Same thing applies for 'simple' forwarding via sendmails '~/.forward'
 mechanism.  the mail server 'accepts' the mail from the original source,
 and then 're-sends' to the new destination.  That re-send originates as
 the _forwarding_party_, WITH an 'envelope from' of that forwarding
 party,

Sorry, this is simply not true (sendmail, postfix, etc, always keep
the original envelope from when forwarding).

 An SPF check of the _immediate_ sender does *NOT* break forwarded
 mail.

Even SPF people say it:

http://spf.pobox.com/faq.html#forwarding


Re: Verisign vs. ICANN

2004-09-10 Thread Joe Rhett

 On Fri, 10 Sep 2004, Joe Rhett wrote:
  In short, if you want to make money selling your patent to someone then you
  must have a valid business that loses money so that your lawsuit against
  them will have teeth.
 
On Fri, Sep 10, 2004 at 12:46:07AM -0700, Dan Hollis wrote:
 So the attorney creates an IP holding company to which the patent is 
 assigned, and the company offers to license the patent to Verisign. 
 When Verisign refuses, they get sued for lost revenue.
 
The holding company must be making money from the patent to demonstrate the 
value of the loss.  It can't be a silent owner -- these have been fairly
routinely tossed out of court as meritless.

 There are companies whos entire revenue stream revolves around licensing 
 patents / litigating. This is quite normal.

Yes, but they use complicated techniques of licensing and subcompanies with
demonstratable revenue to achieve those goals.  It's not as simple as was
suggested here.

-- 
Joe Rhett
Senior Geek
Meer.net


Re: Spammers Skirt IP Authentication Attempts

2004-09-10 Thread Joe Rhett

Robert Bonomi [EMAIL PROTECTED] wrote 
  Same thing applies for 'simple' forwarding via sendmails '~/.forward'
  mechanism.  the mail server 'accepts' the mail from the original source,
  and then 're-sends' to the new destination.  That re-send originates as
  the _forwarding_party_, WITH an 'envelope from' of that forwarding
  party,
 
On Fri, Sep 10, 2004 at 09:55:55AM +0200, Stephane Bortzmeyer wrote:
 Sorry, this is simply not true (sendmail, postfix, etc, always keep
 the original envelope from when forwarding).
 
I'm not sure where true diverges from reality in your analysis, but
perhaps you should create one of those mail environments and test before
you put your foot in your mouth again?

-- 
Joe Rhett
Senior Geek
Meer.net


Re: Verisign vs. ICANN

2004-09-10 Thread Dan Hollis

On Fri, 10 Sep 2004, Joe Rhett wrote:
  On Fri, 10 Sep 2004, Joe Rhett wrote:
   In short, if you want to make money selling your patent to someone then you
   must have a valid business that loses money so that your lawsuit against
   them will have teeth.
 On Fri, Sep 10, 2004 at 12:46:07AM -0700, Dan Hollis wrote:
  So the attorney creates an IP holding company to which the patent is 
  assigned, and the company offers to license the patent to Verisign. 
  When Verisign refuses, they get sued for lost revenue.
 The holding company must be making money from the patent to demonstrate the 
 value of the loss.  It can't be a silent owner -- these have been fairly
 routinely tossed out of court as meritless.

Do you have an example of such a case?

-Dan



Re: Spammers Skirt IP Authentication Attempts

2004-09-10 Thread Stephane Bortzmeyer

On Fri, Sep 10, 2004 at 01:57:51AM -0700,
 Joe Rhett [EMAIL PROTECTED] wrote 
 a message of 19 lines which said:

 I'm not sure where true diverges from reality in your analysis,
 but perhaps you should create one of those mail environments and
 test before you put your foot in your mouth again?

Good idea, I plan to install a Fedora this week-end and to learn a bit
about Postfix. Your wide experience will certainly help.

If you think that sendmail or postfix modify the enveloppe from when
forwarding, I suggest that you send your big discovery to the IETF
MARID working group, where it may change a lot of things in the
current discussion about Sender-ID :-)


The Cidr Report

2004-09-10 Thread cidr-report

This report has been generated at Fri Sep 10 21:50:46 2004 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
03-09-04142564   98111
04-09-04142671   98023
05-09-04142645   97946
06-09-04142493   97997
07-09-04142498   98214
08-09-04142814   98395
09-09-04143221   98358
10-09-04143329   98574


AS Summary
 17936  Number of ASes in routing system
  7281  Number of ASes announcing only one prefix
  1377  Largest number of prefixes announced by an AS
AS7018 : ATTW ATT WorldNet Services
  86705664  Largest address span announced by an AS (/32s)
AS721  : DNIC 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').

 --- 10Sep04 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 143397984814491631.3%   All ASes

AS18566  7397  73299.1%   CVAD Covad Communications
AS4134   781  172  60978.0%   CHINANET-BACKBONE
   No.31,Jin-rong Street
AS4323   778  217  56172.1%   TWTC Time Warner Telecom
AS7018  1377  950  42731.0%   ATTW ATT WorldNet Services
AS6347   539  116  42378.5%   SAVV SAVVIS Communications
   Corporation
AS7843   488  104  38478.7%   ADELPH-13 Adelphia Corp.
AS22773  394   21  37394.7%   CXAB Cox Communications Inc.
   Atlanta
AS6467   385   30  35592.2%   ACSI e.spire Communications,
   Inc.
AS701   1247  899  34827.9%   UU UUNET Technologies, Inc.
AS9583   530  201  32962.1%   SATYAMNET-AS Satyam Infoway
   Ltd.,
AS27364  365   36  32990.1%   ARMC Armstrong Cable Services
AS22909  365   43  32288.2%   CMCS Comcast Cable
   Communications, Inc.
AS6197   717  396  32144.8%   BNS-14 BellSouth Network
   Solutions, Inc
AS1239   951  636  31533.1%   SPRN Sprint
AS9929   346   34  31290.2%   CNCNET-CN China Netcom Corp.
AS17676  346   43  30387.6%   JPNIC-JP-ASN-BLOCK Japan
   Network Information Center
AS11172  352   51  30185.5%   Alestra
AS6478   357   71  28680.1%   ATTW ATT WorldNet Services
AS4355   380   99  28173.9%   ERSD EARTHLINK, INC
AS4766   545  266  27951.2%   KIXS-AS-KR Korea Telecom
AS6140   396  125  27168.4%   IMPSA ImpSat
AS21502  2683  26598.9%   ASN-NUMERICABLE NUMERICABLE is
   a cabled network in France,
AS14654  2576  25197.7%   WAYPOR-3 Wayport
AS9443   359  109  25069.6%   INTERNETPRIMUS-AS-AP Primus
   Telecommunications
AS2386   826  592  23428.3%   ADCS-1 ATT Data
   Communications Services
AS6198   452  222  23050.9%   BNS-14 BellSouth Network
   Solutions, Inc
AS25844  244   16  22893.4%   SASMFL-2 Skadden, Arps, Slate,
   Meagher  Flom LLP
AS721715  510  20528.7%   DNIC DoD Network Information
   Center
AS6327   228   29  19987.3%   SHAWC-2 Shaw Communications
   Inc.
AS5668   393  200  19349.1%   CIH-12 CenturyTel Internet
   Holdings, Inc.

Total  16120 6204 991661.5%   Top 30 total


Possible Bogus Routes

24.138.80.0/20   AS11260 AHSICHCL Andara High Speed Internet c/o Halifax 
Cable Ltd.
24.246.0.0/17AS7018  ATTW ATT WorldNet Services
24.246.38.0/24   AS25994 NPGCAB NPG Cable, INC
24.246.128.0/18  AS7018  ATTW ATT WorldNet Services
64.46.4.0/22 AS11711 TULARO TULAROSA COMMUNICATIONS
64.46.27.0/24AS8674  NETNOD-IX Netnod 

Re: Intel calls for Internet overhaul

2004-09-10 Thread Rik van Riel

On Thu, 9 Sep 2004, Rachael Treu-Gomes wrote:

 And tunnels in tunnels in tunnels...

 I see some deep recursion fun here.

I can see some nice routing loops coming up, with packets for
tunnel endpoints being routed through the tunnel interface
itself, etc... ;)

Rik
-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it. - Brian W. Kernighan


Odd behavior from p4-0-0.MAR1.Austin-TX.us.xo.net

2004-09-10 Thread Scott McGrath


We are originating traffic from AS11 and we are seeing an apparent loop
downstream from the router listed in the header when attempting to connect
to rsync1.spamhaus.org.

Is this problem unique to us or are others seeing the same behavior.
Scott C. McGrath


Re: Spammers Skirt IP Authentication Attempts

2004-09-10 Thread Paul Vixie

  you could bet that by closing off this avenue, SPF will force
  spammers to use other methods that are more easily detected /
  filtered, and that if you play this catmouse game long enough, it
  will drive the cost of spam so high (or drive the volume benefit so
  low) that it'll just die out.
 
 Good summary. This is the right strategy.

on the contrary.  it has been a bad strategy and is still a bad strategy.

  but to me, SPF is just a way to rearrange the deck chairs on the
  Titanic.
 
 I can swim but I believe that the water under the Titanic was quite
 too cold to stay. Any advice to the people on the NANOG mailing list
 before the boat goes down?

the boat will never go all the way down -- the internet, and e-mail, are
survivable.  however, it will get very cold where you are, since you'll
be floating in atlantic icewater while clinging to floating wreckage.  if
that fate does not appeal to you, then embrace change.  specifically, the
kind of change that makes you cringe in fear because it is so alien.  i'm
referring to whitelists, webs of trust, trusted introducers, micropayments,
and bonding.  if you insist on an inbox that's open to all comers no matter
what their intentions or reputation, then get out your snorkle.


Re: Odd behavior from p4-0-0.MAR1.Austin-TX.us.xo.net

2004-09-10 Thread rwcrowe

The loop seems to be in AS 2828 (XO Communications) with router at 64.1.2.38.
--Rob Crowe [EMAIL PROTECTED]
-- Original message --We are originating traffic from AS11 and we are seeing an apparent loop  downstream from the router listed in the header when attempting to connect  to rsync1.spamhaus.org.   Is this problem unique to us or are others seeing the same behavior.  Scott C. McGrath 


Re: Odd behavior from p4-0-0.MAR1.Austin-TX.us.xo.net

2004-09-10 Thread Justin Ryburn

Looking at this now.

Justin Ryburn
Tier II Router Support
XO Communications

- Original Message - 
From: [EMAIL PROTECTED]
To: Scott McGrath [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Friday, September 10, 2004 12:10 PM
Subject: Re: Odd behavior from p4-0-0.MAR1.Austin-TX.us.xo.net


 The loop seems to be in AS 2828 (XO Communications) with router at
64.1.2.38.


 --
 Rob Crowe
 [EMAIL PROTECTED]


 -- Original message -- 

 
 
  We are originating traffic from AS11 and we are seeing an apparent loop
  downstream from the router listed in the header when attempting to
connect
  to rsync1.spamhaus.org.
 
  Is this problem unique to us or are others seeing the same behavior.
  Scott C. McGrath



OT: Anybody from RBC.com read this?

2004-09-10 Thread Alon Tirosh

Please contact me offlist. We're an account client of yours with
periodic trouble getting mail to you for almost a year now, and Id
like to get it resolved.


Weekly Routing Table Report

2004-09-10 Thread Routing Table Analysis

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 11 Sep, 2004

Analysis Summary


BGP routing table entries examined:  146736
Prefixes after maximum aggregation:   87224
Unique aggregates announced to Internet:  70017
Total ASes present in the Internet Routing Table: 18024
Origin-only ASes present in the Internet Routing Table:   15648
Origin ASes announcing only one prefix:7294
Transit ASes present in the Internet Routing Table:2376
Transit-only ASes present in the Internet Routing Table: 78
Average AS path length visible in the Internet Routing Table:   4.8
Max AS path length visible:  22
Prefixes from unregistered ASNs in the Routing Table:39
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space: 16
Number of addresses announced to Internet:   1337060260
Equivalent to 79 /8s, 177 /16s and 235 /24s
Percentage of available address space announced:   36.1
Percentage of allocated address space announced:   58.3
Percentage of available address space allocated:   61.9
Total number of prefixes smaller than registry allocations:   67256

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:28030
Total APNIC prefixes after maximum aggregation:   14146
Prefixes being announced from the APNIC address blocks:   26260
Unique aggregates announced from the APNIC address blocks:14223
APNIC Region origin ASes present in the Internet Routing Table:2133
APNIC Region origin ASes announcing only one prefix:633
APNIC Region transit ASes present in the Internet Routing Table:331
Average APNIC Region AS path length visible:4.8
Max APNIC Region AS path length visible: 22
Number of APNIC addresses announced to Internet:  161753472
Equivalent to 9 /8s, 164 /16s and 41 /24s
Percentage of available APNIC address space announced: 73.8

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
   23552-24575
APNIC Address Blocks   58/7, 60/7, 202/7, 210/7, 218/7, 220/7 and 222/8

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes: 83838
Total ARIN prefixes after maximum aggregation:51137
Prefixes being announced from the ARIN address blocks:64173
Unique aggregates announced from the ARIN address blocks: 22648
ARIN Region origin ASes present in the Internet Routing Table: 9534
ARIN Region origin ASes announcing only one prefix:3401
ARIN Region transit ASes present in the Internet Routing Table: 927
Average ARIN Region AS path length visible: 4.5
Max ARIN Region AS path length visible:  18
Number of ARIN addresses announced to Internet:   231930912
Equivalent to 13 /8s, 210 /16s and 252 /24s
Percentage of available ARIN address space announced:  69.1

ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106
   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,29695-30719, 31744-33791
ARIN Address Blocks24/8, 63/8, 64/6, 68/7, 70/7, 72/8, 198/7, 204/6,
   208/7 and 216/8

RIPE Region Analysis Summary


Prefixes being announced by RIPE Region ASes: 27170
Total RIPE prefixes after maximum aggregation:18966
Prefixes being announced from the RIPE address blocks:24008
Unique aggregates announced from the RIPE address blocks: 15815
RIPE Region origin ASes present in the Internet Routing Table: 5804
RIPE Region origin ASes announcing only one prefix:3120
RIPE Region transit ASes present in the Internet Routing Table: 996
Average RIPE Region AS path length visible: 5.4
Max RIPE Region AS path length visible:  21
Number of RIPE addresses announced to Internet:   170824000
Equivalent to 10 /8s, 46 /16s and 145 /24s
Percentage 

Re: Odd behavior from p4-0-0.MAR1.Austin-TX.us.xo.net

2004-09-10 Thread Justin Ryburn

This should be corrected now.  I still cannot ping the host in question but
I am guessing that spamhaus has ICMP filters on their stuff.  It is
definitely routing to the correct place now.  Our customer service
department is following up with the customer (spamhaus' provider) to make
sure they are seeing everything correctly.

Justin Ryburn
Tier II Router Support
XO Communications

- Original Message - 
From: Justin Ryburn [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; Scott McGrath [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Friday, September 10, 2004 12:42 PM
Subject: Re: Odd behavior from p4-0-0.MAR1.Austin-TX.us.xo.net



 Looking at this now.

 Justin Ryburn
 Tier II Router Support
 XO Communications

 - Original Message - 
 From: [EMAIL PROTECTED]
 To: Scott McGrath [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Sent: Friday, September 10, 2004 12:10 PM
 Subject: Re: Odd behavior from p4-0-0.MAR1.Austin-TX.us.xo.net


  The loop seems to be in AS 2828 (XO Communications) with router at
 64.1.2.38.
 
 
  --
  Rob Crowe
  [EMAIL PROTECTED]
 
 
  -- Original message -- 
 
  
  
   We are originating traffic from AS11 and we are seeing an apparent
loop
   downstream from the router listed in the header when attempting to
 connect
   to rsync1.spamhaus.org.
  
   Is this problem unique to us or are others seeing the same behavior.
   Scott C. McGrath




Qwest engineer?

2004-09-10 Thread andrew2

Sorry to bother the whole list with this...could someone involved in
routing at Qwest ping me offlist?

Thanks,

Andrew