- Test - lists.nanog.org

192.250.24.0/22 (as 23034) not reachable from Verizon, tinet, global crossing, XO
by Brock Massel 19 Sep '14

19 Sep '14

Hi folks, I'm hoping someone can shed some light on the situation. The 192.250.24 addresses have been reachable for several months in the current configuration with no reported issues. Since the 16th we have been hearing reports that destinations in that block are unavailable for some. Several looking glass' report network not in table. Can someone lend a hand? What is the best way to improve this situation? How do we find where the problem is? B

7 7

any suggestion for networktool
by Deric Kwok 19 Sep '14

19 Sep '14

Hi all Any tool can help to collect destination ip in graph for different location? eg: Germany Thank you so much

1 0

Moot thread: Scotland
by jamie rishaw 19 Sep '14

19 Sep '14

Nice exercise in what-ifs, but with 90% reporting and a ten point "No, thank you" majority, the decision to stay as one UK has clearly prevailed. ..Not that I'm up at 0240 Eastern to check on the vote of course. Source: BBC World News. -j -- jamie rishaw // .com.arpa@j <- reverse it. ish. "...let's consider this world like a family and care about each other..." -Malala Yousafzai

1 0

Re: [VoiceOps] ITFS Term vendor question
by Larry Sheldon 19 Sep '14

19 Sep '14

On 9/17/2014 16:59, Jay Ashworth wrote: > ---- Original Message ----- >> From: "Nick Crocker" <nick.crocker(a)gmail.com> > >> Can someone shed some light on how you might be accomplishing this, I have >> a hard time believing that customers are being told they cannot dial TF >> numbers in their own country. > > In the US, it's always been my understanding that what we call INWATS calls > are dipped *at the originating CO*, and the actual toll call across the > SS7/TDM backbone goes out using either the real 10D DN of the target line, > or some fake 10D that routes to the appropriate trunk group somehow at the > destination end. > > So it's not that unusual to me that a network that is interfacing at > Class 4, instead of Class 5, might be unable to originate calls to TF DNs. > > I admit to not being sure this is a worldwide view of the issue, as our > Wikipedian friends would say, though. I don't think I ever know the details of automatic TF routing, but I'm pretty sure that in California Zenith and Enterprise numbers were translated by R & R and sent collect. Zenith 9000 is the only exception I know of. Operator 25 (?) calls were just sent collect to the CB number. In-WATS was purchased for particular areas (rest-of-the-state, for example) and calls from a point not paid-for simply would not translate. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes.

1 0

upstream support for flowspec
by Daniel Corbe 18 Sep '14

18 Sep '14

I was perusing RFC5575 after reading a presentation that ALU did (presumably during some previous NANOG conference). Reference: https://www.nanog.org/sites/default/files/wed.general.trafficdiversion.sero… This seems like it would be a godsend for small operators like myself who don't have access to unlimited bandwidth and are put off by off-site scrubbing services. As far as I can tell though the only platforms that offer support are the 7750-SR and platforms made by Juniper. Is there anything in the air about widening the adoption base? Cisco? Brocade? And once that happens, what are the chances of services providers adopting this for their customers to make use of on as wide of a scale as (for example) blackhole community strings. I'd certainly *love* to have a way to mitigate an attack that doesn't involve me sacrificing one service on my network to save the rest. Best, Daniel

7 10

RE: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet, global crossing, XO
by Brock Massel 18 Sep '14

18 Sep '14

Karsten, Thank you I am not sure why those 702 and 19294 old entries would still be there. We have engaged 812 for help. Shall I assume cleaning up the old entries will solve the problems? -----Original Message----- From: Karsten Elfenbein [mailto:karsten.elfenbein@gmail.com] Sent: Thursday, September 18, 2014 5:46 PM To: Brock Massel Cc: nanog(a)nanog.org Subject: Re: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet, global crossing, XO Hi, looks like you mainly use one transit provider (AS812) or your other transit providers correctly filter that prefix. According to https://stat.ripe.net/data/prefix-routing-consistency/data.json?preferred_v… there is no route object for the 192.250.24.0/22. As a result the AS6453(TATA COMMUNICATIONS (AMERICA) INC) seemed to have started filtering the prefix from AS812. Which reduced the visibility of that prefix. Check the BGplay from the last days: https://stat.ripe.net/192.250.24.0%2F22#tabId=routing so create the correct route object and the prefix should come up over the next day(s) Also get the more specific route objects removed which point to other AS. 192.250.24.0/23 AS702 192.250.24.0/24 AS19294 Karsten 2014-09-18 22:42 GMT+02:00 Brock Massel <BMassel(a)descartes.com>: > Hi folks, > I'm hoping someone can shed some light on the situation. > > The 192.250.24 addresses have been reachable for several months in the current configuration with no reported issues. Since the 16th we have been hearing reports that destinations in that block are unavailable for some. > > Several looking glass' report network not in table. > > Can someone lend a hand? What is the best way to improve this situation? How do we find where the problem is? > > B

2 1

Re: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet, global crossing, XO
by Karsten Elfenbein 18 Sep '14

18 Sep '14

Hi, looks like you mainly use one transit provider (AS812) or your other transit providers correctly filter that prefix. According to https://stat.ripe.net/data/prefix-routing-consistency/data.json?preferred_v… there is no route object for the 192.250.24.0/22. As a result the AS6453(TATA COMMUNICATIONS (AMERICA) INC) seemed to have started filtering the prefix from AS812. Which reduced the visibility of that prefix. Check the BGplay from the last days: https://stat.ripe.net/192.250.24.0%2F22#tabId=routing so create the correct route object and the prefix should come up over the next day(s) Also get the more specific route objects removed which point to other AS. 192.250.24.0/23 AS702 192.250.24.0/24 AS19294 Karsten 2014-09-18 23:46 GMT+02:00 Karsten Elfenbein <karsten.elfenbein(a)gmail.com>: > Hi, > > looks like you mainly use one transit provider (AS812) or your other > transit providers correctly filter that prefix. > > According to https://stat.ripe.net/data/prefix-routing-consistency/data.json?preferred_v… > there is no route object for the 192.250.24.0/22. > As a result the AS6453(TATA COMMUNICATIONS (AMERICA) INC) seemed to > have started filtering the prefix from AS812. Which reduced the > visibility of that prefix. Check the BGplay from the last days: > https://stat.ripe.net/192.250.24.0%2F22#tabId=routing > > so create the correct route object and the prefix should come up over > the next day(s) > > Also get the more specific route objects removed which point to other AS. > > 192.250.24.0/23 AS702 > 192.250.24.0/24 AS19294 > > > > Karsten > > 2014-09-18 22:42 GMT+02:00 Brock Massel <BMassel(a)descartes.com>: >> Hi folks, >> I'm hoping someone can shed some light on the situation. >> >> The 192.250.24 addresses have been reachable for several months in the current configuration with no reported issues. Since the 16th we have been hearing reports that destinations in that block are unavailable for some. >> >> Several looking glass' report network not in table. >> >> Can someone lend a hand? What is the best way to improve this situation? How do we find where the problem is? >> >> B

1 0

Outbound traffic from 208.89.136.0/22 going from L.A. to London?
by Todd Lyons 18 Sep '14

18 Sep '14

I'm seeing some weird routing outbound for *some* destinations. Testing from 208.89.139.252. google.com resolves for me to 74.125.239.112 and the outbound path is fast and appears to stay in the US. yahoo.com resolves for me to 98.138.253.109, but the outbound path goes through Savvis London, then to BT, then to Yahoo. # mtr 98.138.253.109 --report --report-cycles 10 HOST: mail.mrball.net Loss% Snt Last Avg Best Wrst StDev ...internal... 5. gw.iv.ivenue.com 0.0% 10 2.7 2.7 2.6 2.8 0.1 6. 64.70.17.121 0.0% 10 2.8 3.8 2.8 11.5 2.7 7. hr2-v3007.la1.savvis.net 0.0% 10 2.8 22.9 2.8 203.1 63.3 8. 204.70.203.90 0.0% 10 4.0 4.3 3.8 5.6 0.5 9. cr1-pos-0-0-0-0.londonuk1.sa 0.0% 10 177.1 157.9 151.1 179.7 11.5 10. esr1-xe-7-0-0.ams.savvis.net 0.0% 10 166.5 166.4 166.3 166.5 0.1 11. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 12. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 13. ixp1-xe-11-0-0-0.us-ash.eu.b 80.0% 10 597.0 595.7 594.4 597.0 1.9 14. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 15. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 16. ae-5.pat1.nez.yahoo.com 90.0% 10 546.0 546.0 546.0 546.0 0.0 17. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 # mtr 98.138.253.109 -n --report --report-cycles 15 HOST: mail.mrball.net Loss% Snt Last Avg Best Wrst StDev ...internal... 5. 208.89.136.1 0.0% 15 2.6 2.7 2.6 2.9 0.1 6. 64.70.17.121 0.0% 15 2.8 8.9 2.8 57.5 16.2 7. 64.70.11.57 0.0% 15 2.8 2.9 2.8 3.2 0.1 8. 204.70.203.90 0.0% 15 4.4 5.4 3.7 23.5 5.0 9. 204.70.192.122 0.0% 15 151.2 154.7 151.1 172.9 7.0 10. 204.70.202.2 0.0% 15 166.4 168.8 166.3 202.7 9.4 11. ??? 100.0 15 0.0 0.0 0.0 0.0 0.0 12. 166.49.208.90 80.0% 15 508.3 507.2 505.9 508.3 1.2 13. 166.49.208.59 80.0% 15 589.8 589.8 588.9 590.6 0.9 14. ??? 100.0 15 0.0 0.0 0.0 0.0 0.0 15. 216.115.96.81 93.3% 15 521.8 521.8 521.8 521.8 0.0 16. ??? 100.0 15 0.0 0.0 0.0 0.0 0.0 17. 216.115.100.3 93.3% 15 537.4 537.4 537.4 537.4 0.0 18. 98.138.144.29 91.7% 12 537.1 537.1 537.1 537.1 0.0 19. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 20. 98.138.240.28 80.0% 5 537.9 537.9 537.9 537.9 0.0 21. ??? 100.0 4 0.0 0.0 0.0 0.0 0.0 22. 98.138.253.109 66.7% 3 537.9 537.9 537.9 537.9 0.0 Traffic served by Akamai appears to be fast and stays local (i.e. tested to www.apple.com) A call in to Savvis got attached to master ticket 4828052, which is for "large packet loss". Describes the symptom, not the cause. Is there anybody who has more info? Anybody who's a Savvis customer who sees the same weird outbound routing? Or are we the only ones? Feel free to traceroute to 208.89.139.252 to try and duplicate these results. ...Todd -- The total budget at all receivers for solving senders' problems is $0. If you want them to accept your mail and manage it the way you want, send it the way the spec says to. --John Levine

2 2

Re: [VoiceOps] ITFS Term vendor question
by Jay Ashworth 18 Sep '14

18 Sep '14

---- Original Message ----- > From: "Nick Crocker" <nick.crocker(a)gmail.com> > Can someone shed some light on how you might be accomplishing this, I have > a hard time believing that customers are being told they cannot dial TF > numbers in their own country. In the US, it's always been my understanding that what we call INWATS calls are dipped *at the originating CO*, and the actual toll call across the SS7/TDM backbone goes out using either the real 10D DN of the target line, or some fake 10D that routes to the appropriate trunk group somehow at the destination end. So it's not that unusual to me that a network that is interfacing at Class 4, instead of Class 5, might be unable to originate calls to TF DNs. I admit to not being sure this is a worldwide view of the issue, as our Wikipedian friends would say, though. Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

2 1

Re: Scotland ccTLD?
by Larry Sheldon 18 Sep '14

18 Sep '14

On 9/16/2014 18:57, Masataka Ohta wrote: > What will happen to ".uk" if England is left alone? > > Masataka Ohta There are still at least 3 countries left in the UK if Scotland splits. The name change is that in that event, Great Britain (.gb country-code Reserved Domain - IANA) will refer only to the land mass (which it should any way, but if often used to refer to the three kingdoms on it. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes.

7 6