Re: [VoiceOps] ITFS Term vendor question
In article 23734767.2066.1410991191470.javamail.r...@benjamin.baylink.com you write: Original Message - From: Nick Crocker nick.croc...@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. I was under the impression that the dip returns the IXC that handles the number, and the call goes out with the original number for the IXC to handle. The translation to POTS or whatever happens at the IXC's SCP. The SCP could reject the call if there's no route that matches the condition on the incoming call. (The number you are calling is not available from your area) There's a lot of 8xx processing that routes based on time of day or where the caller is or whichever call center is less busy. That would seem hard to do if the 8xx number were already translated. The originating CO often does the dip to get the 10D target for LNP, but that's different. Could someone who understands this better clarify?
Outbound traffic from 208.89.136.0/22 going from L.A. to London?
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%102.7 2.7 2.6 2.8 0.1 6. 64.70.17.121 0.0%102.8 3.8 2.8 11.5 2.7 7. hr2-v3007.la1.savvis.net 0.0%102.8 22.9 2.8 203.1 63.3 8. 204.70.203.90 0.0%104.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.0100.0 0.0 0.0 0.0 0.0 12. ??? 100.0100.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.0100.0 0.0 0.0 0.0 0.0 15. ??? 100.0100.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.0100.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%152.6 2.7 2.6 2.9 0.1 6. 64.70.17.121 0.0%152.8 8.9 2.8 57.5 16.2 7. 64.70.11.57 0.0%152.8 2.9 2.8 3.2 0.1 8. 204.70.203.90 0.0%154.4 5.4 3.7 23.5 5.0 9. 204.70.192.1220.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.0150.0 0.0 0.0 0.0 0.0 12. 166.49.208.9080.0%15 508.3 507.2 505.9 508.3 1.2 13. 166.49.208.5980.0%15 589.8 589.8 588.9 590.6 0.9 14. ??? 100.0150.0 0.0 0.0 0.0 0.0 15. 216.115.96.8193.3%15 521.8 521.8 521.8 521.8 0.0 16. ??? 100.0150.0 0.0 0.0 0.0 0.0 17. 216.115.100.393.3%15 537.4 537.4 537.4 537.4 0.0 18. 98.138.144.2991.7%12 537.1 537.1 537.1 537.1 0.0 19. ??? 100.0 50.0 0.0 0.0 0.0 0.0 20. 98.138.240.2880.0% 5 537.9 537.9 537.9 537.9 0.0 21. ??? 100.0 40.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
Re: Here comes iOS 8...
Hi, Do you have a reference? Someone just told me it is more around 5GB. It seems to depend on the device. IIRC my iPhone 4S downloaded ±0.9GB and my iPad Mini ±1.3GB. That might be because the 4S is still a 32-bit device. Cheers, Sander
Re: Outbound traffic from 208.89.136.0/22 going from L.A. to London?
The issue was seemingly fixed about 30 minutes ago, and has been confirmed to be fixed by multiple parties. Many thanks for the response Vincent. Have a fantastic day! ...Todd On Thu, Sep 18, 2014 at 2:30 AM, Vincent Aniello vanie...@portware.com wrote: We are seeing issues on our Savvis Internet connections in New York to users in London and Sweden. Not many details yet, just seeing slow and sporadic connectivity. --Vincent From:Todd Lyons tly...@ivenue.com To:NANOG list nanog@nanog.org Date:09/18/2014 05:21 AM Subject:Outbound traffic from 208.89.136.0/22 going from L.A. to London? Sent by:NANOG nanog-boun...@nanog.org 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%102.7 2.7 2.6 2.8 0.1 6. 64.70.17.121 0.0%102.8 3.8 2.8 11.5 2.7 7. hr2-v3007.la1.savvis.net 0.0%102.8 22.9 2.8 203.1 63.3 8. 204.70.203.90 0.0%104.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.0100.0 0.0 0.0 0.0 0.0 12. ??? 100.0100.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.0100.0 0.0 0.0 0.0 0.0 15. ??? 100.0100.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.0100.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%152.6 2.7 2.6 2.9 0.1 6. 64.70.17.121 0.0%152.8 8.9 2.8 57.5 16.2 7. 64.70.11.57 0.0%152.8 2.9 2.8 3.2 0.1 8. 204.70.203.90 0.0%154.4 5.4 3.7 23.5 5.0 9. 204.70.192.1220.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.0150.0 0.0 0.0 0.0 0.0 12. 166.49.208.9080.0%15 508.3 507.2 505.9 508.3 1.2 13. 166.49.208.5980.0%15 589.8 589.8 588.9 590.6 0.9 14. ??? 100.0150.0 0.0 0.0 0.0 0.0 15. 216.115.96.8193.3%15 521.8 521.8 521.8 521.8 0.0 16. ??? 100.0150.0 0.0 0.0 0.0 0.0 17. 216.115.100.393.3%15 537.4 537.4 537.4 537.4 0.0 18. 98.138.144.2991.7%12 537.1 537.1 537.1 537.1 0.0 19. ??? 100.0 50.0 0.0 0.0 0.0 0.0 20. 98.138.240.2880.0% 5 537.9 537.9 537.9 537.9 0.0 21. ??? 100.0 40.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 -- 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
upstream support for flowspec
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.serodio.10.pdf 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
Re: upstream support for flowspec
On Thu, 18 Sep 2014 13:53:52 -0400 Daniel Corbe co...@corbe.net wrote: Is there anything in the air about widening the adoption base? Cisco? Brocade? I've seen some suggesting that increased support, but even at Juniper, actions seem to speak larger than words. There seems to be very little interest for awhile now. However, I do know of some providers who use it, largely internal only. We also have tried a community flow-spec service, and more recently have been prototyping a community RTBH server with flow-spec capability (ping me off list if you want to hear more or see me at NANOG 62). A few people have recently told me they would like our community RTBH service via flow-spec instead of just BGP next hop, but really only one seemed seriously intent on configuring it day one. John
Re: upstream support for flowspec
On Thu, Sep 18, 2014 at 1:53 PM, Daniel Corbe co...@corbe.net wrote: 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. there are providers (verizon business, att, sprint, ntt at least) that provide mitigation via bgp update... which is equivalent to the blackhole community stuff, why not investigate those options? (or if you had, what was lacking?)
Re: upstream support for flowspec
Envoyé de mon iPhone Le 18 sept. 2014 à 19:53, Daniel Corbe co...@corbe.net a écrit : 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.serodio.10.pdf 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? Hi, I've submitted a request through my Brocade SE to support this, but it seems they are not interested about it. They claim their strategy is to achieve the same using SDN capabilities via OPENFLOW support. In the mean time, we are sitting ducks with our traditional technics. I read in an old NANOG thread (IIRC) that cisco was about to support this really soon on IOS-XR, but I am not 100% sur. Best regards. 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
Re: upstream support for flowspec
On (2014-09-18 13:53 -0400), Daniel Corbe wrote: Hi Daniel, 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. Cisco IOS-XR supports flowspec today as well. How much more would you pay per Mbps/month to have operator offer flowspec? IP transit is quite low margin product, supporting flowspec may have some adverse effects to business case: a) you're paying less, as you're not receiving the traffic b) operator may get more traffic, as attack does not yield desired outcome And when we look at the feature technically a) junos does not allow setting flowspec on in FW filters and then apply FW filter where you wish to do it, it's automatically turned on for all traffic transiting box. This may be undesirable. b) by default junos accepts all flowspec actions, such as diverting traffic to new IP or new VRF. This may cause undesirable security issues. c) added feature == added complexity == reduced availability -- ++ytti
Re: upstream support for flowspec
Saku Ytti s...@ytti.fi writes: On (2014-09-18 13:53 -0400), Daniel Corbe wrote: Hi Daniel, 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. Cisco IOS-XR supports flowspec today as well. How much more would you pay per Mbps/month to have operator offer flowspec? IP transit is quite low margin product, supporting flowspec may have some adverse effects to business case: a) you're paying less, as you're not receiving the traffic This ventures into the realm of an operator doing something responsible to protect me vs routing me unwanted traffic and going lol, bill. If you want to start playing that game, I'm happy to pay more per mbit of traffic if you're happy to guarantee me that you won't route me traffic that I'm expressly uninterested in. b) operator may get more traffic, as attack does not yield desired outcome Not necessarily true. If I can identify and push malicious traffic towards your edge, then you can do the same towards your peers. If I can ask you to filter by source, can you turn around and do so by source *AND* destination? You know what I'm announcing, so it seems like this ought to be possible. Short of that, it would require us to be in a trust relationship and I can see how that would be problematic. If we circle back around to paying a premium for the service, then I'm going to expect you to absorb the attack on my behalf. And when we look at the feature technically a) junos does not allow setting flowspec on in FW filters and then apply FW filter where you wish to do it, it's automatically turned on for all traffic transiting box. This may be undesirable. b) by default junos accepts all flowspec actions, such as diverting traffic to new IP or new VRF. This may cause undesirable security issues. c) added feature == added complexity == reduced availability -Daniel
Re: upstream support for flowspec
Also, if I'm buying full line rate commit from you then you're not actually losing any money on the deal whether or not you route me the traffic. -Daniel Daniel Corbe co...@corbe.net writes: Saku Ytti s...@ytti.fi writes: On (2014-09-18 13:53 -0400), Daniel Corbe wrote: Hi Daniel, 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. Cisco IOS-XR supports flowspec today as well. How much more would you pay per Mbps/month to have operator offer flowspec? IP transit is quite low margin product, supporting flowspec may have some adverse effects to business case: a) you're paying less, as you're not receiving the traffic This ventures into the realm of an operator doing something responsible to protect me vs routing me unwanted traffic and going lol, bill. If you want to start playing that game, I'm happy to pay more per mbit of traffic if you're happy to guarantee me that you won't route me traffic that I'm expressly uninterested in. b) operator may get more traffic, as attack does not yield desired outcome Not necessarily true. If I can identify and push malicious traffic towards your edge, then you can do the same towards your peers. If I can ask you to filter by source, can you turn around and do so by source *AND* destination? You know what I'm announcing, so it seems like this ought to be possible. Short of that, it would require us to be in a trust relationship and I can see how that would be problematic. If we circle back around to paying a premium for the service, then I'm going to expect you to absorb the attack on my behalf. And when we look at the feature technically a) junos does not allow setting flowspec on in FW filters and then apply FW filter where you wish to do it, it's automatically turned on for all traffic transiting box. This may be undesirable. b) by default junos accepts all flowspec actions, such as diverting traffic to new IP or new VRF. This may cause undesirable security issues. c) added feature == added complexity == reduced availability -Daniel
Re: upstream support for flowspec
On Thu, Sep 18, 2014 at 03:15:41PM -0400, Daniel Corbe wrote: Also, if I'm buying full line rate commit from you then you're not actually losing any money on the deal whether or not you route me the traffic. Ha, I wish all customers would buy in full line rate commits! :-) - Job
Re: upstream support for flowspec
On Thu, Sep 18, 2014 at 03:12:29PM -0400, Daniel Corbe wrote: a) you're paying less, as you're not receiving the traffic This ventures into the realm of an operator doing something responsible to protect me vs routing me unwanted traffic and going lol, bill. If you want to start playing that game, I'm happy to pay more per mbit of traffic if you're happy to guarantee me that you won't route me traffic that I'm expressly uninterested in. Would you be willing to pay for the traffic _not_ delivered to you because of customer-pushed ACLs? If so, that would take the argument away because we filter we can't bill. Would you be willing to pay a premium to be able to do so? Is it worth a premium to insert ACLs in real time in the upstream's network or is a 2 hour delay acceptable? what about 5 minute delay? Aside from practical issues with flowspec as Ytti mentioned already, I don't think the market has yet figured out how stuff like this should work and become cost-effective. Kind regards, Job
Re: upstream support for flowspec
On 9/18/14 1:19 PM, Job Snijders wrote: On Thu, Sep 18, 2014 at 03:12:29PM -0400, Daniel Corbe wrote: a) you're paying less, as you're not receiving the traffic This ventures into the realm of an operator doing something responsible to protect me vs routing me unwanted traffic and going lol, bill. If you want to start playing that game, I'm happy to pay more per mbit of traffic if you're happy to guarantee me that you won't route me traffic that I'm expressly uninterested in. Would you be willing to pay for the traffic _not_ delivered to you because of customer-pushed ACLs? If so, that would take the argument away because we filter we can't bill. Would you be willing to pay a premium to be able to do so? Is it worth a premium to insert ACLs in real time in the upstream's network or is a 2 hour delay acceptable? what about 5 minute delay? It's not really a question we have to ask. Managed firewall services have way higher margins then pure IP transit. By extension dropping packets can be substantially more profitable especially on a per packet or byte basis then delivering them. Not everyone wants that service however. Aside from practical issues with flowspec as Ytti mentioned already, I don't think the market has yet figured out how stuff like this should work and become cost-effective. Ah cost effective is a consideration, yeah that is a bit of a bummer. Kind regards, Job signature.asc Description: OpenPGP digital signature
192.250.24.0/22 (as 23034) not reachable from Verizon, tinet, global crossing, XO
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
Re: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet, global crossing, XO
On Thu, Sep 18, 2014 at 08:42:23PM +, Brock Massel wrote: 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. Which ones? Can someone lend a hand? What is the best way to improve this situation? How do we find where the problem is? Do you have a pingable IP address in the range which is problematic? That would help others who are willing to debug your issue enormously. Kind regards, Job
Re: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet, global crossing, XO
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. Visible from here (AS 2116, Norway). Do you have a pingable IP address in the range which is problematic? That would help others who are willing to debug your issue enormously. 192.250.24.1 and 192.250.24.2 (for example) are pingable from 2116. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet, global crossing, XO
On Thu 2014-Sep-18 23:08:55 +0200, sth...@nethelp.no sth...@nethelp.no wrote: 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. Visible from here (AS 2116, Norway). Do you have a pingable IP address in the range which is problematic? That would help others who are willing to debug your issue enormously. 192.250.24.1 and 192.250.24.2 (for example) are pingable from 2116. Steinar Haug, Nethelp consulting, sth...@nethelp.no Same from AS 19171 (Canada). Shows up in all our transits and the IPs Steinar noted are pingable and traceable. We're currently reaching it through 577 812 23034. All our transits are showing the route through 812 (Rogers). -- Hugo Slabbert Stargate Connections - AS19171
RE: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet, global crossing, XO
-Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of sth...@nethelp.no Sent: Friday, 19 September 2014 9:09 a.m. To: bmas...@descartes.com; j...@instituut.net Cc: nanog@nanog.org Subject: Re: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet, global crossing, XO 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. Reachable from New Zealand - 192.250.24.0/24*[BGP/170] 02:42:04, MED 0, localpref 90 AS path: 4826 174 812 23034 I, validation-state: unverified to 175.45.102.9 via ae1.526 64 bytes from 192.250.24.1: icmp_seq=0 ttl=242 time=193.274 ms 64 bytes from 192.250.24.1: icmp_seq=1 ttl=242 time=196.312 ms 64 bytes from 192.250.24.1: icmp_seq=2 ttl=242 time=197.578 ms
Re: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet, global crossing, XO
Pingable from Montreal area as well Gary Baribault Courriel: g...@baribault.net GPG Key: 0x685430d1 Fingerprint: 9E4D 1B7C CB9F 9239 11D9 71C3 6C35 C6B7 6854 30D1 On 09/18/2014 05:08 PM, sth...@nethelp.no wrote: 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. Visible from here (AS 2116, Norway). Do you have a pingable IP address in the range which is problematic? That would help others who are willing to debug your issue enormously. 192.250.24.1 and 192.250.24.2 (for example) are pingable from 2116. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: Here comes iOS 8...
FWIW ... http://techcrunch.com/2014/09/18/ios-8-adoption-off-to-a-slower-start-than-ios-7-say-multiple-usage-trackers/
Re: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet, global crossing, XO
Hum, Traceroute is not as nice traceroute to 192.250.24.1 (192.250.24.1), 30 hops max, 60 byte packets 1 GW (192.168.0.2) 0.459 ms 0.435 ms 0.422 ms 2 * * * 3 10.170.182.81 (10.170.182.81) 18.417 ms 18.711 ms 18.702 ms 4 216.113.124.126 (216.113.124.126) 16.611 ms 17.774 ms 17.774 ms 5 216.113.122.74 (216.113.122.74) 45.746 ms 46.035 ms 46.025 ms 6 144.232.7.250 (144.232.7.250) 44.529 ms 45.507 ms 45.178 ms 7 be3013.ccr21.ord03.atlas.cogentco.com (154.54.10.37) 38.741 ms 35.537 ms 37.036 ms 8 24.156.159.153 (24.156.159.153) 31.433 ms 32.658 ms 29.417 ms 9 24.156.144.177 (24.156.144.177) 34.106 ms 32.621 ms van58-10-228-225.dynamic.rogerstelecom.net (209.148.228.225) 30.299 ms 10 24.156.144.126 (24.156.144.126) 30.339 ms 30.329 ms 30.055 ms 11 24.153.4.185 (24.153.4.185) 32.955 ms 34.112 ms 34.146 ms 12 gi-3-0-0.agw02.hrnr.phub.net.cable.rogers.com (24.153.7.82) 30.935 ms 32.375 ms 32.356 ms 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * 206.186.1.10 (206.186.1.10) 37.869 ms Gary Baribault Courriel: g...@baribault.net GPG Key: 0x685430d1 Fingerprint: 9E4D 1B7C CB9F 9239 11D9 71C3 6C35 C6B7 6854 30D1 On 09/18/2014 05:08 PM, sth...@nethelp.no wrote: 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. Visible from here (AS 2116, Norway). Do you have a pingable IP address in the range which is problematic? That would help others who are willing to debug your issue enormously. 192.250.24.1 and 192.250.24.2 (for example) are pingable from 2116. Steinar Haug, Nethelp consulting, sth...@nethelp.no
RE: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet, global crossing, XO
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.elfenb...@gmail.com] Sent: Thursday, September 18, 2014 5:46 PM To: Brock Massel Cc: nanog@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_version=0.7resource=192.250.24.0%2F22 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 bmas...@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
BGP per-flow load balancing between eBGP and iBGP learned prefix
Hello, I have a Load Balancer that uses a default route to a VRRP IP hosted between two Juniper MX80 routers. Each MX router has a single BGP feed from the same provider and each session is currently receiving only a default route. I'd like to load balance my outbound traffic across the two links. More specifically I want to balance traffic to a particular prefix across the two links so even if i was receiving full routes trying to manually split prefixes to a second upstream VRRP instance wouldn't help. I believe the typical way to do this would be to run an IGP between the LB and the MX's so that each MX advertises a default route to the LB and let ECMP take care of it. I'm not averse to this long term, but I have a short term need and the LB requires a license to participate in an IGP. Is there another way? I should note that the LB will not let me enter multiple default or identical static routes so I can't try spinning up a second VRRP session and adding a second default route on the LB to it. Is it possible to let BGP do the load balancing? From what I can tell this would be trivial if both of the provider links were terminated on the same router via a few multipath config lines but because they are on different routers I seem to be running into the eBGP iBGP Path selection criteria which prevents the routes from being equal. I appreciate any ideas! regards, -andy
Re: Scotland ccTLD?
On 16/09/2014 16:26, Jay Ashworth wrote: What kind of timeframe would a new ccTLD for a major country roll out on? The main issue wouldn't be the timeframe for a rollout of a Scottish ccTLD but rather the disengagement from the .UK ccTLD. The legislative part will take time and there might also be an issue about the contract to operate the registry being put out to tender. It might definitely be a question of months and these things can drag on. In the event of a Yes vote in the independence referendum, most of Scotland's domain name footprint will still be .UK orientated. That would be very slow to change and the new ccTLD would begin to operate in parallel with that. That .SCOT gTLD could end up being very lucky as it might just fill a niche in a market where there is no serious competition from a local official ccTLD. Regards...jmcc -- ** John McCormac * e-mail: j...@hosterstats.com MC2* web: http://www.hosterstats.com/ 22 Viewmount * Domain Registrations Statistics Waterford * And Historical DNS Database. Ireland* Over 396 Million Domains Tracked. IE * web: http://newgtldnews.com **
RE: Here comes iOS 8...
Depending on the device used, the zip file can range from Length: 1515061530 (1.4G) [application/octet-stream] To Length: 2119504233 (2.0G) [application/octet-stream] Parsed from http://mesu.apple.com/assets/com_apple_MobileAsset_SoftwareUpdate/com_apple_MobileAsset_SoftwareUpdate.xml -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Grant Ridder Sent: Wednesday, September 17, 2014 1:34 PM To: n...@flhsi.com Cc: NANOG Subject: Re: Here comes iOS 8... For those that are curious, it looks like the download is 1.1 gigs. -Grant On Wed, Sep 17, 2014 at 10:04 AM, Nick Olsen n...@flhsi.com wrote: I've been waiting all morning. Expedited repair of a primary link to prepare for the traffic. Not that it didn't have multiple backups. But one doesn't trifle with IOS8 release traffic.. If it's anything like IOS7 was.. Nick Olsen Network Operations (855) FLSPEED x106 From: Zachary McGibbon zachary.mcgibbon+na...@gmail.com Sent: Wednesday, September 17, 2014 12:59 PM To: NANOG nanog@nanog.org Subject: Here comes iOS 8... So Apple is about to release iOS 8... Have you done anything special to your network setup to accommodate the traffic flood ie traffic shaping rules, cache servers, etc? I heard that Apple Caching servers won't work with this update, so I'm guessing it will be pushed through Akamai servers as is usually is. - Zachary The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender or send back to retu...@agoc.com and delete the material from any computer.
IP Geolocation Issue
Hi, Im new here, so any advice would be very appreciated. Is someone from Maxmind IP Geolocation available, that I can talk to offline? Its regarding to a block we assigned to a client. The client and its customers are located in Mexico but the IP Geolocation services says they are located in Brazil. Thanks for your help. [damian cantu]
Re: Here comes iOS 8...
The download was ~1.1GB, the installer requires almost 5GB free to proceed. Tyler. On 9/17/14 9:04 PM, JoeSox wrote: Grant, Do you have a reference? Someone just told me it is more around 5GB. -- Later, Joe On Wed, Sep 17, 2014 at 10:31 AM, Grant Ridder shortdudey...@gmail.com wrote: For those that are curious, it looks like the download is 1.1 gigs. -Grant On Wed, Sep 17, 2014 at 10:04 AM, Nick Olsen n...@flhsi.com wrote: I've been waiting all morning. Expedited repair of a primary link to prepare for the traffic. Not that it didn't have multiple backups. But one doesn't trifle with IOS8 release traffic.. If it's anything like IOS7 was.. Nick Olsen Network Operations (855) FLSPEED x106 From: Zachary McGibbon zachary.mcgibbon+na...@gmail.com Sent: Wednesday, September 17, 2014 12:59 PM To: NANOG nanog@nanog.org Subject: Here comes iOS 8... So Apple is about to release iOS 8... Have you done anything special to your network setup to accommodate the traffic flood ie traffic shaping rules, cache servers, etc? I heard that Apple Caching servers won't work with this update, so I'm guessing it will be pushed through Akamai servers as is usually is. - Zachary
Re: Outbound traffic from 208.89.136.0/22 going from L.A. to London?
We are seeing issues on our Savvis Internet connections in New York to users in London and Sweden. Not many details yet, just seeing slow and sporadic connectivity. --Vincent From: Todd Lyons tly...@ivenue.com To: NANOG list nanog@nanog.org Date: 09/18/2014 05:21 AM Subject:Outbound traffic from 208.89.136.0/22 going from L.A. to London? Sent by:NANOG nanog-boun...@nanog.org 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%102.7 2.7 2.6 2.8 0.1 6. 64.70.17.121 0.0%102.8 3.8 2.8 11.5 2.7 7. hr2-v3007.la1.savvis.net 0.0%102.8 22.9 2.8 203.1 63.3 8. 204.70.203.90 0.0%104.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.0100.0 0.0 0.0 0.0 0.0 12. ??? 100.0100.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.0100.0 0.0 0.0 0.0 0.0 15. ??? 100.0100.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.0100.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%152.6 2.7 2.6 2.9 0.1 6. 64.70.17.121 0.0%152.8 8.9 2.8 57.5 16.2 7. 64.70.11.57 0.0%152.8 2.9 2.8 3.2 0.1 8. 204.70.203.90 0.0%154.4 5.4 3.7 23.5 5.0 9. 204.70.192.1220.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.0150.0 0.0 0.0 0.0 0.0 12. 166.49.208.9080.0%15 508.3 507.2 505.9 508.3 1.2 13. 166.49.208.5980.0%15 589.8 589.8 588.9 590.6 0.9 14. ??? 100.0150.0 0.0 0.0 0.0 0.0 15. 216.115.96.8193.3%15 521.8 521.8 521.8 521.8 0.0 16. ??? 100.0150.0 0.0 0.0 0.0 0.0 17. 216.115.100.393.3%15 537.4 537.4 537.4 537.4 0.0 18. 98.138.144.2991.7%12 537.1 537.1 537.1 537.1 0.0 19. ??? 100.0 50.0 0.0 0.0 0.0 0.0 20. 98.138.240.2880.0% 5 537.9 537.9 537.9 537.9 0.0 21. ??? 100.0 40.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
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_version=0.7resource=192.250.24.0%2F22 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.elfenb...@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_version=0.7resource=192.250.24.0%2F22 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 bmas...@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
Re: 192.250.24.0/22 (as 23034) not reachable from Verizon, tinet, global crossing, XO
The more specific objects are more cosmetic issue. The main problem is the missing object for your /22. As well as your AS23034 does not seem to be listed in AS-ROGERS:AS-CUSTOMERS http://bgp.he.net/AS812#_irr Karsten 2014-09-18 23:54 GMT+02:00 Brock Massel bmas...@descartes.com: 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.elfenb...@gmail.com] Sent: Thursday, September 18, 2014 5:46 PM To: Brock Massel Cc: nanog@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_version=0.7resource=192.250.24.0%2F22 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 bmas...@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
Re: upstream support for flowspec
On 9/18/14 11:06 AM, John Kristoff wrote: On Thu, 18 Sep 2014 13:53:52 -0400 Daniel Corbe co...@corbe.net wrote: Is there anything in the air about widening the adoption base? Cisco? Brocade? I've seen some suggesting that increased support, but even at Juniper, actions seem to speak larger than words. There seems to be very little interest for awhile now. However, I do know of some providers who use it, largely internal only. afaik from some previous experience it was hard to know a-priori which flow-spec route insertion was going to cause aberrant performance on the juniper platforms we were using. That's kinda ok if you use them since at least you can be aware of and revert that if it proves to be a problem. but it's kind of handing your customer a loaded gun. We also have tried a community flow-spec service, and more recently have been prototyping a community RTBH server with flow-spec capability (ping me off list if you want to hear more or see me at NANOG 62). A few people have recently told me they would like our community RTBH service via flow-spec instead of just BGP next hop, but really only one seemed seriously intent on configuring it day one. John signature.asc Description: OpenPGP digital signature
Re: [VoiceOps] ITFS Term vendor question
On 9/17/2014 16:59, Jay Ashworth wrote: Original Message - From: Nick Crocker nick.croc...@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.
RE: IP Geolocation Issue
I would suggest starting with this form: https://www.maxmind.com/en/correction More here: http://nanog.peeringdb.com/index.php/GeoIP Frank -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jose Damian Cantu Davila Sent: Wednesday, September 17, 2014 5:18 PM To: nanog@nanog.org Subject: IP Geolocation Issue Hi, Im new here, so any advice would be very appreciated. Is someone from Maxmind IP Geolocation available, that I can talk to offline? Its regarding to a block we assigned to a client. The client and its customers are located in Mexico but the IP Geolocation services says they are located in Brazil. Thanks for your help. [damian cantu]
Re: BGP per-flow load balancing between eBGP and iBGP learned prefix
On Sep 16, 2014, at 10:33 PM, Andy Litzinger andy.litzinger.li...@gmail.com wrote: I appreciate any ideas! My idea mainly centers around the operational complexity and difficulty of troubleshooting a setup of this nature. Why not just let routing take its natural course? Or at most, play some simple preference games which have consistent outcomes? This kind of thing is generally far more trouble than it's worth, in my experience. -- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Equo ne credite, Teucri. -- Laocoön
Re: BGP per-flow load balancing between eBGP and iBGP learned prefix
On Fri, Sep 19, 2014 at 12:23 AM, Roland Dobbins rdobb...@arbor.net wrote: On Sep 16, 2014, at 10:33 PM, Andy Litzinger andy.litzinger.li...@gmail.com wrote: I appreciate any ideas! My idea mainly centers around the operational complexity and difficulty of troubleshooting a setup of this nature. yes, this. Why not just let routing take its natural course? Or at most, play some simple preference games which have consistent outcomes? I think he's only getting default from his provider(s), which is a shame, get full routes instead and then play the preferences off...(I think). This kind of thing is generally far more trouble than it's worth, in my experience. this, yes. -- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Equo ne credite, Teucri. -- Laocoön
