Re: McAfee/ATT Issue

2009-02-18 Thread Kameron Gasso

Calhoun, Matthew wrote:

9   212 ms   200 ms * 12.118.225.22 Problem occurring here. 
Sometimes traffic gets through, sometimes it doesn't
10   29 ms26 ms26 ms  216.143.71.219
11   26 ms26 ms26 ms  www.mcafeeasap.com [208.69.153.135]


Looks a lot like that hop is rate-limiting ICMP to itself.  Everything 
beyond it seems to be good from the looks of it.


-Kam



RE: McAfee/ATT Issue

2009-02-18 Thread Justin Krejci
We've also seen that busy routers are slower to respond to requests directed
at them as opposed to traffic routing thru them which can continue to work
without issue or performance loss.

-Original Message-
From: Kameron Gasso [mailto:kgasso-li...@visp.net] 
Sent: Wednesday, February 18, 2009 12:03 PM
To: Calhoun, Matthew
Cc: NANOG list
Subject: Re: McAfee/ATT Issue

Calhoun, Matthew wrote:
 9   212 ms   200 ms * 12.118.225.22 Problem occurring
here. Sometimes traffic gets through, sometimes it doesn't
 10   29 ms26 ms26 ms  216.143.71.219
 11   26 ms26 ms26 ms  www.mcafeeasap.com [208.69.153.135]

Looks a lot like that hop is rate-limiting ICMP to itself.  Everything 
beyond it seems to be good from the looks of it.

-Kam




RE: McAfee/ATT Issue

2009-02-18 Thread Calhoun, Matthew
While I agree with all of your assessments, this traceroute was being provided 
to illustrate where traffic *appears* to be stopping when we are seeing the 
issue. It's intermittent, so some times we can reach the destination hosts (via 
HTTP, HTTPS, etc.) and sometimes we can't.

When we can reach the destination hosts (via HTTP), the traceroute completes
When we can't reach the destination hosts (via HTTP), the traceroute won't 
complete and the last hop is the host that I indicated in my previous post 
(12.118.225.22)

Thanks,
Matt

-Original Message-
From: Justin Krejci [mailto:jkre...@usinternet.com] 
Sent: Wednesday, February 18, 2009 11:15 AM
To: kga...@visp.net; Calhoun, Matthew
Cc: 'NANOG list'
Subject: RE: McAfee/ATT Issue

We've also seen that busy routers are slower to respond to requests directed
at them as opposed to traffic routing thru them which can continue to work
without issue or performance loss.

-Original Message-
From: Kameron Gasso [mailto:kgasso-li...@visp.net]
Sent: Wednesday, February 18, 2009 12:03 PM
To: Calhoun, Matthew
Cc: NANOG list
Subject: Re: McAfee/ATT Issue

Calhoun, Matthew wrote:
 9   212 ms   200 ms * 12.118.225.22 Problem occurring
here. Sometimes traffic gets through, sometimes it doesn't
 10   29 ms26 ms26 ms  216.143.71.219
 11   26 ms26 ms26 ms  www.mcafeeasap.com [208.69.153.135]

Looks a lot like that hop is rate-limiting ICMP to itself.  Everything
beyond it seems to be good from the looks of it.

-Kam




RE: McAfee/ATT Issue

2009-02-18 Thread Scott Weeks


--- mcalh...@iodatacenters.com wrote:
From: Calhoun, Matthew mcalh...@iodatacenters.com

While I agree with all of your assessments, this traceroute was being provided 
to illustrate where traffic *appears* to be stopping when we are seeing the 
issue. It's intermittent, so some times we can reach the destination hosts (via 
HTTP, HTTPS, etc.) and sometimes we can't.

When we can reach the destination hosts (via HTTP), the traceroute completes
When we can't reach the destination hosts (via HTTP), the traceroute won't 
complete and the last hop is the host that I indicated in my previous post 
(12.118.225.22)
-



It may be best to use tcptraceroute when it is and when it isn't working.  It 
may help you evaluate where the trouble is occurring more efficiently.

scott