Cisco NOS

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.

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

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.

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