Working with 2 other carriers on a similar issue, response I rec'd was congestion due to automated political dialers. Not sure if I believe that or not... -Keith -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of David Hubbard Sent: Tuesday, November 07, 2006 12:32 PM To: nanog@merit.edu Subject: Verizon PSTN continued The thread yesterday didn't seem to get into much detail; I'm wondering if anyone knows more about what is going on with Verizon? Our PSTN service with XO seems to be affected again by what XO claims is a Verizon problem but they wouldn't elaborate on why they feel that to be the case; I was just amazed to even get someone on the phone at XO since normally they are unreachable. I am inclined to partially believe them since I've found other numbers that I know to be with other carriers that are not working. XO claimed this was at least a regional issue of Verizon's that is affecting multiple carriers. David
On Tue, 7 Nov 2006, Wallace Keith wrote:
Working with 2 other carriers on a similar issue, response I rec'd was congestion due to automated political dialers. Not sure if I believe that or not...
you'd think they'd have systems monitoring that and trimming down the 'fat'? or can they do that? (legally I mean, sorta like QOS for the phone network I suppose)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris L. Morrow wrote:
On Tue, 7 Nov 2006, Wallace Keith wrote:
Working with 2 other carriers on a similar issue, response I rec'd was congestion due to automated political dialers. Not sure if I believe that or not...
you'd think they'd have systems monitoring that and trimming down the 'fat'? or can they do that? (legally I mean, sorta like QOS for the phone network I suppose)
- ------------------------ I guess it depends on the type of VoIP deployment. http://www.softarmor.com/wgdb/docs/draft-camarillo-sipping-sbc-funcs-02.txt regards, /virendra -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFUX0VpbZvCIJx1bcRAqUQAKCwfwsszTIAkMeEtwp0J4g5CxrVIACfYqjD WNcHEZDbB1o344Ck6h91bbk= =b/hK -----END PGP SIGNATURE-----
On Tue, 7 Nov 2006, Chris L. Morrow wrote:
Working with 2 other carriers on a similar issue, response I rec'd was congestion due to automated political dialers. Not sure if I believe that or not...
you'd think they'd have systems monitoring that and trimming down the 'fat'? or can they do that? (legally I mean, sorta like QOS for the phone network I suppose)
They can, and do. But SS7 interconnect battles between carriers are about as much fun as peering battles between ISPs, lots of finger pointing and blustering and more lawyers. If you lose SS7 links between carriers, and there is not enough SS7 capacity remaining, the SS7 systems start "flapping" (the SS7 folks probably use a different term, but it gives the IP folks some idea of what happens). It has happened a few times. I expect the SS7 vendors and protocol wizards are thinking up more clever ways to address it. It has nothing (essentially) to do with the type of calls being made, although high call volumes always make any problem worse. Another time it happened was just before Christmas a few years ago, during peak shopping time and the dialup credit card authorization numbers (and lots of other types of numbers) got jammed up during a SS7 incident as I found out doing my Christmas shopping that afternoon.
At around 1345 Central it was brought to my attention that we had lost access to a number of websites out on the 'net... Two big-name examples are Oracle, which has our development team screaming for my blood. The other that's come to light as well is, of course, Yahoo... which means the rest of the userbase hates me. Traceroutes like the two below for Oracle generally die after one of Sprint's routers or its peer with Level3. I've already opened a case with SprintLink's broadband group and the tech I've spoken to said that there have been an influx of calls about routing/website availability problems, but nothing had been identified inside Sprint yet. Just curious if anybody else is seeing this sort of action. -------- jolsen@mcp [/export/home/jolsen] $ traceroute www.oracle.com traceroute: Warning: Multiple interfaces found; using 10.2.2.230 @ ce0 traceroute to www.oracle.com (141.146.8.66), 30 hops max, 40 byte packets 1 core2-vlan1.obt.devry.edu (10.2.2.1) 0.407 ms 0.278 ms 0.265 ms 2 obtfw-virtual.obt.devry.edu (10.2.1.10) 1.413 ms 2.380 ms 2.400 ms 3 * * 205.240.70.2 (205.240.70.2) 5.209 ms 4 * * sl-gw32-chi-6-0-ts3.sprintlink.net (144.232.205.237) 10.738 ms 5 * sl-bb21-chi-4-2.sprintlink.net (144.232.26.33) 14.616 ms 32.739 ms 6 sl-bb20-chi-14-0.sprintlink.net (144.232.26.1) 16.901 ms 33.400 ms 27.028 ms 7 sl-st20-chi-12-0.sprintlink.net (144.232.8.219) 42.269 ms 6.190 ms 3.835 ms 8 * 209.0.225.21 (209.0.225.21) 9.971 ms 148.152 ms 9 * * * 10 * * * 11 * * * 12 * * * -- and -- root@opnvw1p [/usr/local/sbin] # ./tcptraceroute www.oracle.com 80 Selected device ge0, address 10.2.2.4 for outgoing packets Tracing the path to www.oracle.com (141.146.8.66) on TCP port 80 (http), 30 hops max 1 10.2.2.1 (10.2.2.1) 0.289 ms 0.224 ms 0.208 ms 2 10.2.1.10 (10.2.1.10) 1.547 ms 1.502 ms 1.218 ms 3 205.240.70.2 (205.240.70.2) 2.555 ms 5.551 ms 6.408 ms 4 sl-gw32-chi-6-0-ts3.sprintlink.net (144.232.205.237) 4.120 ms 8.185 ms 6.024 ms 5 sl-bb21-chi-4-2.sprintlink.net (144.232.26.33) 5.470 ms 3.884 ms 6.889 ms 6 sl-bb20-chi-14-0.sprintlink.net (144.232.26.1) 8.851 ms 7.624 ms 5.671 ms 7 sl-st20-chi-12-0.sprintlink.net (144.232.8.219) 7.913 ms 7.283 ms 7.427 ms 8 209.0.225.21 (209.0.225.21) 4.730 ms 6.033 ms 7.925 ms 9 * * * 10 * * * 11 * * *
On 11/9/06, Olsen, Jason <jolsen@devry.com> wrote:
At around 1345 Central it was brought to my attention that we had lost access to a number of websites out on the 'net... Two big-name examples are Oracle, which has our development team screaming for my blood. The other that's come to light as well is, of course, Yahoo... which means the rest of the userbase hates me. Traceroutes like the two below for Oracle generally die after one of Sprint's routers or its peer with Level3. I've already opened a case with SprintLink's broadband group and the tech I've spoken to said that there have been an influx of calls about routing/website availability problems, but nothing had been identified inside Sprint yet.
Just curious if anybody else is seeing this sort of action.
Sprint has been made aware of the issue, as has Level3. Matt
--------
jolsen@mcp [/export/home/jolsen] $ traceroute www.oracle.com traceroute: Warning: Multiple interfaces found; using 10.2.2.230 @ ce0 traceroute to www.oracle.com (141.146.8.66), 30 hops max, 40 byte packets 1 core2-vlan1.obt.devry.edu (10.2.2.1) 0.407 ms 0.278 ms 0.265 ms 2 obtfw-virtual.obt.devry.edu (10.2.1.10) 1.413 ms 2.380 ms 2.400 ms 3 * * 205.240.70.2 (205.240.70.2) 5.209 ms 4 * * sl-gw32-chi-6-0-ts3.sprintlink.net (144.232.205.237) 10.738 ms 5 * sl-bb21-chi-4-2.sprintlink.net (144.232.26.33) 14.616 ms 32.739 ms 6 sl-bb20-chi-14-0.sprintlink.net (144.232.26.1) 16.901 ms 33.400 ms 27.028 ms 7 sl-st20-chi-12-0.sprintlink.net (144.232.8.219) 42.269 ms 6.190 ms 3.835 ms 8 * 209.0.225.21 (209.0.225.21) 9.971 ms 148.152 ms 9 * * * 10 * * * 11 * * * 12 * * *
-- and --
root@opnvw1p [/usr/local/sbin] # ./tcptraceroute www.oracle.com 80 Selected device ge0, address 10.2.2.4 for outgoing packets Tracing the path to www.oracle.com (141.146.8.66) on TCP port 80 (http), 30 hops max 1 10.2.2.1 (10.2.2.1) 0.289 ms 0.224 ms 0.208 ms 2 10.2.1.10 (10.2.1.10) 1.547 ms 1.502 ms 1.218 ms 3 205.240.70.2 (205.240.70.2) 2.555 ms 5.551 ms 6.408 ms 4 sl-gw32-chi-6-0-ts3.sprintlink.net (144.232.205.237) 4.120 ms 8.185 ms 6.024 ms 5 sl-bb21-chi-4-2.sprintlink.net (144.232.26.33) 5.470 ms 3.884 ms 6.889 ms 6 sl-bb20-chi-14-0.sprintlink.net (144.232.26.1) 8.851 ms 7.624 ms 5.671 ms 7 sl-st20-chi-12-0.sprintlink.net (144.232.8.219) 7.913 ms 7.283 ms 7.427 ms 8 209.0.225.21 (209.0.225.21) 4.730 ms 6.033 ms 7.925 ms 9 * * * 10 * * * 11 * * *
"Centralised switching guarantees QOS!" Keep saying it and it might be true! On 11/9/06, Sean Donelan <sean@donelan.com> wrote:
On Tue, 7 Nov 2006, Chris L. Morrow wrote:
Working with 2 other carriers on a similar issue, response I rec'd was congestion due to automated political dialers. Not sure if I believe that or not...
you'd think they'd have systems monitoring that and trimming down the 'fat'? or can they do that? (legally I mean, sorta like QOS for the phone network I suppose)
They can, and do. But SS7 interconnect battles between carriers are about as much fun as peering battles between ISPs, lots of finger pointing and blustering and more lawyers. If you lose SS7 links between carriers, and there is not enough SS7 capacity remaining, the SS7 systems start "flapping" (the SS7 folks probably use a different term, but it gives the IP folks some idea of what happens). It has happened a few times. I expect the SS7 vendors and protocol wizards are thinking up more clever ways to address it.
It has nothing (essentially) to do with the type of calls being made, although high call volumes always make any problem worse. Another time it happened was just before Christmas a few years ago, during peak shopping time and the dialup credit card authorization numbers (and lots of other types of numbers) got jammed up during a SS7 incident as I found out doing my Christmas shopping that afternoon.
participants (7)
-
Alexander Harrowell -
Chris L. Morrow -
Matthew Petach -
Olsen, Jason -
Sean Donelan -
virendra rode // -
Wallace Keith