Has anybody hired Cisco for their NOS (Network Optimization Services)? I would like to hear about your experience (good or bad). I'm particularly interested in their CNC box. Bryant.
On Wed, Feb 18, 2009 at 3:51 PM, Bryant Valencia <bvlmv5@gmail.com> wrote:
Has anybody hired Cisco for their NOS (Network Optimization Services)? I would like to hear about your experience (good or bad). I'm particularly interested in their CNC box.
Either this is merely exquisite acronym collision, or someone from marketing was been slamming too much www.drinknos.com and reading about botnets on the FUNSEC list. As for the service, one of my old clients has been engaging Cisco for some years now for a variety of needs. The reports are, in their subjective use, basically positive. My opinion is simply that it's a formalization of stuff Cisco has been doing for years. That is, doing the good engineering and planning work that many organizations are not (for any number of reasons) doing themselves. When it comes to the sale of box A, B, and C, (where the value of the set is not obvious to, say, a rural co-op ILEC management team) a vendor providing 'staff embedded' engineering can easily be a determining factor in winning or losing. -Tk
We are seeing intermittent connectivity issues via AT&T to McAfee's Update service network (208.69.152.0/21). Attempts to contact McAfee Support and AT&T support have gotten standard responses. If there is a McAfee Net Admin on list, maybe you can initiate a ticket with AT&T? We've got several downstream customers that are being affected by the issue. 3 3 ms 3 ms 2 ms iodc-69-71-48-2.ioconnect.net [69.71.48.2] 4 3 ms 3 ms 3 ms 12.89.121.177 5 26 ms 25 ms 25 ms cr1.phmaz.ip.att.net [12.123.206.138] 6 26 ms 25 ms 25 ms cr1.dlstx.ip.att.net [12.122.28.181] 7 26 ms 26 ms 27 ms tbr1.dlstx.ip.att.net [12.122.18.138] 8 25 ms 25 ms 25 ms gar4.dlstx.ip.att.net [12.123.16.97] 9 212 ms 200 ms * 12.118.225.22 <--------Problem occurring here. Sometimes traffic gets through, sometimes it doesn't 10 29 ms 26 ms 26 ms 216.143.71.219 11 26 ms 26 ms 26 ms www.mcafeeasap.com [208.69.153.135] Thanks, Matt Calhoun i/o Data Centers
On Feb 18, 2009, at 9:58 AM, Calhoun, Matthew wrote:
We are seeing intermittent connectivity issues via AT&T to McAfee's Update service network (208.69.152.0/21). 9 212 ms 200 ms * 12.118.225.22 <--------Problem occurring here. Sometimes traffic gets through, sometimes it doesn't 10 29 ms 26 ms 26 ms 216.143.71.219 11 26 ms 26 ms 26 ms www.mcafeeasap.com [208.69.153.135]
Richard Steenbergen did an excellent presentation at NANOG 45 on interpreting traceroutes. The final hop here looks quite healthy in terms of latency and packetloss. http://www.nanog.org/meetings/nanog45/abstracts.php?pt=MTE4NSZuYW5vZzQ1&nm=nanog45 Kris
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 ms 26 ms 26 ms 216.143.71.219 11 26 ms 26 ms 26 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
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-lists@visp.net] Sent: Wednesday, February 18, 2009 12:03 PM To: Calhoun, Matthew Cc: NANOG list Subject: Re: McAfee/AT&T 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 ms 26 ms 26 ms 216.143.71.219 11 26 ms 26 ms 26 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
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:jkrejci@usinternet.com] Sent: Wednesday, February 18, 2009 11:15 AM To: kgasso@visp.net; Calhoun, Matthew Cc: 'NANOG list' Subject: RE: McAfee/AT&T 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-lists@visp.net] Sent: Wednesday, February 18, 2009 12:03 PM To: Calhoun, Matthew Cc: NANOG list Subject: Re: McAfee/AT&T 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 ms 26 ms 26 ms 216.143.71.219 11 26 ms 26 ms 26 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
participants (6)
-
Anton Kapela -
Bryant Valencia -
Calhoun, Matthew -
Justin Krejci -
Kameron Gasso -
kris foster